Problem: Testing can be started when the project plan says so?
If you've ever been involved with testing in projects you know that they tend to hit this invisible "time's up"-wall. And that's exactly when testing will start. Not that the product is complete or the test lab is ready but estimates, plan and reality meet and the test starts.
As an experienced test professional you know that this will have a number of consequenses like defect opening rate that will break records, testers that will be demotivated (especially if they are from the business), project managers that will demand a million answers (their minds are always set for "green"), etc.
So what to do?
Solution: As early as possible create and maintain a list of entry criteria for the given test phase!
I know this is the most trivial suggestion in the world. It's so basic that is screams. So rudimentary it cannot be missed in any project. But why is it that so many projects they tend to skip this exercise?
Sometimes because the list will be ignored anyway. Some organisations tend to turn the blind eye to formal testing activities and are thus bound to fail. So no matter whether you like it or not the first exercise that an entry criteria list can be used for is the benchmark: "Test does matter". If not, then adjust your ambitions and test approach.
Anyway, preparing an entry criteria list is fun. A certain kind of fun, yes, but it is operational or should aim to be operational on a fairly low level. Not to the extent that all activities have to be specified in minutes and seconds but "Test lab ready" is usually to broad to accomplish.
If you find yourself in a project that can only come up with high level entry criteria you have another challenge. This is the clear indication that the project is immature, no-one understands the goals, the constraints and ownership are missing. That problem needs to be adressed or you can have the best test plan which nobody will be able to exercise. But the missing project goals have to be handled on project management level. Back to the test lab and some work that can be done while PM takes care of project goals.
"Test lab" is instead a good example of a category that can be used for grouping related activities on the list. You know you need some physical space, desks, hardware, network etc. This goes into the list. Documentation might be another.
The fun part is especially true when you find somebody with an interest this area. Again - end users or business are usually your friend. They don't know what "entry criteria" are but they can be woken up at 2 am and will be ready to specifically state what they expect. Usually this will be in form of a one liner as in: "Everything works". This is where the final fun part starts because as a test professional you have the possibility to challenge the "everything works-expectation" and understand what's really important and what's not important at all. This will impact entry criteria and can be used as a leverage towards project management and be used in prioritisation of import defects etc.
"Must have" and "nice to have" categories as well as a "done" mark is a great way to communicate to all relevant stakeholders that there is a list of known and understood activities that have to take place before it makes sense to start testing. Otherwise it will be a bad trip in the roller coaster.
Entry criteria lists as dead documents are boring and useless but as support for living discussions and negotiations they are priceless and tangible. "This is what you get - will it work out for you".
There is more inspiration to be found in this document which I came across searching for the generic check list for entry criteria. Such one does exist but you need to adjust it to your project reality and goals.
If you've ever been involved with testing in projects you know that they tend to hit this invisible "time's up"-wall. And that's exactly when testing will start. Not that the product is complete or the test lab is ready but estimates, plan and reality meet and the test starts.
As an experienced test professional you know that this will have a number of consequenses like defect opening rate that will break records, testers that will be demotivated (especially if they are from the business), project managers that will demand a million answers (their minds are always set for "green"), etc.
So what to do?
Solution: As early as possible create and maintain a list of entry criteria for the given test phase!
I know this is the most trivial suggestion in the world. It's so basic that is screams. So rudimentary it cannot be missed in any project. But why is it that so many projects they tend to skip this exercise?
Sometimes because the list will be ignored anyway. Some organisations tend to turn the blind eye to formal testing activities and are thus bound to fail. So no matter whether you like it or not the first exercise that an entry criteria list can be used for is the benchmark: "Test does matter". If not, then adjust your ambitions and test approach.
Anyway, preparing an entry criteria list is fun. A certain kind of fun, yes, but it is operational or should aim to be operational on a fairly low level. Not to the extent that all activities have to be specified in minutes and seconds but "Test lab ready" is usually to broad to accomplish.
If you find yourself in a project that can only come up with high level entry criteria you have another challenge. This is the clear indication that the project is immature, no-one understands the goals, the constraints and ownership are missing. That problem needs to be adressed or you can have the best test plan which nobody will be able to exercise. But the missing project goals have to be handled on project management level. Back to the test lab and some work that can be done while PM takes care of project goals.
"Test lab" is instead a good example of a category that can be used for grouping related activities on the list. You know you need some physical space, desks, hardware, network etc. This goes into the list. Documentation might be another.
The fun part is especially true when you find somebody with an interest this area. Again - end users or business are usually your friend. They don't know what "entry criteria" are but they can be woken up at 2 am and will be ready to specifically state what they expect. Usually this will be in form of a one liner as in: "Everything works". This is where the final fun part starts because as a test professional you have the possibility to challenge the "everything works-expectation" and understand what's really important and what's not important at all. This will impact entry criteria and can be used as a leverage towards project management and be used in prioritisation of import defects etc.
"Must have" and "nice to have" categories as well as a "done" mark is a great way to communicate to all relevant stakeholders that there is a list of known and understood activities that have to take place before it makes sense to start testing. Otherwise it will be a bad trip in the roller coaster.
Entry criteria lists as dead documents are boring and useless but as support for living discussions and negotiations they are priceless and tangible. "This is what you get - will it work out for you".
There is more inspiration to be found in this document which I came across searching for the generic check list for entry criteria. Such one does exist but you need to adjust it to your project reality and goals.
No comments:
Post a Comment