Podejścia zwinne oparte są o zmiany – metamorfozę w wytwarzaniu i zarządzaniu operacyjnym (ludzie, procesy i technologie), umożliwiającą dostarczanie innowacyjnego oprogramowania tak szybko, jak to możliwe. Pomimo tych wszystkich przekształceń, jeden element wydaje się niezachwiany. To proces testowania oprogramowania. Według różnych badań, 70%-88% organizacji przyjęło zwinne podejście do wytwarzania oprogramowania, podczas gdy zaledwie 26%-30% z nich zaimplementowało na szeroką skalę automatyzację testów. Innymi słowy, proces testowania zazwyczaj pozostaje w niezmienionej formie, mimo że organizacje inwestują mnóstwo czasu i pracy w transformację swojego procesu wytwórczego, by sprostał dzisiejszym i przyszłym potrzebom biznesowym. Większość narzędzi i procesów związanych z testowaniem, będących spuścizną po okresie przed przekształceniem, nie jest w stanie spełnić wymagań ciągłego testowania narzucanych przez podejście DevOps z kilku powodów: Niezdolność do przesunięcia testowania „w lewo” – testy zwykle są wykonywane na koniec cyklu, gdy zakończona jest implementacja interfejsu użytkownika; poza tym brak wcześniejszych automatycznych testów API. Testy są czasochłonne, więc rzadko są wykonywane w całości. Oznacza to brak pełnej informacji o wpływie zmian na wszystkie obszary systemu i na sposób, w jaki użytkownicy dotychczas postrzegali system. Wysokie nakłady na utrzymanie, bowiem testy UI często wymagają znacznych przeróbek, aby odzwierciedlać nieustanne zmiany ze względu na dynamiczny proces wytwarzania. Automatyzacja w takim przypadku jest wyjątkowo pracochłonna i nierzadko zostaje porzucona. Niestabilność środowisk testowych (spowodowana problemami z danymi testowymi, niedostępnością innych systemów itp.) zwykle powoduje opóźnienia, niekompletną realizację testów, fałszywe alarmy lub przeoczenia błędów, czy nieadekwatne wyniki, co uniemożliwia szybkie dostarczenie informacji o jakości systemu, tak we współczesnych podejściach niezbędne. Aby umożliwić ciągłe testowanie, poziom automatyzacji powinien sięgać, a nawet przekraczać 85% wszystkich testów. Aby to osiągnąć, niezbędnych jest kilka zmian w podejściu do kontroli jakości: Ograniczenie do minimum testów manualnych i zarządzanie pozostałymi z nich w formie odpowiednio dokumentowanych sesji testów eksploracyjnych, które można wykorzystać do jeszcze dalej idącej automatyzacji. Oparcie testów o ryzyko biznesowe, aby zoptymalizować ilość testów i wdrożyć zautomatyzowane punkty decyzyjne. Przesunięcie testów do warstwy API, gdzie to tylko możliwe. Zintegrowanie testów funkcjonalnych w procesie Continuous Delivery. Odpowiednie zarządzanie danymi testowymi oraz wykorzystanie wirtualizacji serwisów, umożliwiające powtarzalne i częste przeprowadzanie testów end-to-end.

1. Michał Błaszak
From testing to quality monitoring:
Challenges of QA in Continuous Delivery
Educational materials

2. Michał Błaszak
I’ve been working in IT for over 10 years now
(testing, test management, requirements analysis,
projects and services management, QA consultancy).
Outside of my professional career I’m a multihobbyst 
Photo by oczami m. | DiscoPogo

3. The Digital Disruption
“Businesses must continuously exploit digital technologies
to both create new sources of customer value and increase
operational agility in service of customers.”
Forrester, March 2014, “The Future Of Business Is Digital”

4. DevTestOps reality
Continuous Testing is a must

5. Waterfall
Years - Months
Requirements
Design
Implementation
Testing
Acceptance
Deployment

6. Rational Unified Process
Months - Weeks
Inception Elaboration Construction Transition
Requirements
Design
Implementation
Testing
Deployment

7. Agile
Weeks - Days
Oooops
!!!
Ooops
!!!

8. Dev(Test)Ops
Days - Minutes
Continuous Testing
Continuous Integration
Collaborative Development Continuous Release & Deployment
Continuous Feedback
Continuous Monitoring

9. Big Bang
Incremental
Iterative
DevOps
Delivery cycle time
Agile
Today
Level of complexity Robotics
IoT
DevOps
Picture from Futurama animated series

10. 67%
average level of
redundancy
40%
average risk coverage
10%
of all test
automation is
API test automation
80%
manual testing
55%
of systems only
partially
accessible by
Testers
56%
of overall test effort
goes into
test case maintenance
30%
of bugs found in
acceptance
& production stage
50%
of manual testing goes
into test
data preparation &
organization
8 problems that influence
testing agility

