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.
0 komentar:
Post a Comment