I had to switch jobs 9 months ago, because my ex-boss almost got bancrupt because of the World Economic Crisis, so he was unable to pay me anymore. It took some research in the job market. Took me 2 months to choose what to do next. I’ve been jack-of-all-trades IT, support, programmer, manager, etc. Never been a QA in my life, so when the guys from Telco System called, I’ve said to myself “Why not? Never been a QA in my life.” 

Ever wondered what the QAs are actually doing? I’ve done some research before the interview. The top google picks were around the so called Standard ISO 9001 for quality. Not telling much about what is expected from me to do. Not a single diagram what’s what. Not a single test plan to see an example. I’ve been a bit unprepared on the interview but managed well 😉
I am writing this artice, so anyone in future searching “How to” or “What is” QA to have some ideas in his mind on what exactly is QA and how to live with it.

Introduction.

Software development and testing is done in some few overlapping steps, some of them lead to others, while some of them take the whole process back to the workbench to rewrite from scratch. It sometimes takes 3 months for a feature to enter the Development cycle and exit as a qualified and approved for publishing or selling to the customer.

If you ever managed to look in this process while working as an IT or developer, you already know how many bugs are coded. Statistics gathered by leading development companies say that the code initially has at least 10 defects per ~500 lines or 20-25 bugs per KLOC (Kilo Lines Of Code) and every few fixes raise another (new) bug. By looking in the diagram you can say that the process is not straight forward. You may get a bug back for development and the developers can make a fix and take it back for you to analyze and retest. At least that is what an SQA team is doing. Testing, analyzing and providing feedback on the bugs found.

Quality vs quantity.

Every bug has it’s own weight and severity. If a bug is very severe (a critical one that can’t be left because the feature is actualy not working) that bug is served from the development team with highest priority. Cosmetic bugs (e.g. a misspelling or a typo in the interface) can be always served later. The product/feature is ready when all major bugs are resolved and all the visible minor bugs are taken care of.

However, if the QA team focuses on catching all the minor bugs and missing even one severe bug, the whole process will be tainted and meaningless.

Automation.

The minor bugs can be found by automated testing software that is developed solely for this purpose. There is rarely any ready-out-of-the-box testing suite, so most of the companies have a QA developers that work on the test automation itself. Automated testing catches most of the minor bugs and provides “sanity” for a future testing. e.g If the system does not boot with the newly compiled software – future testing is obviously not sane. This minor version gets back to the developers for a review and recompilation.

There are very good script languages able to login remotely to a testing unit, apply new configuration and check results such as TCL, Python, Perl and others.

The QA job is to actually run the automated tests on every minor release and check if all the basics are working.

Manual testing.

That’s the bread and butter of this profession. For every new feature there must be a new test plan written. The test plan consist of test cases. By definition any test case should test only one aspect of the feature or only one of its parameters. A few steps example:

1. Configure VLAN Id 200 on port 1/1/1
2. Check that the running device configuration has the line.
3. Configure out of range [1..4095] VLAN ID .
4. Check that error message pops up.
5. Check that the running device configuration does not have the line.

The QA job is to design a good plan stretching to all the feature parameters and options and write test cases for every and each one of them. Test cases can be either just a parameter chec, negative check or mixed as this one. The good test plan has all the checks and the negative cases possible.

Some examples of the above can be found in specific QA forums, but the information is scarce because every product has it’s own testing strategies and some of the information regarding the testing or the product, can be also well protected secret.

Interested? Than keep reading.