程序代写 Fundamental Agile Testing Principles and Practices

Fundamental Agile Testing Principles and Practices

Fundamental Agile Testing Principles and Practices
Lecture 05

These slides are from:
Agile Testing Foundations : An ISTQB Foundation Level Agile
Formal Citation: Black, Rex, and . Agile Testing Foundations : An ISTQB Foundation Level Agile . BCS, The Chartered Institute for IT, 2017.

Available for access from library.
Search the catalogue for the title and you will be able to read it online.

Describe the differences between testing activities in Agile Projects and non-Agile Projects.

Describe how development and testing activities are integrated in Agile projects.

Describe the role of independent testing in Agile projects.

How retrospectives can be used as a process improvement approach in Agile projects?

Describe how development and testing activities are integrated in Agile projects.

Differences between testing in traditional environment and testing in an agile environment

The primary differences are:
The involvement of testers throughout the entire release.
Continual testing throughout an iteration.
Coaching, collaboration and pairing.
Flexibility to accommodate change.
Reference: mountaingoatsoftware.com
Agile – Scrum Approach

Project work products
Traditional development teams had product work products consisting of vast amounts of very detailed documentation.
With Agile development, the emphasis is on
Working software over comprehensive documentation
Therefore, meaningful documentation is produced – also known as ‘just enough’ documentation.

Project work products in Agile testing

Business-oriented work products;

Development work products;

Teamwork products.

1. Business-oriented work products
Objective is to describe :
what is needed?
Business Requirements
Improvements
New product idea
how to use it?
Help manuals
User documentation

Business Requirements
In agile teams, user stories are used to define the business requirements.
User stories provide a light-weight approach to managing requirements, providing a short statement of a single function.
They are captured either on an index card or in a tool.
The story acceptance criteria are then recorded, either at the bottom of the story or on the back of the index card.
All user stories much contain acceptance criteria before they can be considered for inclusion in an iteration.

As a: [role]
I want to: [what]
So that: [why]
User Story:
Acceptance Criteria:

Collection of related user stories or large and complex stories are known as epics.
It may take several iterations to complete.
For example:
Increase click n collect functionality in our mobile application of a retail shop.
User Story 1: As a customer, I want to access my previous shopping list so that I can choose the same items again.
User Story 2: As a customer, I want to see the categories (e.g. grocery, meat, self-grooming etc.) and purchase amount in each to keep an account of my expenditure.

2. Development Work Products

Development work products usually consist of the following types:
Describing how the system is built;
database entity-relationship diagrams and software architecture diagrams (UML etc. )
Describing what is used to actually implement the system
Describing how to evaluate individual pieces of code;
automated tests

Test Driven Development (TDD)

Here test cases are created prior to the code being developed.
Verify the new code works as expected.
TDD lets the developers think about the requirements and design of the code before writing the code.
Tests are then added, which incrementally improve the design.

We are going to do TDD using Microsoft’s MSTestAPI for unit testing.

3. Test work products

Test work products usually consist of the following:
WPs that describe how the system is tested;
test strategies and plans
WPs that actually test the system
manual and automated tests
WPs that present test results
test dashboards

Test Strategy

The test strategy include:
Describe the approach to verification and validation activities.
Define quality success criteria in terms of measures and metrics for all test activities.
Provide stakeholders with an understanding of how and what the test approach will be for the whole team.
A high-level description of the test levels to be performed and the testing within those levels for an organisation or programme (one or more projects).

It is a common practice in Agile teams that more detail is put into the test strategy, and then shorter (generally single page) test plans are produced during iteration planning activities.
Many Agile teams develop their test plans on flipcharts or whiteboards or in mind map tools – whichever method, the whole team contributes and agrees about what is sufficient to ensure quality for that iteration.

Test Strategy (TS) — Continued
Before implementation of a Test Strategy, the tester needs to understand the TS.
As change is expected, the TS will need to be continuously updated.
The TS must also define:
What kind of tests and
quality characteristics
need to be tested and when?

The purpose of a test plan in Agile teams is to outline
What are you going to test in one iteration?
How you are going to test it?, and
How you confirm you meet the acceptance criteria?

For example, if the graphical user interface (GUI) is modified in each iteration to allow new features, regression tests must also be run against the GUI in each of these iterations. Also, the test approach can identify when end-to-end or performance tests can be executed without mocks.
Test planning activities, may include updating the test strategy and defining the necessary test types and levels; also, for regression testing, estimating testing effort for all testing tasks

Test Plan — Continued

In sprint plan, each user story is split into several tasks, some of which will be testing tasks.

Independent testing tasks can be put into the sprint backlog and task list.

Typically, each task is one to two days’ work, but as everything is decided by the team, so is the task length.

From best practices perspective, tasks should not take longer than two days because otherwise they are hard to estimate and often contain hidden subtasks and dependencies that result in delays.

Tasks, including the testing tasks, are then displayed and tracked on the team task board. The task board should provide a clear view of the status of each task.

Often, testing tasks are shown in different colours to make them stand out from the rest of the tasks.

Defects could also be put on the task board if the changes they require are too large to fix immediately.

Test Automation

Agile teams rely heavily on test automation.
Reason: Automation of tests at all levels (e.g., unit, integration, and acceptance) and for all test types (e.g., functional and non-functional) enables software changes to be rapidly verified and then potentially deployed.
Test automation scripts form a critical role in test work products as they describe how the system has been tested.
The use of software to perform or support test activities, e.g. test management, test design, test execution and results checking

Manual Testing

As automation testing’s emphasis is on automation of repetitive testing activities, manual testing focuses more on exploratory testing.
WPs include:
Test charters;
Checklists;
Mind map diagrams;
Exploratory test logs.

Testing and Configuration Management

Traditionally, developers were the primary users of configuration management tools for code source control and management.

