Faq

From a Developers perspective
What to look for in functional designs

As a Development representative you can be asked to review Functional designs. Probably you can review these on understandability and connectivity with current functionality.

Relation to the document

RR_2ndReceipientAfter your review

You must feel confident to announce that “I understand the functionality and I can use this design to perform my development activities 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 existing functionality.
  • The design must be correct and complete, at least to your knowledge of the current system.
  • The design must contain enough details to perform your development activities.
  • The design must have a clear relation to technical documentation (if any).

Permalink.

What to look for in technical designs

As a Development representative you can be asked to review Techical designs. Probably you can review these on ‘buildability’.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in test cases

As a Development representative you can be asked to review Test cases. From your role you can review these on technical coverage and correctness of the test steps.

Relation to the document

RR_1stSenderAfter your review

You must feel confident to announce that “These test cases cover the built functionality in the way it is intended for this test level and the test cases can be executed following the described prerequisites, test actions and checks.”

Review suggestions

  • The test cases are presented in such a way that I can easily check the technical coverage.
  • The described test actions can be executed in the way it’s described. Order, action, prerequisites and expected results are conform what’s built.
  • The test cases cover the built functionality as expected based on the test plan,  technical risks or technical scenario’s.

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.