"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.
- 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]
- Scenario: Let’s say you are validating “Font Styles” for Microsoft Word
- 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.
