Co robi zespół QA w rozwoju oprogramowania, jeśli codziennie nie znajduje błędów?

Inżynierowie ds. zapewniania jakości (QA) często słyszą to:

„Twój zespół wykrył wczoraj dwadzieścia błędów, ale dzisiaj nie masz żadnego!”

Stanowisko to, jakkolwiek zasadne by się nie wydawało, jest sprzeczne z celem i celami zapewniania jakości w tworzeniu oprogramowania.

Co dokładnie robi QA w rozwoju oprogramowania?

W tym artykule Andrey Gilyov, zastępca szefa działu kontroli jakości w ITRex, wyjaśnia, dlaczego Twój zespół kontroli jakości nie próżnuje, nawet jeśli znajdzie mniej błędów. Dowiesz się również, dlaczego zawsze powinieneś zatrudniać inżynierów ds. kontroli jakości, aby wzmocnili wewnętrzny lub zlecony na zewnątrz zespół IT, zamiast zlecać testowanie kodu przez inżynierów oprogramowania.

Zrozumienie celów kontroli jakości i dlaczego nie ograniczają się one do śledzenia błędów

W zależności od typu i złożoności oprogramowania, które chcesz zbudować, możesz potrzebować specjalisty ds. kontroli jakości w niepełnym wymiarze godzin lub dedykowanego zespołu ds. kontroli jakości przydzielonego do Twojego projektu. A ich obowiązki wykraczają daleko poza wykrywanie błędów i zgłaszanie ich kierownikowi projektu i zespołowi programistów.

W szczególności cele zapewniania jakości obejmują:

• Zapobieganie błędom. Ostatnie badania wskazują, że inżynierowie oprogramowania spędzają około 20% swojego czasu na naprawianiu błędów. Pomnóż ten czas przez średnią stawkę godzinową inżyniera oprogramowania, a zdasz sobie sprawę, ile wadliwy kod może kosztować Twoją firmę. Cena poprawiania błędów również rośnie wykładniczo wraz z upływem czasu w procesie tworzenia oprogramowania — nie wspominając już o długoterminowych konsekwencjach wprowadzenia do produkcji oprogramowania obarczonego błędami, takich jak luki w zabezpieczeniach, pogorszenie jakości obsługi klienta i utrata reputacji. Tak więc kluczowym celem zapewniania jakości w tworzeniu oprogramowania jest znajdowanie błędów, zanim spowodują one znaczne szkody. Aby to osiągnąć, zespół ds. kontroli jakości przygotowuje się do testowania na długo przed położeniem ręki na oprogramowaniu. Te czynności przygotowawcze obejmują przegląd dokumentacji testowej, napisanie planu testów i przypadków testowych, wybór odpowiednich narzędzi testowych i skonfigurowanie środowiska testowego.
• Śledzenie i ocena stanu oprogramowania. Aby podejmować świadome decyzje w projektach oprogramowania, kierownik projektu i klient potrzebują aktualnych informacji o oprogramowaniu, nad którym pracują. Cele zapewniania jakości obejmują między innymi dostarczanie tych informacji w dowolnym okresie na osi czasu projektu oprogramowania. Warto jednak wspomnieć, że inżynierowie ds. zapewnienia jakości nie wybierają najlepszego czasu na uruchomienie oprogramowania. Zamiast tego to klient podejmuje ostateczną decyzję. Po konsultacji z zespołem kontroli jakości klient może nawet zdecydować się na wdrożenie oprogramowania zawierającego udokumentowane błędy! Na przykład możesz podjąć taką decyzję, gdy ramy czasowe na wydanie produktu są stosunkowo krótkie, a kompromis między nagrodą — tj. wyprzedzenie konkurencji lub włączenie krytycznej funkcji — jest większy niż ryzyko wprowadzenia go z drobnymi błędami. Tak czy inaczej, musisz wykryć, udokumentować i nadać priorytet tym błędom, co jest również jednym z celów Twojego zespołu ds. kontroli jakości.
• Walidacja wymagań. Podstawową rolą kontroli jakości w rozwoju oprogramowania jest potwierdzenie, że oprogramowanie działa zgodnie z oczekiwaniami i spełnia wszystkie kryteria określone w dokumencie specyfikacji wymagań dotyczących oprogramowania (SRS). Kiedy specjaliści ds. zapewniania jakości przeprowadzają ręczne lub automatyczne testy i identyfikują błędy, tworzą zgłoszenie w oprogramowaniu do śledzenia błędów, takim jak Jira lub ClickUp, dla zespołu programistów. Gdy zespół programistów naprawi błędy, cykl testowania się powtarza. Zatem znajdowanie błędów nie jest celem zapewniania jakości; jest raczej produktem ubocznym działań QA.

Zespoły kontroli jakości czasami nie znajdują żadnych błędów. I to jest w porządku

