Strona testowa pierwsza

Agenda – Lekcja 1:

  • Czym jest jakość?
  • Czym jest Testowanie i po co testujemy?
  • 7 zasad Testowania
  • Psychologia Testów


Co to jest jakość?     
   
Jakość jest stopniem zaspokojenia potrzeb odbiorcy docelowego przez wyrób, usługę lub towar.

   

1. Od strony użytkownika produkt musi spełniać wymagania, potrzeby i oczekiwania. W zależności od funkcji produktu może być:

  • Ładny
  • Wygodny
  • Funkcjonalny

Produkt może spełniać wiele wymagań zależnych od potrzeb klienta docelowego

Jako przykład możemy tutaj rozpatrywać „konflikt” między użytkownikami systemów iOS i Android. Każda ze stron „konfliktu” uważa, że jeden z tych systemów jest lepszy niż drugi. Mimo, że oba systemy pełnią podobną funkcję, tj.: pozwalają nam na korzystanie z telefonu komórkowego – „przeciwnicy” uważają swój system za lepszy. Wynika to głównie z innych potrzeb użytkowników i innego sposobu postrzegania tego, co dla nich znaczy jakość produktu. Oba produkty mogą być doskonałe, jednakże różnice w systemach i poziom istotności danych różnic dla użytkownika końcowego powoduje, że mimo niewielkich obiektywnych różnic w jakości – nie reprezentuje wartości dla użytkownika systemu konkurencyjnego. 


2. Podejście producenta – jest to jakość jako spełnienie wymagań postawionych w specyfikacji produktu

  • Posiada funkcje, jakich wymaga klient
  • Ładny design
  • Szybkość działania
  • Wytrzymały

Zgodność ze specyfikacją bardzo łatwo zmierzyć, jeśli dokumentacja jest wysokiej jakości. W przypadku braku zgodności ze specyfikacją narażamy się na brak zadowolenia odbiorcy końcowego.

Idealnym przykładem może być tutaj Titanic – przez producenta reklamowany jako niezatapialny i na ówczesne czasy – wzór innowacyjności i jakości. Titanic został zaprojektowany w sposób, że rzeczywiście mógłby być rozpatrywany jako niezatapialny – określono dokładny projekt i specyfikację statku. Jednakże producent ze względu na wysokie koszty podjął decyzję o wprowadzeniu zmian konstrukcyjnych, co spowodowało zupełnie inny poziom jakości produktu końcowego i jak się okazuje, przyniosło katastrofalne skutki podczas dziewiczego rejsu. Badacze katastrofy Titanica doszli do konkluzji, że wypadek, jaki miał miejsce – przyniósł tak tragiczne skutki głównie ze względu na zmianę konstrukcji statku. Jeśli producent podchodzi w sposób podobny do zapewnienia jakości swoich produktów – rezultatem odstępstwa od specyfikacji mogą przynieść poważne konsekwencje dla przedsiębiorstwa.



3. Podejście produktowe – produkt wysokiej jakości określany jest jako spełniający wymagane funkcje lub właściwości

  • Wyjątkowy sposób spełniania zadanej funkcji
  • Ponadprzeciętna jakość wykonania
  • Nowe funkcjonalności – produkt zaspokaja potrzeby, o których klient nie miał wcześniej pojęcia


Jako przykład możemy rozpatrzeć firmę Apple i ich produkty. Firma ta jest często przedstawiana jako kreator innowacyjnych rozwiązań dla użytkownika końcowego, o których nie miał pojęcia lub nie był świadomy, że jego potrzeby mogą być rozwiązane w inny sposób niż dotychczas. Firma ta potrafi również wypromować swoje produkty w odpowiedni sposób. Apple zmienił wiele w współczesnym świecie technologii a skupienie się na produkcie spowodowało, że iPhone może być postrzegany jako prekursor dzisiejszego smartphone. Wiele produktów Apple opartych jest na bazie wcześniej istniejących produktów, jednakże przez unikalne podejście do upraszczania i łączenia istniejących technologii spowodowało, że to Apple jest często postrzegany jako firma, która wymyśliła dane rozwiązanie lub urządzenie. Idealnym przykładem jest tutaj Macintosh z interfejsem graficznym wprowadzony w 1984 – natomiast prawie 10 lat wcześniej – w roku 1973 firma Xerox wprowadziła Alto – komputer osobisty z interfejsem graficznym. Ale kto o tym słyszał? 😊

  

