Traditional Elements of Test Process Agile Testing

The final section of this chapter reviews the typical elements of a traditional testing process,focusing in detail on the relationship between the classic model of testing and the development approaches described in the earlier sections.Many traditional views of software testing are based on the V-model, which itself is largely based on the waterfall view of software development. The V-model approach to organizing testing has also been applied to spiral and other models of software development, producing a number of variants, such as the W-model.

A typical interpretation of the V-model

typical interpretation of the V-model

The V-model provides a powerfulmeans of assisting testing practitioners to move testing earlier into the software development life cycle, and to encourage more frequent testing.

A major tenet of the V-model is that testing can begin as early as the requirements acquisition phase – with the test manager reviewing the requirements to determine the resources needed for testing, and with the test analyst or designer reviewing the requirements to determine testability and identify errors in the requirements (such as omissions, contradictions, duplications, and items that need further clarification). As a generalization, we can identify four basic test levels or phases associated with the V-model approach to testing:3

  1. Unit test (also known as developer or component testing) is typically conducted by the developer to ensure that their code meets its requirements, and is the 3 However, in practice we might also include other variations of the testing phases, such as systems integration testing(often employed where the application under test has a requirement to interact witha number of other independent systems), user acceptance testing,and operations acceptance testing. lowest level of testing normally identified. Historically, unit testing was a manual process(often involving a test harness or some other means of simulating other planned software components that would communicate with the component under test, but which had not been coded at that point). Today, unit testing is usually conducted using one of the many developer testing tools that are available.
  2. Integration test (also known as module testing)is used to demonstrate that the modules that make up the application under test, interface and interact together correctly. As a general rule(but clearly dependent on the size and importance of the project), integration testing is conducted by the developers under the supervision of the project leader. Where a more formal approach to development and testing is being followed, possibly on a large or commercially important project, an independent tester or test team could be involved in conducting integration testing.
  3. System test is employed to establish confidence that the (now completed)application under test will pass its acceptance test.During system testing, the functional and structural stability of the system is examined, as well as the nonfunctional aspects of the application under test, such as performance and reliability.typically,although again dependent on the size and importance of the project, system testing is conducted by an independent testing team. Often, a customer or user representative will be invited to witness the system test.
  4. Acceptance test (also known as user acceptance test or UAT)is used to ensure that the application under test meets its business requirements, and to provide confidence that the system works correctly and is usable before being formally handed over to the end users. Typically, UAT will be conducted by nominated. user representatives (sometimes with the assistance of an independent testing representative or team).

The role of regression testing is also worth noting; its purpose is to provide confidence that the application under test still functions correctly following a new build or new release of the software(perhaps caused by requests from the customer for modifications or enhancements to the software, or a change to the environment in which the software runs, such as a new release of the underlying operating system). Within each of the test levels or phases, we can identify a number of common elements that they all share.In each testing phase the following must be addressed:

  • Overview of test phase – providing information on the purpose of the testing phase, its goals, and its characteristics.Information should also be provided relating this testing phase to the appropriate development phase within the V-model and to the adjacent testing phases.
  • Test phase approach and test data requirements – describing the overall approach to the testing used in this phase (such as white box or black box testing; see [4]),and addressing the format,content,and origin of the data required to successfully test the software.
  • Test planning and resources – providing the plan used to drive the testing conducted during this phase, its timescales, milestones, dependencies, risks and deliverables, as well as information on the resources needed to complete the testing successfully(including both the staff and the physical resources,such as\computer equipment).
  • Roles and responsibilities – specifying the staff required to fulfill the various roles within this phase(such as test team leader, test analyst, or tester) and their specific responsibilities(e.g., “the test analyst shall be responsible for designing and implementing the test scripts required to test the application under test . . . ”). Issues of reporting,management, and liaison should also be specified.
  • Inputs and outputs – specifying those artifacts (the items created and/or used within phases) required as inputs to this phase to ensure successful testing of the application under test(such as the test plan,the software itself, and the requirements documentation), artifacts created during this phase(such as test designs, test scripts,and test result record forms), and artifacts output from this phase (such as the tested software, completed test result record forms, and the test summary report).
  • Specific test techniques for this test phase – describing any specific testing techniques (such as boundary analysis, equivalence partitioning, or state transition analysis;see[4])or tools to be used within this testing phase such as test execution tools;.
  • Reusable assets – providing test practitioners with access to standard reusable assets(such as test plan,test script, and test summary report templates) that are shared across the project (or even across an organization). These assets can ensure that significant project time, effort, and cost are saved by preventing different practitioners on different projects from reinventing different versions of the same artifacts again and again. Standardization also makes it easier for staff to move between projects without having to relearn a new and different set of project documentation.

The preceding information is traditionally recorded in one or more testing documents (usually within the test plan document and the test specification document). Although this approach to software testing has been widely adopted and used, as with the traditional development processes, this classic view of testing process has its critics:

  • A key criticism leveled against the approach is that it is underpinned by the V-model,which is itself based on the frequently criticized waterfall model of software development. The relevance of the classic viewof test process is often questioned when applied to more contemporary, agile views of software development.
  • Where the approach is used on small, simple projects with low complexity,practitioners often complain that thereis “too much process,” and that the reality is that “experienced testers don’t need so much detailed guidance. ”In effect,the process itself is criticized for taking too much time and effort to follow.
  • Paradoxically, the use of a formal and prescriptive testing process may also be criticized for preventing testers from finding defects; many a well-hidden defect has been unearthed by the intuition of a skilled and experienced tester. Testing places high reliance on practitioners who are able to track down defects using their creative and lateral thinking skills, but a highly prescriptive testing solution is often thought to constrain and inhibit such skills.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics