In an Agile testing team, testers must closely collaborate with all other team members and with business stakeholders. This has a number of implications in terms of agile tester skills must have and the activities they perform within an Agile team.

Agile Tester Skills

A tester in an Agile team should be competent in test automation, test-driven development, acceptance test-driven development, white-box, black-box, and experience-based testing.

As Agile methodology depend heavily on collaboration, communication, and interaction between the team members as well as stakeholders outside the team, testers in an Agile team should have good interpersonal skills. Below are the Agile Tester Skills –

• Be positive and solution-oriented with team members and stakeholders
• Display critical, quality-oriented, skeptical thinking about the product
• Actively acquire information from stakeholders (rather than relying entirely on written specifications)
• Accurately evaluate and report test results, test progress, and product quality
• Work effectively to define testable user stories, especially acceptance criteria, with customer representatives and stakeholders
• Collaborate within the team, working in pairs with programmers and other team members
• Respond to change quickly, including changing, adding, or improving test cases
• Plan and organize their own work

Continuous skills growth, including interpersonal skills growth, is essential for all testers, including those on Agile teams.

The Role of a Tester in an Agile Team

The role of a tester in an Agile team includes activities that generate and provide feedback not only on test status, test progress, and product quality, but also on process quality. In addition to the activities described elsewhere in this syllabus, these activities include:

• Understanding, implementing, and updating the test strategy
• Measuring and reporting test coverage across all applicable coverage dimensions o Ensuring proper use of testing tools
• Configuring, using, and managing test environments and test data o Reporting defects and working with the team to resolve them
• Coaching other team members in relevant aspects of testing
• Ensuring the appropriate testing tasks are scheduled during release and iteration planning
• Actively collaborating with developers and business stakeholders to clarify requirements, especially in terms of testability, consistency, and completeness
• Participating proactively in team retrospectives, suggesting and implementing improvements

Within an Agile team, each team member is responsible for product quality and plays a role in performing test-related tasks.

Agile organizations may encounter some test-related organizational risks:

• Testers work so closely to developers that they lose the appropriate tester mindset
• Testers become tolerant of or silent about inefficient, ineffective, or low-quality practices within the team
• Testers cannot keep pace with the incoming changes in time-constrained iterations
• To mitigate these risks, organizations may consider variations for preserving independence.

The Role of a Tester in a Scrum Lifecycle

Throughout this study content, general reference has been made to Agile methods and techniques, and the role of a tester and agile tester skills within various Agile lifecycles. This subsection looks specifically at the role of a tester in a project following a Scrum lifecycle .

Teamwork

Teamwork is a fundamental principle in Agile development. Agile emphasizes the whole-team approach consisting of developers, testers, and business representatives working together. The following are organizational and behavioural best practices in Scrum teams:

• 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 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
• Transparent: Development and testing progress is visible on the Agile task board.
• 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.

These best practices maximize the likelihood of successful testing in Scrum projects and agile tester skills.

The First Sprint

In the first iteration of the Scrum many preparation activities take place. The tester collaborates with the team on the following activities during this iteration:

• 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, and coverage goals
• Perform an initial quality risk analysis
• 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
• Define when to continue or stop testing before delivering the system to the customer
• First Sprint sets the direction for what testing needs to achieve and how testing needs to achieve it throughout the sprints.

Integration

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.

Test Planning

Since testing is fully integrated into the Agile team, test planning should start during the release planning session and be updated during each sprint. Test planning for the release and each sprint should address the issues.

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.

Agile Testing Practices in scrums

Many practices may be useful for testers in a agile scrum team, some of agile tester skills include:

• 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. For example, testers can use mind mapping to identify which test sessions to perform, to show test strategies, and to describe test data.

The post Agile Tester Skills appeared first on World Of Agile.

Some of the options while deciding the strategy for structuring of Agile Testing teams are as follows

• Testers Embedded into the Development Teams : Independent testers are often more effective at finding defects. In some Agile teams, developers create many of the tests in the form of automated tests. One or more agile testing engineer may be embedded within the team, performing many of the testing tasks. However, given those testers’ position within the team, there is a risk of loss of independence and objective evaluation.
• Testers on a on-demand basis : Other Agile teams retain fully independent, separate test teams, and assign testers on-demand during the final days of each sprint. This can preserve independence, and these agile testing engineers can provide an objective, unbiased evaluation of the software. However, time pressures, lack of understanding of the new features in the product, and relationship issues with business stakeholders and developers often lead to problems with this approach.
• Independent Test Teams : A third option is to have an independent, separate test team where testers are assigned to Agile testing teams on a long-term basis, at the beginning of the project, allowing them to maintain their independence while gaining a good understanding of the product and strong relationships with other team members. In addition, the independent test team can have specialized testers outside of the Agile testing teams to work on long-term and/or iteration-independent activities, such as developing automated test tools, carrying out non-functional testing, creating and supporting test environments and data, and carrying out test levels that might not fit well within a sprint (e.g., system integration testing).
• Testing in case of multiple large Agile Teams and Independent Test Teams : Organizations may plan on having independent testing teams for large implementations involving larger number of teams. It is therefore important to integrate across scrums so that the testing team sees a fully integrated version at all times instead of working on versions which may work for a particular functionality but may not work well if integrated with other teams. Principles of Continuous Integration are particularly useful in such an approach. Doing a regular Scrum of Scrum meetings across development teams and testing teams is also a useful technique which may help in independently assuring quality.

