Serving the method

In a discussion with a fellow tester we talked about testing effort. The situation was deliverance of certain request for changes. It contained functionality of which the persons who wrote the functional designs claimed it hadn't that much impact. The users who were involved also claimed it can be tested intensively spending several days or just the main things accepting risks.

There were also users involved which had their own history with the system. They wanted to test the system based on their experience from the past.
The fellow tester admits there might be more options to test which the others didn’t think about. He based that idea on the method he has been thought. From theory, he might be right. He also used the arguments based on the method. One of the main arguments was: the quality must be right and optimal. To claim this we should spend a lot of test effort.

In the discussion it was not about who has right and who is wrong it was about the effort needed and if it was valid to use a test method as argument for the direction.

When people are discussing, there are several views. As the fellow tester doesn’t blog I can only present my view.

In my opinion the following points were important
- No discussion was needed as the changes were important, it was forced by top management;
- End date was fixed due to management decision;
- Resources for test execution was available because of importance;
- Resources and quality of documentation to derive test cases using test techniques was not sufficient available;
- System was available;
- Support from development and business was sufficient;
- Solutions would be delivered in time and on time, just before the deadline;
- Time was left to follow phases from TMap, no time left to identify and cover all risks;
- Knowledge of application managers and business was more important to select test cases then the documentation and test techniques;
- Cost of not delivering was larger the solving after implementing on production.

When looking to a method like TMap, it wouldn't be possible to implement a solution on productive system as not enough proven information was provided about the risks. No defined and measured coverage was made visible. Requirements were too poor. No test techniques were selected and used which were mentioned in the method. Still we made it to deliver successfully to productive system.