Do you work in a company which has established effective testing process, which ensure high quality and support Agile methodologies? Can your testing process be used as a model for other companies? Fortunately, we were in that place a few years ago and had to ask ourselves a question about the next step. The answer was: Let’s be Quality Assurance Engineers rather than Testers. But what should we do? How can we do this transformation? At the same time, I got feedback from my colleague – Head of Java practice: “Your testers found defects in areas / scenarios which weren’t included in development scope / my devs didn’t know that should cover those edge cases. What can we do with that?” I had to agree with him. There is no sense to test scenarios which weren’t implemented. This was the starting point of our transformation. We decided to implement Shift left model as it looks like the most promising one. But when we implemented it not everything worked as smooth as we wished. New challenges appeared, but more in my presentation.

1. Shift left
First transformation step into Quality
Assurance
1

2. Intro
2

3. Agenda
3
01 Context
02 Test-based process
03 Introducing shift left
04 Mindset switch
05 Summary

4. Context
▪ Project-based company
▪ Mostly Web, where the center
of the galaxy are
Content Management Systems
▪ Delivered by Adobe or Sitecore
▪ Which are Customizable
▪ And Integrated with everything
(even black hole)
▪ In addition, we do Digital
Transformation of our clients
4

5. Testing process principles
▪ No test case managment, no reporting, …
–No test managers
▪ Testing process inside of feature development
–Task flow ensures that each task is tested
–Easy to visualise
▪ Task status is connected with test status
▪ Exploratory testing,
–Extended by Session Based Testing idea
5

6. Test process as workflow
6

7. Acceptance criteria status
7

8. Testing process achievements
▪ Task reject ratio below 50%
▪ Which means that each task is tested two times:
–Rejected, defect raised, back to dev for fixes
–Retested and Accepted
▪ The above testing process works very well for Scrum and Kanban
–Allows to avoid mini waterfall trap
8

9. Ping pong is sport not development methodology
Reject ratio metric
▪ Reject - task moved from Testing in progress to Reopen state
▪ Accept - task moved from Testing in progress to Resolved state
9

10. CALM before the storm
▪ Stabilization (it’s boring when there are no changes)
▪ Trends & Fashion - more and more discussions about Quality Assurance vs Testing
10

11. Internal feedback
Your testers found defects using scenarios which weren’t
included in development scope or my devs didn't know that they
should cover them.
What can we do with that?
11

12. TDD
The new meaning of Test Driven Development
12

13. Shift Left principles
▪ Agree scope of test beforehand
▪ Discover requirement issues and gaps early
▪ Discover impact of change
▪ Share with developers how story should be tested
–Empower devs to do testing work
▪ Identify and minimise duplication in testing
▪ Minimise “Won’t fix” issues
▪ No excuse ;-)
13

14. QA activities inside software development lifecycle
14

15. Impact on project resourcing
15

16. Shift Left Activities - Prior to project start
▪ Project Plan assumes QA & Testing activities as part of the project scope
▪ QA Plan which contains activities executed by all team members
– Cross-practice cooperation
16

17. Shift Left Activities - before The first line of code
▪ Requirement Testing
–Before sprint
–3 Amigos
–Backlog Refinement
–Completeness & common understanding (Developable and Testable)
–Do not be afraid to extend Acceptance Criteria
▪ Test Hug / Test Ideas
–How can I help you deliver the feature?
–QA - dev meeting inside sprint, before coding starts
–Do not forget about feature architecture
–How the feature should be tested?
–List of test ideas
17

18. Shift Left Activities - are we done?
▪ QA Demo
–Dev demos feature for QA Engineer (other team members are welcome)
–Demonstrate what feature does and doesn’t
–Demonstrate how feature was tested
–Talk about edge cases
–What’s next?
– Does feature require additional testing?
– If yes, what should be tested?
– If not, are we done?
18

19. Selfreject
http://bit.ly/thebesttestingever
19

20. There is always someone to save your skin
▪ Old workflow implementation:
–Action for developer: submit to testing / QA.
–Task statuses: Waiting for Testing, Testing in Progress.
–Summary: our workflow said to send task to someone else to execute an action (in our case testing)
▪ Developers reception: Why should I spend my precious time on testing if there is always
someone else who did it?
20

21. Change the mindset - Confirm your work
▪ Why statuses and buttons (actions) say what I have just done, not what action is required next?
▪ Actions are the confirmation of your work,
–Implemented & tested on feature branch, merged to integration branch, sanity tested / automated tests
passed.
▪ Workflow status describes the actual status of task on board from business perspective (what
has been done so far).
21

22. Acceptance criteria status - restore responsibility among
developers
22

23. Be lean
▪ Why makes you decide that story is DONE and is not going to be tested after QA demo?
–Restore the responsibility among developers
–Less duplication in project
–It takes time to build trust between Dev and QA
23

24. Reminder: Test process
24

25. Quality Assurance process as a workflow
25

26. Standardization trap
▪ Standardization process
–Create process from scratch for each project
–Gather best practices, which comes bottom - up
–Set those best practices as standard
–Start project with standard process and customize it for your need
▪ Result:
–People lost freedom because official standard appear
▪ Why?
– Nothing new, all best practices used in projects earlier
– Just new starting point
– They still has a freedom and can change standard
– But each changes need a reason
26

27. Unexpected reward
▪ Reject rate only about 10%
▪ Continuous Delivery approach introduced in our project very smoothly
27

28. Summary
Transformation to Quality Assurance is not only about the introduction process but mostly about
change in our minds.
28

29. 29
Thank you