• Applications where Requirements are Fluid (Mobile Applications, Internet Applications) :

Where the requirements are fluid (e.g. Mobile Application Development, Internet websites etc), the obvious choice of most customers is to go for Agile Development Methodology.

To speed up testing, it is worth taking a N+1 approach as shown in the diagram below. In this approach, Functional testing is done (manually) along with the development team. However, the functional testing done manually is automated in the following sprint (N+1). This makes it possible to have a fully updated Regression Test Suite. This Regression Test Suite will be useful in performing the functional testing in the subsequent sprints.

• Large Enterprise Applications:

For Large Enterprise Applications, upfront planning and design is generally done in a waterfall way. Thus a detailed design and detailing of all important features is available upfront before the implementation starts.

However, in such situations also, where the requirements and known upfront (Large Enterprise Applications) Customer may still prefer Agile Development for various reasons

o   Customer may still like to see incremental deliverables instead of a big-bang delivery.

o   Agile gives the customer ability to Inspect and Adapt based on what they see.

o   In requirements may end up changing due to various needs of the market or how the market evolves over time.

o   Risk of the requirements fluidity may be high, while it’s a perception that the requirements are known upfront

In such situations following are the things which could be done upfront to create a more effective deliverable

o   Automating the Acceptance Test suites and providing the same to development upfront to create an environment of preventive testing rather than reactive testing. The focus here is on prevention rather than on finding defects.

o   A More thorough acceptance test suite could be written in close coordination with the business teams.

o   The testing team now focuses on keeping the acceptance test suites updated all the time based on changes in the requirements.

o   The testing team will now get more time to focus on Exploratory testing and finding defects that the machine may not be able to do.

o   Thus a right mix of Automated and Manual testing could be used by the independent testing teams.

The post Organization Options for Agile Testing appeared first on World Of Agile.

Many kinds of testing exist. Brian Marick came up with the Agile Testing Quadrant as shown below.

In this diagram, he categorized tests according to whether they are business facing or technology facing and whether they support the development process or are used to critique the project.

Q1-Technology Facing Tests that Support the Development Process

These automated tests are written and maintained exclusively by developers. There are three kinds of tests that falls into this category : Unit tests, Component tests and Deployment tests.

Q2-Business-Facing tests that support the Development Process

The tests in this quadrant are more commonly known as functional or acceptance tests. Acceptance testing ensures that the acceptance criteria for a story are met. Acceptance tests should be written and ideally automated before development starts on a story. Acceptance tests, like acceptance criteria, can test all kinds of attributes of the system being built, including functionality, capacity, usability, security, modifiability, availability and so on.

Q3-Business Facing Tests that Critique the Project

These manual tests verify that the application will in fact deliver to the users the value they are expecting. This is not just a matter of verifying that the application meets its specifications, it is also about checking that the specifications are correct.

Q4- Technology-Facing Tests that critique the Product

Acceptance testing comes in two categories : Functional and Non-Functional tests. By Non-Functional tests, it means that all the qualities of the system other than its functionality, such as capacity, availability, security and so forth. This quadrant covers the Non-Functional tests which are equally important for the success of the product.

The post Agile Testing Quadrant appeared first on World Of Agile.

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).

Test Levels

Test levels are test activities that are logically related, often by the maturity or completeness of the item under test.

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. Test levels overlap. Requirement specification, design specification, and development activities may overlap with test levels.

In some Agile lifecycles, overlap occurs because changes to requirements, design, and code can happen at any point in an iteration. While Scrum, in theory, does not allow changes to the user stories after iteration planning, in practice such changes sometimes occur. 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

^o    Feature verification testing, which is often automated, may be done by developers or testers, and involves testing against the user story’s acceptance criteria

o   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

Example of Feature acceptance testing:

As a new depositor, in order to protect my money, I want to save my money a bank account. Since, I am a new depositor; my default opening balance in a new bank account is INR 0.00

In addition, there is often a parallel process of regression testing occurring throughout the iteration. This involves re-running the automated unit tests and feature verification tests from the current iteration and previous iterations, usually via a continuous integration framework.