4. Podejście wartości – jakość miarą tego, jaką cenę jest klient gotowy zapłacić

Podejście wartości warto rozpatrzeć w oparciu o następujące przykłady:
Pierwszy rysunek dziecka – dla matki jest to bezcenne dzieło, natomiast dla osób niezwiązanych sentymentalnie z autorem dzieła – nie przedstawia żadnej wartości i nie byłby w stanie za to zapłacić.
Obraz zakupiony w sklepie – dla części odbiorców sztuki będzie to dzieło, które będą wysoko cenić, natomiast dla wyszukanego odbiorcy – nie będzie przedstawiać żadnej wartości i mimo, że cena zakupu takiego obrazu jest atrakcyjna – ze względu na brak subiektywnej jakości kupującego – nie przedstawia wymaganego poziomu jakości.
Mona Lisa – dla części odbiorców obraz Leonardo da Vinci będzie tylko starym obrazem i w ich ocenie obraz nie może być wart tyle ile szacowana jego wartość. Natomiast dla części koneserów sztuki – niezależnie od zasobów finansowych będzie to sztuka warta każdej złotówki – niezależnie od tego czy to będzie bilet do Luwru, żeby obejrzeć obraz czy jeśli pojawiłaby się taka możliwość – by móc zakupić obraz dla siebie na wyłączność. 

Czy jakość wpływa na zadowolenie klienta?



Jak widać istnieje wiele podejść do jakości i tego jaką stanowi wartość dla różnych interesariuszy w firmie i jej otoczeniu. Bardzo ważnym aspektem prowadzenia firmy i projektów jest określenie podejścia przedsiębiorstwa i produktu do jakości, ale przede wszystkim – zrozumienie potrzeb użytkownika i zapewnienie jakości zadowalającej jego potrzeby w określonym czasie lub budżecie.

Zadowolenie klienta = wartościowy produkt + wysoka jakość + dostawa w założonym czasie lub budżecie

Jakość w oprogramowaniu

W latach 90-tych największe korporacje zaczęły zauważać, że tracą miliardy dolarów rocznie z powodu oprogramowania, które nie dostarcza założonych funkcji.
Światowe rządy wraz z przemysłem doszli do wniosku, że awarie oprogramowania uderzające w krytyczne systemy informatyczne mogą powodować straty rzędu dziesiątek miliardów dolarów.
W 2001 roku Magazyn CIO opublikował artykuł „Let’s Stop Wasting $78 Billion a year” opisujący problemy z niską jakością oprogramowania

„Efektywny proces wytwarzania użytecznego oprogramowania zastosowany w sposób, który pozwala na zapewnienie „mierzalnej” wartości dla producentów oprogramowania oraz ich klientów” Bessin, J., “The Business Value of Quality”


Jakość według D. Garvina

Jakość powinna być rozważana jako pojęcie wielowymiarowe.

  • Jakość dostawy – Zawartość, funkcje i cechy sprecyzowane w specyfikacji są dostarczane w sposób przynoszący korzyść dla klienta
  • Jakość cech – Oprogramowanie zapewnia cechy, które zaskoczą klienta od pierwszego użycia
  • Niezawodność – Funkcjonalności dostarczane są w sposób ciągły bez awarii
  • Zgodność – Oprogramowanie jest zgodne z lokalnymi i globalnymi standardami, na przykład z konwencjami projektowania UI
  • Trwałość – Możliwość utrzymywania i poprawiania bez niezamierzonych efektów ubocznych. Zamiany nie powodują spadku niezawodności
  • Obsługa serwisowa – Oprogramowanie utrzymywane i poprawiane w krótkim czasie. Personel może uzyskać wszystkie informacje potrzebne do naprawy w krótkim czasie
  • Estetyka – Oprogramowanie posiada estetyczny interfejs
  • Postrzeganie – Uprzedzenia wpływają na postrzeganie jakości. Doświadczenia z przeszłości

Jak zapewnić jakość?


