How to get a suitable test approach
At first, what is a test approach and why does it need to be suitable?
You could imagine that tests are tests and they consist in executing some business cases.
Then you will think that this is a suitable approach because you will be convinced, you personally that the system work.
But are you sure that other people will have the same way of using this software? Did you test all cases? Then you will have a doubt if someone ask for you to say « OK, we release it to the operations » !
Yes in fact, the way you proceeded is good, but if you want to test all use cases, it will take time, it will cost a lot because you need to test on all operational environments all cases, screen behaviors, and then there is a risk at the end that your software is anymore useful for the users because they are using a new version of software by a competitor, or because users have lost their job because they could not work without the software you are developing.
Then a good approach for you, is to use a test structured approach to imagine a suitable test approach. Like a checklist can help you to not forget some topics, a test structured approach helps you to write and discuss all relevant information to write a test strategy.
Which are the testing goals and objectives? Imagine that you order a new house. You explain your requirement to an engineer. When the house is built, you validate the house and check if it meets your needs. Does it look nice?, Is it easy to use, to switch on and off the lights ?
But before you do that, other people need to test during the project.
The design documents have to be reviewed and discussed, the materials have to be tested, the way they have been integrated has also to be tested and at each time a task is done, it has to be tested also. When the house is almost finished, a completed review of the house has to be done by the engineers to check if you, the customer, will be satisfied with the house.
This is the same for a software component. A test structured approach explains you
the different testing levels along the project and their objectives,
the different product risks, the different quality characteristics which are important for the customer (functionalities, security, performances, usability), for the operations (robustness, security, reliability), for the development (Maintainability).
How to do a risk analysis with the PRA methodology
the testing techniques that have to be used,
the documentation needed to explain your strategy and for reporting,
the tools which can be used
the environments needed to represent the field
How to calculate the costs, the duration of the tests, the size of the testing teams for the different phases of a testing process (planning and control, preparation, test specification, implementation and execution, completion)
When you need to test
Who are the stakeholders, testers, managers, users, and all people who will be involved in testing activities? Which are the different roles of a tester. Also a test structured approach helps you to identify project risks like risks about communication. People must get and give the correct and useful information. Testers must know what is their role, what they have to do, and what the others will do.
To imagine a suitable strategy, you need
To have a global picture of the lifecycle and of the processes of the organization.
To have a test structured approach available to get information when needed
To get the customer needs, functional and non functional requirements.
You identify the main quality risks using the PRA methodology.(including business risks, operation and development risks) to get complexity and criticality of the functions.
You evaluate the testing cost to get funds and time for testing.
You prepare the Master test plan based on the global testing policy and strategy and complete it by iteration
You meet each responsible for each test level and discuss with him about what he will test (depending on business risks and complexity to realize), on which environments and after the meeting you update the MTP and see another responsible (Development for component testing, integration, operations, business). For example, you explain what is “integration”, system integration, and what kind of white or black box tests you can perform to test interoperability. Or again, you explain what the component tests are and define the level of coverage needed.
You update the Master test Plan and present it to the whole stakeholders (and their team if possible)
The master test plan will give the global picture of the tests and inform people on who do testing activities and when. On complex projects, stakeholders have to understand what they have to do, their testing objectives and how they interact with other people.
The customer has to understand that the quality of the product depends on its requirements and on a quality control along the development lifecycle. On Agile projects, a testing approach is also important for the release and also for the iterations (sprints).
Then you can implement the MTP in smaller test plans like Level test plans and then detail the functionalities, features to be tested. This level test plan is important for the tester to identify the tests that he has to perform, techniques he has to use, how deep he has to design its tests.
In all cases, having a suitable testing strategy means also having an effective communication between stake holders and the customer.