Kiedy projekt zakłada, że po ostatniej fazie testów aplikacja będzie wolna od błędów, dział testów staje się odpowiedzialny za każdy problem znaleziony w wersji produkcyjnej. Z kolei próba przetestowania wszystkich aspektów tworzonej aplikacji spowoduje opóźnienie w dostarczeniu wersji produkcyjnej. W rzeczywistości prawie każda aplikacja zawiera błędy. Pytanie, jakiego są one rodzaju i jak często objawiają się w np. niestabilnym działaniu gotowego produktu.

Testy powinny być przeprowadzane w pełni skonfigurowanym środowisku.
Im bardziej środowisko testowe przypomina docelowe środowisko produkcyjne, tym bardziej można polegać na wynikach testów. Jeśli środowisko produkcyjne klienta jest przez niego w pełni kontrolowane, testowanie może odbywać się w jak najbardziej zbliżonych warunkach. Jeśli tak nie jest, testy przeprowadzone w pełni skonfigurowanym środowisku mogą spowodować, że ważne przypadki testowe mogą w ogóle nie powstać.

Testowanie jest potrzebne, aby udowodnić, że oprogramowanie nie zawiera błędów.
Testowanie samo w sobie nie służy do poprawienia jakości aplikacji, ale jest tej jakości miernikiem. Przystępując do testów nie należy robić tego z założeniem, że system działa.

Zazwyczaj przypadki testowe, których wykonanie nie spowodowało wykrycia błędu oznacza się statusami “passed”, “ok”, “tested ok”. Jednak z punktu widzenia testera to właśnie Test Case, który pozwolił na odkrycie błędu jest sukcesem.
Oprogramowanie oprócz tego, że powinno poprawnie wykonywać pożądane i zaimplementowane funkcjonalności, nie powinno pozwalać na operacje, do których wykonywania nie zostało stworzone.

Automatyzacja testów. Jeśli można coś zautomatyzować należy to zrobić.
Automatyzacja jest potrzebna. Oszczędza nam, testerom długich wieczornych godzin spędzonych przy manualnych testach regresywnych. Z kolei estymowana liczba godzin na testy manualne, może skłonić projekt do zainwestowania w automatyzację testów.

Jednak co z czasem spędzonym na nauce narzędzi do testów automatycznych, tworzeniu skryptów i ich aktualizacją? Jedynie odpowiednia kombinacja testów automatycznych, testów eksploracyjnych i manualnych testów wykonywanych na podstawie przypadków testowych może spowodować, że informacja o jakości testowanego oprogramowania będzie kompletna i wiarygodna.

• Masz wskazówki lub wnioski, którymi chciałbyś podzielić się z innymi?  Zapraszam do nadsyłania artykułów. Artykuły podpisane są imieniem i nazwiskiem autora.
• Szukasz informacji na temat związany z testowaniem oprogramowania? Wpisz swój temat na listę materiałów do opracowania. Artykuł ukaże się niebawem.

• czas (data uruchomienia w środowisku produkcyjnym, data zakończenia testów aplikacji, tzw. deadline)
• przypadki testowe (test cases) - odpowiedni procent przypadków testowych, których wykonanie nie spowodowało wykrycia błędu.
• wyczerpanie budżetu na testy
• pokrycie kodu, funkcjonalności, wymagań w założonym zakresie
• krzywa wykrywania błędów poniżej założonego wcześniej progu

Kto zatem powinien podjąć decyzję o zakończeniu testowania?

Osobą odpowiedzialną za testy w organizacji jest Test Manager. Z punktu widzenia jakości to on podejmuje decyzję o tym czy system spełnia zdefiniowane wcześniej kryteria jakości, jednak z punktu widzenia projektu informacja ta jest jedną ze składowych, które brane są pod uwagę przed wdrożeniem wersji produkcjyjnej testowanej aplikacji:

• daty uruchomienia współpracujących systemów
• cele związane ze sprzedażą
• sytuacja na rynku i poczynania konkurencji
• czynniki prawne
• oczekiwania klienta

Z powyższych wynika, że odpowiedzialnością Test Managera jest dostarczenie informacji nt jakości grupie osób odpowiedzialnych za podjęcie decyzji o “wypuszczeniu aplikacji na rynek”. W małych organizacjach/projektach taką rolę może pełnić Project Manager lub Product Manager. W dużych decyzja może być podejmowana przez grupę osób ze strony biznesu i projektu.

Pierwszy poziom kwalifikacji Foundation Level został uznany w roku 2006 za zgodny z Foundation Exam oferowanym przez ISEB.

Celem ISTQB było stworzenie ścieżki rozwoju dla testerów pod wspólną nazwą “Certified Tester”.

Certyfikaty ISTQB uznawane są w ponad 50 krajach na całym świecie.

ISTQB oferuje możliwość uzyskania następujących certyfikatów:

