To write better scripts Testers need to have some “Play time” with the application/system that they are testing.
Hands up, how many of us here have been on project where the test scripts by well meaning test analysts that have never been near, or barely touched the application that is going to be tested. The well meaning TA’s (I include myself here) have had to rely on the bobble heads who have written the specs. I am very aware that in most projects today that this is the norm and sometimes it is the only way to go. So here we go, you have your well meaning TA’s sitting in some bunker ( probably in some other continent) wading through pile of incomprehensible badly written specification documents that have been put together by five different people who probably don’t like each other and have very different ideas about what they are trying to achieve. IF the well-meaning TA’s are lucky, they might just have a couple of diagrams that are on the back of a beer mat (probably doodled after a good session in the pub), to help them along. Okay I being a bit hard on the some of the people that write specs, but you get my drift.
The result of all this though is the well meaning TA’s try enlist the help of the very bobble heads that wrote the spec to write scripts. After being further bamboozled by the bobble heads, the TA’s the last ditch resort will try use a user manual that has a pictures of smiling men smoking pipes standing round large computers form the 1950’s, its covered in dust and rather large scary spiders are crawling out of it. Quite often scripts from such an exercise are turgid, over complicated and do things that simply not needed. Worse thing of all though is that the people who are executing the scripts often know that the scripts are not doing enough or doing too much. However, they are powerless to do anything about it as the Test leads have told them that they have to run xzillion scripts that week and do not have the time QA scripts as they go.
We all know what happens next don’t we? You are three weeks into testing and of the thousand odd scheduled scripts only half a dozen haven been run. This is because the executers are spending hours trying to run the incomprehensible scripts from the musings of some business bobble head and a user manual with the dust and spiders. The entire project eventually staggers to a halt; the powers at be take everyone off site and then locked into a room to start de-scoping scripts. The business bobble heads start wailing that have been misunderstood and say they really want to do in life is write self-help books on blame displacement .The Test Manager has to be strapped into the straight jacket and sedated to stop the mass murder of the business analysts, meanwhile the test leads book their flights out of the country. The Test executers shrug their shoulders and go “oh no not again”.
The above is rather extreme; nonetheless, we should be pushing to get our hands on what ever we are testing as early as possible. It does not matter if it’s just small demo or few knocked up screens. If gives the TA’s a chance to get a feel of what they are going to be testing on. It will give them the confidence to write far leaner and meaner test scripts that will test the requirements properly. During the analysis we should be having some “Play time” with the app we are testing. Sit down with the people who are actually writing the specs and use the application with them as well, even they will see things that perhaps they were not aware of. Above all try and push to be involved with the actual reviewing of the resulting spec. IF we start doing all this we might not have to get the straight jacket out for the poor test manger…
Is Brian living in a dream world? Agree or Disagree leave a comment.