Pierwszym ważnym czynnikiem wpływającym na jakość jest struktura. Im większy stopień uporządkowania projektu, tym większa jego finalna jakość. Nie chodzi tutaj o formalizowanie procedur, procesów decyzyjnych ani wprowadzanie innego rodzaju „spowalniaczy wytwarzania”. Jakość powinna być przedstawiana jako wartość, do której wszyscy dążą.

Dobre zebranie wymagań na początku projektu, spisanie szczegółowych zadań dla programistów, zaplanowanie czasu na testy i określenie metod weryfikujących po każdym z etapów prac. To podstawowe kroki, które powinny składać się na proces zapewnienia jakości stosowany przez firmy wdrożeniowe. Jakość nie powinna być wypadkową losowych zdarzeń tylko wynikową powtarzalnych czynności.

Drugim czynnikiem wpływającym na jakość projektu jest poziom odpowiedzialności i zaangażowania zespołu. Oprogramowanie jest tworzone przez ludzi, nie przez procedury, i to od nich zależy jego ostateczny kształt.

Checklisty

Czasem najprostsze rozwiązania są najlepsze.

Jednym z niewielu dokumentów, który w różnych formach towarzyszy projektowi od samego początku jest lista zawierająca spis prostych zapytań/kroków zrozumiałych dla każdego członka zespołu. Listy kontrolne (ang. checklisty) stosowane są np. w lotnictwie, wypełniane jest częścią procedury startowej.

Listy kontrolne mogą dotyczyć różnych aspektów tworzonego produktu:

  1. Aspektów związanych z pisaniem kodu:
    • Czy są tworzone komentarze?
    • Czy kod znajduje się repozytorium systemu kontroli wersji?
  2. Aspektów związanych z testami:
    • Czy zostały przeprowadzone testy wydajności?
    • Czy zostały przeprowadzone testy funkcjonalne?
  3. Aspektów związanych z użytecznością:
    • Czy zostały przeprowadzone testy z użytkownikami?
    • Czy projekt został finalnie przetestowany przez projektanta interakcji?

Checklisty nie powinny odstraszać. Powinny być bardzo zwięzłe i precyzyjnie oznaczać kolejne kroki. Pytania powinny być tak sformatowane, żeby można było na nie odpowiedzieć w sposób binarny 0,1 – tak lub nie. Inne odpowiedzi typu „może”, „w pewnym sensie” , „raczej tak” nie powinny  być akceptowalne.

Checklisty są stale aktualizowane i rozwijane przez pracowników. Ich zaangażowanie wpływa na większe utożsamianie się ze spisanymi zasadami i stosowanie ich w praktyce. Mogą mieć formę dokumentów tworzonych w narzędziu on-line np. Google Docs. Ważne, aby miał do nich dostęp cały zespół.

Dlaczego tak chętnie używamy checklist?

Są szybkie!

Napisanie checklisty wdrożeniowej dla średniej wielkości systemu zajmuje stosunkowo mało czasu
(w porównaniu do np. scenariuszy testowych i przypadków użycia).

Są proste!

Jak zostało już powiedziane. Checklisty są napisane w taki sposób, że każdy członek zespołu może bez problemów ją zrozumieć oraz edytować.

Umożliwiają ocenę stopnia ukończenia projektu!

Po odpowiedzeniu na wszystkie pytania z checklisty wyłania się obraz kondycji projektu. Widoczne jest, które elementy są już skończone a które wymagają poprawek.

Są re-użyteczne!

Nawet systemy pisane w różnych technologiach mają swoje części wspólne. W sklepach internetowych jest to np. proces dodawania produktu do koszyka.

„Pamiętają” o rzeczach z pozoru błahych!

W każdym projekcie są rzeczy/funkcje, które zostawia się „na koniec”. Podczas dużych wdrożeń nie zawsze się o nich pamięta, ale skutki nie uruchomienia ich mogą mieć bardzo zły wpływ na ogólny odbiór oprogramowania.

Jak może wyglądać checklista

Wygląd strony – Ogólne

jakosc1

Scenariusze testowe

Scenariusze testów funkcjonalnych są podstawowym narzędziem weryfikacji czy oprogramowanie działa prawidłowo i jest zgodne z projektem. Opisują one jaka powinna być reakcja systemu na wykonanie określonych czynności przez użytkownika. Scenariusze opisują ścieżki funkcjonalne, które użytkownicy mogą przemierzyć korzystając z aplikacji.

