Zapewnienie jakości:

Zapewnienie jakości to zbiór praktyk mających na celu zagwarantowanie, że produkt spełnia swoje wymagania i działa prawidłowo, obejmujący procesy, standardy i działania, które zapewniają jakość, a nie tylko te, które sprawdzają jej brak. Różnica między kontrolą jakości, czyli inspekcją gotowego produktu, a kontrolą jakości, ma charakter nie tylko terminologiczny: zapewnienie jakości dotyczy zapobiegania wadom, a kontrola ich wykrywania.

Tradycyjny układ, w którym oddzielny zespół testuje ukończone prace w odrębnej fazie przed wydaniem, ma dobrze udokumentowane słabości. Defekty są wykrywane długo po ich wprowadzeniu, gdy kontekst zostaje zapomniany, a koszty ich poprawy są najwyższe. Opóźnienie między pisaniem a testowaniem oznacza, że ​​programiści nie otrzymują na czas informacji zwrotnej o własnych schematach błędów. Odpowiedzialność za jakość jest przenoszona na grupę, która nie ma kontroli nad sposobem wykonania pracy.

Współczesne praktyki dystrybuują odpowiedzialność, zamiast ją koncentrować. Programiści piszą testy automatyczne w ramach kompilacji, przegląd kodu wykrywa problemy, zanim dotrą do jakiegokolwiek środowiska, ciągła integracja uruchamia weryfikację przy każdej zmianie, a specjaliści ds. jakości koncentrują się na strategii testów, testach eksploracyjnych i obszarach, do których automatyzacja nie jest w stanie dotrzeć. Rola specjalisty staje się rolą umożliwiającą i projektującą weryfikację, a nie jej pełną realizacją.

Piramida testów opisuje rozsądny rozkład automatycznej weryfikacji. Szeroka baza testów jednostkowych działa szybko i precyzyjnie wskazuje awarie. Mniejsza warstwa testów integracyjnych weryfikuje poprawność działania komponentów. Wąska, wierzchnia warstwa testów kompleksowych obejmuje kompletne ścieżki przez rzeczywisty system. Odwrócenie tego schematu, z silnym wykorzystaniem powolnych i niestabilnych testów kompleksowych, prowadzi do powstania zestawów testów, których uruchomienie zajmuje wiele godzin, które ulegają nieprzewidywalnym awariom i ostatecznie są ignorowane.

Testowanie eksploracyjne pozostaje niezbędne i często niedoceniane w organizacjach skoncentrowanych na automatyzacji. Testy automatyczne weryfikują, czy określone zachowanie nadal działa; nie są w stanie zauważyć, że przepływ jest mylący, że komunikat o błędzie jest nieprzydatny, że kombinacja, której nikt nie rozważał, prowadzi do nieporozumień lub że zmiana pogorszyła coś w sposób, którego nie obejmuje żadna asercja. Umiejętne, ręczne badanie znajduje kategorie problemów, których nie wykryje żaden zestaw testów.

Zobowiązania jakościowe wykraczają daleko poza poprawność funkcjonalną. Dostępność, wydajność w realistycznych warunkach, bezpieczeństwo, zachowanie na urządzeniach i połączeniach, z których faktycznie korzysta odbiorca, oraz poprawność przetwarzania danych – to wszystko są atrybuty jakości, a organizacje, które weryfikują wyłącznie zachowanie funkcjonalne, dostarczają produkty, które działają poprawnie, ale zawodzą znaczną część swoich odbiorców.

Zarządzanie danymi testowymi to mało efektowne ograniczenie, które decyduje o tym, jak wiele z tego jest możliwe do osiągnięcia w praktyce. Realistyczne dane są niezbędne do wykrycia realistycznych defektów, podczas gdy dane produkcyjne często nie mogą być wykorzystane bezpośrednio ze względu na obowiązki związane z prywatnością, a zbyt czyste dane syntetyczne ukrywają dokładnie te problemy, które warto znaleźć. Utworzenie reprezentatywnego, zgodnego z wymaganiami zbioru danych testowych jest zazwyczaj warunkiem wstępnym do miarodajnej weryfikacji, a nie szczegółem.

Ekonomiczny argument za zapobieganiem jest dobrze ugruntowany. Koszt usunięcia usterki gwałtownie rośnie wraz z upływem czasu jej wykrycia – od błahych, gdy zostanie wykryta na etapie rozwoju, do znacznych, gdy zostanie wykryta w fazie produkcyjnej, gdzie wiąże się również z kosztami operacyjnymi i utratą reputacji. Inwestycja we wcześniejsze wykrywanie usterek jest zatem uzasadniona wyłącznie kosztami, niezależnie od argumentu dotyczącego doświadczenia klienta.

Ponieważ jakość jest określana przez sposób wykonania pracy, a nie przez to, co dzieje się na końcu, praktyki te należą do dostawy, a nie po niej. W praktyce jest to ustalane w ramach rozwój produktów w ramach definicji ukończenia, z kryteriami dostępności i doświadczenia zaczerpniętymi z Audyt UX normy i progi wydajności od wydajność sieci budżety, tak aby weryfikowane informacje odpowiadały temu, co produkt ma faktycznie dostarczyć.