Some Pointers to Planning
Submitted by Stevan Zivanovic on Mon, 25/07/2005 - 15:56.
test management
A common theme that I have come across when coming onto client sites is that people cannot tell me why they are testing what they are. If I am lucky, the reply is that it is identified in the Test Plan. When I look at the Test Plan however, I tend get 20 to 30 pages of hard work that still does not tell me what and why people are testing.
Now I am not planning on re-analysing the IEEE 829 template test plan. This is a great document and can assist greatly. However I want to look at the overall purpose and necessity to plan. Regardless of the overall development methodology, e.g. SCRUM or Waterfall, some time needs to be spent defining the approach to testing.
All good development starts off with a plan, whether that is a story board within Agile or detailed specifications in the highly formalised project, the same applies to testing. To do good, relevant and appropriate testing requires some careful thinking. Good questions to ask and to try to define are:
• What is the system I am testing?
This relates to the software, the infrastructure and any related systems/applications. Try drawing a schematic of the system you will be testing, showing what software will sit on which piece of hardware and how these connect to other applications.
• How am I going to test this?
What approach am I going to use? Am I using exploratory testing, test driven design, validation or any other approach or mix of approaches. This can help highlight issues around having the right resources to support the activities, including people and skills.
• What is the purpose of my testing?
Am I trying to ensure that this safety critical system is fit to fly? Is to confirm that an application is stable enough to go for a demo somewhere? More fundamentally, what do my customers, the business, require from me? Depending on the response to this will determine the depth and rigour required.
• What will I test for?
By answering the questions above and then using whatever knowledge of the system is available, you can start to highlight key areas that need testing. This could start as a list of key risk areas, features, scenarios or even test techniques (e.g. I know I need to do some performance testing, but I don’t know quite what I need testing yet).
By answering these questions and communicating them to others, significant improvements can made very rapidly in clarifying and defining clearly to all the stakeholders what testing is required and why.
Now I am not planning on re-analysing the IEEE 829 template test plan. This is a great document and can assist greatly. However I want to look at the overall purpose and necessity to plan. Regardless of the overall development methodology, e.g. SCRUM or Waterfall, some time needs to be spent defining the approach to testing.
All good development starts off with a plan, whether that is a story board within Agile or detailed specifications in the highly formalised project, the same applies to testing. To do good, relevant and appropriate testing requires some careful thinking. Good questions to ask and to try to define are:
• What is the system I am testing?
This relates to the software, the infrastructure and any related systems/applications. Try drawing a schematic of the system you will be testing, showing what software will sit on which piece of hardware and how these connect to other applications.
• How am I going to test this?
What approach am I going to use? Am I using exploratory testing, test driven design, validation or any other approach or mix of approaches. This can help highlight issues around having the right resources to support the activities, including people and skills.
• What is the purpose of my testing?
Am I trying to ensure that this safety critical system is fit to fly? Is to confirm that an application is stable enough to go for a demo somewhere? More fundamentally, what do my customers, the business, require from me? Depending on the response to this will determine the depth and rigour required.
• What will I test for?
By answering the questions above and then using whatever knowledge of the system is available, you can start to highlight key areas that need testing. This could start as a list of key risk areas, features, scenarios or even test techniques (e.g. I know I need to do some performance testing, but I don’t know quite what I need testing yet).
By answering these questions and communicating them to others, significant improvements can made very rapidly in clarifying and defining clearly to all the stakeholders what testing is required and why.