Ensure that The Requirement change are communicated

When Test Procedures are based on Requirements, it is important to keep Test Team members informed of Changes to the Requirements as they occur. This may seem obvious, but it is surprising how often test procedures are executed that differ from an application’s implementation that has been changed due to updated Requirements. Many times, Testers responsible for developing and executing the test procedures are not notified of Requirements changes, which can result in false reports of defects, and loss of Required Research and valuable time.

There can be several reasons for this kind of process breakdown, such as:

• Undocumented Changes

If someone, (Project manager, customers, requirements Analyst) has instructed the developer to implement a feature change, without agreement from other stakeholders, and the developer has implemented the change without communicating or documenting it. A process needs to be in place that makes it clear to developer how and when requirements can be changed. This is commonly handled through a Change Control Board, an Engineering Review Board, or some similar mechanism, discussed below.

• Outdated Requirement Documented

An oversight on the testers part or poor configuration management may cause a tester to work with an outdated version of the requirement documentation when developing a test plan or procedures. Updates to requirements needed to be documented, placed under configuration management control (baselined), and communicated to all stakeholders involved.

• Software Defect

The developer may have implemented a requirement incorrectly, although the requirement documentation and the test documentation are correct. In the last case, a defect report should be written. However if a requirement change process is not being followed, it can be difficult to tell which of the aforementioned scenarios is actually occurring. Is the problem in the software, the requirements, the test procedures, or all the above? To avid guesswork, all requirement changes must be openly evaluated, agreed upon, and communicated to all stakeholders. This can be accomplished by having a requirement-change process in place that facilities the communication of any requirement changes to all stakeholders.

If a requirement needs to be corrected, the change process must take into account the ripple effect upon design, code, and all associated documentation, including test documentation. To effectively manage this process, any changes should be baselined and versioned in a configuration management system. The change process outlines when, how, by whom, and where change request are initiated. The process might specify that a change request can be initiated during any phase of the life cycle, during any type of review, walk-through, or inspection during the requirements, design, code, defect tracking, or testing activities, or any other phase.

Design Test Procedure as soon as Requirements are available

Just as Software Engineers produce design documents based on requirements. It is necessary for the Testing Team to design test procedures based on these requirements as well. In some organizations, the development of Test Procedures is pushed off until after a build of the software is delivered to the testing team, due either to lack of time or lack of properly specified requirements suitable for test procedure design.
Moving the Test Procedure Development effort closer to the requirements phase of the process, rather than waiting until the Software Development Phase, allows for test procedure to provide benefit to the requirement specification activity. During the course of developing a test procedure, certain oversights, omissions, incorrect flows, an other errors may be discovered in the requirements document, as Testers attempt to walk through an interaction with the system at a very specific level, using sets of Test Data as input. If a problem is uncovered in the requirement, that requirement will need to be reworked to account for this discovery. The earlier in the process such corrections are incorporated, the less likely it is that the corrections will affect Software Design or implementation.
As I mentioned before, early detection equates to lower cost. If a requirement defect is discovered in later phases of the process, all stakeholders must change the requirement, design, and code, which will affect budget, schedules, and possibly morale. However, if the defect is discovered during the Requirements Phase repairing it is simply a matter of changing and reviewing the requirement text.
The process of identifying errors or omissions in a requirement through test procedure definition is referred to as Verifying the Requirement’s Testability. If not enough information exists, or the information provided in the specification is too ambiguous to create a complete test procedure with its related test cases for relevant paths, the specification is not considered to be testable, and may not be suitable for Software Development. Whether a test can be developed for a requirement is a valuable check and should be considered part of the process of approving a requirement as complete.
If a requirement cannot be verified, there is no guarantee that it will be implemented correctly. Being able to develop a test procedure that includes data inputs, steps to verify the requirement, and known expected outputs for each related requirement can assure requirement completeness by confirming that important requirement is not missing, making the requirement difficult or even impossible to implement correctly and un-testable. Developing test procedures for requirements early on allows for early discovery of non-verifiability issues.
Developing test procedures after a software build has been delivered to the Testing Team also risks incomplete test-procedure development because of intensive time pressure to complete the product’s testing cycle. This can manifest in various ways. For example, the test procedure might be missing entirely, or it may not be thoroughly defined, omitting certain paths or data elements that may make a difference in the test outcome. As a result, defect might be missed, or the requirement may be incomplete, as described earlier, and not support the definition of the Necessary of Test Procedures, or even proper software development. Incomplete requirements often result in incomplete implementation.
Early evaluation of the Testability of an application’s requirements can be the basis for defining a testing strategy. While reviewing the testability of requirements, testers might be determine, for example, that using a capture/playback tool would be ideal, allowing execution of some of the tests in automated fashion. Determining this early allows enough lead time to evaluate and implement automated testing tools.

