Sometimes testers make some assumptions, but hopefully they avoid them. This series of posts will show you some well-known pitfalls and assumptions that tester make. This second post describes is about responsibilities.
Assumption: The developer has performed all the technical checks
In my opinion it’s the task of the developers to perform all the technical checks. Unfortunately daily business shows us that many defects aren’t found during development testing. (Clemens Reijnen has several post about testing for developers) The developers goal is to prove the software works properly.
The goal of a tester is give insight in the quality of the application. If needed a tester has to prove the software doesn`t work as expected. The goal of a test expert is not to break the software, however this is the motivation most testers have.
Talk with the developers in your project team to understand them and to know who they are and what they do. After knowing who a developer is you can discuss what is in his scope and what`s in yours. (I think you can write a separate post about this topic, maybe in the future)
Assumption: The business will test the complete application
This isn’t the truth, there are reasons the business will not test the total application.
They test what they need, not every person needs the complete application. That means they only test the part of the application that will affect their daily processes.
Most of the time during an user acceptance test they will accept the software, the result from this is that they test the happy flow. The happy flow is mostly a short path through the application without. Not all the possible exceptions are part of their test cases.
Assumption: They business knows all the exceptions and they’ll test them.
As you gueseds this assumption isn’t true for several reasons. Of course often does the business know the exceptions that are in the application, for example in the business rules or constraints. But the people that will test during the User Acceptance Test are not always a correct representation of the organization. For example, not all roles in the process are selected, or sometimes people are just available in the organization so they can do the UAT.
It is also possible that they forget some exceptions. What do you do with these forgotten things?
Assumption: The test strategy is accepted, that’s the only thing we do
If you want to be out of business very quickly I would suggest this approach. If the project is constantly changing and you’re rigid in the things you do, you don`t have an added value that is needed to successfully accomplish the project.
Be aware for the changes in the infrastructure, think about the scope of the project. But also the role stakeholders will have in the project or the always changing risks that are caused by unexpected incidents.
In a lot of projects is the lead time for test executing is under pressure. With this pressure some test cases can`t be executed. You have to redefine what you will test and what not.
Tips: How to handle in this situation
What to do with these things, some practical tips:
- Be focused at changes of scope or responsibilities, if needed change your test strategy during the project.
- Ask for an overview of the test cases the developers did. With this overview you get insight in what is tested and what`s not.
- Do some coordination of the UAT now you can trace what test cases are done and what part of the application is covered.
- Be sure all exception are covered, you can avoid this in an early stage with evaluating the requirements for example.
This is not an extensive list but a few tips you can use to help you cope with these falsely made assumptions