Software Testing

Test Log Identifier Some type of unique company generated number to identify this test log, its level and the level of software that it is related to. Preferably the test log level will be the same as the related test case or procedure level. Ideally the test log naming convention should follow the same general rules as the testware it is related to. This is to assist in coordinating software and testware versions within configuration management.        ·  Unique "short" name for the log        ·  Version date and version number of log Description ·  Items being tested and any supporting reference materials        ·  Case Specification        ·  Procedure specification        ·  Transmittal report ·  Date & time ·  Executed by        ·  Tester        ·  Observer ·  Environment         ·  Especially any variances from the planned test environment Activity and Event Entries ·  Date/time       ·  Beginning of each significant activity       ·  End of each

Finally, moving back up to a higher level, think about what would be true about the project when the project was ready to start executing tests. The factors to consider in such decisions are often called  'entry criteria'  and  'exit criteria.' For such criteria, typical factors are: •  Acquisition and supply : the availability of staff, tools, systems and other materials required. •  Test items : the state that the items to be tested must be in to start and to finish testing. •  Defects : the number known to be present, the arrival rate, the number predicted to remain, and the  number resolved. •  Tests : the number run, passed, failed, blocked, skipped, and so forth. •  Coverage : the portions of the test basis, the software code or both that have been tested and which have not. •  Quality : the status of the important quality characteristics for the system. •  Money : the cost of finding the next defect in the current level of testing com pared to the cost o

At a high level, you need to consider the purpose served by the testing work. In terms of the overall organizational needs, this purpose is referred to variously as the test team's mission or the organization's testing policy. In terms of the specific project, understanding the purpose of testing means knowing the answers to questions such as: • What is in scope and what is out of scope for this testing effort? • What are the test objectives? • What are the important project and product risks? • What constraints affect testing (e.g., budget limitations, hard deadlines, etc.)? • What is most critical for this product and project? • Which aspects of the product are more (or less) testable? • What should be the overall test execution schedule and how should we decide the order in which to run specific tests? In addition, it is need to decide how to split the testing work into various levels (e.g., component, integration, system and acceptance). Moving down into the

Test plan identifier  Test deliverables Introduction Test tasks Test items Environmental needs Features to be tested Responsibilities Features not to be tested Staffing and training needs Approach Schedule Item pass/fail criteria Risks and contingencies Suspension and resumption criteria Approvals