Verifying Requirements (Cont)

Testers need to have guidelines to ensure quality measure for verifying requirement during requirement phase. Following is the checklist that can be used by testers during the requirement phase to verify the quality of requirement. Using this checklist is a first step toward trapping requirement-related defects as early as possible, so they do not propagate to subsequent phases, where they would be more difficult and expensive to find and correct. All stakeholders responsible for requirements should verify that requirements posses the following attributes:

• Correctness

Correctness of a requirement is judged based on what the user wants. Following is the questions that need to be concern: Are the rules and regulations stated correctly? Are the standard being followed? Does the requirement exactly reflect the user’s request? It is imperative that the end user, or a suitable representative, be involved during the requirements phase.

• Completeness

Completeness ensures that no necessary elements are missing from the requirement. The goal is to avoid omitting requirements simply because no one has asked the right question or examined all of the pertinent source documents. Testers should insists that associated Non Functional Requirements, such as performance, security, usability, compatibility, and accessibility are described along with each Functional Requirements usually documented in two steps:

1. A System-wide specification is created that defines the Nonfunctional Requirements that apply to the system.

2. Each requirement description should contain a section titled “Nonfunctional Requirements” documenting any specific nonfunctional needs of that particular requirement that deviate from the system-wide nonfunctional specification.

More details about Functional and Nonfunctional Requirements, I will explain in another posts.

• Consistency

Consistency verifies that there are no internal or external contradictions among the elements within the work products, or between works products. We should ask a question “Does the specification define every essential subject-matter term used within the specification?” We can determine whether the elements used in the requirement are clear and precise. Without clear and consistent definitions, determining whether a requirement is correct becomes a matter of opinion.

• Testability or Verifiability

Testability of the requirement confirms that it is possible to create a test for the Requirement, and that an expected result is known and can be programmatically or visually verified. If a requirement cannot be tested or otherwise verified, this fact and its associated risks must be stated, and the requirement must be adjusted if possible so that it can be tested.

• Feasibility

Feasibility of a requirement ensures that it can be implemented given the budget, schedules, technology, and other resources available.

• Necessity

Necessity verifies that every requirement in the specification is relevant to the system. To test for relevance or necessity, tester checks the requirement against the stated goals for the system. “Does this requirement contribute to those goals?”, “Would the excluding this requirement prevent the system from meeting those goals?”, “Are any other requirements dependent on this requirement?”. Some irrelevant requirements are not really requirements, but proposed solutions.

• Prioritization

Prioritization allows everyone to understand the relative value to stakeholders of the requirement. We use scale from 1 to 5 to specify the level of reward for good performance, and penalty for bad performance on a requirement. If a requirement is absolutely vital to the success of the system, then it has a penalty of 5 and reward of 5. A requirement that would be nice to have but is not really vital might have a penalty of 1 and reward of 3. This knowledge can be used to make prioritization and trade-off decision when the time comes to design the system. This approach needs to balance the perspective of the user against the cost and technical risk associated with a proposed requirement.

• Unambiguousness

Unambiguousness ensures that requirements are stated in a precise and measurable way.

• Traceability

This ensures that each requirement is identified in such a way that it can be associated with all parts of the system where it is used. For any change to requirements, is it possible to identify all parts of the system where this change has an effect