Boosting QA effectiveness via developer planning
At the beginning of many software development cycles, good intentions abound about how everything will be done correctly and thoroughly this time around. These good intentions include lip service about "test plans" to be produced by QA.
Much more often than not, test plans don't materialize. Why? Most QA people don't have a really clear sense of what to test until they have actual software in hand. They may spend some time with specifications trying to understand what test exercises would be appropriate. But the sad fact is that this work requires immense effort and imagination, and thus it is usually goes undone. In the end, QA proceeds without a map of what to test, and often overlooks significant problems until they are uncovered by accident late in the development cycle.
The enormous effort required to create a test plan is a sign a task needs to be broken down into several tasks. In this particular case, the several smaller tasks include obtaining test exercises from the initial project task list created by the developer. This presupposes your developers create an up-front project task list with test exercises.
Developer-QA collaboration is an extremely sensible thing to do. The developer is going to generate test exercises for each of his tasks anyways, so why not share these test exercises with the QA person to provide a sense of the things which need testing? The QA person needs to expand on these tests, but the initial set from the developer constitute a very significant running start for the QA person.
There are a number of ways a developer can share test exercises with QA. For instance, a developer can share out project directories so QA has access to test files and other data. A much better way to go is to implement a web-based project task list, each entry of which includes a simple test procedure and links to test files, if relevant.
For example, in the 'Battleship' game I've written about elsewhere, imagine one of the developer's tasks is to implement the rendering of a hit on one of your opponents ships. The test procedure would read something like:
1. Open testfile.dat ( a saved game state -- your battleships, your shots, your opponents battleships and your opponents shots)
2. Enter the coordinates of a shot which hits one of your opponents ships
3. Observe that the shot is rendered as a 'hit'.
The test exercise web page would contain a link to testfile.dat.
A bonus feature on the web page would be a status field which reported whether the exercise works successfully in the current version of the software. Both the developer and the QA person would be able to set the status. If the QA person sets the status to 'DOES NOT WORK', an additional feature could be an email notification to the developer.
The advantages of a web-based approach are many. For instance, everyone involved (developers, QA, management) has instant access to the most current version of this information. Managers can see the status of a project by visiting a summary page. Developers can add or modify tasks and test exercises with minimal effort.
I recommend developer-QA collaboration not only because it sounds good, but because it has worked spectacularly for me in practice. Instead of major adrenalin rushes and heart-in-your-throat panic, projects where I've involved QA from the start with my test exercises have wound down in boring, uneventful, predictable fashion. Early in the project, an overzealous QA person may mark many an exercise with 'DOES NOT WORK'. However as a project progresses, 'DOES NOT WORK' steadily changes to 'WORKS!'
One last point: your company culture probably isn't set up for sharing test exercises yet. The reason? Most developers don't create an initial project task list with test exercises up front. So a prerequisite for using the QA-developer collaboration is to change your software development culture -- to teach your developers to make their best effort to create an up-front project task list complete with test exercises, and to keep it current.
Much more often than not, test plans don't materialize. Why? Most QA people don't have a really clear sense of what to test until they have actual software in hand. They may spend some time with specifications trying to understand what test exercises would be appropriate. But the sad fact is that this work requires immense effort and imagination, and thus it is usually goes undone. In the end, QA proceeds without a map of what to test, and often overlooks significant problems until they are uncovered by accident late in the development cycle.
The enormous effort required to create a test plan is a sign a task needs to be broken down into several tasks. In this particular case, the several smaller tasks include obtaining test exercises from the initial project task list created by the developer. This presupposes your developers create an up-front project task list with test exercises.
Developer-QA collaboration is an extremely sensible thing to do. The developer is going to generate test exercises for each of his tasks anyways, so why not share these test exercises with the QA person to provide a sense of the things which need testing? The QA person needs to expand on these tests, but the initial set from the developer constitute a very significant running start for the QA person.
There are a number of ways a developer can share test exercises with QA. For instance, a developer can share out project directories so QA has access to test files and other data. A much better way to go is to implement a web-based project task list, each entry of which includes a simple test procedure and links to test files, if relevant.
For example, in the 'Battleship' game I've written about elsewhere, imagine one of the developer's tasks is to implement the rendering of a hit on one of your opponents ships. The test procedure would read something like:
1. Open testfile.dat ( a saved game state -- your battleships, your shots, your opponents battleships and your opponents shots)
2. Enter the coordinates of a shot which hits one of your opponents ships
3. Observe that the shot is rendered as a 'hit'.
The test exercise web page would contain a link to testfile.dat.
A bonus feature on the web page would be a status field which reported whether the exercise works successfully in the current version of the software. Both the developer and the QA person would be able to set the status. If the QA person sets the status to 'DOES NOT WORK', an additional feature could be an email notification to the developer.
The advantages of a web-based approach are many. For instance, everyone involved (developers, QA, management) has instant access to the most current version of this information. Managers can see the status of a project by visiting a summary page. Developers can add or modify tasks and test exercises with minimal effort.
I recommend developer-QA collaboration not only because it sounds good, but because it has worked spectacularly for me in practice. Instead of major adrenalin rushes and heart-in-your-throat panic, projects where I've involved QA from the start with my test exercises have wound down in boring, uneventful, predictable fashion. Early in the project, an overzealous QA person may mark many an exercise with 'DOES NOT WORK'. However as a project progresses, 'DOES NOT WORK' steadily changes to 'WORKS!'
One last point: your company culture probably isn't set up for sharing test exercises yet. The reason? Most developers don't create an initial project task list with test exercises up front. So a prerequisite for using the QA-developer collaboration is to change your software development culture -- to teach your developers to make their best effort to create an up-front project task list complete with test exercises, and to keep it current.
posted by John Keklak at
9:53 AM
0 Comments:
Post a Comment
<< Home