Testing as well as development has it’s part in problem solving and puzzle solving activities on daily basis. It will be naive to think that the devs only have that ability. Of course, we can not compare the job that a dev would do in creating an efficient and fast algorithm for operating big amounts of data or machine learning algorithm, but we testers need to do some puzzle solving as well. And if a tester believes that the QA jobs is simply define test cases and execute them accordingly with product development, he or she is wrong.
Creating test cases.
I bet many of the professionals in IT, including developers, testers and project managers, share the belief that writing a test case is simple – you have the specifications, you know or might easily guess what functionalities should be implemented, so it just seems easy as childs play to write test cases for it. The only true part in this assumption is, yes writing test cases is pretty basic, or at least not writing but creating them, thinking of complicated scenario where you could compromise quality. The term “writing” is not exactly correct, that’s a way to simulate activity in front of your manager, so he/she wont think you’re sitting there scratching your balls all day long. Creating complicated test scenarios and executing test plans has nothing to do with writing them down, nor the opposite. If you’ve written 10000 test cases for an application it doesn’t mean you did a good job, it doesn’t mean you did even the half of the job, in fact it doesn’t even mean you did anything about the product’s quality. To me it just means you spend a lot of time writing instead of testing.
So, how to write test cases, then? That’s where puzzle solving comes in handy and why I believe it is a core skill every QA should have. I think I will spend the time to split that into a whole new topic, but in couple of words I could put it really simple:
- Just as in programming. attack the task to be tested in a clever, not in a methodical way – try to tackle it with style and less effort, instead of brute-forcing it by writing billions of test cases.
- Don’t overcomplicate your test scenarios.
- Don’t double tests – for example when testing values, use boundary value analysis, but imputing numbers from the same range just to have that 1 more test is a total waste.
- Try to get to the root of the test situation. Many times for similar tasks application use the same background logic, which means one fault in a more generic class of code might lead to more than one defect in the derived classes. Normally, testers would say that this is developers work, but to be more effective it’s wise if we try to do that for them or at least give them the proper direction where to look at. This would be better for team’s overall performance and will show to your colleagues that you know more than just functional testing, through the UI.
As you could see it’s more brains in writing test cases than just functional testing. There is puzzle solving in creating test cases and it’s you that has to solve it.
When automation testing is involved and nowadays it’s almost always involved, the puzzle solving and problem solving abilities are put to the test as much as every regular developer’s. I mentioned many times that to me all testers are developers as well, doesn’t matter if performing automated or manual tests. Creating the tests themselves is a development task, some might say this is quite an easy task or trivial task, and I will answer to you, yes, that’s why we have dedicated people to do it, because they know the difference.
If you want me to put it in the more literal way, testers writing automated scripts and automated tests in any programming language face the same issues as any dev:
- Creating the best abstraction for your testing framework – in the OOP world, normally you want to apply some level of inheritance, polymorphism and other OOP buzzwords over your tests instead of copy-pasting the same stupid code over and over again.
- Doing the above without overcomplicating your architecture – normally we are talking big projects here. As we know object oriented programming isn’t too big deal to learn, as design it’s created to simplify stuff and make them more human understandable. The true power of OOP is to use it in an efficient way, and the biggest challenge is to do it in an elegant manner, not using complicated design patterns that noone has ever heard of and by this to screw things up.
- Write error free code – as you could imagine, writing code to do tests isn’t way different than writing code for an application, meaning you could write buggy tests and false logic. That could seriously harm your performance and steal from your time, if you consider that it’s a bug in the code of the developer, but it’s in fact in your own.
- Resources for performance testing – this applies mainly for performance testing and it’s quite a weird one, you need good performance in order to test performance. I will say it in other words, let’s say you want to test how your app’s login page under load of 1000000 requests using the Apache Jmeter, for example. This is not easily done with a single PC, you can’t generate so much traffic with a single node. That’s where you have to decide if you will use some sort of clustering or cloud services, and when you start talking about cloud a business person kicks in and says it’s too expensive and so on and so on… as I said, a good challenge for your problem solving skills. It’s one of the cases you have to optimize not only your code but the resources you are given as well.
As we see the QA profession offers enough tasks that might challenge your problem solving or puzzle solving skills. And this is not just a “good to have”, it’s a must. Any professional in the software testing area should be aware that testing includes a lot of problem solving, a lot of strange problems to solve, a lot of reverse engineering if you want to put it this way – that’s when you have to predict what something does, without being able to look inside it. So testing is not a routine job, it’s not just stating the obvious and clicking on the user interface to find defects, there’s a lot of complexity.
Please feel free to comment and share the article if you liked it. I will be happy to see you next time for the last article of the series.