In some Agile projects, there may be a system test level, which starts once the first user story is ready for such testing. This can involve executing functional tests, as well as non-functional tests for performance, reliability, usability, and other relevant test types.

Agile teams can employ various forms of acceptance testing. Internal alpha tests and external beta tests may occur, either at the close of each iteration, after the completion of each iteration, or after a series of iterations. User acceptance tests, operational acceptance tests, regulatory acceptance tests, and contract acceptance tests also may occur, either at the close of each iteration, after the completion of each iteration, or after a series of iterations.

The post Agile Test Pyramid appeared first on World Of Agile.

The Differences between Testing in Traditional and Agile Approaches

Testers must understand the differences between testing in traditional lifecycle models (e.g., sequential such as the V-model or iterative such as RUP) and Agile lifecycles in order to work effectively and efficiently. The Agile models differ in terms of the way testing and development activities are integrated, the project work products, the names, entry and exit criteria used for various levels of testing, the use of tools, and how independent testing can be effectively utilized.

Testers should remember that organizations vary considerably in their implementation of lifecycles. Deviation from the ideals of Agile lifecycles may represent intelligent customization and adaptation of the practices. The ability to adapt to the context of a given project, including the software development practices actually followed, is a key success factor for testers.

Testing and Development Activities

One of the main differences between traditional lifecycles and Agile lifecycles is the idea of very short iterations, each iteration resulting in working software that delivers features of value to business stakeholders. 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, as with traditional lifecycles. They should self manage and build skills necessary in the team to make things happen (cross functional)

• 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.

In some cases, hardening or stabilization iterations occur periodically to resolve any lingering defects and other forms of technical debt. However, the best practice is that no feature is considered done until it has been integrated and tested with the system. Another good practice is 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”).

However, some complain that this practice results in a situation where the total work to be done in the iteration is unknown and it will be more difficult to estimate when the remaining features can be done. At the end of the sequence of iterations, there can be a set of release activities to get the software ready for delivery, though in some cases delivery occurs at the end of each iteration.

When risk-based testing is used as one of the test strategies, a high-level risk analysis occurs during release planning, with testers often driving that analysis. However, 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.

In some Agile Testing practices (e.g., 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. Pairing can be difficult when the test team is distributed, but processes and tools can help enable distributed pairing.

Testers may also serve as agile testing and quality coaches within the team, sharing testing knowledge and supporting quality assurance work within the team. This promotes a sense of collective ownership of quality of the product.

Test automation at all levels of testing occurs in many Agile teams, and this can mean that testers spend time creating, executing, monitoring, and maintaining automated tests and results. 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. While developers will focus on creating unit tests, testers should focus on creating automated integration, system, and system integration tests. This leads to a tendency for Agile teams to favour testers with a strong technical and test automation background.

One core Agile principle is that change may occur throughout the project. Therefore, lightweight work product documentation is favoured in Agile projects. Changes to existing features have testing implications, especially regression testing implications. 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)

In a typical Agile project, it is a common practice to avoid producing vast amounts of documentation. Instead, focus is more on having working software, together with automated tests that demonstrate conformance to requirements. This encouragement to reduce documentation applies only to documentation that does not deliver value to the customer. In a successful Agile project, a balance is struck between increasing efficiency by reducing documentation and providing sufficient documentation to support business, testing, development, and maintenance activities. The team must make a decision during release planning about which work products are required and what level of work product documentation is needed.

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. Larger collections of related features, or a collection of sub-features that make up a single complex feature, may be referred to as “epics”. Epics may include user stories for different development teams. For example, one user story can describe what is required at the API-level (middleware) while another story describes what is needed at the UI-level (application). These collections may be developed over a series of sprints. Each epic and its user stories should have associated acceptance criteria.

Epics can be easily broken down into user stories by slicing them vertically and they comply to INVEST criteria. Each Epic and user story contains acceptance criteria with necessary business rules and mockups attached to them.

Typical developer work products on Agile projects include code. Agile developers also often create automated unit tests. These 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. While this approach is referred to as test first or test-driven development, in reality the tests are more a form of executable low-level design specifications rather than tests.

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. The documents are captured in as lightweight a fashion as possible, which is often also true of these documents in traditional lifecycles. Testers will also produce test metrics from defect reports and test results logs, and again there is an emphasis on a lightweight approach.

In some Agile implementations, especially regulated, safety critical, distributed, or highly complex projects and products, further formalization of these work products is required. For example, some teams transform user stories and acceptance criteria into more formal requirements specifications. Vertical and horizontal traceability reports may be prepared to satisfy auditors, regulations, and other requirements.

In some regulated agile projects, more inspection of the documentation that is being produced during the project execution may be required.

For example: Federal drug administration (FDA) projects require lot of audit reports, strategy reports and compliance reports that need to be produced during the project execution.

The post Agile Testing appeared first on World Of Agile.