Scenariusze testowe używane są do testów czarnoskrzynkowych (ang. black-box test), czyli takich które skupiają się na efektach działania systemu, a nie na mechanizmach powodujących określone rezultaty. W trakcie tych testów nie analizuje się kodu, ale efekt jego działania.

Dzięki temu, testy w oparciu o scenariusze mogą wykonywać członkowie zespołu, którzy nie są programistami. Daje to dodatkowe możliwości sprawdzenia, czy zespół wdrażający zinterpretował poprawnie  wymagania funkcjonalne. Jest to szczególnie przydatne, gdy początkowa dokumentacja jest wybrakowana lub projekt jest niedokładny.

Scenariusze testowe przypominają swoją formą rozpisane do postaci scenariuszy przypadki użycia aplikacji, czyli mogą one powstawać na etapie analitycznym (przed wdrożeniem). Stanowią uzupełnienie dokumentacji. Równie dobrze mogą powstawać przy samym końcu wdrożenia, tworzone już na bazie funkcjonującej wersji systemu.

Dlaczego używamy scenariuszy testów w Divante?

Bo przypadki użycia to nie wszystko.

Przypadki użycia są zarysem przebiegu „sterowania” w danej funkcji. Często opisują tylko jedno główne przejście. Scenariusze testowe rozszerzają te przypadki o wszystkie lub prawie wszystkie możliwe ścieżki zarówno te poprawne jak i kończące się (zamierzonym) błędem.

Bo pisane są w naturalnym języku.

Kolejne kroki są sformułowane w taki sposób, aby nawet osoba nietechniczna, nie zaznajomiona z projektem mogła bez problemów odtworzyć przebieg sterowania.

Bo łatwo się je czyta.

Scenariusze testowe mają z góry narzuconą strukturę. Czytając taką „instrukcję” dokładnie wiemy: co jest nam potrzebne do rozpoczęcia testu (założenia początkowe, wymagane dane, potrzebne narzędzia), co powinniśmy otrzymać/zobaczyć po zakończeniu testu (np. komunikat walidacji o niepoprawnym adresie, nową wiadomość w skrzynce email) oraz co trzeba zrobić. Rozpisane krok po kroku.

Bo pełnią funkcję edukacyjną.

Klient, odbiorca oprogramowania przechodząc przez scenariusze testowe uczy się serwisu. Takie „poprowadzenie za rączkę” jest nierzadko skuteczniejsze niż przeczytanie instrukcji obsługi czy dokumentacji technicznej.

Jak może wyglądać taki scenariusz?

Scenariusze swoją formą przypominają przypadki użycia. Jeśli takowe były tworzone na etapie analizy warto wspomagać się nimi, jako bazą do utworzenia scenariuszy testowych. Można tworzyć je w sposób „tradycyjny” w edytorze teksu lub arkuszu kalkulacyjnym.

TCBXX – Przykład

jakosc2

Jednak takie dokumenty ciężko edytować i utrzymywać – dostosowywać do zmian w systemie.

Lepszym rozwiązaniem jest użycie prostego narzędzia jakim jest TestLink. Pozwala on na jednoczesną pracę zespołu nad jednym pakietem scenariuszy.

Każdy scenariusz składa się z następujących elementów:

  • Cel testu opisuje jaka funkcja będzie testowana w tym scenariuszu. Najczęściej są to dwa trzy zdania.
  • Wartości Początkowe — pole opisuje jak rozpocząć scenariusz testowy oraz co jest wymagane do zakończenia testu. W przykładzie powyżej są to zastrzeżenia o statusie klienta – niezalogowany, niezarejestrowany oraz jego położeniu w serwisie.
  • Scenariusz (kroki testowe) — to najważniejszy element opisu scenariusza testowego. Kroki są podzielone na akcje użytkownika oraz na odpowiedzi systemu. Scenariusz przypomina budową scenariusz filmowy w którym są uwzględnione wszystkie „kwestie” użytkownika oraz odpowiedzi systemu. Opis w formie dialogu w przejrzysty sposób pokazuje interakcje testera z systemem. Niepowodzenie testu może zostać od razu stwierdzone w przypadku nieodpowiedniej odpowiedzi systemu lub niemożliwości wykonania kolejnej akcji przez użytkownika
  • Rezultat— to pole pozostaje puste, do wypełnienia podczas przeprowadzania testów przez osobę odpowiedzialną.