1. Foundation Level (CTFL)
   Egzamin poprzedzony jest szkoleniem dla osób zamierzających uzyskać certyfikat Certified Tester Foundation Level.

   Zakres zagadnień poruszanych na szkoleniu przygotowującym do uzyskania certyfikatu:

   • 1. Podstawy testowania
   • 2. Testowanie w cyklu życia oprogramowania
   • 3. Statyczne techniki testowania
   • 4. Techniki projektowania testów
   • 5. Zarządzanie testowaniem
   • 6. Testowanie wspierane narzędziami
2. Advanced Level (CTAL) - Test Manager, Test Analyst, Technical Test Analyst
   Egzamin poprzedzony jest szkoleniem przygotowującym do uzyskania certyfikatu. Jest ono przeznaczone jest dla osób posiadających już certyfikat Foundation ISTQB lub ISEB. Wymaga praktycznej wiedzy z zakresu zarządzania procesem testowania, analizy oraz znajomości narzędzi używanych w procesie testowania oprogramowania.Dla każdego poziomu wymagana jest ogólna wiedza z każdego rozdziału, ale w szczegółach są one różne.

   Warto pamiętać, że do egzaminu można podchodzić bez szkolenia.

   Zakres zagadnień poruszanych na szkoleniu przygotowującym do uzyskania certyfikatu:

   • 1. Podstawowe aspekty testowania oprogramowania
   • 2. Proces testowy
   • 3. Zarządzanie testami
   • 4. Techniki testowania
   • 5. Testowanie charakterystyk oprogramowania
   • 6. Techniki przeglądów
   • 7. Zarządzanie incydentem
   • 8. Standardy i usprawnienie procesu testowego (Test Process Improvement)
   • 9. Narzędzia testowe i automatyzacja
   • 10. Budowanie zespołu testowego
3. Expert Level

Podoba mi się szczególnie jedno zdanie z artykułu “Be the Worst” -  ”be the worst of the people you are surrounded by”, or “surround yourself with really great people.”

Oprócz tego, że jest to zasada, którą warto stosować w życiu to w kontekście projektu, rola testera pasuje do obu stwierdzeń powyżej

Magazyn w wersji elektornicznej do pobrania: www.agilerecord.com/agilerecord_01.pdf

Spis artykułów:

1. Be the Worst
2. Are All Pigs Equal? – or are some more equal than others?
3. 7 Steps to efficient GUI test automation using Selenium RC with Java
4. How Agile Methodologies Challenge Testing
5. Testing in an organisation going agile
6. Is there such a thing as an Agile tester?
7. Guerrilla Scrum: How to force organizational change
8. Quality – An agile point of view
9. Testability: Investment, not Overhead
10. The Future of Testing – How Testing and Technology will Change
11. Agile and Performance testing? “A Contradiction of terms?”
12. Software Testing Craft
13. Five tips for successful retrospectives
14. Still playing planning poker? Stop gambling with your project budget.
15. Scrum and RUP - A Comparison Doesn’t Go on All Fours
16. Masthead

Jakie ryzyka wiążą się z zastosowaniem podejścia typu Risk Based Testing?

• niesprecyzowana defininicja ryzyka - umieszczanie ryzyk i błędów w jednej  grupie
• subiektywna ocena wpływu ryzyka na projekt oparta na “pasujących” czynnikach
• brak przeglądów listy ryzyk w kolejnych fazach SDLC

Testując oprogramowanie nie da się sprawdzić wszystkich scenariuszy (tak jak nie da się znaleść wszystkich błędów). Dlatego tak ważne jest podjęcie decyzji co testujemy, a czego nie. Na których obszarach aplikacji skupić uwagę, a które uznać za “niezagrożone”. Testowanie np. metodami czarnej skrzynki z użyciem klas równoważności czy wartości brzegowych zapewnia co prawda pokrycie funkcjonalności testami, ale przy okazji powoduje, że liczba przypadków testowych (test cases) rośnie. Co więcej nie wszystkie z nich są tak samo istotne z punktu widzenia jakości systemu, czasu, który mamy na testowanie oraz wymagań klienta.

Sposobem na zmniejszenie liczby przypadków testowych jest wybranie tych funkcjonalnych obszarów aplikacji, które są najbardziej podatne na błędy oraz tych, których uszkodzenie może spowodować największe koszty.

Gdzie i kiedy spodziewać się największej liczby błędów?

To tylko kilka czynników, które warto wziąć pod uwagę przy ustalaniu zakresu testów aplikacji. Moim zdaniem -ważnych, ale jak zwykle wszystko zależy od kontekstu i danego projektu.

Złożone funkcjonalności.
Złożoność jest jedną z najczęstszych przyczyn powstawania błędów: wiele zmiennych użytych w kodzie, rozłożony na wiele kroków przepływ danych, skomplikowana logika biznesowa, zgromadzenie w jednym module wielu funkcji, których interfejsy wychodzą na zewnątrz.

Obszary systemu, które zostały zmodyfikowane/przepisane.
Testy regresywne powinny załatwić sprawę. Jednak i one mają swoje priorytety, które mogą zmienić się po wprowadzeniu zmian w funkcjonalności. Innego rodzaju zagrożeniem przy wyborze scenariuszy testowych do testów regresywnych jest paradoks pestycydów.

