Platformy dla testów automatycznych

Prostą i dużo wyjaśniającą prezentację nt. różnych "frameworków" do testów automatycznych można znaleźć w prezentacji http://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/ghanakotagayatri.pdf.

Opisuje ona zalety i wady "modular testing", "data driven testing", "keyword driven testing" oraz "hybrid framework testing".

Przegląd narzędzi automatyzujących testy aplikacji na Androida.

Po linkiem http://blog.bughuntress.com/automated-testing/useful-tools-for-android-apps-test-automation można znaleźć, krótki przegląd narzędzi do testów aplikacji androidowych.

Test czy nie test case

Od wielu lat mam szczęście pracować ze stałym zespołem ekspertów zajmujących się testowaniem oprogramowania. Oczywiście ludzie w zespole zmieniają się, jednak wiedza i doświadczenie powinny pozostać. Ta właśnie "krzywa uczenia się" jest największą korzyścią z utrzymywania takiego zespołu. Oczywiście obok wielu innych czynników, jak "kuźnia talentów" dla innych działów, elastyczność w realizacji zadań z różnych dziedzin, obsługa zdarzeń ad-hoc, itd.

Obecność stałego zespołu ekspertów pracujących dla klienta wewnętrznego, eliminuje w dużej części konieczność dokumentowania przypadków testowych. Zaznaczam, że przez przypadek testowy rozumiem pełną gębą procedurę ściśle opisującą co i jak (pisałem o tym  między innymi tutaj lub tutaj).

Nie ma sensu przeznaczania cennego czasu inżyniera na opisywanie tego co będzie robił. Lepiej jest zachęcić go do zrobienia tego co zrobić ma. Z moich obserwacji wynika, że i tak większość testerów robi notatki i zapiski oraz stara się strukturalizować swoją pracę. Jedynie szczypiorniści w tym zawodzie mają tendencję do rzucania się na głęboką wodę. Ale i tutaj zespół przychodzi z pomocą i szybko wydobywa topielca z topieli problemu wskazując mu sposób na rozwiązanie problemu.

Bardzo pomocne przy tym trybie pracy są wszelkie listy kontrolne i heurystyki wspierające inżyniera w jego pracy. Dobrze jest aby takie narzędzia systematyzować i katalogować wewnątrz zespołu.

Problem szacowania, planowania i raportowania przeniosłem na poziom wymagań. Umożliwia mi to proces wytwarzania funkcjonujący w mojej firmie. Plan testów i raport z testów jest jedynym obowiązkowym dokumentem pracy testera/grupy testerów. Pozostałe elementy są opcjonalne.

Nie ma więc w tutaj przypadków testowych co nie znaczy, że jest bałagan. Formalizujemy te obszary, które podlegają częstej regresji. Te które jest sens automatyzujemy. Jednak w głównej mierze polegamy na znajomości środowiska, doświadczeniu i z własnych potrzeb wytworzonym na własny użytek narzędziach.

W zamian otrzymujemy elastyczność, niski nakład prac administracyjnych, jasny i prosty proces oraz - liczę na to - poczucie odpowiedzialności i autonomii.

Zilustruję to przykładem z niedalekiej przeszłości, kiedy w trybie awarii pojawiła się konieczność sprawdzenia sporego kawałka oprogramowania. Testy szacowaliśmy na dwa tygodnie dla 1 osoby. Harmonogram innych projektów nie pozwalał na zrobienie tego w wymaganym czasie. Podjęliśmy decyzję, że przez 1 dzień (8 godzin) cały zespół (8 osób) wykonana możliwe do wykonania testy. Proces rozdzielania pracy był bardzo krótki i polegał na "poborze ochotniczym". Jedna osoba zajęła się koordynowaniem prac aby się nie dublować.

Efekt był taki, że po przekazaniu na produkcję, awaria został zażegnana a inne defekty nie pojawiły się na w ten sposób przetestowanym releasie.

Oczywiste oczywistości czyli o podstawach kompletnych testów

