It is very likely you‘ll meet a lot of opposition when you give opinions like ‘this is not good enough to go live’. In test reporting it is strongly recommended to stick to the facts. Do test reporting periodically (e.g. every 2 weeks). This will give valuable information to other project parties. It is said that a software project is like driving on a long, dark road and testing provides the headlights. It is very likely that testing is the only party in the project organisation that has a clear view on the real progress of the project. Share this knowledge!
You might consider these chapters in your Test Report:
Progress reporting
Here you give a view on the statuses of the different test levels / sub projects for the entire project (helicopter view)
This includes:
– Status of Test preparation
- – Progress of test preparation
- – Number of tests per Sub Project
– Status Test execution: Here you can show progress by giving percentages and figures regarding:
- the number of tests that have been executed
- The number of executed tests that have passed or failed the test
If you use the this method method you’ll have this already in the Project View. Other test management tools all have similar views (See details in Testing Project View.xls ).
Download Testing Project View.xls (password: osst)
Defects reporting
Here you can see the status of the reported bugs
– Open defects for the different Sub Projects
– Total open defects per priority
– Total open defects per detail status (reported, ready to test, accepted)
If you use the this method you’ll find a summary of the reported defect statuses for every SubProject. At the same time you’ll find the number of ‘Show stoppers’.
Refer Project_view_test_execution_example.xls (password: osst) for above templates.
If you like more detail in the Project View.xls on the other priority statuses (Major, Minor, Nice to have), just add them to the Project View.
Workload estimates
Here you can give an estimate on the workload that is to be expected for testing in a certain period ahead (e.g. 2 weeks)
This can help you to define the risk of not having enough time to test before going live
– Issues you can include
– Workload for test preparation and review activities
– Workload for test execution
Risks
This is a summary of all the issues that can slow down / obstruct the progress of testing.
This might include:
– a planning that is to tightly (e.g. not enough time reserved for testing)
– lack of information (e.g. analysis documents not delivered on time)
– people not available (e.g. illness of key tester, no testers found, …)
– Later than planned delivery of the application by IT
Recent Comments