The Differences between Testing in Traditional and Agile Approaches Flashcards
Testing and Development Activities
- At the beginning of the project, there is a release planning period.
- This is followed by a sequence of iterations. At the beginning of each iteration, there is an iteration planning period.
- Once iteration scope is established, the selected user stories are developed, integrated with the system, and tested.
- These iterations are highly dynamic, with development, integration, and testing activities taking place throughout each iteration, and with considerable parallelism and overlap.
- Testing activities occur throughout the iteration, not as a final activity.
Testers, developers, and business stakeholders all have a role in testing, Explain why?
- Developers perform unit tests as they develop features from the user stories.
- Testers then test those features.
- Business stakeholders also test the stories during implementation.
- Business stakeholders might use written test cases, but they also might simply experiment with and use the feature in order to provide fast feedback to the development team.
Testing and Development Activities: The best practice is that no feature is considered done until when?
- It has been integrated and tested with the system
- To address defects remaining from the previous iteration at the beginning of the next iteration, as part of the backlog for that iteration (referred to as “fix bugs first”).
Testing and Development Activities: When risk-based testing is used as one of the test strategies, what happens?
- High-level risk analysis occurs during release planning, with testers often driving that analysis
- The specific quality risks associated with each iteration are identified and assessed in iteration planning
- This risk analysis can influence the sequence of development as well as the priority and depth of testing for the features.
- It also influences the estimation of the test effort required for each feature.
Testing and Development Activities: Extreme Programming:
- Pairing is used.
- Pairing can involve testers working together in twos to test a feature
- Pairing can also involve a tester working collaboratively with a developer to develop and test a feature.
Testing and Development Activities: Extreme Programming:
- Pairing is used.
- Pairing can involve testers working together in twos to test a feature
- Pairing can also involve a tester working collaboratively with a developer to develop and test a feature.
Testing and Development Activities: Test automation at all levels of testing occurs in many Agile teams, Why?:
- Because of the heavy use of test automation, a higher percentage of the manual testing on Agile projects tends to be done using experience-based and defect-based techniques such as software attacks, exploratory testing, and error guessing.
Testing and Development Activities: Why do Agile teams tend to favor testers with a strong technical and test automation background?
*While developers will focus on creating unit tests, testers should focus on creating automated integration, system, and system integration tests
Testing and Development Activities: Why is lightweight work product documentation is favored in Agile projects?
One core Agile principle is that change may occur throughout the project.
Testing and Development Activities: Changes to existing features have testing implications, especially regression testing implications. What is the one way to manage it?:
- The use of automated testing is one way of managing the amount of test effort associated with change.
- However, it’s important that the rate of change not exceed the project team’s ability to deal with the risks associated with those changes.
Project Work Products: Project work products of immediate interest to Agile testers typically fall into three categories:
- Business-oriented work products that describe what is needed (e.g., requirements specifications) and how to use it (e.g., user documentation)
- Development work products that describe how the system is built (e.g., database entity-relationship diagrams), that actually implement the system (e.g., code), or that evaluate individual pieces of code (e.g., automated unit tests)
- Test work products that describe how the system is tested (e.g., test strategies and plans), that actually test the system (e.g., manual and automated tests), or that present test results (e.g., test dashboards as discussed in Section 2.2.1)
Project Work Products: Typical business-oriented work products on Agile projects include?
- User stories and acceptance criteria.
- User stories are the Agile form of requirements specifications, and should explain how the system should behave with respect to a single, coherent feature or function.
- A user story should define a feature small enough to be completed in a single iteration.
Project Work Products: Define Epic?
- Larger collections of related features, or a collection of sub-features that make up a single complex feature.
- Epics may include user stories for different development teams.
- Each epic and its user stories should have associated acceptance criteria.
Project Work Products: Which approach is referred to as test first or test-driven development?
- Tests might be created after the development of code. In some cases, though, developers create tests incrementally, before each portion of the code is written, in order to provide a way of verifying, once that portion of code is written, whether it works as expected.
Project Work Products: Typical tester work products on Agile projects include?
- Automated tests, as well as documents such as test plans, quality risk catalogs, manual tests, defect reports, and test results logs.
- Testers will also produce test metrics from defect reports and test results logs
Project Work Products: Which work products may be prepared to satisfy auditors, regulations, and other requirements?
- Teams transform user stories and acceptance criteria into more formal requirements specifications. Vertical and horizontal traceability reports.
Project Work Products: Which work products may be prepared to satisfy auditors, regulations, and other requirements?
- Teams transform user stories and acceptance criteria into more formal requirements specifications. Vertical and horizontal traceability reports.
Test Levels: What are Test Levels?
- Are test activities that are logically related, often by the maturity or completeness of the item under test.
Test Levels: In sequential lifecycle models, the test levels are often defined such that the exit criteria of one level are part of the entry criteria for the next level. In some iterative models, this rule does not apply. Why?
- Test levels overlap. Requirement specification, design specification, and development activities may overlap with test levels.
Test Levels: During an iteration, any given user story will typically progress sequentially through the following test activities:
- Unit testing, typically done by the developer
- Feature acceptance testing, which is sometimes broken into two activities:
- Feature verification testing, which is often automated, may be done by developers or testers, and involves testing against the user story’s acceptance criteria
- Feature validation testing, which is usually manual and can involve developers, testers, and business stakeholders working collaboratively to determine whether the feature is fit for use, to improve visibility of the progress made, and to receive real feedback from the business stakeholders.