1
Q
Test-Driven Development: What is it?
A
Test-driven development (TDD) is used to develop code guided by automated test cases. The process for test-driven development is:
- Add a test that captures the programmer’s concept of the desired functioning of a small piece of code
- Run the test, which should fail since the code doesn’t exist
- Write the code and run the test in a tight loop until the test passes
- Refactor the code after the test is passed, re-running the test to ensure it continues to pass against the refactored code
- Repeat this process for the next small piece of code, running the previous tests as well as the added tests
2
Q
Test-Driven Development; Expand?
A
The tests written are primarily unit level and are code-focused, though tests may also be written at the integration or system levels.
Test-driven development gained its popularity through Extreme Programming [Beck02], but is also used in other Agile methodologies and sometimes in sequential lifecycles.
3
Q
Test-Driven Development; It helps developers focus on?
A
- Focus on clearly-defined expected results. The tests are automated and are used in continuous integration.
4
Q
Acceptance Test-Driven Development: Define?
A
- Defines acceptance criteria and tests during the creation of user stories.
- Acceptance test-driven development is a collaborative approach that allows every stakeholder to understand how the software component has to behave and what the developers, testers, and business representatives need to ensure this behavior.
5
Q
Acceptance Test-Driven Development: Expand?
A
- Acceptance test-driven development creates reusable tests for regression testing.
- Specific tools support creation and execution of such tests, often within the continuous integration process.
- These tools can connect to data and service layers of the application, which allows tests to be executed at the system or acceptance level.
- Acceptance test-driven development allows quick resolution of defects and validation of feature behavior.
- It helps determine if the acceptance criteria are met for the feature.
6
Q
Behavior-Driven Development: Define?
A
- Allows a developer to focus on testing the code based on the expected behavior of the software. Because the tests are based on the exhibited behavior of the software, the tests are generally easier for other team members and stakeholders to understand.
7
Q
Behavior-Driven Development: Behavior-driven development frameworks?
A
- Can be used to define acceptance criteria based on the given/when/then format:
Given some initial context,
When an event occurs,
Then ensure some outcomes.
8
Q
Behavior-Driven Development: How does it assist developers?
A
- The behavior-driven development framework generates code that can be used by developers to create test cases.
- Behavior-driven development helps the developer collaborate with other stakeholders, including testers, to define accurate unit tests focused on business needs.
8
Q
Behavior-Driven Development: How does it assist developers?
A
- The behavior-driven development framework generates code that can be used by developers to create test cases.
- Behavior-driven development helps the developer collaborate with other stakeholders, including testers, to define accurate unit tests focused on business needs.
9
Q
The Test Pyramid: Define?
A
- A software system may be tested at different levels. Typical test levels are, from the base of the pyramid to the top, unit, integration, system, and acceptance.
- The test pyramid emphasizes having a large number of tests at the lower levels (bottom of the pyramid) and, as development moves to the upper levels, the number of tests decreases (top of the pyramid).
- Usually unit and integration level tests are automated and are created using API-based tools. At the system and acceptance levels, the automated tests are created using GUI-based tools. The test pyramid concept is based on the testing principle of early QA and testing (i.e., eliminating defects as early as possible in the lifecycle).
10
Q
Testing Quadrants, Test Levels, and Testing Types: Define?
A
- Testing quadrants align the test levels with the appropriate test types in the Agile methodology.
- The testing quadrants model, and its variants, helps to ensure that all important test types and test levels are included in the development lifecycle.
- This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.
11
Q
Testing Quadrants, Test Levels, and Testing Types: The four quadrants are as follows:
A
* Quadrant Q1 is unit level, technology facing, and supports the developers. This quadrant contains unit tests. These tests should be automated and included in the continuous integration process.
- Quadrant Q2 is system level, business facing, and confirms product behavior. This quadrant contains functional tests, examples, story tests, user experience prototypes, and simulations. These tests check the acceptance criteria and can be manual or automated. They are often created during the user story development and thus improve the quality of the stories. They are useful when creating automated regression test suites.
- Quadrant Q3 is system or user acceptance level, business facing, and contains tests that critique the product, using realistic scenarios and data. This quadrant contains exploratory testing, scenarios, process flows, usability testing, user acceptance testing, alpha testing, and beta testing. These tests are often manual and are user-oriented.
- Quadrant Q4 is system or operational acceptance level, technology facing, and contains tests that critique the product. This quadrant contains performance, load, stress, and scalability tests, security tests, maintainability, memory management, compatibility and interoperability, data migration, infrastructure, and recovery testing. These tests are often automated.
11
Q
Testing Quadrants, Test Levels, and Testing Types: The four quadrants are as follows:
A
* Quadrant Q1 is unit level, technology facing, and supports the developers. This quadrant contains unit tests. These tests should be automated and included in the continuous integration process.
- Quadrant Q2 is system level, business facing, and confirms product behavior. This quadrant contains functional tests, examples, story tests, user experience prototypes, and simulations. These tests check the acceptance criteria and can be manual or automated. They are often created during the user story development and thus improve the quality of the stories. They are useful when creating automated regression test suites.
- Quadrant Q3 is system or user acceptance level, business facing, and contains tests that critique the product, using realistic scenarios and data. This quadrant contains exploratory testing, scenarios, process flows, usability testing, user acceptance testing, alpha testing, and beta testing. These tests are often manual and are user-oriented.
- Quadrant Q4 is system or operational acceptance level, technology facing, and contains tests that critique the product. This quadrant contains performance, load, stress, and scalability tests, security tests, maintainability, memory management, compatibility and interoperability, data migration, infrastructure, and recovery testing. These tests are often automated.
12
Q
Testing Quadrants, Test Levels, and Testing Types: Apply to which test type, static or dynamic?
A
The testing quadrants apply to dynamic testing rather than static testing.
13
Q
The Role of a Tester: Teamwork :The following are organizational and behavioral best practices in Scrum teams:
A
- Cross-functional: Each team member brings a different set of skills to the team. The team works together on test strategy, test planning, test specification, test execution, test evaluation, and test results reporting.
- Self-organizing: The team may consist only of developers, but, as noted in Section 2.1.5, ideally there would be one or more testers.
- Co-located: Testers sit together with the developers and the product owner.
- Collaborative: Testers collaborate with their team members, other teams, the stakeholders, the product owner, and the Scrum Master.
- Empowered: Technical decisions regarding design and testing are made by the team as a whole (developers, testers, and Scrum Master), in collaboration with the product owner and other teams if needed.
- Committed: The tester is committed to question and evaluate the product’s behavior and characteristics with respect to the expectations and needs of the customers and users.
- Transparent: Development and testing progress is visible on the Agile task board (see Section 2.2.1).
- Credible: The tester must ensure the credibility of the strategy for testing, its implementation, and execution, otherwise the stakeholders will not trust the test results. This is often done by providing information to the stakeholders about the testing process.
- Open to feedback: Feedback is an important aspect of being successful in any project, especially in Agile projects. Retrospectives allow teams to learn from successes and from failures.
- Resilient: Testing must be able to respond to change, like all other activities in Agile projects.
14
Q
The Role of a Tester: Sprint Zero:
A
- Sprint zero is the first iteration of the project where many preparation activities take place.
- Sprint zero sets the direction for what testing needs to achieve and how testing needs to achieve it throughout the sprints.
15
Q
The Role of a Tester: Sprint Zero: The tester collaborates with the team on the following activities during this iteration:
A
- Identify the scope of the project (i.e., the product backlog)
- Create an initial system architecture and high-level prototypes
- Plan, acquire, and install needed tools (e.g., for test management, defect management, test automation, and continuous integration)
- Create an initial test strategy for all test levels, addressing (among other topics) test scope, technical risks, test types (see Section 3.1.3), and coverage goals
- Perform an initial quality risk analysis (see Section 3.2.1)
- Define test metrics to measure the test process, the progress of testing in the project, and product quality
- Specify the definition of “done”
- Create the task board (see Section 2.2.1)
- Define when to continue or stop testing before delivering the system to the customer
16
Q
The Role of a Tester: Integration
A
- In Agile projects, the objective is to deliver customer value on a continuous basis (preferably in every sprint).
- To enable this, the integration strategy should consider both design and testing.
- To enable a continuous testing strategy for the delivered functionality and characteristics, it is important to identify all dependencies between underlying functions and features.
17
Q
The Role of a Tester: Test Planning
A
- Since testing is fully integrated into the Agile team, test planning should start during the release planning session and be updated during each sprint.
- Sprint planning results in a set of tasks to put on the task board, where each task should have a length of one or two days of work. In addition, any testing issues should be tracked to keep a steady flow of testing.
18
Q
The Role of a Tester: Agile Testing Practices: Many practices may be useful for testers in a scrum team, some of which include:
A
- Pairing: Two team members (e.g., a tester and a developer, two testers, or a tester and a product owner) sit together at one workstation to perform a testing or other sprint task.
- Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones.
- Mind mapping: Mind mapping is a useful tool when testing [Crispin08]. For example, testers can use mind mapping to identify which test sessions to perform, to show test strategies, and to describe test data.
19
Q
How do you Assess Quality Risks in Agile Projects?:
A
- Risk identification, analysis, and risk mitigation strategies can be used by the testers in Agile teams to help determine an acceptable number of test cases to execute
20
Q
Assessing Quality Risks in Agile Projects: Define risk:
A
- Risk is the possibility of a negative or undesirable outcome or event.
- The level of risk is found by assessing the likelihood of occurrence of the risk and the impact of the risk.
- When the primary effect of the potential problem is on product quality, potential problems are referred to as quality risks or product risks.
21
Q
Assessing Quality Risks in Agile Projects: What are potential problems referred to When the primary effect of the potential problem is on project success?
A
- project risks or planning risks
22
Q
Assessing Quality Risks in Agile Projects: In Agile projects, quality risk analysis takes place at two places:
A
- Release planning: business representatives who know the features in the release provide a high-level overview of the risks, and the whole team, including the tester(s), may assist in the risk identification and assessment.
- Iteration planning: the whole team identifies and assesses the quality risks.
23
Assessing Quality Risks in Agile Projects: What are Higher and Lower Risks?:
Tasks associated with higher risks should start earlier and involve more testing effort. Tasks associated with lower risks should start later and involve less testing effort.
24
Estimating Testing Effort Based on Content and Risk:
A high estimate usually means that the story is not well understood or should be broken down into multiple smaller stories.
25
Estimating Testing Effort Based on Content and Risk: What is a poker game?
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss the differences in estimates after which the poker round is repeated until agreement is reached, either by consensus or by applying rules (e.g., use the median, use the highest score) to limit the number of poker rounds.
26
Estimating Testing Effort Based on Content and Risk: Estimation technique?
A common estimation technique used in Agile projects is planning poker, a consensus-based technique.
27
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing:
Agile projects outline initial requirements as user stories in a prioritized backlog at the start of the project. Initial requirements are short and usually follow a predefined format
28
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Non-functional requirements may follow a predefined format or standard, such as?
ISO25000, or an industry specific standard.
29
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: The user stories serve as an important test basis. Other possible test bases include:
* Experience from previous projects
* Existing functions, features, and quality characteristics of the system
* Code, architecture, and design
* User profiles (context, system configurations, and user behavior)
* Information on defects from existing and previous projects
* A categorization of defects in a defect taxonomy
* Applicable standards (e.g., [DO-178B] for avionics software)
* Quality risks (see Section 3.2.1)
30
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: The user stories serve as an important test basis. Other possible test bases include:
* Experience from previous projects
* Existing functions, features, and quality characteristics of the system
* Code, architecture, and design
* User profiles (context, system configurations, and user behavior)
* Information on defects from existing and previous projects
* A categorization of defects in a defect taxonomy
* Applicable standards (e.g., [DO-178B] for avionics software)
* Quality risks (see Section 3.2.1)
31
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: To be testable, acceptance criteria should address the following topics where relevant:
* Functional behavior: The externally observable behavior with user actions as input operating under certain configurations.
* Quality characteristics: How the system performs the specified behavior. The characteristics may also be referred to as quality attributes or non-functional requirements. Common quality characteristics are performance, reliability, usability, etc.
* Scenarios (use cases): A sequence of actions between an external actor (often a user) and the system, in order to accomplish a specific goal or business task.
* Business rules: Activities that can only be performed in the system under certain conditions defined by outside procedures and constraints (e.g., the procedures used by an insurance company to handle insurance claims).
* External interfaces: Descriptions of the connections between the system to be developed and the outside world. External interfaces can be divided into different types (user interface, interface to other systems, etc.).
* Constraints: Any design and implementation constraint that will restrict the options for the developer. Devices with embedded software must often respect physical constraints such as size, weight, and interface connections.
* Data definitions: The customer may describe the format, data type, allowed values, and default values for a data item in the composition of a complex business data structure (e.g., the ZIP code in a U.S. mail address).
32
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: In addition to the user stories and their associated acceptance criteria, other information is relevant for the tester, including:
* How the system is supposed to work and be used
* The system interfaces that can be used/accessed to test the system
* Whether current tool support is sufficient
* Whether the tester has enough knowledge and skill to perform the necessary tests
33
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: Unit testing
* 100% decision coverage where possible, with careful reviews of any infeasible paths
* Static analysis performed on all code
* No unresolved major defects (ranked based on priority and severity)
* No known unacceptable technical debt remaining in the design and the code [Jones11]
* All code, unit tests, and unit test results reviewed
* All unit tests automated
* Important characteristics are within agreed limits (e.g., performance)
34
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: Integration testing
* All functional requirements tested, including both positive and negative tests, with the number of tests based on size, complexity, and risks
* All interfaces between units tested
* All quality risks covered according to the agreed extent of testing
* No unresolved major defects (prioritized according to risk and importance)
* All defects found are reported
* All regression tests automated, where possible, with all automated tests stored in a common repository
35
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: System testing
* End-to-end tests of user stories, features, and functions
* All user personas covered
* The most important quality characteristics of the system covered (e.g., performance, robustness, reliability)
* Testing done in a production-like environment(s), including all hardware and software for all supported configurations, to the extent possible
* All quality risks covered according to the agreed extent of testing
* All regression tests automated, where possible, with all automated tests stored in a common repository
* All defects found are reported and possibly fixed
* No unresolved major defects (prioritized according to risk and importance)
36
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: User Story
* The user stories selected for the iteration are complete, understood by the team, and have detailed, testable acceptance criteria
* All the elements of the user story are specified and reviewed, including the user story acceptance tests, have been completed
* Tasks necessary to implement and test the selected user stories have been identified and estimated by the team
37
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: Feature
* All constituent user stories, with acceptance criteria, are defined and approved by the customer
* The design is complete, with no known technical debt
* The code is complete, with no known technical debt or unfinished refactoring
* Unit tests have been performed and have achieved the defined level of coverage
* Integration tests and system tests for the feature have been performed according to the defined coverage criteria
* No major defects remain to be corrected
* Feature documentation is complete, which may include release notes, user manuals, and on-line help functions
38
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: Iteration
* All features for the iteration are ready and individually tested according to the feature level criteria
* Any non-critical defects that cannot be fixed within the constraints of the iteration added to the product backlog and prioritized
* Integration of all features for the iteration completed and tested
* Documentation written, reviewed, and approved
At this point, the software is potentially releasable because the iteration has been successfully completed, but not all iterations result in a release.
39
Techniques in Agile Projects: Acceptance Criteria, Adequate Coverage, and Other Information for Testing: Test Levels: Release
* Coverage: All relevant test basis elements for all contents of the release have been covered by testing. The adequacy of the coverage is determined by what is new or changed, its complexity and size, and the associated risks of failure.
* Quality: The defect intensity (e.g., how many defects are found per day or per transaction), the defect density (e.g., the number of defects found compared to the number of user stories, effort, and/or quality attributes), estimated number of remaining defects are within acceptable limits, the consequences of unresolved and remaining defects (e.g., the severity and priority) are understood and acceptable, the residual level of risk associated with each identified quality risk is understood and acceptable.
* Time: If the pre-determined delivery date has been reached, the business considerations associated with releasing and not releasing need to be considered.
* Cost: The estimated lifecycle cost should be used to calculate the return on investment for the delivered system (i.e., the calculated development and maintenance cost should be considerably lower than the expected total sales of the product). The main part of the lifecycle cost often comes from maintenance after the product has been released, due to the number of defects escaping to production.
40
Techniques in Agile Projects: Applying Acceptance Test-Driven Development
* Acceptance test-driven development is a test-first approach.
* Test cases are created prior to implementing the user story.
* The test cases are created by the Agile team, including the developer, the tester, and the business representatives [Adzic09] and may be manual or automated.
* The first step is a specification workshop where the user story is analyzed, discussed, and written by developers, testers, and business representatives.
*Any incompleteness, ambiguities, or errors in the user story are fixed during this process.
41
Techniques in Agile Projects: How do you Apply Acceptance Test-Driven Development?
* Typically, the first tests are the positive tests, confirming the correct behavior without exception or error conditions, comprising the sequence of activities executed if everything goes as expected.
* After the positive path tests are done, the team should write negative path tests and cover non-functional attributes as well (e.g., performance, usability).
* Tests are expressed in a way that every stakeholder is able to understand, containing sentences in natural language involving the necessary preconditions, if any, the inputs, and the related outputs.
* No two examples should describe the same characteristics of the user story.
42
Techniques in Agile Projects: Functional and Non-Functional Black Box Test Design:
* Testers can apply traditional black box test design techniques such as equivalence partitioning, boundary value analysis, decision tables, and state transition testing to create these tests.
* In many situations, non-functional requirements can be documented as user stories. Black box test design techniques (such as boundary value analysis) can also be used to create tests for non-functional quality characteristics.
* The user story might contain performance or reliability requirements.
43
Techniques in Agile Projects: Exploratory Testing and Agile Testing:
* Exploratory testing is important in Agile projects due to the limited time available for test analysis and the limited details of the user stories.
* In order to achieve the best results, exploratory testing should be combined with other experience-based techniques as part of a reactive testing strategy, blended with other testing strategies such as analytical risk-based testing, analytical requirements-based testing, model-based testing, and regression-averse testing.
44
Techniques in Agile Projects: Exploratory Testing and Agile Testing: Test charter:
* In exploratory testing, test design and test execution occur at the same time, guided by a prepared test charter.
* A test charter provides the test conditions to cover during a time-boxed testing session.
45
Techniques in Agile Projects: Exploratory Testing and Agile Testing: A Test Charter includes which information?
* Actor: intended user of the system
* Purpose: the theme of the charter including what particular objective the actor wants to achieve, i.e., the test conditions
* Setup: what needs to be in place in order to start the test execution
* Priority: relative importance of this charter, based on the priority of the associated user story or the risk level
* Reference: specifications (e.g., user story), risks, or other information sources
* Data: whatever data is needed to carry out the charter
* Activities: a list of ideas of what the actor may want to do with the system (e.g., “Log on to the system as a super user”) and what would be interesting to test (both positive and negative tests)
* Oracle notes: how to evaluate the product to determine correct results (e.g., to capture what happens on the screen and compare to what is written in the user’s manual)
* Variations: alternative actions and evaluations to complement the ideas described under activities
46
Techniques in Agile Projects: Exploratory Testing and Agile Testing: To manage exploratory testing a method called session-based test management can be used:
A session is defined as an uninterrupted period of testing which could last from 60 to 120 minutes.
Test sessions include the following:
* Survey session (to learn how it works)
* Analysis session (evaluation of the functionality or characteristics)
* Deep coverage (corner cases, scenarios, interactions)
47
Techniques in Agile Projects: Exploratory Testing and Agile Testing: Examples of relevant questions to ask about what to test:
* What is most important to find out about the system?
* In what way may the system fail?
* What happens if.....?
* What should happen when.....?
* Are customer needs, requirements, and expectations fulfilled?
* Is the system possible to install (and remove if necessary) in all supported upgrade paths?
48
Techniques in Agile Projects: Exploratory Testing and Agile Testing: A set of heuristics examples that can be applied when testing:
* Boundaries
* CRUD (Create, Read, Update, Delete)
* Configuration variations
* Interruptions (e.g., log off, shut down, or reboot)
49
Techniques in Agile Projects: Exploratory Testing and Agile Testing: The following list provides examples of information that may be useful to document:
* Test coverage: what input data have been used, how much has been covered, and how much remains to be tested
* Evaluation notes: observations during testing, do the system and feature under test seem to be stable, were any defects found, what is planned as the next step according to the current observations, and any other list of ideas
* Risk/strategy list: which risks have been covered and which ones remain among the most important ones, will the initial strategy be followed, does it need any changes
* Issues, questions, and anomalies: any unexpected behavior, any questions regarding the efficiency of the approach, any concerns about the ideas/test attempts, test environment, test data, misunderstanding of the function, test script or the system under test
* Actual behavior: recording of actual behavior of the system that needs to be saved (e.g., video, screen captures, output data files)
50
Tools in Agile Projects: Task Management and Tracking Tools: These tools serve the following purposes:
* Record stories and their relevant development and test tasks, to ensure that nothing gets lost during a sprint
* Capture team members’ estimates on their tasks and automatically calculate the effort required to implement a story, to support efficient iteration planning sessions
* Associate development tasks and test tasks with the same story, to provide a complete picture of the team’s effort required to implement the story
* Aggregate developer and tester updates to the task status as they complete their work, automatically providing a current calculated snapshot of the status of each story, the iteration, and the overall release
Provide a visual representation (via metrics, charts, and dashboards) of the current state of each user story, the iteration, and the release, allowing all stakeholders, including people on geographically distributed teams, to quickly check status
* Integrate with configuration management tools, which can allow automated recording of code check-ins and builds against tasks, and, in some cases, automated status updates for tasks
51
Tools in Agile Projects: Communication and Information Sharing Tools:
* In addition to e-mail, documents, and verbal communication, Agile teams often use three additional types of tools to support communication and information sharing: wikis, instant messaging, and desktop sharing.
52
Tools in Agile Projects: Communication and Information Sharing Tools: Wikis:
Wikis allow teams to build and share an online knowledge base on various aspects of the project, including the following:
* Product feature diagrams, feature discussions, prototype diagrams, photos of whiteboard discussions, and other information
* Tools and/or techniques for developing and testing found to be useful by other members of the team
* Metrics, charts, and dashboards on product status, which is especially useful when the wiki is integrated with other tools such as the build server and task management system, since the tool can update product status automatically
* Conversations between team members, similar to instant messaging and email, but in a way that is shared with everyone else on the team
53
Tools in Agile Projects: Communication and Information Sharing Tools: Instant messaging:
Instant messaging, audio teleconferencing, and video chat tools provide the following benefits:
* Allow real time direct communication between team members, especially distributed teams
* Involve distributed teams in standup meetings
* Reduce telephone bills by use of voice-over-IP technology, removing cost constraints
that could reduce team member communication in distributed settings
54
Tools in Agile Projects: Communication and Information Sharing Tools: Desktop sharing:
Desktop sharing and capturing tools provide the following benefits:
* In distributed teams, product demonstrations, code reviews, and even pairing can occur
* Capturing product demonstrations at the end of each iteration, which can be posted to the team’s wiki
55
Tools in Agile Projects: Configuration Management Tools:
* On Agile teams, configuration management tools may be used not only to store source code and automated tests, but manual tests and other test work products are often stored in the same repository as the product source code.
* This provides traceability between which versions of the software were tested with which particular versions of the tests, and allows for rapid change without losing historical information.
* The main types of version control systems include centralized source control systems and distributed version control systems.
56
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Test design tools:
* Test design tools: Use of tools such as mind maps have become more popular to quickly design and define tests for a new feature.
57
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Test case management tools:
* Test case management tools: The type of test case management tools used in Agile may be part of the whole team’s application lifecycle management or task management tool.
58
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Test data preparation and generation tools:
* Tools that generate data to populate an application’s database are very beneficial when a lot of data and combinations of data are necessary to test the application.
* These tools can also help re-define the database structure as the product undergoes changes during an Agile project and refactor the scripts to generate the data.
* This allows quick updating of test data as changes occur.
* Some test data preparation tools use production data sources as a raw material and use scripts to remove or anonymize sensitive data.
* Other test data preparation tools can help with validating large data inputs or outputs.
59
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Test data load tools:
* Test data load tools: After data has been generated for testing, it needs to be loaded into the application.
* Manual data entry is often time consuming and error prone, but data load tools are available to make the process reliable and efficient.
* In fact, many of the data generator tools include an integrated data load component. In other cases, bulk-loading using the database management systems is also possible.
60
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Automated test execution tools:
* Automated test execution tools: There are test execution tools which are more aligned to Agile testing.
* Specific tools are available via both commercial and open source avenues to support test first approaches, such as behavior-driven development, test-driven development, and acceptance test-driven development.
* These tools allow testers and business staff to express the expected system behavior in tables or natural language using keywords.
61
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Exploratory test tools:
* Exploratory test tools: Tools that capture and log activities performed on an application during an exploratory test session are beneficial to the tester and developer, as they record the actions taken.
* This is useful when a defect is found, as the actions taken before the failure occurred have been captured and can be used to report the defect to the developers.
* Logging steps performed in an exploratory test session may prove to be beneficial if the test is ultimately included in the automated regression test suite.
62
Tools in Agile Projects: Test Design, Implementation, and Execution Tools: Cloud Computing and Virtualization Tools:
* Virtualization allows a single physical resource (server) to operate as many separate, smaller resources.
* When virtual machines or cloud instances are used, teams have a greater number of servers available to them for development and testing.
* This can help to avoid delays associated with waiting for physical servers.
* Provisioning a new server or restoring a server is more efficient with snapshot capabilities built into most virtualization tools.
* Some test management tools now utilize virtualization technologies to snapshot servers at the point when a fault is detected, allowing testers to share the snapshot with the developers investigating the fault.
