Faq

From a Testers perspective
What to look for in functional designs

As a tester you can be asked to review a design. Probably you will need this design to create your test cases, so it should be fit for that purpose. Maybe you are already known with the subject, so maybe you can also check if the design correctly fits in the current environment. Lastly, you need to understand the design without having to make any assumptions.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “I can use this design to create my test cases without having to make any assumptions”

Review suggestions

  • The design must be unambiguously clear. Look for
    • a description of the goal of the design;
    • vague words;
    • incomplete lists;
    • missing boundary values;
    • incomplete or incorrect definitions;
    • examples, charts, pictures;
    • consistency with other designs.
  • The design must be correct and complete, at least to your knowledge of the current system.
  • The design must contain enough details to create your (logical) test cases.
    • all IF…ELSE constructions must be complete;
    • all functional paths should lead somewhere;
    • alternatives must be described
  • The design must be traceable to requirements

Permalink.

What to look for in test cases

As a tester you can be asked to review test cases. Except for a peer-review situation, most likely these test cases will be created for an other test level then yours. For example you might receive Integration Test test cases if you’re a System Tester.

Be sure to stick to your role; coverage and correctness will primarily be reviewed by a designer!

Relation to the document

RR_HorizontalAfter your review

You must feel confident to announce that “These test cases complement my test cases and do not overlap or leave a gap with my test cases.”

Review suggestions

  • It is clear to me how these test cases where created. (Test technique)
  • The test cases do belong to the test level they are created for.
  • The test plan is followed.
  • Input, output, interfaces and screens are tested on the correct way for the test level at hand.
  • The test cases complement my test cases.
  • The way the test cases are described makes them transmissible to an other tester for execution.
  • Execution steps contain an actor and an action. (e.g. “The user presses the red button.“)
  • Expected results describe a verifiable result. (e.g. “The output file on location A contains parameter ABC with value XYZ.“)

Permalink.

What to look for in implementation plans

As a tester you can be asked to review implementation plans. Your main task will be to check if any issues found during the testing phase affect the implementation.

Relation to the document

RR_1stSenderAfter your review

You must feel confident to announce that “The issues found during the testing phase which could influence the implementation are taken care of.”

Review suggestions

  • Open test defects/findings are related to a risks mentioned in the implementation plan.
  • Issues encountered during implementation on a test environment are covered in the implementation plan.
  • The (functional/technical) scope of the implementation is consistent with your test scope.

Permalink.

What to look for in technical designs

As a Test representative you can be asked to review Techical designs. Probably you can review these on testability, functional correctness and technical correctness.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in requirements

As a Test representative you can be asked to review requirements. Probably you can review these on testability, but also you are thé quality minded reviewer, so look for ambiguities, SMART requirements and missing requirement types.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “These requirements are complete, SMART, unambiguous and I can define my (risk based) test strategy on it.

Review suggestions

  • All requirements (functional and non-functional) are described.
  • (Non-)Functional requirements are traceable to business requirements.
  • Each requirement is specific (what/why/who/where/which? etc.)
  • Each requirement is measurable (how much/how many/how is determined if the requirement is met?)
  • Each requirement is attainable and realistic (how can it be accomplished?)
  • Each requirement is relevant (MoSCoW; right time/right efforts/correct stakeholders involved?)
  • The requirement are time-bound (when is it needed/what sequentiality applies? etc.)
  • Each requirement has a relation with a stake holder.
  • There are no ambiguities in the requirements.
  • Requirements are traceable and are uniquely numbered/marked.

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.