Redakcja
Poniższe mity możesz podzielić na te, z którymi sam się spotykasz i w które sam wierzysz. Jeśli masz już trochę wiedzy i doświadczenia w testowaniu, to masz również szasnę, aby je prostować.
Mit 1: Testowanie jest za drogie.
Jak jest naprawdę: Im większy budżet wydamy na testowanie, tym mniej przeznaczymy na jego późniejsze utrzymanie albo naprawę. Wczesne testy pozwolą zaoszczędzić zarówno czas, jak i koszty w wielu obszarach, ale oszczędzanie na testach może doprowadzić do błędnego zaprojektowania rozwiązania, czyniąc produkt w ostateczności bezużytecznym. Testowanie na wielu poziomach potrafi zredukować dług technologiczny.
Mit 2: Testowanie pochłania za dużo czasu.
Jak jest naprawdę: Podczas faz cyklu życia systemu najwięcej czasu pochłania debugowanie zgłoszeń i naprawianie defektów zidentyfikowanych podczas testów. Samo testowanie będzie tu najmniej czasochłonnym procesem.
Mit 3: Testowane muszą być tylko dostępne aplikacje.
Jak jest naprawdę: Do przeglądu wymagań i opracowania przypadków testowych nie jest wymagane opracowanie kodu źródłowego. Choć uruchomienie testów jest ściśle związane z dostępnym oprogramowaniem, to istnieje wiele obszarów testowania, które nie są związane z dynamicznym operowaniem na GUI. Iteracyjne lub przyrostowe modele cyklu życia mogą zmniejszyć zależność testowania od w pełni dostępnego oprogramowania.
Mit 4: Można przetestować wszystko.
Jak jest naprawdę: Ani klient, ani tester nie powinni uważać, że możliwe jest przeprowadzenie pełnych testów. Możliwe, że wszystkie ścieżki zostały uruchomione, ale kompletne testy nigdy nie będą miały miejsca. Istnieć mogą bowiem pewne scenariusze, które nigdy nie są wykonywane przez zespół testowy lub klienta podczas cyklu wytwarzania oprogramowania i mogą zostać dopiero wykonywane po wdrożeniu produktu.
Mit 5: Testowane oprogramowanie jest wolne od błędów.
Jak jest naprawdę: Ten mit powielany jest najczęściej przez klientów, kierowników projektów czy zarządy. W rzeczywistości nikt nie jest w stanie zapewnić, że aplikacja jest w pełni wolna od błędów, nawet jeśli jej testowania podjął się tester / zespół testerów wyposażony w doskonałe umiejętności i posiadający bogate doświadczenie.
Mit 6: Odpowiedzialność za przegapienie defektu spoczywa na testerze.
Jak jest naprawdę: Zdarza się, że po zakończeniu testów, oprogramowanie nadal nie jest wolne od defektów. Nie jest to jednak wina wyłącznie testera. Sama strategia organizacji, dostępny czas i budżety, kontrola jakości na poszczególnych etapach mogą skutkować przeoczeniem błędów przez cały zespół testowy.
Mit 7: To testerzy są odpowiedzialni za jakość produktu.
Jak jest naprawdę: Myślenie, że odpowiedzialność za jakość produktu powinna spoczywać tylko na testerach / zespołach testujących, jest błędne. Obowiązkiem testerów jest identyfikacja defektów, a decyzję o ich wyeliminowaniu bądź ostatecznym wydaniu oprogramowania w takim stanie, w jakim jest obecnie, podejmuje klient. Dochodzi do paradoksu, w którym testerzy nie mają wpływu na decyzję o (nie) wydaniu oprogramowania, ale to właśnie oni są obwiniani za każdy defekt na produkcji.
Mit 8: Automatyzacja powinna być stosowana wszędzie.
Jak jest naprawdę: Nie jest możliwe, aby wdrożyć automatyzację na każdym, dowolnym etapie tworzenia oprogramowania. Należy dokonać tego dopiero wtedy, gdy oprogramowanie uzyskało pewien stopień stabilności. Nie jest wskazane również, aby wdrażać automatyzację w projektach, w których wymagania ciągle ulegają zmianom.
Mit 9: Każdy może przetestować oprogramowanie.
Jak jest naprawdę: Funkcjonuje przekonanie, że testować mogą też ludzie spoza branży IT, a testowanie wcale nie jest trudną pracą. Przetestowanie oprogramowania z wykorzystaniem różnych scenariuszy w celu znalezienia potencjalnych błędów może okazać się niewykonalne dla osób bez kompetencji, dla zamawiających czy dla samych twórców oprogramowania.
Mit 10: Jedynym zadaniem testera jest znalezienie defektów.
Jak jest naprawdę: Szukanie defektów może być głównym zadaniem testera, ale jednocześnie jest on odpowiedzialny za potwierdzanie działania oprogramowania. Tak, jak programista jest odpowiedzialny za określony i przypisany mu obszar, tak tester rozumie nie tylko ogólne działanie aplikacji, ale także zależności oraz wzajemne wpływy na siebie modułów. Pomaga mu to pokazywać obszary niedziałające, ale również budować zaufanie dla działającej części rozwiązania.
Poprzednią porcję najważniejszych mitów opisaliśmy już w naszym wcześniejszym artykule.
Przygotowujemy już także publikację "Mity testowania dla seniorów":
- Bogate doświadczenie nie czyni cię lepszym testerem.
- Seniorowi można płacić mniej, bo rzadziej zmienia pracę.
- Klikający senior to przegryw.
Czy znacie jakieś inne? Dajcie nam o nich znać w komentarzu.
