Friday, March 28, 2014

The characteristics of a specialist tester - Great writing skills

No, you don’t need to write a novel, but in the testing world, writing skills can do the difference between failure and success. For me there are two main areas where writing skills are crucial:

Writing Test cases
Think about the following scenario: 
  1. Tester X write STD with 1000 test cases.
  2. After six months a new tester arrived at the company (Tester Y).
  3. Tester Y should run tester X documentation (STD).
  4. Tester Y start the execution. 

Available scenarios:
  1. Tester Y receive highly detailed STD with expected results, execution is flawless.
  2. Tester Y receive highly detailed STD without the expected results, execution is a total failure
  3. Tester Y receive Low detailed STD with expected results, execution is a total failure.
  4. Tester Y receive Low detailed STD without the expected results, execution is a total failure.

Simple quiz, but as you can see, writing skills are great characteristics that you must master, the specialist tester will know how to write in a way that other tester will understand and run without is a personal help. That’s not all, sometimes a tester can write an STD that executed single time and forgotten for a year, the specialist tester will create this doc in a way that he can use it after such time without the need to rethinking about the cases and why he wrote them in such way, the reason for that is that all tests written perfectly from the first place.

Criteria for a successful test design:
  • All tests should be highly detailed.
  • Expected results should be available per step.
  • A description should be added for each test that explains the reason for “why we need to run this test…?”
  • Tester design the tests based on requirements (Covering the application requirements
  • All tests receive an appropriate prioritization (High, Medium and low).

Writing great Bugs
Writing a great bug is a true ‘Art’, for me a great bug should be highly informative from both the human and technical perspective, you need to remember that every bug that written by you will be reviewed by other collogues (Product Manager, Developer, tester and more) therefore you cannot waste their time when trying to configure out the missing information or what you mean by stating ‘X’ against ‘Y’.

The specialist tester will know how to write his bugs in a way that other collogue can read is a description and understand the information without asking a trivial information that different tester (The one without this skill..) will be failed to add as a result of missing knowledge or simply bad technical understanding in the product. 

Criteria for great bug reporting: 

  • Collogue will understand the bug from the bug title.
  • A description is writing with Micro details about the problem.
  • Description must contain the tested architecture (OS versions, product architecture on this lab, build number and more).
  • The specialist tester will know how this bug effects the version and determine the appropriate “Severity” (not all bugs are ‘Show stoppers’).
  • The bug must be readable.
  • The bug must contain reproduction steps for dummies.
  • If available, investigate and provide the actual result, most testers will open the bug based on symptoms (Not good enough!).
  • Reporting the defect is not good enough, you must describe the expected results. (sometimes the bug reviewed by new employs that will be failed to understand why you open this bug).
  • Add additional information about how this bug may cause issues with other components, in addition, show this bug to developer and understand the risk of fixing it (save your manager time..), and add the info into the bug description.
  • Add info about the influence of this bug from the QA perspective (for example: ask yourself if you can continuing your work? If you do, should you retest cases after the fix..?), this info is very important when your manager should determine the bug priority.


  1. Cant 'highly detailed test cases' be a waste of time and resources that could be better spent on actual testing? Isn't the scenario of a new tester coming in and running these tests 6 months later a straw man argument? How often does this actually happen? And if it were to happen, aren't there better ways to do it?

    Agreed that writing is a great skill to have - whether it's best used writing test cases is a separate discussion

  2. my opinion is that test case should be written in a way that the "monkey" tester can run, otherwise question will be raised and the time you waste in explanation is greater than writing this case in an informative way in the first place.


My Presentations