Within Agile teams, as the test automation being more prevalent, the testers also utilise the configuration management tools to ensure correct versioning and control of their test automation code.

How retrospectives can be used as a process improvement approach in Agile projects?

Retrospective
A retrospective is a meeting, usually held at the end of an iteration, to discuss
what was successful in the iteration?
and what could be improved?
The meeting also focuses on
how to incorporate the identified improvements and retain the successes in future iterations.

Topics in Retrospectives
Topic Example
Process Change the start time of daily meeting
Deciding to better define the tasks to be done during sprint.
People Deciding to assign a team member to functional tests.
Inviting a performance tester onto the team to define specific test cases.
Organisations Using a test centre to organise end-to-end testing without mocks.
Setting up a Scrum of Scrums and splitting the product backlog across several teams.
Relationships Organising more meetings with user representatives to better understand their needs.
Tools Storing test cases in a test management tool.
Using a tool to create test data.

Describe the role of independent testing in Agile projects.

Organisational options for independent testing

There are three main ways that testers are integrated into the Agile team.
To have developers building automated tests with testers embedded in the team performing testing tasks.
To have a fully independent and separate test team in which testers are assigned to the project on-demand generally at the end of the Sprint or iteration.
To have an independent and separate test team in which testers are assigned to Agile teams on a long-term basis from the commencement of the Agile project.

Advantages

First Option
(Embedded in the team) Second Option
(Separate Team on demand) Third Option
(Independent Team for long-term)
Testers can concentrate on the manual testing of user stories.
Testers are part of the team from the beginning; therefore they understand the applications being built.
Testers build a strong relationship with the team. Testers can maintain their independence.
Testers can provide an objective and unbiased evaluation of the software.
Testers maintain their independence.
Testers gain a good knowledge of the product and understanding of the features in the product.
Testers build a strong relationship with the business stakeholders and developers.
Testers can leverage other testers outside the Agile team for tooling or specialised support.

Disadvantages

First Option
(Embedded in the team) Second Option
(Separate Team on demand) Third Option
(Independent Team for long-term)
Testers can possibly lose their independence by being part of the team, without the support of other testers in the organisation.
Test automation is being built by developers and therefore may not contain the same level of verification or detail that it would contain if written by testers. Testers face time pressures to test features developed over the entire iteration in a very short period of time.
Testers do not have knowledge of the product and lack understanding of the features in the product.
Testers have not had the opportunity to build a relationship with the business stakeholders and developers, which can lead to communication and interaction problems.
This method defeats the objective of Agile development. This approach works well within large organisations but is not really suited for smaller organisations with limited resources.

When independent testers work outside Agile team?

The independent team can have specialist testers outside the Agile team working on activities such as:
Automated test tool development;
Performing non-functional testing, such as performance testing, security testing and so forth;
Supporting and managing test environments;
Developing or generating test data to support test activities;
Support multiple Agile teams by performing test activities that might not fit well within a sprint or iteration.

Status of Testing in Agile Projects

Describe the tools and techniques used to communicate the status of testing in an Agile Project, including test progress and product quality.

Communicating Test Status, Progress and Product Quality
Daily Stand-up meetings.
Project Task board
Burndown Charts
Satisfaction Surveys
Metrics of work processes

Daily Stand-up Meetings

Daily Stand-up meeting, answering the same three questions:
What have you completed since the last meeting?
What do you plan to complete by the next meeting?
What is getting in your way?

Project Task Boards
This can be either physical board on the wall, with sticky notes, or
An electronic task board with automated work-flows.
This Photo by Unknown Author is licensed under CC BY

Burndown Charts

How many story points should be left to complete (or burn) in any single day of the iteration.
This graph shows, that the team is taking more time to or the team is delivering less story points they signed up for and they need to take corrective actions.

This Photo by Unknown Author is licensed under CC BY-SA

Satisfaction Surveys
To measure the overall product quality, Agile teams conduct satisfaction surveys.
Satisfaction surveys gauge the user’s understanding and experience with the product to improve the quality of the product.
There could be some team satisfaction surveys, to know how team is performing.
Niko- -Niko

Described by using
yellow smiley face for a good day,
a red neutral face for an ordinary day;
a blue sad face for a bad day.
Other implementation have used the traffic light colour coding.
Depends on the teams to see which one they want.
Major interpersonal issues can be resolved.

Metrics of work processes
From traditional development methodologies
Test pass/fail rates
Defect discovery rates
Confirmation and regression test results
Defect density
Defects found and fixed
Requirements coverage
Risk coverage
Code coverage
Code churn

Skills of a tester in an agile team
Agile tester skills
Being positive and solution-oriented
Displaying critical, quality-oriented, sceptical thinking about the product.
Actively acquiring information from stakeholders.
Accurately evaluating and reporting test results, test progress and product quality.
Working effectively to define testable user stories.
Collaborating within the team, and working in pairs.
Planning and organising their own work.

Role of the tester

Each team member is responsible for product quality- total ownership.
May consider the quality from their own perspective and focus.
During the test strategy
Before implementing
During the implementation
During the retrospective

Test-related Organisational Risk

Test activities must be well-defined in the test strategy.
Testers become tolerant of, or silent about inefficient, ineffective or low quality practices within the team.
Changes must be contained within the release backlog and not the iteration backlog.

the differences between testing activities in Agile Projects and non-Agile Projects.

how development and testing activities are integrated in Agile projects.

the role of independent testing in Agile projects.

how retrospectives can be used as a process improvement approach in Agile projects?

financial stock market graph

.MsftOfcThm_Accent1_Fill {
fill:#4F81BD;
.MsftOfcThm_Accent1_Stroke {
stroke:#4F81BD;

/docProps/thumbnail.jpeg

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts