Testowanie bez zasobów QA

Czy możliwe jest przeprowadzenie wystarczających testów aplikacji tylko z programistami i licencjatami bez zasobów QA?

Istnieją dwie szkoły myśli:

Jednym z nich jest przekonanie, że wszystkie błędy są związane z kodem i że jeśli masz bardzo wysoki procent pokrycia testami dla swojego kodu, to zasadniczo nie powinieneś mieć żadnych błędów. Jako testerzy wszyscy wiemy, że to nieprawda!

Innym przekonaniem jest to, że wykonujesz wystarczające testy jednostkowe, a także przeprowadzasz testy integracji, systemu i akceptacji użytkowników, aby upewnić się, że aplikacja jest odpowiednia do celu. Chociaż wydaje się to fajnym pomysłem, nie jest to praktyczne, ponieważ programiści muszą zacząć kodować nowe funkcje!

Oba te przekonania są skrajne.

Testowanie własnego kodu może być efektywne, ponieważ jako programista wiesz, która część kodu jest złożona i jest bardziej podatna na błędy, więc możesz skupić się na tym obszarze. Ponadto, wiedząc, że nie ma już kontroli jakości, jesteś zmuszony pisać kod wysokiej jakości, jak to ujął jeden z programistów

W mojej pierwszej pracy nie miałem kontroli jakości. Do mnie należało upewnienie się, że mój własny kod jest wystarczająco wysokiej jakości przed jego wydaniem, a ten aspekt przeraził mnie na tyle, że nauczyłem się pisać kod wysokiej jakości (co w zasadzie oznacza, że ​​dokładnie testujesz swój własny kod, wykonując własną kontrolę jakości).

Czy testowanie przez programistów wystarczy?

Uważam, że zachęcanie programistów do przejmowania odpowiedzialności za jakość własnego kodu jest dobrym posunięciem, jednak podczas testowania własnego kodu jest więcej niż prawdopodobne, że przegapisz całą klasę błędów.

Możesz być bardzo skuteczny w wyłapywaniu rodzajów błędów, o których możesz pomyśleć, ale są to zawsze najłatwiejsze do złapania błędy. Testy, które piszesz dla siebie, nigdy nie będą dobrze wychwytywać błędów w twoich założeniach dotyczących tego, co kod powinien robić, jakiego rodzaju danych wejściowych musi obsługiwać itp. Wyłapywanie tego rodzaju błędów koncepcyjnych naprawdę wymaga testów kontradyktoryjnych od kogoś, kto nie jest nie zaczyna się od tego samego zestawu założeń.

Praca jako tester automatyzacji oznaczała, że ​​musiałem skupić się na testowaniu i kodowaniu w tym samym czasie i często miałem problemy! Kiedy tworzyłem testy, chciałem tylko upewnić się, że kod jest wykonywany i że test przeszedł pomyślnie, nie przejmowałem się tym, jaki jest rzeczywisty test, ponieważ skupiałem się głównie na kodowaniu. Wkrótce zdałem sobie sprawę, że automatyzuję bezużyteczne testy, które nie dają żadnej wartości.

Inną ważną kwestią, na którą należy zwrócić uwagę, jest to, że testy jednostkowe wychwytują tylko błędy programistów w kodzie, testy jednostkowe nie wykrywają błędów w aplikacji, co oznacza, że ​​jeśli masz 100% pokrycia kodu, nie oznacza to, że aplikacja jest wolna od błędów.

Chociaż zawsze konieczne jest przetestowanie własnego kodu za pomocą testów jednostkowych, zanim zostanie on przekazany, ważne jest również, aby spojrzeć na niego z drugiej strony z behawioralnego punktu widzenia. Często jesteśmy zbyt blisko kodu, by naprawdę go poprawiać i poddawać naprawdę dziwnym skrajnym przypadkom, a dobrzy pracownicy kontroli jakości są w tym całkiem biegli. Testowanie na poziomie systemu przez inną grupę użytkowników, na przykład testerów, może często ujawnić bardzo interesujące błędy.

Nie chodzi też tylko o testowanie funkcjonalne. Musimy dbać i martwić się o testy wydajności, testy bezpieczeństwa, testy użyteczności itp., Które są wymagane, jeśli chcemy wypuścić oprogramowanie wysokiej jakości.

Dlaczego nadal potrzebujemy kontroli jakości?

Testerzy są czasami postrzegani jako wąskie gardło w całym rurociągu dostaw. Czy nie byłoby lepiej, gdyby wszystko było zautomatyzowane, bez ręcznej interwencji i bez testerów zgłaszających błędy, aby zatrzymać wydanie?

Częścią problemu, gdy testerzy są postrzegani jako wąskie gardła, jest brak poczucia jakości wśród programistów. Jeśli wszyscy naprawdę czuli, że są odpowiedzialni za jakość produktu (nie tylko kodu), to programiści i testerzy dążą do tego samego celu.

Testerzy mogą łączyć się z programistami w celu pisania lepszych testów jednostkowych, a programiści mogą pomóc testerom w pisaniu automatycznych testów, a także kształcić testerów w zakresie architektury aplikacji, aby mogli projektować dobre testy, aby znaleźć obszary, które mogą się zepsuć podczas testowania systemu.

W idealnym świecie, testerzy nie powinni znajdować żadnych usterek, lub przynajmniej błahe wady. Kiedy istnieje „zespół QA”, którego zadaniem jest znajdowanie usterek, programiści kuszą, aby polegać tylko na testerach, aby znaleźć wszystkie usterki, podczas gdy programiści koncentrują się na programowaniu i kodowaniu.

Chociaż posunięcie Yahoo w kierunku wyeliminowania działu kontroli jakości i testów zachęca programistów do przejęcia odpowiedzialności za jakość produktu, nadal nie jest on wystarczająco dobry, aby zapewnić solidny produkt. To powiedziawszy, nawet z zespołem testerów nadal nie możesz zagwarantować oprogramowania wolnego od błędów, ale ważne jest, aby upewnić się, że oprogramowanie jest postrzegane z różnych punktów widzenia i z różnych perspektyw. przychodzi dobra funkcja QA (w przeciwieństwie do zespołu QA).

Testerzy mogą zapewnić, że programiści przestrzegają najlepszych praktyk zapewniania jakości i pomagają przy projektach testów technicznych i biznesowych, aby pomóc zidentyfikować najbardziej krytyczne błędy przed wydaniem oprogramowania.