Zanim odpowiemy sobie na pytanie jak zapewnić jakość – ważne jest zrozumienie różnicy między kontrolą a zapewnieniem jakości. Kontrola swoim zakresem obejmuje produkt i jej celem jest wykrycie jego wad (czynność detekcyjna), natomiast zapewnienie zajmuje się procesami i zapobieganiem potencjalnym wadom – proces prewencyjny. 
W przypadku oprogramowania zapewnienie jakości polega na transparentności komunikacji, zdefiniowanym rolom i odpowiedzialności w zespole. Bardzo ważne jest określenie cyklu życia oprogramowania i poprawna definicja wymagań w projekcie. Bardzo ważnym aspektem jest definicja jakości określona i przyjęta przez cały zespół. Kontrola jakości w procesie wytwarzania oprogramowania polega na testowaniu na różnych poziomach testów, wyszukiwaniu błędów, ale także weryfikacji i walidacji produktu pracy.

„Jakość pamięta się dłużej niż cenę”
                                       Gucci



Czym jest Testowanie i po co to robimy?

Aktualnie z dużym trudem można znaleźć dziedzinę życia, która nie wykorzystuje w różnym stopniu oprogramowania.
Systemy informatyczne odgrywają dużą rolę w naszym życiu i często od ich jakości zależy nie tylko jakość naszej zabawy podczas grania w gry komputerowe, ale także nasze finanse, a nawet życie.

Oprogramowanie, które zostało wprowadzone do użytku z błędami może:
1. Spowodować utratę zaufania publicznego, czasu i pieniędzy
2. Uniemożliwić pozyskanie nowych kontrahentów
3. Narazić na stratę czasu lub pieniędzy
4. Może spowodować utratę zdrowia a nawet życia ludzkiego

Definicja Testowania
Testowanie oprogramowania jest to proces związany z wytwarzaniem oprogramowania. Składa się ze wszystkich czynności cyklu życia, skoncentrowany na planowaniu, przygotowaniu i ocenie oprogramowania by określić czy spełnia założone wymagania, dopasowane do celów w jakich zostało wyprodukowane oraz wykrywania usterek.

Cele Testowania

  • Dokonanie oceny produktów pracy
  • Sprawdzenie, czy zostały spełnione wymagania ze specyfikacji
  • Skontrolowanie, czy przedmiot testów jest jest kompletny i działa zgodne z oczekiwaniami interesariuszy i użytkowników końcowych
  • Budowanie zaufania co do poziomu jakości przedmiotu testów
  • Wykrywanie defektów i awarii i zapobieganie im
  • Dostarczenie niezbędnych informacji do podejmowania świadomych decyzji przez interesariuszy
  • Obniżenie poziomu ryzyka związanego z jakością oprogramowania
  • Przestrzeganie przepisów i norm

Dlaczego Testowanie jest niezbędne?


Jak już wcześniej wspomniano, brak kontroli jakości oprogramowania może doprowadzić do wielu zdarzeń, które nie tylko mają potencjał do doprowadzenia do upadku firmy, utraty klientów lub co gorsza utraty zdrowia lub życia użytkowników końcowych. Dlatego też w momencie wykrycia defektu ważne są następujące pytania:
·       Jak poważny jest defekt?
·       Jaki będzie koszt jego naprawy?
·       Jakie jest prawdopodobieństwo jego zajścia?

7  Zasad Testowania

1. Testowanie ujawnia usterki, ale nie może dowieść ich braku
Testowanie udowadnia, że coś nie działa, ale testowanie nie może zapewnić, że w oprogramowaniu nie ma żadnych defektów. Najbardziej prozaiczną przyczyną tego jest brak możliwości przewidzenia niestandardowego zachowania oprogramowania lub użytkownika.

2. Testowanie gruntowne jest niemożliwe
Gruntowne testowanie w przypadku oprogramowania znaczy sprawdzenie każdej możliwej wartości wejściowej, każdej możliwej konfiguracji (przeglądarki, urządzenia końcowe), ale także zachowania użytkownika. W przypadku testowania np. numeru PESEL – testowanie gruntowne sprowadzałoby się do sprawdzenia każdego możliwego numeru PESEL.

3. Wczesne testowanie oszczędza czas i pieniądze
Im wcześniej zaczniemy testować, tym mniejszy koszt usunięcia defektu i jego wpływu na resztę oprogramowania. Przykładem może być tutaj testowanie dokumentacji – w przypadku wykrycia defektu wiąże się z poprawą dokumentacji – jest to łatwiejsza i tańsza metoda wykrycia defektu niż wykrylibyśmy to na etapie testów.

