So, I was reading a blog called Awesome Testing the other day, (really clever name, I know, it’s what caught my attention) and I saw a whole section of pages titled “TestOps”. Intrigued, I ventured further by reading the posts, which led me to the initial blog post that coined the term, by Seth Elliot. The short and sweet of it is that originally testing can be represented by this diagram:
The tests are created, they are run on the system, the results are obtained, the results are checked against the ‘oracle’, and an assessment is completed. However, the interesting thing is the current trend in software products. The most popular products now a days are not simple programs, but are actually services. Facebook, Amazon, Twitter, etc. With this new change, testing becomes a bit more different. Big Data concepts are used, new features are tested with exposure control and monitors. This becomes the new model:
The testing system becomes a whole architecture testers are serviced with maintaining and using. This whole post was incredibly interesting to me. As someone new to Software Testing, my experience up until now has been discrete test cases and suites. With TestOps however, testing becomes a whole new beast. Using Big Data techniques to test how well a service is doing, not just if it runs correctly was a definite surprise. As someone who is currently dipping their toes into Big Data as I take a Software Quality Assurance course, I didn’t expect the areas to meet like this.
The final paragraphs of the post describing how this development is also blurring the lines between tester and developer is exciting. There was the worry in the back of my head, that software testing and development were two divided areas. That one had to choose one or the other. But knowing how much they will intermingle in the present and future helps alleviate this to a great extent.
It also makes a large amount of sense. As the software being tested becomes much more dynamic, testing must as well. Not just testing if software is working, but working well is quite the interesting distinction that requires more complicated solutions. These tests will require a process similar to software development to create. Choosing the right kind of Architecture, using tools similar to software process management tools to cut down on the time QA requires to make new tests or change existing ones, and the continuous updates and integration.
The incredibly interesting blog post can be found here: https://dojo.ministryoftesting.com/lessons/the-future-of-software-testing-part-two
The original blog post that sent me to it: http://www.awesome-testing.com/2016/07/testops-missing-piece-of-puzzle.html
Fu's Faulty Functions 