Już sam tytuł ma wydźwięk mocno kontrowersyjny. Jak to zapomnieć o jakości, zwłaszcza na konferencji poświęconej zapewnianiu jakości i testowaniu? Nie ukrywam, że moim celem jest wywołanie kontrowersji. Chciałbym rozpocząć dyskusję o znajdowaniu balansu pomiędzy prewencją, testowaniem a głodem podjęcia ryzyka przy wypuszczaniu niepewnych zmian w świecie ciągłego dostarczania, wdrażania. Popularne wśród testerów są dzisiaj dwa tematy. Shift Left, czyli zwrócenie swojej uwagi na jak najwcześniejsze etapy wytwarzania oprogramowania w celu eliminacji problemów przed ich wystąpieniem, oraz DevOps, czyli przygotowanie podłoża pod wdrażanie niepewnych zmian w sposób jak najbardziej ograniczający ryzyko idące za zmianą i redukujące czas reakcji w przypadku problemu. Gdzie przy Shift Left a DevOps znajdujemy czas na testowanie? Czy w ogóle potrzebujemy testowania? W jaki sposób i na podstawie jakich przesłanek podjąć decyzję o inwestycji w prewencje, zamiast w odpowiedni monitoring na produkcji? Podzielę się z wami moimi doświadczeniami oraz konkretnymi technikami, które stosujemy zamiennie z testowaniem, przy pracy z produktem ciągle wdrażanym. Pokażę, jak Shift Left i DevOps wpłynęły na sposób mojej pracy. Naszkicuję problemy stawiane testerom w dzisiejszych realiach, kiedy to stawiamy się na szybkość, a każda mała zmiana potencjalnie ingerująca w pracę programistów musi zostać poprzedzona konkretną analizą strat i korzyści. Pokażę, że koniec końców osobie dbającej o jakość powinno również zależeć na prędkości. Szybki zespół to zespół dostarczający wysokiej jakości oprogramowanie. Zespół, który nie traci czasu na rozwiązywanie problemów, których nie tworzy.

1. Forget about
quality.
Think about speed.Principles of Quality at Speed.

2. About me.

3. Agenda
- Disclaimer.
- Interpretation of speed v1.
- Interpretation of speed v2.
- Interpretation of speed v3.
- Interpretation of speed v4.
- Interpretation of speed v5.
- Interpretation of speed v5 supplement.

4. Disclaimer.

5. I still care about quality, but
changing my thinking on
how to achieve it.

6. Wealthy people don’t
become rich by focusing
their efforts on making
more money.

7. I argue the same is true
when it comes to quality.

8. Improve quality indirectly
by improving your team
velocity.

9. What is speed?
(part 1)

10. How long until you speak
about problem to
developer?

11. Do you need to wait for
“working” software to begin
discussion?

12. Forget about quality. Think about speed.
Forget about continuous pursuit of finding bugs
in software.
Deriving quality of software by the number of
bugs found during testing phase is yesterday
thinking.
Prevent bugs by participating at very early
stages of the development process.
Question ideas, proposals, designs.
Manage risks and delegate responsibilities.

13. Forget about
quality.
Think about
speed.
Quantum testing.
Prevent bugs before code gets
implemented.

14. What is speed?
(part 2)

15. How long until you run your
regression tests?

16. Are you the only one who
can run the suite?

17. Forget about quality. Think about speed.
Forget about automated regression testing as
your primary responsibility.
Forget about making big impact by finding all
regression issues in a single run.
Share responsibility for running regression test
suite by including it in continuous integration.
Run regression tests on every change and find
problems fast.
Teach developers how to run and maintain
regression tests.

18. Forget about
quality.
Think about
speed.
Continuous testing.
Avoid fatal blow by running
regression suites at the end of
delivery cycle. Instead frequently
pinch developers with problems as
you go.

19. What is speed?
(part 3)

20. How long until your feature
is used by anyone?

21. How long until you learn
what your users expect?

22. How long until you learn
how your system performs?

24. Forget about quality. Think about speed.
Forget about presumptive quality.
Forget about key performance indicators.
Forget about comprehensive test coverage.
Leave quality bubble, and learn how quality is
perceived by the people.
Monitor performance on production and
correlate data with user happiness score.
Monitor users interactions and features usage,
and look for anomalies.

25. Forget about
quality.
Think about
speed.
Continuous deployment.
Face the uncertainty. Learn what
you don’t know. Prepare for the
worst. Build operational muscles.

26. Up until now I’ve been
considering speed just by
prism of feedback.

27. Forget about quality. Think about speed.
Speed in software development is multidimensional property.
Up until now I considered it only as a function of feedback.
What if you reach accelerate your feedback to maximum?
What if you reach continuous deployment?
What are the other dimensions?

28. What is speed?
(part 4)

29. Anomaly detection and
feature flags help reduce
resolution time.

30. What you use as a metric to
derive quality from once
bugs are out of the scope?

31. Forget about quality. Think about speed.
Forget about tracking number of bugs has had
been created.
Forget about explaining developers how
avoiding bugs helps deliver better quality
software.
Track the time spent on things that do not bring
business value.
Team up with developers on improving their
efficiency and helping them work on new
features only.
The more team focus on business value the less
bugs and engineering problems they have to
struggle with.

32. Forget about
quality.
Think about
speed.
Continuous value.
Avoid death by thousands cuts by
looking into delivered value and
development efficiency.

33. What is speed?
(part 5)

34. How smooth is the road
developer has to take in
order to deliver something?

35. How many bumps there are
in the road? How frequently
they happen?

36. How flaky are your tests?

37. How often pull requests get
rejected?

38. How often demo fails?

39. Forget about quality. Think about speed.
Forget about testing. Leave testing up to developers and help them
with their development experience.
Mentor them on how to implement better quality
automated tests. Create services for monitoring
quality of tests.
Analyse root causes of rejected pull requests
and think about ways of improving the process.
Teach developers how to become more critical
and better in testing so it’s harder for them to fail
demos.

40. Forget about
quality.
Think about
speed.
Smooth developer experience.
Reduce types and number of
recurring bumps in development by
identifying causes, proposing and
implementing solutions.

41. What is speed?
(part 5 supplement)

42. How deep are the bumps in
road?

43. How long it takes developer
to accomplish something?

44. How long it takes to run
tests locally?

45. How much time is needed to
set up an instance for
exploratory testing?

46. Forget about quality. Think about speed.
Forget about testing. Understand what developers desire and what
they’re struggling with.
Create a timeline of development process. What
are the stages, how long they take, and is there
something you can do to reduce them?
Look for anomalies in development process.
Compare teams between each other. Look for
teams that are lagging behind to help them
improve. Look for teams that are superior to
learn from them.
Provide developers with data. Visualise it.
Watch how they improve.

47. Forget about
quality.
Think about
speed.
Reduce development time.
Ease developers work by providing
them with tools and procedures.
Analyse and spread knowledge on
best practices.

48. Summary

49. Forget about
quality.
Think about
speed.
The great premise.
Developers are good.
Developers just want to develop
new features.
Developers, as most people, are
lazy.
The harder it’s to do something, the
less likely they do it.

50. Quality Engineering

51. Quality Engineering

52. Engineering Productivity

53. Thank you.