Ever been in a situation were you did not have much control over your test environment? Have you been in such a situation the developers deployed their solutions whenever they thought it was ready? Or have you been in a situation when you came back at work new deployments have been done?
To me it seems that those kinds of situations all previous work you have done on testing was useless when your goal is prove quality instead of finding as much issues in code as there are.
You might compare it with the game: Mikado
In this game every stick has its own color and every color has its own value. When starting you bundle the sticks and let them cautious fall. And your aim is to get the most valuable sticks without disturbing the other sticks. If you translate this to testing every functionality has its own value and you want to see how it works and how it is integrated. Does it disturb other functionality when using it?
Only what happens when new functionality or solutions are offered? All sticks are picked up again and newly setup. The whole stick-pile is transformed and you have to start again. This result into a new situation, sticks which had in earlier phase no direct interaction with other sticks might have now.
Only do you have the time to start testing all things again? Did you handle some kind of regression testing? I think if you keep continuing testing without any additional effort you performing some kind of Mikado Management. You are not aiming for gaining as much points in your time window, you aiming for getting as much sticks in you time window. Your test strategy shifted from proofing quality of main and import/risk full functionality towards finding as much issues in the top shelf of your system.
To deal with situations as this perhaps the following actions can be performed:
1. I would start making sure that you have control of you system under test, you give approval when code can shift in your environment. A disadvantage of this is that some necessary code is not there for you to test
2. Another option is Continuous Integration: it allows you all those transports and delivery time is decreased, only when in this continuous integration also automatic quality measurement is done by the development part, or better: the team, the sticks have not been picked up again, there is prove about the impact of the new code on the system.
3. Or define a set of regression test and after every delivery moment you execute those test set. You can decide based on technical impact of new functionality or solution if you run it immediately or after several deliveries. Or when deliveries are done on daily basis, you can start in the morning with executing that basic set of test cases. Keep in mind that these sets can be dynamically based on the area where solutions are provided and time is under pressure.
4. Another option could be automating your regression set. You can start the regression set when ever a deployment is done.
I think the best situation here could be having the continuous integration mind set. Where it might be an optimal situation where also the regression set of functional test is embedded in this integration and also automatically executed.
Only not every organization or project is yet mature to deal with such an approach. In such a case I suggest to prevent Mikado Management, and keep control or gain control over your test environment. If you have to decide what the quality of the system is, you should be responsible for the state of the system. Therefore you decide when deployments are done. Important in such a case is that management accepts the risk that the test process can extend due to deliver later in time.
And for those dare devils, if you can not get control over the test environment and transports are made when ever. Take the Mikado Game with you and start playing that game instead of testing. Think about what sense does it make if you keep continue testing and you don't get time of performing some regression testing? You loose the picture of quality. In that case playing Mikado you have at least some fun. Playing it with your manager might help make them understand the situation you are into.
No comments:
Post a Comment