Potential Future Traps

After the last post my mind has been on the future of software testing, but after a week or so it’s taken a bit of a journey and now I’m wondering about my future in software testing. And as it usually does when I think of the future, negativity is on the forefront. Which is why potential pitfalls are something I’m really interested in. So wonderfully, I found a helpful post on Awesome Testing listing possible software testing traps and describing them. The ‘traps’ in this case are mistaken implementations or uses of software testing that lead to very unfortunate results, based on the authors own experiences and what he has read or discussed with others.

It is incredibly interesting seeing the ways companies mistakenly attempt to optimize use of testers. Rating them on the amount of bugs found or incentivizing them to find as many bugs as possible only were issues that seem obviously awful to me, but I have hindsight on my side. A good amount of the traps were something I didn’t consider, issues with not having developers do any testing themselves. By leaving only testers as the ones to run tests and do quality assurance, it led to developers using testers being turned into scapegoats for issues or testers becoming a commodity that is moved around too often to do their job correctly.

Trap number three shows the human side of the process, to me at least. If testers make bad tests and have to constantly fix them, or the tests offer very little information due to their issues, then developers become disillusioned with them. It becomes safer and more likely for the tests to become more and more ignored. Software testing is not just finding bugs in programming, it must do so reliably and in a way that aims for improvement. Developers and testers are also not asĀ  clear cut as one would think. Or they shouldn’t be, at least.

I feel much more confident now knowing many of the issues that one can accidentally fall into in the process of software creation and testing, and how to possibly avoid them. I also found the idea of testing not simply being about finding bugs, but just a part of a greater system working towards an end goal of a wonderful software product insightful. It is incredibly useful to understand the full Software Engineering Life-Cycle no matter where your job lands on it.


The Future of Testing Taking An Interesting Turn

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

What’s Up World!

First Post of the blog! Exciting stuff.

The main focus for now is going to be Quality Assurance and Software Testing. The faulty functions in question are hopefully not going to be ones I myself create.

The picture is actually really symbolic, by the way. Let’s see if the Anteater symbolizes me and the blog or if the glass does.