Being an Agile Tester

Role Of A Tester

Skills

Testing Tools

Team Structure

Supporting The Team

High Quality

CI

Feedback Loops

ATDD/TDD

Exploratory Testing

Automation

Company structure

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

A-HA wall

Parking lot

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.4

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.5


Photos


In each Group:

What are the 3 biggest issues your facing today, with you development process?

Lets Discuss

Eliminate waste.

Faster release cycles.

Deliver maximum business value.

Measure and improve.

Respond to change.

Increase quality.

Have Fun.

SCRUM is very simpleA complex process draws focus from real issues.

SCRUM maximize feedbackUsing SCRUM everything is known.

All the information to enable good decision making

SCRUM is flexibleGives the ability to respond to change

Inspect and adapt

First Step – Prepare the Product Backlog

Stories Priority Estimate

As a user I want to be able to input disability % data using a GUI, so it will be faster.

1 5

As a user I want to get the calculation result for a complex case 2 3

As a developer I want to be able to input disability % data using a text file, so it can be easier to test.

3 1

As a user I want to be able to store result to a file 4 1

As a user I want to be able to easily install the application. 5 3

As a user I want to be able to learn how to use the application 6 2

A story represents a requirement

3C’s – Ron Jeffries

Card – Placeholder for conversation

Conversation – discussion between implementer and customer

Confirmation – Definition Of Done (DOD)

Possible format:

As a ____ I want ______ so that _____.

Stories Pri. Est.

As a user I want … 1 5




Stories Pri. Est.As a user I want … 1 5As a user I want … 2 3As a user I want … 3 1As a user I want … 4 1As a user I want … 5 3As a user I want … 6 1As a user I want … 7 1As a user I want … 8 3As a user I want … 9 1As a user I want … 10 1

Sprint 2

Rest

Stories Priority EstimateAs a user I want … 1 5As a user I want … 2 3As a user I want … 3 1As a user I want … 4 1As a user I want … 5 3As a user I want … 6 5As a user I want … 7 3As a user I want … 8 1As a user I want … 9 1As a user I want … 10 3As a user I want … 11 5As a user I want … 12 3As a user I want … 13 1As a user I want … 14 1As a user I want … 15 3As a user I want … 16 5As a user I want … 17 3As a user I want … 18 1

… … …

Product Backlog

Stories Pri. Est.







Sprint 1

Help in Story Writing

Help to define the scope of the stories

Write Acceptance criteria

Think on Testing aspects

What other thing we need to consider?

Planning

Help with Story estimation

Make sure there is enough time to test

Sprint is a short cycle in which work get done.

Typically between 1-4 weeks

Once started, content does not change

Goal

Allow the team to work, without interference, in order to produce a potentially shippable productthat will increase business value.

A sprint results in a Product Increment.

Product Backlog

Sprint Planning

Story To Do In Progress Done

As a user…

As a user…

As a user…

As a user…

Stories Priority EstimateAs a user I want … 1 5As a user I want … 2 3As a user I want … 3 1As a user I want … 4 1As a user I want … 5 3As a user I want … 6 5As a user I want … 7 3As a user I want … 8 1As a user I want … 9 1As a user I want … 10 3As a user I want … 11 5As a user I want … 12 3As a user I want … 13 1As a user I want … 14 1As a user I want … 15 3As a user I want … 16 5As a user I want … 17 3As a user I want … 18 1As a user I want … 19 1As a user I want … 20 3As a user I want … 21 5As a user I want … 22 3

… … …

Understanding the storyExplain how this is going to be tested

Ask question that will help to set clear scope boundaries

Task decompositionAdd testing tasks (what about automation)

Make sure programmer do some unit test

What about setting up the system?

Help with estimation

Stand up meeting held every day (15 minutes).

Each team member answer 3 questions (only)What has he done the previous day,

What is he going to do today

Is there anything holding him back (that the team can help with).

Goals Daily planning

Communication with other team members

Report on your progress

Push work to testing as soon as possible

Guard the sprint time-box

Will there be enough time for testing?

“Code that isn't tested doesn't work—this seems to be the safe assumption.”

Kent Beck 2002

Get feedback

General feedback – are we headed in the right direction

Specific feedback – to the stories completed

feedback should reflect in product backlog.

Share your story

What have been done (and tested)

Where do you feel are the weak points?

Provide general feedback to the PO & stakeholders

Scrum is an adaptive processReview what went well and we want to keep,

and what needs to be changed.

Team formingLet the team be heard

Let the team handle issues

Reflect on overall planChanges to release plans.

Changes to goals.

Agile = no processScrum is a rigorous process.

Agile = No DocumentationAgile stresses only needed documentation.

Agile = No DesignDesign is an ongoing activity.

Agile = No PlanningJust in Time & just enough Information.

Agile = Small TeamsHas been scaled to very large groups (hundreds).

“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team… The Product Owner is the sole person responsible for managing the Product Backlog …. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. … The Product Owner is one person…” – Scrum guide

Goal Setting (on many levels)Responsible for the ROI.Responsible for the product backlog

Writing StoriesPrioritizationUpdating backlog

Helps the developers understand what needs to be done

DOD – Definition Of DoneProduct conflicts resolution

“The Scrum Master is responsible for ensuring Scrum is understood and enacted … The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” – Scrum guide

Finding techniques for effective Product Backlog managementHelping the Scrum Team understand the need for clear and concise Product Backlog itemsUnderstanding product planning in an empirical environmentEnsuring the Product Owner knows how to arrange the Product Backlog to maximize valueUnderstanding and practicing agilityFacilitating Scrum events as requested or needed.

Coaching the Development Team in self-organization and cross-functionalityHelping the Development Team to create high-value productsRemoving impediments to the Development Team’s progressFacilitating Scrum events as requested or neededCoaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Leading and coaching the organization in its Scrum adoption

