I work in a project who's owners are working few thousand miles away. Developments are done there and we receive the product to be 'black box-tested' for quality before it reaches the customer.
If everything is going OK then there is no issues. But things don't go the way we like..as anything in our life.
So what goes wrong? well..things can go wrong from the very moment guys say now the product is ready to test till its successfully set up in our testing environments.
Things get worsen if they have a product line. This is the case with my situation. We have not only one product but multiple products to be tested. How awkward?
Now comes the nightmares...multiple different products, different supporting environments, limited domain/product knowledge on each, perhaps some are totally new!!!, installation issues, above all - Fixed dead lines.
So shouldn't we think of a way to come out of this misery?
If one can device an approach to tackle this, wouldn't that be nice ?May be a heuristic approach ??
What are your requirements?
1. If you are installing the build for the first time, then you should expect the 'unexpected'. Keep your MSN and Outlook (or what ever method you use to communicate)handy for immediate communication. Make sure to identify who the responsible people are. Troubleshooting will need expert help from the developers/architects. If an installation guild is available make use of it. but probably you may not find one
2. Set up your test environment as soon as possible. Best case would be to get ready with them before you get the mail saying 'OK guys build is ready for testing...'. You should have a matrix stating that which environment set up is required for which product. So make sure that you have procured necessary hardware and software in time. Co-ordinate with system administrators.
3. Gather domain/product knowledge
You might find several documentation related to the product being tested. may be the Help, use case, specification, and even test cases can be used to learn the product. Also trying out similar product which are available might be a good approach to learn the stuff. Playing around is also a good way to learn
4. Next most important thing is to document the lessons learned for future references.
If the all above are met, then its up to the tester to 'break the code' !!!
following diagram explains the scenarios
If everything is going OK then there is no issues. But things don't go the way we like..as anything in our life.
So what goes wrong? well..things can go wrong from the very moment guys say now the product is ready to test till its successfully set up in our testing environments.
Things get worsen if they have a product line. This is the case with my situation. We have not only one product but multiple products to be tested. How awkward?
Now comes the nightmares...multiple different products, different supporting environments, limited domain/product knowledge on each, perhaps some are totally new!!!, installation issues, above all - Fixed dead lines.
So shouldn't we think of a way to come out of this misery?
If one can device an approach to tackle this, wouldn't that be nice ?May be a heuristic approach ??
What are your requirements?
- Successful build installation
- Test environments set up for the product being tested
- Domain/product knowledge
- Time
- communication issues- delays, misunderstandings among parties
- Getting help from partners
- Acquiring necessary documentation
1. If you are installing the build for the first time, then you should expect the 'unexpected'. Keep your MSN and Outlook (or what ever method you use to communicate)handy for immediate communication. Make sure to identify who the responsible people are. Troubleshooting will need expert help from the developers/architects. If an installation guild is available make use of it. but probably you may not find one
2. Set up your test environment as soon as possible. Best case would be to get ready with them before you get the mail saying 'OK guys build is ready for testing...'. You should have a matrix stating that which environment set up is required for which product. So make sure that you have procured necessary hardware and software in time. Co-ordinate with system administrators.
3. Gather domain/product knowledge
You might find several documentation related to the product being tested. may be the Help, use case, specification, and even test cases can be used to learn the product. Also trying out similar product which are available might be a good approach to learn the stuff. Playing around is also a good way to learn
4. Next most important thing is to document the lessons learned for future references.
If the all above are met, then its up to the tester to 'break the code' !!!
following diagram explains the scenarios
Wow...you are really in to this...great.
ReplyDeleteThanks Yas :)
ReplyDelete