Testowanie oprogramowania - mity

Poniżej przedstawiono niektóre z najczęstszych mitów dotyczących testowania oprogramowania.

Mit 1: Testowanie jest zbyt drogie

Reality- Jest takie powiedzenie, płać mniej za testowanie podczas tworzenia oprogramowania lub płać więcej za konserwację lub poprawki później. Wczesne testowanie oszczędza czas i koszty w wielu aspektach, jednak obniżenie kosztów bez testowania może skutkować niewłaściwym zaprojektowaniem aplikacji, co spowoduje, że produkt stanie się bezużyteczny.

Mit 2: Testowanie jest czasochłonne

Reality- Podczas faz SDLC testowanie nigdy nie jest procesem czasochłonnym. Jednak diagnozowanie i naprawianie błędów zidentyfikowanych podczas prawidłowego testowania jest czynnością czasochłonną, ale produktywną.

Mit 3: Testowane są tylko w pełni opracowane produkty

Reality- Bez wątpienia testowanie zależy od kodu źródłowego, ale przeglądanie wymagań i tworzenie przypadków testowych jest niezależne od tworzonego kodu. Jednak podejście iteracyjne lub przyrostowe jako model cyklu rozwojowego może zmniejszyć zależność testowania od w pełni opracowanego oprogramowania.

Mit 4: Pełne testowanie jest możliwe

Reality- Staje się problemem, gdy klient lub tester uważa, że ​​pełne testowanie jest możliwe. Możliwe, że wszystkie ścieżki zostały przetestowane przez zespół, ale przeprowadzenie pełnego testowania nigdy nie jest możliwe. Mogą istnieć scenariusze, które nigdy nie są wykonywane przez zespół testowy lub klienta podczas cyklu życia oprogramowania i mogą zostać wykonane po wdrożeniu projektu.

Mit 5: Testowane oprogramowanie jest wolne od błędów

Reality - To bardzo powszechny mit, w który wierzą klienci, kierownicy projektów i zespół zarządzający. Nikt nie może twierdzić z absolutną pewnością, że aplikacja jest w 100% wolna od błędów, nawet jeśli tester z doskonałymi umiejętnościami testowania przetestował aplikację .

Mit 6: Pominięte usterki są spowodowane przez testerów

Reality- Nie jest właściwym podejściem do obwiniania testerów za błędy, które pozostają w aplikacji nawet po przeprowadzeniu testów. Ten mit dotyczy czasu, kosztu i wymagań zmieniających ograniczenia. Jednak strategia testowa może również skutkować pominięciem błędów przez zespół testujący.

Mit 7: Testerzy są odpowiedzialni za jakość produktu

Reality- Bardzo częstą błędną interpretacją jest to, że tylko testerzy lub zespół testujący powinni być odpowiedzialni za jakość produktu. Do obowiązków testerów należy identyfikacja błędów dla interesariuszy, a następnie to od nich zależy, czy naprawią błąd, czy wydadzą oprogramowanie. Wydanie oprogramowania w tym czasie wywiera większą presję na testerów, ponieważ zostaną obarczeni winą za każdy błąd.

Mit 8: Aby skrócić czas, należy wszędzie, gdzie to możliwe, stosować automatyzację testów

Reality- Tak, to prawda, że ​​automatyzacja testów skraca czas testowania, ale nie jest możliwe rozpoczęcie automatyzacji testów w dowolnym momencie podczas tworzenia oprogramowania. Automat testowy należy uruchomić po ręcznym przetestowaniu oprogramowania i pewnej stabilizacji. Ponadto automatyzacji testów nie można nigdy używać, jeśli wymagania stale się zmieniają.

Mit 9: Każdy może testować aplikację

Reality- Osoby spoza branży IT myślą, a nawet wierzą, że każdy może przetestować oprogramowanie, a testowanie nie jest pracą twórczą. Jednak testerzy doskonale wiedzą, że to mit. Myślenie alternatywnych scenariuszy, próba awarii oprogramowania z zamiarem zbadania potencjalnych błędów nie jest możliwa dla osoby, która je opracowała.

Mit 10: Jedynym zadaniem testera jest znajdowanie błędów

Reality- Znajdowanie błędów w oprogramowaniu jest zadaniem testerów, ale jednocześnie są oni ekspertami dziedzinowymi w zakresie danego oprogramowania. Deweloperzy są odpowiedzialni tylko za określony komponent lub obszar, który jest im przypisany, ale testerzy rozumieją ogólne działanie oprogramowania, jakie są zależności oraz wpływ jednego modułu na inny moduł.