Art of Requirement Elucidation – Learn by Game

This game was shared by my friend, Shibaji Ganguly.  He is well known for clear and flawless testing artifacts. I do not have any name for this exercise. But I am certain many of us would have played the variants & equivalents of this game. Believe me this game is worth a try in your leisure time with your team member, as it heightens your interpretation skill.

To start, let’s assume you are the organizer, take a white paper and draw an object of your wish. Ensure object drawn, can be designed with the help of ONLY geometrical figures (Square, Rectangle, Rhombus, Triangle & many more).

Now form teams with at-least three members. Each team should have Presenter, Drawer and Observer.  Hand over the sheet with object, only to Presenter.

• Presenter - Provide hints to “Drawer” for depicting the object. Presenter should not face the board until “Drawer”  finish sketching the object.
• Drawer - Sketches the object on board based upon hints provided by presenter.
• Observer - As name insist just a observer. Identifies the object as penciled by Drawer.

Remember "Presenter" hints should always stick to geo-metrical figures and violating this rule, appeals for team elimination. Team which pinpoints intended object more rapidly is the champion.

To explain further, here is an illustration: A conical flask (Erlenmeyer flask to be perfect) closed with cork and also an apple within flask.

Object to be identified
Image source:http://teachers.egfi-k12.org/master-stem-teachers/

Hints that shall be provided by the presenter for this diagram

•  Draw an equilateral triangle.
•  Erase tip of the triangle, at the top. Do not erase the base.
Expected(To be penciled by drawer)
• Draw pipe connecting open end of triangle, at the top.
• Pipe should be like two parallel lines of equal length.
• One end of the pipe should connect the erased end of the triangle.
• Do close the other end of the pipe with an ellipse
• Focus on ellipse
• Draw an inverted cone within ellipse
• Base of the inverted code should be above ellipse
• Tip of the inverted code should be flat
• Tip of Inverted cone should not touch base of the triangle
• Height of inverted cone should be equivalent to pipe length.
• Above the base of the triangle, say 1 centimeter
• Draw a circle or sphere
• Draw a line of 1 centimeter at one edge of circle
• The other end of line should point to open end of triangle
• Line drawn from circle should not touch the tip of inverted cone.

At the end of this workout, each team will realize the importance of clear and distinctive requirements. That is, as small teams with single object on hand; amount of confusion is manageable upto a magnitude. Then visualize a typical software project where geographical distributed teams would work on multiple features, aggregate of misunderstanding will grow exponentially with unclear requirements.

For those who ponder how this exercise is linked to requirement collection, in software industry many tester treat requirements document (esp with single liners) as ONLY reference/guide for verification either because they are forced to do or trained in that way. So why do not we(testers) cultivate clear, comprehensive & complete communication within our-self and try to dive deep with information on hand. Quality can be easily assured if a tester understands product being shipped.

Above snapshots are few of the avatars which was spawned from my team :).
Do try this game and share your comments. I am definite you will like the revolution.

Unknown’s Unidentified – Implicit Requirements

"Why this case was not covered in your test plan? Have not you done test coverage sign off? Probably you should take our organization process training (so called) to extemporize your analytic skills! From henceforth work with “Mr. Smart” (most likely pet of manager) to certain no false-steps are seen in future."

Ever faced whichever of these questions in your testing life path, Well I have faced a few, to be straightforward. The moment these queries hit our cochlea, stimulus ensures to point our finger towards business analyst or project manager, to outline all requirements. Yes, you are right but it is also the liability of a blameless tester to serve his stakeholder, better

There could be voluminous technical or non-technical documents spawned in a project, but it is predominantly the tester artifacts which catch customer’s responsiveness. Because each tester’s artifact reveals readiness & quality of the project/product, which customers want to utilize & of course pay for, correspondingly. So why can’t testers utilize this prospect to retain customers in page with project’s status.

Let’s start with Test Plan attributes

• Scope - Defining scope is vital part of planning. I have seen test plans where scope is defined within 500 characters!. Make sure to present the range of testing, unmistakably.

• What won’t be tested? - Identify boundaries and potential environment variables. Call out which will NOT be covered in your test execution. This section will bring out hidden requirements from any dependent team or even customers.
  

Assumptions – Whenever you author any shared document, explicitly insist on assumptions you did while drafting that doc. Having said that do not quote negative cases or uncertain conceptions under assumption section. Ensure this section is precise and informative.

Scenario: Let’s say you are validating “Font Styles” for Microsoft Word
• Valid: Font style is supported for both Horizontal and Vertical<Japanese> Contents
• Invalid: Font style is not applicable for superscript and subscript.[Negative case]
• Invalid: Font style rendering are respected only for ASCII and UTF-8 encoded formats.[Uncertain about encoding formats, this can be added as an open question]

• Unanswered Questions/ Open items - Here capture all confusions lingering in your mind. You can even append the point of contact for each item, for better tracking.

Test Case Categorization - Use either breadth <user story> or depth <Feature/Component> wise approach to tag test cases. Remember each has their own pros and cons, so stick to one that fits you. Gaps can be spotted in ease if suitable test case classification is in place, by any reviewer.

Test Data - Numerous software failures arise due to improper handling of data, misleading information and unexpected inputs. If possible get data from customer field or ensure to share format of likely inputs with real time users/stakeholders. Real time data are often unpredictable!

Test Result - Test results should be logically complete, quantifiable and measurable. In short, any stakeholder should visualize quality from our test results. Recently I stumbled upon a test result document from a start-up organization, which had user stories and its corresponding status (Pass or Fail), making it more informative.

Reviews - Voluminous after-effects arise due to the mis-communication or synchronization among project stakeholders. So review all your artifacts with possible stakeholders. Try to involve actual customer once in a while. Reviews will elude dis-satisfiers, who forgot to explicitly mention about a requirement or assumed it as a basic provision in equivalent application. Reviews also aids in avoidance of non-delighted stakeholders, who may not be aware of actual technology, standards or domain updates

Questioning is a strategic skill for any passionate tester so do cultivate it. Before closing any artifact, ask yourself “Have I asked questions”? This will encourage in perceiving unknown/hidden requirements. As always, want to share your comments?? Please feel free.