Fundamental Agile Testing Principles and Practices
Fundamental Agile Testing Principles and Practices
Lecture 05
Copyright By PowCoder代写加微信 assignmentchef
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 purposeof 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
TopicExample
ProcessChange the start time of daily meeting
Deciding to better define the tasks to be done during sprint.
PeopleDeciding to assign a team member to functional tests.
Inviting a performance tester onto the team to define specific test cases.
OrganisationsUsing 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.
RelationshipsOrganising more meetings with user representatives to better understand their needs.
ToolsStoring 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;
.MsftOfcThm_Accent1_Fill {
fill:#4F81BD;
.MsftOfcThm_Accent1_Stroke {
stroke:#4F81BD;
.MsftOfcThm_Accent1_Fill {
fill:#4F81BD;
.MsftOfcThm_Accent1_Stroke {
stroke:#4F81BD;
.MsftOfcThm_Accent1_Fill {
fill:#4F81BD;
.MsftOfcThm_Accent1_Stroke {
stroke:#4F81BD;
.MsftOfcThm_Accent1_Fill {
fill:#4F81BD;
.MsftOfcThm_Accent1_Stroke {
stroke:#4F81BD;
/docProps/thumbnail.jpeg
程序代写 CS代考加微信: assignmentchef QQ: 1823890830 Email: [email protected]
Reviews
There are no reviews yet.