Wiele zmian w pojedyńczym module systemu może być symptomem źle wykonanej analizy. To sygnał aby otworzyć plik z wymaganiami i przypadkami użycia (Use Cases) -jeśli mamy ich zaktualizowaną wersję

Liczba osób zaangażowanych w programowanie/testy.
Im więcej osób jest zaangażowanych w zadanie tym większy nakład środków i czasu na komunikację. Wydłużony przepływ informacji prowadzi do ich zniekształcenia, nadinterpretacji czy pomijania. Może działać to zarówno podczas kodowania jak i przy testach.

Jakość wykonania testów (nie mówię tu o jakości aplikacji, ale o jakości pracy) jest ważniejsza niż odpowiedź na pytanie “Zostało nam trzy tygodnie na testy. Ile dodatkowych osób możemy w nie zaangażować?”. Jedną z metryk (z pewnością nie najlepszą) wydajności testera jest liczba zgłoszonych przez niego błędów.

Trudno jest porównać trójosobowy, doświadczony zespół testowy i zgłoszone przez niego błędy ukryte w architekturze systemu z 10-cioosobową grupą nie-testerów, którzy testują w międzyczasie i chcąc wykonać przypadek testowy, a więc przejść z ekranu A na ekran B, zaglądają np. do kodu aplikacji.

Presja czasu, zarówno przy kodowaniu jak i testach.
Błędne estymacje czasu, problemy w komunikacji, sytuacje nieprzewidziane podczas fazy analizy ryzyka projektu. Wszystko to powoduje opóźnienia zarówno w fazie kodowania jak i testów. Brak czasu jest wrogiem jakości. Skłania do pomijania pierwotnie obranej ścieżki i stosowania skrótów.

Pytania jakie warto zadać przed podjęciem decyzji co testujemy:

• które elementy aplikacji mogą zostać przetestowane we wczesnej fazie SDLC?
• które części kodu/moduły są najbardziej skomplikowane i dlatego najbardziej narażone na wystąpienie błędów?
• która funkcjonalność jest najważniejsza z punktu widzenia zastosowania projektu?
• która funkcjonanlość jest najbardziej widoczna dla klienta?
• które z testów mają najlepszy współczynnik pokrycia obszarów o wysokim ryzyku do czasu potrzebnego na testowanie?
• które z wymagań zostały zmienione lub ogólnie zdefiniowane?
• która funkcjonalność ma największy wpływ na bezpieczeństwo aplikacji?
• która funkcjonalność ma największy wpływ na finanse?
• Które elementy testowanej aplikacji mają największe znaczenie dla klienta?
• które aspekty podobnych, ukończonych poprzednio projektów powodowały problemy?
• które elementy podobnych, ukończonych projektów powodowały największe problemy w fazie utrzymania (maintenance)?
• co programiści uznają na najbardziej narażony na ryzyko element aplikacji?
• która część systemu była tworzona pod presją czasu?
• jaki rodzaj problemów może spowodować negatywną reakcję klienta?
• jaki rodzaj testów może pokryć możliwie najwięcej funkcjonalności?
• które z poprzednio wykonanych przypadków testowych powodowały wykrycie błędów? (test case value)

• sylabus (plan kursu dla Poziomu Podstawowego)
• słownik testerski dla Poziomu Podstawowego
• słownik testerski dla Poziomu Zaawansowanego (v 0.99)
• przykładowe pytania egzaminacyjne (wersja 2.0)

Rozwiązania:

1. zdefiniowane wymagania - jasne, kompletne, szczegółowe, spójne logicznie oraz testowalne wymagania, które zostaly zaakceptowane przez wszystkie strony. W projektach prowadzonych wg metodyk lekkich, niezbędna jest ciągła koordynacja  wymagań z udziałem klienta.
2. realistyczne estymacje czasu - zapewnienie odpowiedniej ilości czasu na planowanie testów, tworzenie przypadków testowych, testowanie, poprawę i retesty błędów, zmiany (change requests), raporty i dokumentację -zarówno tworzenie jak i czytanie. Zespół powinien mieć szansę na ukończenie projektu bez efektu wypalenia się.
3. testowanie w odpowiednim momencie - rozpoczęcie testów na wczesnym etapie SDLC, retesty po poprawie błędów, testy regresywne po zmianach w bieżącej wersji systemu.
4. trzymanie się zdefiniowanych wymagań - kiedy ruszy kodowanie, pojawią się zmiany, które zazwyczaj oznaczają dodatkową pracę w ustalonym na początku zakresie godzin. Dobrą praktyką jest komunikowanie konsekwencji takich zmian i jeśli są one niezbędne -reestymacja czasu na testy.
5. komunikacja - tam gdzie ma to sens, pomagają przeglądy i inspekcje. Narzędzia do pracy grupowej: email, repozytorium błędów i dokumentacji. Wersjonowanie. Aktualne wersje dokumentów projektowych. Oraz najważniejsze - bezpośredni kontakt członków zespołu.