Tym razem chciałbym napisać o rzeczach, które uważam za kompletne podstawy... . Chciałem zdanie dokończyć 'testowania oprogramowania' ale uzmysłowiłem sobie, że to nie dotyczy wyłącznie testowania. A więc... chcę napisać o kompletnych i podstawowych zabiegach, stosowanych w szeroko pojętej inżynierii w mocnym kontekście testów oprogramowania, odchylonych - z kolei - mocno w stronę automatyzacji i/lub powtarzalności.

• Parametryzacja - separacja danych od logiki ich przetwarzania. Duża część testów polega na mnipulacji samymi danych (klasy równoważności, wartość graniczne, dziedziny itd). W związku z tym o wiele łatwiej jest zarządzać tymi danymi mając je "na zewnątrz" skryptu.
  
• Atomizacja - rozbijanie złożonych problemów na proste. Informatyka jest pod tym kątem szczególnie łaskawą dziedziną. Praktycznie każdy złożony problem składa się z mniejszych i prostszych. Trzeba tylko umieć wyłowić powiązania prostych problemów w kontekście złożonego. Dodatkowo, "testowo" obsłużone proste problemy mogą być re-używalne.
  
• Logika - nie testować w oparciu o nazwy kontrolek ale w oparciu o logiczne przepływy danych. Każde oprogramowanie składa się z warstwy prezentacyjnej (interfejs użytkownika), warstwy przetwarzania (middleware) i warstwy sterowania (sterowniki). Dobrze napisane oprogramowania ma te warstwy mocno odseparowane co pozwala na wydajne testowanie logiki w oderwaniu od kontrolek i zasilaniu logiki bezpośrednio z zestawów danych testowych np. poprzez API.
  
• Narzędzia - co może za nas zrobić narzędzie to niech to zrobi. Pytanie tylko czy potrafimy tym narzędziem się posłużyć. Narzędzi jest całe mnóstwo i nie problem znaleźć takie, które wydaje się przydatne ale wcześniej trzeba wiedzieć do czego chce się wykorzystać takie narzędzie.
  
• Abstrakcja - nie związywanie procedur testowych z konkretną wersją (wyglądem) testowanego oprogramowania ale raczej z jego przeznaczeniem. Np. przypadki testowe odwołujące się do konkretnych nazw kontrolek muszą być aktualizowane gdy zmieni się wersja GUI. A z drugiej strony, skoro przypadki już są gotowe to po co czekać i nie uruchomić procedur testowych od razu. Przecież kontrolki na interfejsie użytkownika można potraktować jako swojego rodzaju dane, które się weryfikuje (czy kontrolka jest, wartości kontrolki, funkcjonalności kontrolki).
  
• Elastyczność - łatwość rozbudowywania i dostosowywania do konkretnych potrzeb. W przypadku automatyzacji chodzi np. o możliwość zestawiania poszczególnych skryptów czy przypadków testowych w różnych sekwencjach.
  
• Generowalność - generowanie scenariuszy i generowanie rezultatów testów. Wybudowanie środowiska testowego pozwalającego na swobodne generowanie scenariuszy testowych o jasno określonym celu jest bardzo trudne jeśli wręcz nie możliwe. Jakkolwiek, należy budować przypadki testowe w taki sposób aby na ich podstawie móc generować scenariusze. Drugą stroną jest możliwość generowania wyników z testów. Każdy przeprowadzony test kończy się określonym wynikiem. Dobrze jest jeśli takie wyniki odnotowywane są automatycznie w sposób umożliwiający ich dalszą weryfikację.
  

Data Driven Test Automation Frameworks

Zaczynając budowę automatycznego środowiska testowego, bardzo pomocne jest zdefiniowanie podstaw. Pozwala to na późniejsze uniknięcie błędów związanych z utrzymaniem i rozwojem takiego środowiska co jest jednym z największych zagrożeń związanych z taką architekturą testów. "Data Driven Test Automation Frameworks" jest to dokument zawierający kilka propozycji w jaki sposób można zorganizować sobie to środowisko w sposób pozwalający zminimalizować te zagrożenia. Niestety opis ten zawiera tylko rozwiązania oparte o dane.