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

The trio of test topics: plans, estimates and strategies depend on a number of factors, including the level, targets and objectives of the testing we're setting out to do. Writing a plan, preparing an estimate and selecting test strategies tend to happen concurrently and ideally during the planning period for the overall project, though we must ready to revise them as the project proceeds and we gain more information. The purpose and substance of test plans While people tend to have different definitions of what goes in a test plan, for us a test plan is the project plan for the testing work to be done . It is not a test design specification, a collection of testcases or a set of test procedures; in fact, most of our test plans do not address that level of detail. Why do we write test plans? We have three main reasons. First, writing a test plan guides our thinking . We find that if we can explain something in words, we understand it. If not, there's a good chance we d

Testing is a complex activity. Testing is often a distinct sub-project within the larger softwaredevelopment, maintenance, or integration project. Testing usually accounts for a substantial proportion of the overall project budget. Therefore, its important to manage the testing that is done. Independent and integrated testing The approaches to organizing a test team vary, as do the places in the organization structure where the test team fits. Since testing is an assessment of quality, and since that assessment is not always positive, many organizations strive to create an organizational climate where testers can deliver an independent, objective assessment of quality. When thinking about how independent the test team is, recognize that independence is not an either/orcondition, but a continuum. At one end of the continuum lies the absence of independence, where the programmer performs testing within the programming team. Moving toward independence, you find an integrated tester