Reasons to Consider Software Testing as Difficult Task
Software testing begins from idea and never ends.
Quality assurance is not about bugs, it is not about tests and it is not about testers. We can not define software testing as separate task. A lot of people will be involved in QA (even not QA people). Developers, Product Managers, Customers even your office manager and stuff in your office is a part of QA process. Sometimes as member of Quality Assurance department you should prove your value to your employer. Do not be afraid because your task (software testing) is indeed very important and difficult. A lot of people even think that QA is redundant and all they need is just to have good customers support. Well.. I will not buy something on internet if their web application crashes every time. So in this article we will try to help testers with finding reasons for employers or just to raise their value in their minds.
I do not need QA. My program will work without QA.
Let's do some reverse logic. If QA is easy task then why do we need it? It does not matter why you need your program and how it is difficult. You or your customers will not be happy to see broken program and you developers will not be happy that you (as employer) will be angry. So any program need QA because without it there is 99% chance that program will not work properly.
Why developers can not do QA stuff?
You may think that their job is too expensive to do "QA" and I can not give you answer "Yes" or answer "Not". Yes sure Developers spent a lot of time on education and their $/hour is a bit higher than QA have. But to be honest Dev that doing QA tasks it is same as QA doing Dev tasks in scope of quality. Allow each person to do what he should do. Developers can not think as customers. Developers usually do just their separate part (front-end, back-end etc.). So developers will not see full picture and will miss a lot of bugs.
Ok. We need QA. But why software testing is a difficult task?
To answer this question we should take a look on problems which QA department usually tries to solve.
Every bug should be described well but if someone outside of QA can not understand why it is a bug then it is communication problem. Every QA member should be able to prove his point of view. Resolving a lot of communication problems every day allow to gain experience and allow QA member to avoid them all in the future.
Dividend and quotient
Positive checks, negative checks, regression, sanity, random checks. When and what QA should do and what is priority of each action are very important questions. Each QA member should understand his estimates and what he is doing and why. It is not so easy sometimes but good established process has great impact on whole project
Integration in all levels
Every tester should be able to imagine whole picture of their program. It is like gray-box testing. QA member should understand all process at certain level. Tester should be a half-developer, half-customer, half-product manager etc. in order to understand critical places in the system. So looking on the same situation from different angle is some sort of art.
If some requirement was not mentioned by Product team it does not mean that it was their fault. It was actually their fault but it will be shown as QA members did not spot this opportunity and they did not investigate this question.
If some requirement was mentioned but developers understood it incorrectly and developed it is not their fault. It is fault of testers that they did not discuss this in more detailed way with developers and product managers. So whatever was done in the project in most cases QA members will take responsibility. And it is OK because QA is the pre-last station before final destination - angry customers.
Another problem is correct covering. Tests take time and time is money. It is hard to find golden rule. The main goal here is to find the best ways to test maximum by using minimum resources. It is not possible to find all bugs but QA should try to check all possible use-cases and only then to test edge-cases. What is use case and what is not is question to product managers (communication problem).
QA department should know their estimates and should be able to set up priorities for testing. It is very important that non of QA members will not have any functional to test because he did his job and devs were not developed next job for him. Every QA member should be involved in process. So planning is important part of process and priorities helps to determinate importance of each check which leads up to stability in whole process. Knowing priority of each task will also help with all other problems such as responsibility, covering etc.
Luck Testing is not gambling so "Luck" here is not just random chance. Sometimes critical and even blocker bugs may be found by surprise checks. No one expected to see those bugs in such preconditions but tester adjusted his six sense and found them. So "Luck" here is related to experience and that's why it is part of our list.
Testing is not gambling so "Luck" here is not just random chance. Sometimes critical and even blocker bugs may be found by surprise checks. No one expected to see those bugs in such preconditions but tester adjusted his six sense and found them. So "Luck" here is related to experience and that's why it is part of our list.
So if you want to earn money try to not spend it on something that you do not need. But QA is not in the list of such unnecessary things. Pay for QA and remember that it is not such easy task as you thought before.