4. Kumulowanie się defektów
Defekty nigdy nie rozkładają się równomiernie w oprogramowaniu i czasie ich wykrycia – jest to niesamowicie istotne z perspektywy analizy ryzyka i dalszych działań. Gdy podczas testowania jeden z modułów ma zdecydowanie więcej defektów niż inne to istnieje bardzo duża szansa, że moduł ten jest obarczony dużo większą ilością defektów. Dzięki temu możemy lepiej zaplanować strategię testów i identyfikację modułów, które są podejrzane do intensywniejszych testów.

5. Paradoks pestycydów
Gdy będziemy używać ciągle tych samych, niezmienionych testów, istniej duża szansa, że te testy nie będą spełniały swojej roli w przyszłości i przestaną wykrywać defekty. Aby przezwyciężyć ten paradoks istotne jest, aby modyfikować testy, ale także tworzyć nowe. Przykładem mogą być pestycydy w rolnictwie – im więcej i dłużej używamy danego środka tym bardziej rośliny, które ma zlikwidować są na niego uodpornione.

6. Testowanie jest zależne od kontekstu
Testowanie oprogramowania przeprowadza się zawsze w zależności jakie zastosowanie będzie miało dane oprogramowanie.

7. Przekonanie o braku „błędu” jest błędem
Nie ma możliwości gruntownego przetestowania (oprócz szczególnych przypadków), ale też jako tester nie możemy dowieść braku usterek, dlatego mimo wykonania nawet dużej ilości testów – nie ma możliwości stwierdzenia, że oprogramowanie nie zawiera defektów.

Psychologia Testowania

  • Podejmij postawę współpracującą, nie walcz z zespołem
  • Podkreślaj korzyści płynące z czynności testowych
  • Przekazuj informacje o wynikach testów i uwagi w sposób neutralny
  • Raporty o defektach i wnioski z przeglądów formuj w sposób obiektywny w oparciu o fakty
  • Próbuj zrozumieć rozmówcę i dlaczego reaguje negatywnie na informacje
  • Upewnij się, że ty i twój rozmówca rozumiecie się wzajemne, zwłaszcza, gdy nie pracujecie w jednym miejscu


Warto pamiętać, że programista i tester bardzo często mają różne sposoby myślenia. Programista ma głównie na celu zaprojektować i wytworzyć produkt, natomiast tester jest nastawiony bardziej na weryfikację i walidację produktu pracy, ale także wykrywanie czy podczas implementacji wystąpiły defekty. Niektórzy programiści, jeśli reprezentują odpowiednią postawę – mogą także testować oprogramowanie. Bardzo ważnym zjawiskiem psychologicznym w tym aspekcie jest efekt potwierdzenia – jest to tendencja do wybierania informacji, które są zgodne z naszymi poglądami. Zjawisko to jest powszechnie wykorzystywane w mediach społecznościowych – algorytmy poznają nasze preferencje i wyświetlają nam informacje zgodne z naszymi przekonaniami, czasem niezależnie od tego czy są prawidłowe tworząc wokół nas bańkę informacyjną. W przypadku pracy testera to zjawisko ma duże znaczenie – gdy znajdujemy defekt następuje w nas silne przekonanie, że ma to miejsce przez błąd popełniony w kodzie – jednakże czasem może to wynikać z tego, że test był wykonany w niepoprawny sposób, co przez efekt potwierdzenia może być trudne do akceptacji. Dlatego bardzo ważna jest jasna definicja celów testowania i kontrolowanie by testerzy przestrzegali wyznaczonych ram i starali się, by ich osobiste przekonania nie miały wpływu na proces testowy. Dodatkowo, testerzy ze względu na częste przekonanie, że testowanie jest czynnością destrukcyjną i negatywnie wpływającą na proces wytwarzania oprogramowania – testerzy swoje uwagi powinni zgłaszać w sposób neutralny i konstruktywny, by nie powodować napięć w zespole. Dlatego też ważne jest, żeby tester był osobą o rozwiniętych zdolnościach interpersonalnych. Testerzy, ze względu na swoją rolę i punkt widzenia mają uprzedzenia poznawcze, które są bardzo istotną wartością dodaną do projektu – dzięki innemu spojrzeniu na produkt i wraz ze wzrostem doświadczenia mają możliwość wykrywania większej ilości defektów