5. • Manual testing takes too much time
• Manual testing is error prone
• Release of key resources
• Regression testing as a ‘safety net’
• Test automation as a source of feedback
• Test driven develpoment
• Automated tests as a live documentation
• Automation – good return of investment
Why to automate?
16-Apr-15 5Source: http://media.gamerevolution.com/images/misc/Image/cat-nap-on-comp.jpg
6. • Developers’ approach
• Hump of pain
• Initial costs
• Constantly changed code
• Legacy software
• Fear
• Bad habbits
• Wrong assumptions
Impediments for test automation
16-Apr-15 6Source: http://librairie.immateriel.fr/baw/9780596159818/httpatomoreillycomsourceoreillyimages329397.png
7. • Team work
• Transparent goals
• Well defined test strategy
Overcomming obstacles
16-Apr-15 7
10. What can we automate?
16-Apr-15 10Source: http://coding-is-like-cooking.info/wp-content/uploads/2013/07/agile-testing-quadrants.009.jpg
Unit Tests
Component
Tests
Functional Tests
Examples
Story Tests
Prototypes
Simulations
Exploratory
Testing
Usability Tests
UAT
Alpha / Beta
Performance
Tests
Security Testing
„ility” Testing
Automated
Automated
& Manual
Manual
Tools
11. What can we automate?
16-Apr-15 11
Manual
tests
GUI tests
Functional / API
tests
Unit tests
12. • Code analysis
• Builds and deployment, Continous Integration
• Unit and component tests
• API / Web services tests
• Business layer tests
• Presentation layer tests
• Load, performance, stress tests
• Results comparison
• Repetable activities
• Data / configuration setup
What can be automated?
16-Apr-15 12Source: http://blog.typemock.com/wp-content/uploads/2012/04/crash-test-dummies.jpg
13. • Usability tests
• Exploratory tests
• Tests that will always pass
• Tests that are executed only once
What shouldn’t be automated
16-Apr-15 13
14. • Code that was not designed to be tested automatically
• Software that doesn’t have clear separation between layers
• Tests when requirements constantly changes
What can be hard to automate?
16-Apr-15 14
17. Test strategy
16-Apr-15 17Source: http://4.bp.blogspot.com/_S3TFiuLoYtg/S_PdfSptbZI/AAAAAAAAAMk/nRrI4LB-3dc/s1600/Where%20to%20start.jpg
18. • Aim where it hurt most
• Multilayer approach
• Properly designed tests structure and maintenance
• Correct tools selection
• Do it agile
Test strategy
16-Apr-15 18
Testowanie automatyczne w kontekście metody zwinnych
Testowanie automatyczne w kontekście metody zwinnych
Dlatego testujemy?
sonda po kilkuletnim locie, epicko roztrzaskałą się o powierzchnię Marsa”
Remember what is important
Tell the truth, work hard, and come to dinner on time. -- Gerald R. Ford
SPYTAĆ!!!
Automatyacja dotyka wielu aspektów i wielu ludzi, programiści nawet dobrze testująć TDD nie muszą mieć pojęcia o aspektach biznesowych
Wiedząc dlaczego automatyzujemy i co będziemy automatyzować, łatwiej zaadresować potencjalne problemy
Mając z kolei określony plan działania minimalizujemy ryzyko nadmiernych kosztów i konfliktów w zespole
Testowanie automatyczne w kontekście metody zwinnych
Testowanie oprogramowania można podzielić na kilka podgrup. Ja zastosuje tutaj tak zwane kwadranty testowania w agile
Cztery kategorie które różnić się powodem dla którego wykonujemy poszczególne testy i też czy są to testy techniczne czy biznesowe. Mamy cztery: Q1 – Q4
Każdy z nich zawiera inne lementy (przeklikać)
Każdy z nich należy inaczej zautomatyzować – i nie wszystkie warto automatyzować (przeklikać)
Jeżeli spojrzeć by na całość tego wykresu w kontekście projektu, może ułatwić to wybór poprawnych narzędzi oraz strategii jak proces wdrażania automatyzacji miałby wyglądać
Niestety kwadranty testowania nie pokazują jednej rzeczy – które z tych grup testów są najbardziej potrzebne. Taką wartość przedstawia tak zwana piramida automatyzacji:
- prawdziwą podstawą dla testowania są testy jednostkowe – są najszybsze, najtańsze do napisania, najczęściej pisane dają najszybsze wyniki przez co są najlepszą inwestycją
Drugim poziomem są testy funkcjonalne – testy ukierunkowane iznesowo. Testujemy wszystko co jest logiką biznesową
Testy GUI – mają najniższy poziom zwrotu, ponieważ wymagają najwięcej nakładu czasowego do wytworzenia i utrzymania. Zwłaszcza ze względu na to, żę GUI się najłatwiej zmienia
Dobre podstawy to konieczność – tak jak dom lub też można porównać tak jak do Patrick Wilson-Welsh [2008] do bajki o trzech małych świkach, cełga, drewna i słomy – jak za dużo czasu będziemy ładować w wyższe poziomy, możemy marnować czas
Najwyższy poziom to oczywiście testy manualne, które pozostaną niezautomatyzowane
Automatyzować można prawie wszystko:
SPYTAĆ!!!
http://blog.typemock.com/wp-content/uploads/2012/04/crash-test-dummies.jpg
Automatyacja dotyka wielu aspektów i wielu ludzi, programiści nawet dobrze testująć TDD nie muszą mieć pojęcia o aspektach biznesowych
Wiedząc dlaczego automatyzujemy i co będziemy automatyzować, łatwiej zaadresować potencjalne problemy
Mając z kolei określony plan działania minimalizujemy ryzyko nadmiernych kosztów i konfliktów w zespole
Jeżeli nei będzie współpracy pomiędzy developerami a testerami oraz automatyzacja testowania nie zostanie wpisana w wymagania projektowe, wytworzony kod może być bardzo słabo testowalny automatycznie
Przykłądem tego może być kod gdzie wszystkie komponenty robią wszystko
Jeżeli od pewnego momentu wprowadzić poprawny standard i automatyzować testowanie nowych funkcjonalności to z czasem, kiedy stary kod będzie poprawiany, pokrycie testami wzrośnie – ale dobrze to naprawiać krok po kroku
Testowanie automatyczne w kontekście metody zwinnych
Firma decyduje się wprowadzać automatyzację nie mając doświadczenia, kupując drogie narzędzie i licząc ze wszystkie sprawy ono załatawi – to nie jest recepta na suckes
Dlatego od czego powinniśmy zacząć
Co sprawia najwięcej problemu – czy jest to dostarczanie testowalnego produktu – no to automatyzujemy deploy, czy są to problemy z wydajnością systemu – testy preformancowe, wysokie ryzyko porażki przy robieniu backupów – przetestujmy to
Nie da się uleczyć wszystkie na raz, więc trzeba inkrementacyjnie poprawić się
Co sprawia najwięcej problemu – czy jest to dostarczanie testowalnego produktu – no to automatyzujemy deploy, czy są to problemy z wydajnością systemu – testy preformancowe, wysokie ryzyko porażki przy robieniu backupów – przetestujmy to
Nie da się uleczyć wszystkie na raz, więc trzeba inkrementacyjnie poprawić się