Prezentacja Przemysława Podsiadlika i Rafała Peronia przedstawiona na 12. Quality Meetupie.

2. Testy regresji z perspektywy
piramidy testów
Przemysław Podsiadlik
Rafał Peroń

3. Agenda
1. Testy regresji
2. Problemy, z jakimi się zetknęliśmy
3. Piramida testów
4. Przykładowe user story i propozycja pokrycia testami
5. Propozycja procesu testowego

4. Testy regresji

5. Testy regresji
• Przeprowadzane po zmodyfikowaniu aplikacji

6. Testy regresji
• Przeprowadzane po zmodyfikowaniu aplikacji
• Ujawniają błedy powstałe w wyniku zmian kodu lub środowiska

7. Testy regresji
• Przeprowadzane po zmodyfikowaniu aplikacji
• Ujawniają błedy powstałe w wyniku zmian kodu lub środowiska
• Nieefektywne przy przeprowadzeniu w pełni ręcznie

8. Testy regresji
• Przeprowadzane po zmodyfikowaniu aplikacji
• Ujawniają błedy powstałe w wyniku zmian kodu lub środowiska
• Nieefektywne przy przeprowadzeniu w pełni ręcznie
• Dobry kandydat do automatyzacji ze względu na powtarzalność

9. Testy regresji
• Przeprowadzane po zmodyfikowaniu aplikacji
• Ujawniają błedy powstałe w wyniku zmian kodu lub środowiska
• Nieefektywne przy przeprowadzeniu w pełni ręcznie
• Dobry kandydat do automatyzacji ze względu na powtarzalność
• Możliwe do zautomatyzowania na różnych poziomach testów

10. Taka sytuacja

11. Taka sytuacja
• Projekt trwa
• Dodawane są kolejne funkcjonalności
• Developerzy piszą „swoje” testy
• QA testują manualnie i również automatyzują na poziomie GUI

12. Taka sytuacja
• Projekt trwa
• Dodawane są kolejne funkcjonalności
• Developerzy piszą „swoje” testy
• QA testują manualnie i również automatyzują na poziomie GUI
... a bugi wracają... Dlaczego?

13. Problemy z jakimi się zetknęliśmy

14. Problemy z jakimi się zetknęliśmy
• Za mało unit testów, DEVowie niechętni do ich pisania

15. Problemy z jakimi się zetknęliśmy
• Za mało unit testów, DEVowie niechętni do ich pisania
• Zbyt dużo testów na poziomie integracyjnym (API)

16. Problemy z jakimi się zetknęliśmy
• Za mało unit testów, DEVowie niechętni do ich pisania
• Zbyt dużo testów na poziomie integracyjnym (API)
• Zbyt dużo testów na poziomie UI (i zbyt atomowe)

17. Problemy z jakimi się zetknęliśmy
• Za mało unit testów, DEVowie niechętni do ich pisania
• Zbyt dużo testów na poziomie integracyjnym (API)
• Zbyt dużo testów na poziomie UI (i zbyt atomowe)
• Duplikacja testów pomiędzy poziomami (głównie UI i API)

18. Problemy z jakimi się zetknęliśmy
• Za mało unit testów, DEVowie niechętni do ich pisania
• Zbyt dużo testów na poziomie integracyjnym (API)
• Zbyt dużo testów na poziomie UI (i zbyt atomowe)
• Duplikacja testów pomiędzy poziomami (głównie UI i API)
• Brak wysokopoziomowych przekrojowych testów e2e sprawdzających
procesy biznesowe

19. Jak to się kończyło

20. Jak to się kończyło

21. Piramida testów

22. Piramida testów
• Najistotniejsze unit testy (najwięcej)

23. Piramida testów
• Najistotniejsze unit testy (najwięcej)
• Funkcjonalne testy API

24. Piramida testów
• Najistotniejsze unit testy (najwięcej)
• Funkcjonalne testy API
• Przekrojowe testy e2e na poziomie UI

25. Przykładowe user story
User story:Wykonanie przelewu
Jako klient banku
Chcę przekazać określoną ilość pieniędzy na inne konto
Aby w sposób bezgotówkowy zapłacić posiadaczowi docelowego konta

