I’ve already told you how I described to my Mother, who specialises in growing prize-roses, what I do. This post is about how I describe my role to other people in IT.
The best way that I can do this is in general terms using the sequence of events in a typical software development lifecycle. I hope you enjoy my account and cannot relate to it too much in your everyday working life.
The role of a tester is to identify what is wrong, analyse the impact and flag that issue to be fixed. However, sometimes the problem is not something that is as straightforward as a software bug but rather a company wide policy that infects a small part of the company workflow. This can be frustrating for the tester whose role in a company is too small to be able to do anything other than point out the problem and vow, that when they rule the world things will be different.
The examples given below are the most extreme of circumstances seen in companies I worked for in the past and is not to be taken as a measure of quality control in those otherwise excellent organisations. The names and the numbers have been changed to protect the guilty.
It is worth pointing out that now that I am big chief testing dogsbody here at KnowledgeMill with my own whip, nothing like this happens at all. Ever. It is a very very big whip.
In any new software project, the ideal time for testers to first get involved is at the end of the project documentation stage. In most companies they tend get involved before this phase is complete with the result they began putting the testing plan together without all the software functionality or business requirements detailed for them. There are exceptions to this practice. Back when the dinosaurs roamed the earth, I went to work for a company who very proudly announced to the testing team that they had produced a full set of software specificatons and put the lot into the repository of the first release of software product we were testing. Then no-one could find the docs. Like a modern-day keystone cops episode, six testers and not one document could we find. That was my first bug logged with that company.
Most testers begin asking lots of questions from the business right about this time. They don’t really expect answers. It is just amusing to watch as everyone on a new project shunting emails from one person to another in order to avoid actually having to do the work involved in answering queries. I once got an email forwarded 27 times but this was with a company with 60 project manager-types in one office alone. My testing team used to have competitions to see who could have the longest forwarded mail trail. With any luck, the average experienced tester can keep this going for about a month and earn themselves the time to get on with some real work like writing the test plan and fleshing out the framework for the testcases they are going to write and run.
From very early on, it is essential to establish a good working relationship with the developers working on the product. A good tester will kick-start this by plonking themselves on the developer’s desk and sharing any dirt they have on the project manager. With any luck, the developer might also talk about the product they are writing so a tester can get enough information to make a start on the testcases. Two jobs done in one. A big part of being an effective tester is multi-tasking in this way. Listening to people talk complete rubbish without interrupting them with an act of physical violence on their person is also another good skill to have. When I came back to work after being on maternity leave, I sat in a meeting and listened to someone tell me that testers should not do any exploratory testing. Since all functionality was scripted, they claimed, it was a waste of time. I felt the old trottling fantasy return and smiled. Any worries that Motherhood has softened me as a tester were gone but I digress …
Eventually though, it is conceivable that the project will deliver you some specification documents. This leads to the next stage of the project:
- Making sense of the project technical and functional specs.
A degree in jabbwockey and telepathic abilities are a necessity at this point. These documents are sometimes written by the developers to wind up the business or by the business to make the developers cry. At least that is the way it looks to the poor testers caught in the middle.
Around this time, you will get the first cut of the product. So this involves a lengthy (“You have an hour”) phase of:
- Learning the product.
If any other department wants to hold on to their hardware, it is advised that they use nail guns and superglue to attach them to their person otherwise they are fair game for appropriation as far as a tester is concerned. No matter how many times I warn people about this, they never listen. I tried wearing a t-shirt that warned: “Testers heart hardware” but had to stop wearing it. I got a letter from the HR department telling me to.
Next comes my least favourite part of the process. Finding out from the business what they want from the product. Some faffy business types give the impression that they would accept a fish tank held together with a packet of band-aids as long as it looked like it might hold water long enough for them to be transferred to another project. This phase is also known as:
- Learning the expectations of the environment or customers the product is being developed for.
There are several approaches to this stage. A very ill-advised one is to just pretend you are carrying out this assessment. It would be wrong of you to conclude that this pretense is a good one. Just because the business managers appear to make up their expectations willy-nilly as the project goes along, that is no reason for you to sink to this level. If you will insist on taking this path of no return, then you must remember to include a few generalised claims about assessment of risk, managing expectations and functional complexity in all your communications.
Remember, this is not something I recommend.
Finally, you have completed your test plan. You have formatted a nice index, put in headers and footers, signed your name to this thing and done everything but wrap it in a soft yellow blanket. This stage is known as:
- Submitting the test approach
When a newborn baby is taken from its Mother in the hospital, it is checked for heart and lung function, cleaned up a bit and generally handed back the proud parent with all its limbs intact. Not so with a test plan. The test plan that is conceived in version 1 is a drastically different beast to version 9 which will be altered drastically due to the constrains in time / money and a general all-prevailing lack of sanity characteristic in every business person who reviews it.
Now the test plan has been amputated, I mean agreed. The big writing body of work will start. This is:
- Writing the testcases
It is not enough that testcases now prove functionality. They now have to prove business logic and/or the drunken claims of the project sponsor in the pub. There is no advice I can give you on this one except to always keep copies of what you write for the day some moron wipes the entire testcase database. It happened to me, it will happen to you too.
So now you have established all your relationships, done all the research, got your testplan accepted, written all the testcases. What happens next? Oh yes, everything changes. This is the stage when the project decides to:
- Change the methodology used in the software development lifecycle
This will happen as new project management systems become fashionable. Don’t worry if you do not like the new process, it will be re-organised, re-thought, re-named and spring up in a reincarnated for with its own cult of disciples within a few years. Waterfall anyone? Keep all the documents that you write proving how you have altered your processes to make them work with the new methodology, you may be re-cycling them with great frequency.
One continual task is to work on the communication channels that you have opened. Working relations are like eating, they are something you have to do everyday. This is known as:
- Maintaining good relationships with developers
This is why coffee, doughnuts and beers were invented. They really help.
There is also the relationship with the business to be considered:
- Maintaining good relationships with project managers
As a very general statement, the most important action here is not to frequently put your hands around the PM’s neck and try to strangle them. You may feel tempted to do this if they are the types who ask for the one thing 18 different ways, one of which appears to be written in ancient Aramaic. The doughnuts and the beers are best applied to the tester at this stage.
Next we get to the reason d’etre of the tester, the point which we battle through glue-thick mudstorms and are editing taskcases until 3am. It’s time for:
- The actual testing itself.
Heaven forbid that is forgotten in the general melee of doing everything else. To the casual observer, the sounds coming from the tester will vary between wild shreiking laughter and dark tormented cries from the depths of hell. During this phase, they are best left alone.
Then the last stage, project completion where the tester will watch is despair as defect after defect are marked as known issues in order to make the software pass the exit criteria of no open issues logged against the product. Then they are expected to write a report which says the product has passed testing.
- The test exit report
How each tester phrases this varies from person to person and I am not with the school of thought that refers to this stage as downright lying.
My own personal favourite test exit report was written by a colleague in a company I worked for many moons ago. It was a heartfully expressed piece of poetry which I have committed to my eternal memory. Unfortunately it was so expletive ridden that the only parts of it that I can repeat here are: To the bunch of, concerns, listening, you, off. I quit.
This method of test reporting is also something that I do not recommend, no matter how much fun it is.