Anton Chekhov was a Russian short story writer known to be one of the best in field of literature. I remember that as a child I used to buy his books translated in Punjabi – that’s a long time ago. I’m not sure how I landed into his wikipedia page reading about one of his concepts. It must be a typical web surfing day for me which started from some reading or watching a movie where I became interested in something, searched about it on web, this led to another and so on. I am very happy that it happened.

As per wikipedia:

Chekhov’s Gun is a literary technique whereby an element is introduced early in the story, but its significance does not become clear until later in the narrative. It owes its origin to one of his stories, in which “a pistol is introduced early on as a seemingly irrelevant prop and, towards the end of the play, becomes much more important as Uncle Vanya, in a rage, grabs it and tries to commit homicide”.

Chekhov mentioned several variants of this technique in his letters. I found one of them very interesting:

“One must not put a loaded rifle on the stage if no one is thinking of firing it.” Chekhov, letter to Aleksandr Semenovich Lazarev (pseudonym of A. S. Gruzinsky), 1 November 1889.

This is very relevant to the world of testing. I would take this discussion in the context of Test Plans, though it can be applied to other areas as well.

A Test Plan is like the gun on the wall in Chekhov’s story. It is introduced in the early stages of the testing story. When one is writing a test plan, the importance of it is not evident, it is realised somewhere in the middle of the project and at later stages wherein we have to decide whether the goals are being met, where we stand from where we started.

What goes wrong with Test planning?

• We typically think of it as a “sign-off” activity so that the team can start with some “real stuff”. Such plans are better not referred because they are bad and incomplete. Such plans would never be referred because the team knows there’s nothing in there. No body would like to take up the burden of updating it during the cycle. This breaks the principle of Chekhov’s gun. The gun if not used in the later part of the story should not be there on the wall. On a similar note, James Whittaker in his talk in GTAC 2010 at Hyderbad had a slide saying “I see dead test plans”. Such teams do treat the test plan as dead, they treat the gun on the wall as a decoration piece rather than as the plot’s crucial element.

• Test Plan writing is made the responsibility of the “senior” tester in the team, where seniority is usually depicted by designation or number of years of experience. This also has another perspective – the “junior” team members prefer this because they don’t want the responsibility of ownership of a bad test plan on them. I’d love to see a story where various sub-plots of different characters revolve around the gun. Test plan is a team responsibility. This can be exercised even in teams with strict document ownership. Team can still contribute via reviews, brainstorming and providing contents for various sections of the plan.

• Should the gun look the same way on the wall of the all the plays shown? I am not a fan of “standardised”/”templatised” test plans. Why should all test plans look alike? Do we confuse test planning as an activity with test plan as a document? Is the effectiveness of test planning measured by the number of pages in the plan or beautified bulleted points/numbered point of actions?

• We think of test plan as a single lengthy document. It suffers from the same problems that we study about requirements. Those against test automation say, why should we write faulty code to test another fault code? So, should we write a faulty document to test a faulty software? A variant of Chekhov’s gun could be Chekhov’s guns. Splitting the test plan into multiple smaller, manageable test plans which are frequently updated. It is something which I have seen working wonderfully in all my recent projects. These smaller test plans are owned by the testers for their respective testing areas, are kept up-to-date, don’t follow any strict standards, are more of test planning notes which help in communicating the tester’s understanding of the feature under test to the rest of the team, including developers.

Some concluding thoughts:

• Test planning in my opinion is not an optional exercise. If there’s no gun on the wall, how would the plot build?

• Test planning should be documented in some way. The gun on the wall should be visible.

• Test plan document should be made available to all at even early stages of development. The gun on the wall should be accessible to all characters so that any one in the plot could have picked it up.

• Test plan documentation if made to subscribe to too many standards, becomes an uninteresting activity. Team should be given the freedom to follow their own structure/templates for the purpose while setting up some primary expectations on the purpose of the plan. Imagine watching the Chekhov’s play in 20 locations by different unrelated teams with the gun on the wall of the same type hanging at the same angle with same exact background.

• Test plan should be updated often. If it is not up to date, it’s dead. Team should keep referring to it in their discussions and communication. The gun on the wall should get referred by the characters at various stages in the plot. This is called repetitive designation.