26. Kryteria akceptacji
1. gdy numery kont są prawidłowe oraz saldo rachunku źródłowego jest większe niż
kwota przelewu, bilans konta źródłowego zostanie pomniejszony o wartość
transferu, a saldo konta docelowego powiększone o tą samą wartość
2. gdy numery konta są nieprawidłowe, nie ma możliwości wykonania przelewu
3. gdy saldo konta źródłowego jest mniejsze niż wartość transferu, nie ma
możliwości wykonania przelewu, a użytkownik zostanie powiadomiony, iż saldo
jest niewystarczające
4. gdy wartość transferu jest mniejsza lub równa zero, nie ma możliwości wykonania
przelewu

27. Poglądowa architektura
Web
App HttpResponceMsg SendTransfer() {
ValidateAccounts();
ValidateCredit();
CalculateBalance();
UpdateBalance();
}
DB
API

28. Co proponujemy?

29. Co proponujemy?
Logika domenowa

30. Co proponujemy?
Logika domenowa
Biznesowe kryteria akceptacji
Komunikacja pomiędzy modułami

31. Co proponujemy?
Logika domenowa
Biznesowe kryteria akceptacji
Komunikacja pomiędzy modułami
Proces biznesowy

32. Poglądowa architektura
Web
App HttpResponceMsg SendTransfer() {
ValidateAccounts();
ValidateCredit();
CalculateBalance();
UpdateBalance();
}
DB
API

33. Kryteria akceptacji
1. gdy numery kont są prawidłowe oraz saldo rachunku źródłowego jest większe niż
kwota przelewu, balans konta źródłowego zostanie pomniejszony o wartość
transferu, a saldo konta docelowego powiększone o tą samą wartość
2. gdy numery konta są nieprawidłowe, nie ma możliwości wykonania przelewu
3. gdy saldo konta źródłowego jest mniejsze niż wartość transferu, nie ma
możliwości wykonania przelewu, a użytkownik zostanie powiadomiony, iż saldo
jest niewystarczające
4. gdy wartość transferu jest mniejsza lub równa zero, nie ma możliwości wykonania
przelewu

34. W jaki sposób dążyć do ideału?

35. W jaki sposób dążyć do ideału?
• QA oraz DEV ustalają na wczesnym etapie developmentu funkcjonalności
co, jak i na jakim poziomie należy przetestować

36. W jaki sposób dążyć do ideału?
• QA oraz DEV ustalają na wczesnym etapie developmentu funkcjonalności
co, jak i na jakim poziomie należy przetestować
• DEV w trakcie developmentu pisze testy UT (najlepiejTDD)

37. W jaki sposób dążyć do ideału?
• QA oraz DEV ustalają na wczesnym etapie developmentu funkcjonalności
co, jak i na jakim poziomie należy przetestować
• DEV w trakcie developmentu pisze testy UT (najlepiejTDD)
• DEV w początkowej fazie developmentu wystawia nagłówki API, a tester
pisze testy funkcjonalneAPI

38. W jaki sposób dążyć do ideału?
• QA oraz DEV ustalają na wczesnym etapie developmentu funkcjonalności
co, jak i na jakim poziomie należy przetestować
• DEV w trakcie developmentu pisze testy UT (najlepiejTDD)
• DEV w początkowej fazie developmentu wystawia nagłówki API, a tester
pisze testy funkcjonalneAPI
• Code review (QA zaangażowany)

39. W jaki sposób dążyć do ideału?
• QA oraz DEV ustalają na wczesnym etapie developmentu funkcjonalności
co, jak i na jakim poziomie należy przetestować
• DEV w trakcie developmentu pisze testy UT (najlepiejTDD)
• DEV w początkowej fazie developmentu wystawia nagłówki API, a tester
pisze testy funkcjonalneAPI
• Code review (QA zaangażowany)
• Testy e2e

40. W jaki sposób dążyć do ideału?
• QA oraz DEV ustalają na wczesnym etapie developmentu funkcjonalności
co, jak i na jakim poziomie należy przetestować
• DEV w trakcie developmentu pisze testy UT (najlepiejTDD)
• DEV w początkowej fazie developmentu wystawia nagłówki API, a tester
pisze testy funkcjonalneAPI
• Code review (QA zaangażowany)
• Testy e2e
• Continuous Integration i Continuous Deployment

41. To było tylko 1 user story.
Zadbaj o wszystkie!