This blog expressed my technology vision and based on my professional experience in the Software industry.
Contains Knowledge base, Tutorials, Code examples and Best practices of frequently Software design issues.
The characteristics of a specialist tester - Great writing skills
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:
the following scenario:
Tester X write STD with 1000 test cases.
After six months a new tester arrived into the company
Tester Y should run tester X documentation (STD).
Tester Y start the execution.
Tester Y receive highly
detailed STD with expectedresults, execution is flawless.
Tester Y receive highly detailed STD without the
expected results, execution is a total failure
Tester Y receive Low detailed STD with expected
results, execution is a total failure.
Tester Y receive Low detailed STD without the
expected results, execution is a total failure.
but as you can see, writing skills is 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 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
for a successful test design:
All tests should be highly detailed.
Expected results should be available per step.
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
All tests receive an appropriate prioritization (High, Medium
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’.
tester will know how to write his bugs in a way that other collogue can read is
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
Criteria for great bug reporting:
Collogue will understand the bug from the bug title.
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
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.