Planning Scrum implementations within the organization

Helping employees and stakeholders understand and enact Scrum and empirical product development

Causing change that increases the productivity of the Scrum Team

Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

“The Development Team The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. … Development Teams are structured and empowered by the organization to organize and manage their own work…” – Scrum Guide

They are self-organizing. Development Teams are cross-functionalScrum recognizes no titles for Development Team members other than Scrum recognizes no sub-teams in the Development TeamIndividual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

In each Group:

Go over the list of issues we have and see if you can find things in the process that might address them.

Lets Discuss

Team size should be 5-9 members.

Focus on team results:

• Team must share a common goal.

Team should be heterogeneous:

• Include coders, testers, DBA, GUI,…

Self Contained teams:

• All required skills are present at the team level.

• Allow the team to progress at full speed.

1. Formingpolite but untrusting.

2. StormingI know best.

3. NormingMaybe they can help me.

4. PerformingThey are really good.

Tuckman added a 5th stage 10 years later:5. Adjourning

Time to move on.

Versatile

Should be able to do several things.

Responsible

Take ownership of the process

Collaborative

“Lone wolves” generally does not fit an agile team.

Development and QA are often operational silos.

Tests are derived from detailedrequirements and specifications.

Usually don’t actively participate in planning

Almost never help in the product design

Testers are often viewed as second class citizens

They are not active partners at building the product

Developers considers testing as an obstacle in the delivery process.

Testers do not get the necessary knowledge (from R&D) to test effectively.

Represents the customer.

Provide feedback about new work.

Improve the testing process.

May help in defects handling.

Help define and elicit the acceptance criteria (or requirements)

Preferably in the form of automated acceptance tests.

Work with the customer (PO) to identify risks

If its hard to test it might be very hard to use.

Provide information to customer about Quality.

Performing regression tests When major changes are about to be committed.

Validate acceptance criteria's

Exploratory testingPut more testing effort into the areas where the developers tests (unit and integration) are weakest.

Quality must have an owner.

Train developers in effective testing.

Build specialized internal testing tools

Identify trends and areas of deteriorating quality.

Two main strategiesHandle as they come

Postpone until next cycle and schedule as any other feature.

Pragmatic approach Allocate resources for treating critical defects as they come.

Postpone the rest (or when allocated resources are not enough)

Reproduce Defect

Work with customer to understand the issue.

Initial investigation

Is it a defect or a misunderstanding.

Root Cause Analysis

Defects are not acceptable.

Verify fix

To make sure this wont happen again.

Stakeholders always have questions:

What’s the status?

When will you finish?

Why is it taking so long?

Is the testing of __________ finished?

A report containing

Product Areasvs.

Test Effort, Coverage &

Quality Assessment

vs.

Time

Testing Dashboard Ver. # -1.1.4.31

Last Updated: 3/12/2016

Area Effort Cov. Qual. RemarksSuppliers Ship 3

Search Flow High 2+ Def 1674

Booking Flow Pause 2 Automation broken

Auxiliary Operation Low 1+

Asmx Low 1 Memory leak

Cont. search Blocked 0 No testing Env.

Scoring & Connosuir Start (20/12)

0

MarkUp None 0

None - No Plan to Test

Start - Expect to start testing soon

Low - Mainly regression, keeping cov.

High - In focus, increase cov.

Pause - hard to test/stopped for now

Blocked – Cant test this for now

Ship - Final testing before live

0 We don’t know

1 Sanity only

1+ some functional, not all

2 Finished Common cases + some

2+ did some error & edge cases

3 All Corner cases covered

We don’t know about any problems that should stop production or suspect any.

We know of possible showstoppers, or suspect there are some severe issues

We have issue that should not reach production,.

If I Could have 3 magic boxes, I would like to know:

1. Am I doing things right?

2. Am I doing the right things?

3. Am I Adding Business Value?

This is what unit test are used for.

Unit tests:Are fast

Test each unit in isolation

Enable me to test all paths of my code

Will improve my technical design

E2E tests are a good tool for:Help me understand the requirements

E2E tests:Goes through all the system

Help me understand how the system behaves

Help me refine Acceptance Criteria

The foundation that supports all of the rest.

Majority of effort should be invested at this level.

Very cheap to write and maintain, have high ROI.

Very effective at catching regression bug

Usually done by the programmer who writes the code

Should & can be automatedRelatively cheap to write and maintain

Business-facing testsFunctional tests that verify we are “building the right thing”Should be written in domain specific language, that customers understand

Operate at the API level, “below the GUI”They run more slowly, to cover complex scenarios

Focus on GUI operated tests:

Written after code is completed, to critique the product

Likely to change often (high maintenance)–as often as GUI changes

Run slow & breaks often

so we try to keep the number small

Never use a recorder to generate them

Have a lot of value

Should be intelligent (not scripted)

Utilize human advantages over the computer (exploratory testing)

In Pairs:Find a volunteer.

Have him map out his team/company testing process.

Write down the different kinds/Levels of testing they perform.

See if you can draw out his pyramid

Lets Discuss

Automated Unit 60% - 70%

Automated E2E 20% - 30%

Exploratory 20% - 30%

Unit Testing

An integral part of the coding phase. (TDD)

All code should be tested before it moves to next stage

E2E Testing

Most of the effort is done as part of the requirement.

Actual automation in parallel to coding

Exploratory Testing

Final activity before Done.

Unit TestingProgrammers (Each on his own code)

E2E TestingProduct + Testers (Programmers) – define the test scenarios

Test Engineers/Programmers - Automation

Exploratory TestingExpert testers

Developed by Elisabeth Hendriksom

Being an Agile Tester

Technology