11. 10%
of all test
automation is
API test automation
56%
of overall test effort
goes into
test case maintenance
40%
average risk coverage
80%
manual testing
55%
of systems only
partially
accessible by
Testers
30%
of bugs found in
acceptance
& production stage
50%
of manual testing goes
into test
data preparation &
organization
67%
average level of
redundancy
The biggest strength of DevOps is not solving problems,
but exposing buried problems.
Picture from Star Wars: Episode IV – A New Hope

12. Focus your testing on the business risk
Do what matters most

13. Low
High
Medium
Time limit for testing activities
New
Test
Cases
Development cycle iterations 1 2 3 4 5
?
Business
Risk

14. Focus on prime criteria
without drowning in
test cases.
Assign a unique test
goal to each of your
test cases.
Let the root cause
analysis
become an easy task.
React on product
changes
almost instantly.
4 rules to challenge this situation

15. 60%
80%
100%
40%
20%
0%
Intuition
Methodology
100%20%0% 40% 60% 80%
Created Test Cases
Risk
Coverage
Key to success is achieving maximum risk
coverage with a minimal number of
meaningful test cases.

16. What if reporting is based on
number of successfully executed test cases?
What is the quality of the delivered software?
422 9
Can we safely release it?
What does the number of test cases really mean?
108Version x.x

17. This should be the new currency in testing
66% 15% 10%Version x.x
And what if reporting is based on
Risk Coverage [%]?
9%

18. Business Risk-based approach to test coverage
W = 2[F] * 2[D]
W – Weigth, F – Frequency, D - Damage

19. Automate and test API. Focus on key enablers.
Reverse the two pyramids

20. % Completed
API
UI
4x 6x 20x
Creation Maintenance Execution
0 %
100 %
Delivery cycle time
Increase efficiency

21. ?
API
API
80%
Manual Testing
20%
Automated Testing
UI
Today
15%
Manual Testing
85%
Automated Testing
UI
Tomorrow
Ability to test is
becoming driven by
automation

22. On average
organisations require access to
33 systems
for development and testing
18Average number of
systems with
unrestricted access
Designed by Freepik
WELCOME TO
TESTER’S HELL
Pictures from South Park animated series

23. Orchestrated
Service
Virtualization
Designed by Freepik
Service Virtualization allows
development teams to identify
60% to 90% more defects at least
one step earlier
in the development process.

24. Orchestrated Service Virtualization reduces defect costs by 38%
Unit Integration System Acceptance Production
Defect
Costs 1 3 4 6 30
Relative Defect Frequency [%]
OSV
w/o OSV
Orchestrated
Service
Virtualization
Service Virtualization allows
development teams to identify
60% to 90% more defects at least
one step earlier
in the development process.

25. Distributed
Execution
Test Portfolio
Execution
Designed by Freepik

26. Continuous
Integration
Designed by Freepik
Tricentis

27. Test developers focus on technical challenges and become mentors
Manual testers become
automation specialists

28. ?
API
API
80%
Manual Testing
20%
Automated Testing
UI
Today
15%
Manual Testing
85%
Automated Testing
UI
Tomorrow
Manual Testers
Automation Specialists
Former Manual Testers
Automation Engineers
Ratio
10
:
1

29. Model-Based
Test Automation
Test
Development
Framework
Record /
Replay
30%10% 90%+Level of automation
Programming needed
Buisness readability
Automation Tools
Generations

30. Extract system model Build Test Cases
Feed Test DataAutomate
Model-Based Automation
System under test
Designed by Freepik

31. SDET?(Software Development Engineer in Test)
Development and Testing
require
different prespectives.

32. Visualize code Map to test cases
Find test gaps Track root cause

33. Easy to read.
No programming skills.
Easy maintenance for
both UI and API tests.
Maximum reuse
across technologies
Minimum effort on
maintenance.
4 rules of automated tests
of the future

34. Michał Błaszak | michal.blaszak@secorda.com
Thank you!

35. Example implementation
Unknown
Risk
Coverage
37%
2.5
Weeks
100%
Automation Level
Smoke Testing
Model Based
Automation
Value Based
Test Cases
Continuous
Integration
Test Data
Management
AutomateOptimize
1193
89%
48
Hours
92%
Single Agent Regression
8
Hours
Automation
Level
Distributed
Regression
34
Minutes
Distributed
Smoke Testing
Integrate
53%
Risk Coverage
Smoke Testing
Redundancy 75%
4755
10
Weeks
Tests
Execution
Test Case Count 7%
11
Testers
Effort Test Data 50%

36. Michał Błaszak | michal.blaszak@secorda.com
Thank you!