Teraz, gdy już omówiłeś cele i cele kontroli jakości, wróćmy do pytania, które postawiliśmy na początku tego artykułu.

Co robi zespół QA w rozwoju oprogramowania, jeśli jego raporty o błędach nie zawierają żadnych defektów przez wiele dni?

Istnieje kilka powodów, dla których specjaliści ds. kontroli jakości mogą nie znaleźć błędów w Twoim oprogramowaniu:

1. Oprogramowanie zostało dokładnie przetestowane. Jeśli oprogramowanie zostało dokładnie przetestowane, jest mniej prawdopodobne, że podczas powtarzania cyklu kontroli jakości lub gdy produkt wejdzie do produkcji, pojawią się błędy.
2. Oprogramowanie ma prostą konstrukcję. Aplikacje z ograniczonym zestawem funkcji, integracją i prostym interfejsem użytkownika rzadziej zawierają błędy niż oprogramowanie o bardziej złożonej architekturze i wymaganiach dotyczących wydajności.
3. Oprogramowanie jest zbudowane z wykorzystaniem najlepszych praktyk. Zespoły inżynierów oprogramowania, które piszą czysty i dobrze udokumentowany kod, przestrzegają standardów kodowania i stosują kontrolę wersji, często dostarczają oprogramowanie z niewielką liczbą błędów. Błędy te są wykrywane i korygowane na wczesnym etapie procesu testowania, a dalsze wady nie ujawnią się na późniejszych etapach.
4. Proces testowania mógłby być bardziej kompleksowy. Brak czasu, zasobów lub umiejętności może uniemożliwić specjalistom ds. kontroli jakości dokładne przetestowanie Twojego oprogramowania. W rezultacie niektóre błędy mogą zostać przeoczone.
5. Błędy nie są powtarzalne. Czasami specjaliści ds. kontroli jakości mogą nie znaleźć żadnych błędów, ponieważ błędy nie występują konsekwentnie. Do takich sytuacji mogą prowadzić różne czynniki, w tym złożoność oprogramowania, korzystanie z bibliotek innych firm lub obecność zewnętrznych zależności.

Bez względu na przyczynę nie należy lekceważyć znaczenia kontroli jakości w tworzeniu oprogramowania, nie mówiąc już o zabawie pomysłem umożliwienia programistom przetestowania kodu za Ciebie.

Nie zrozum mnie źle: programiści mogą pisać i wykonywać testy automatyczne w wielofunkcyjnych zespołach Agile. Lub nawet ręcznie testuj oprogramowanie.

Jednak w takich zespołach, w których role projektowe są często dzielone, głównym celem jest szybsze udostępnianie działającego oprogramowania lub funkcji, skrócenie czasu do uzyskania wartości i wczesne zebranie opinii. W tym przypadku możemy mieć do czynienia z kwestią ryzyka w stosunku do nagrody opisaną w poprzedniej sekcji. W ten sposób Twój projekt może się kumulować, prowadząc do problemów z wydajnością i znacznych kosztów debugowania w przyszłości.

Inne powody, dla których warto zatrudnić dedykowanych specjalistów ds. kontroli jakości to:

• Wiedza o tym, jak kodować, nie jest równoznaczna z wiedzą, jak przejrzeć kod pod kątem potencjalnych błędów
• Deweloperzy rzadko lubią testować, podczas gdy eksperci ds. kontroli jakości tak
• Stawki godzinowe inżynierów oprogramowania są zwykle wyższe niż stawki godzinowe specjalistów ds. zapewnienia jakości
• Programiści i inżynierowie kontroli jakości zwykle mają różne umiejętności miękkie. W przypadku kontroli jakości dbałość o szczegóły, umiejętność analizowania złożonych systemów i wielozadaniowość zajmują centralne miejsce. Z drugiej strony inżynierowie oprogramowania często pracują w środowiskach współpracujących i skupiają się na jednym zadaniu na raz.

Tak więc, nawet jeśli Twój zespół ds. kontroli jakości nie znalazł dziś żadnych błędów, nie ulegaj pokusie zwolnienia specjalistów ds. zapewniania jakości ani powierzenia zadań testowych głównemu zespołowi programistycznemu. Nawet jeśli takie podejście może w krótkim czasie zmniejszyć Twoją wypłatę, koszt utraty klientów z powodu słabej wydajności oprogramowania lub cyberataków związanych z błędami może być wielokrotnie wyższy.

A jeśli potrzebujesz pomocy w sprawdzeniu, czy Twoje oprogramowanie działa dobrze, spełnia wszystkie wymagania określone w SRS lub wizji technicznej i pomaga osiągnąć cele biznesowe, skontaktuj się z ekspertami ITRex QA!

Pierwotnie opublikowane na stronie https://itrexgroup.com 20 stycznia 2023 r.