Zautomatyzowane testowanie: objaśnienie jego wartości biznesowej

Aby rozpocząć nie sądzę, że jest to powtórka z innych pytań dotyczących testów jednostkowych . Potrzebuję pomocy w wyrażeniu jej wartości zespołowi programistów, analityków, menedżerów i testerów. Za pomocą automatycznych testów nie sądzę, że muszę wprowadzać rozróżnienie między testami jednostkowymi (np. JUnit), BDD (np. JBehave, Fitness) i interfejsem użytkownika (Selenium, Watir), ponieważ uważam, że wszystkie zapewniają podobną wartość (ale nie krępuj się napisz odpowiedź, która się nie zgadza :))

Oto lista, którą zidentyfikowałem, szukam odpowiedzi, które pomogą rozwinąć lub udoskonalić:

1. Oszczędność czasu / kosztów : pisanie automatycznych testów może zająć więcej czasu niż pisemne przypadki testowe. Biorąc jednak pod uwagę, że testy są przeprowadzane wiele razy, marginalna praca (tj. Koszt / czas) w celu wykonania testów automatycznych jest o kilka rzędów wielkości mniejsza. Zautomatyzowane testy są tanie w użyciu, co z czasem ułatwia zmianę systemu.
2. Dokumentacja : nie ma prawdziwszego sposobu, aby dowiedzieć się, jak działa system, niż jego testy. Każda inna dokumentacja jest zwykle nieaktualna od momentu jej napisania, ale testy (przynajmniej te, które przechodzą) pokazują, jak rzeczy faktycznie działają. Dotyczy to zarówno dokumentacji użytkownika końcowego, jak i dokumentacji API.
3. Jakość kodu : pisanie testów zmusza do:
   • rozważ klientów, ponieważ testy są klientem
   • niszczy zależności, w których testowanie kodu często oznacza zastanawianie się, jak sprawić, by kod nie wymagał dostępu do innego dużego systemu

Kilka moich myśli:

1. Bądź szczery, że pisanie automatycznych testów zajmie więcej czasu. Jeśli wykonujesz TDD na poziomie jednostki (który poleciłbym jako punkt wyjścia, jeśli zamierzasz zainwestować w automatyczne testy), możesz spodziewać się około 30% dodatkowego czasu potrzebnego na kodowanie funkcji. Kluczem tutaj jest wyjaśnienie, że te dodatkowe 30% (prawdopodobnie więcej niż 30% na początku, gdy Twój zespół uczy się, jak pisać dobre testy) to inwestycja stworzona, aby zaoszczędzić na czasie. Jak najmniej w przypadku TDD na poziomie jednostki, konstrukcja twojego systemu jest luźno sprzężona i bardzo spójna, co sprawia, że ​​twój system można dostosowywać do zmian w czasie. Nowe wymagania i nieoczekiwane błędy zawsze wymagają zmian w systemie,
2. Toczy się wiele debat na temat wartości poziomu akceptacji i testów poziomu interfejsu użytkownika, biorąc pod uwagę ilość czasu potrzebnego na napisanie tych testów, czas ich uruchomienia oraz wymaganą konserwację. Poleciłbym przeczytać o tym artykuł Jamesa Shore'a.
3. W świecie zautomatyzowanych testów istnieją dobre i złe sposoby na zrobienie tego. Jeśli przekazujesz kierownictwu zautomatyzowane testy, chciałbym przedstawić Ci, jak planujesz przeszkolić swój zespół w pisaniu dobrych testów. Sztuka testów jednostkowych autorstwa Roy Osherove, Efektywna praca ze starszym kodem Michaela Feathersa oraz Sztuka rozwoju zwinnego Jamesa Shore'a to świetne książki, które poruszają te tematy bezpośrednio lub pośrednio. Powinieneś również przyjrzeć się pewnego rodzaju szkoleniom trenerskim lub formalnym. To duża zmiana.
4. Jeśli chodzi o wartość biznesową, # 2 i # 3 z powyższych punktów faktycznie służą Twojemu pierwszemu punktowi, więc wybiłbym do domu punkt 1 i omówię, w jaki sposób punkty 2 i 3 służą temu większemu punktowi. Dokumentacja sprawia, że ​​Twój system jest bardziej zrozumiały, co przyspiesza pracę Twojego zespołu. Jakość kodu umożliwia dostosowanie systemu do zmian, co przyspiesza pracę zespołu. Dla ludzi biznesu chodzi o maksymalizację przepływu wartości od momentu wprowadzenia pomysłu do momentu dostarczenia pomysłu jako działającego oprogramowania.

Jedną z rzeczy o określonej wartości jest to, że automatyczne testy mogą być uruchamiane w sposób ciągły; na przykład co godzinę w trakcie przebudowy lub podobnego. Powoduje to, że wszelkie błędy lub regresje są szybko ujawniane w ciągu kilku godzin lub dni od programisty pracującego nad naruszającym kodem, co znacznie ułatwia przełączanie kontekstu. Drugą korzyścią ciągłego testowania jest to, że zmusza do utrzymywania testów w stanie roboczym; nic nie jest bardziej nużące niż spędzanie pierwszego tygodnia cyklu testów na naprawianiu wszystkich nieaktualnych testów. Jeśli możesz je zautomatyzować, możesz je uruchomić w dowolnym momencie, a uruchamiając je regularnie, możesz szybko wykryć błędy w testach lub kodzie.

Koszt testu

Po napisaniu testu automatycznego można go uruchomić na komputerze za cenę kilku dżuli. Równoważny test ręczny wymaga, aby osoba na liście płac opracowała listę instrukcji.

Niezawodność testu

Można ufać komputerowi, że za każdym razem wiernie wykona tę samą procedurę testową. Człowiek ma skłonność do popełniania błędów i lenistwa.

Tryby błędów testowania komputera są również znacznie bardziej widoczne - rozbił się (raporty z testów przestały się pojawiać), miał trochę błędu, który spowodował fałszywy wynik testu (ponownie uruchom test deterministyczny, a wynik różni się). Jeśli człowiek ominie krok i sprawdzi „OK”, jak możemy to stwierdzić?

Trwałość testu

Test automatyczny musi być konkretnym artefaktem (np. Fragmentem kodu), aby mógł zostać uruchomiony, i jest oczywiście dołączony do innych artefaktów programistycznych - repozytorium źródłowego. Test ręczny może zostać opracowany przez testera na kartce papieru notatkowego i nigdy nie sformalizowany. Jest bardziej prawdopodobne, że firma będzie potrzebować procesów, aby mieć pewność, że tak się nie stanie.

Wartość testowa

Komputer można zaprogramować do wyświetlania wyników testu w spójnej, łatwej do analizy formie. Osoba albo wprowadza dane, aby wygenerować to samo, albo zapisuje notatki w dowolnej formie, które wymagają analizy od analityka, programisty lub menedżera.

Przeważnie (w zależności od pokrycia testowego) kod wolny od błędów, i powiedziałbym, że jednym z największych argumentów jest to, kiedy mówisz swojemu kierownikowi, że możesz napisać test na wykryty błąd, upewniając się, że zawsze będziesz wiedział w przyszłości, czy ten błąd wraca :)

Moim zdaniem testy jednostkowe / integracyjne są najważniejsze, a jeśli zastosujesz jakiś wzorzec interfejsu użytkownika, taki jak MVC, wystarczy dla większości projektów. Zwykle testuję wszystkie działania na moich kontrolerach / prezenterach i pozostawiam wiązanie danych w widokach.

Oczywiście zautomatyzowane testowanie nie zastępuje dobrej starej przygody typu „wskaż i kliknij” wokół Twojej aplikacji, próbując znaleźć najdziksze rzeczy, które użytkownik może zrobić.

Istnieje również punkt ciągłej integracji .

Jeszcze jedno - należy dążyć do tego, aby jakość kodu prowadziła do jakości produktu, wartości biznesowej i łatwości konserwacji - w przeciwnym razie nie ma sensu tego robić.

Myślę, że powinieneś prowadzić z magicznymi punktami „niższy koszt” i „więcej funkcji / czas jednostkowy” / mniejszy czas cyklu.

Zanim jednak to zrobię, radzę zastanowić się nad twoją sytuacją. Twoje pytanie skłoniło mnie do napisania posta na blogu na temat potencjalnych wad zautomatyzowanego testowania.

Ważnym czynnikiem jest łatwość refaktoryzacji. Mając dobry zasięg dzięki ładnemu i czytelnemu testowi jednostkowemu (!!!), możesz przebudować swój system bez obawy o pogorszenie istniejącej funkcjonalności.

Musisz sprzedać tę koncepcję - musisz unikać mówienia im, że poprawi kod. Jeśli zainwestują w kod, który natychmiast wystawi je na testowanie anty / auto. Jeśli są jakieś dobre, zrozumieją również GIGO, więc nie zrozumieją, dlaczego uważasz, że to nie ma zastosowania.

Pozostawiłbym też sprzedaż jako aspekt dokumentacji, rzeczy takie jak Fitnesse mogą to zrobić dobrze, ale dopóki się nie przekonają, wizualizacja może być trudna.

Sądzę, że obszary mogą mieć szczęście, sprzedając je

1. Testy jednostkowe mogą zastąpić wiele uprzęży programistycznych - w których tworzysz aplikację, aby dostać się do obszaru do debugowania / testowania bez przechodzenia przez wszystkie menu logowania / menu.

2. Testy umożliwiają konfigurowanie i łatwe powtarzanie problemów - bez poświęcania dużej ilości czasu na konfigurowanie danych testowych (szczególnie przy użyciu porządnego systemu kpiącego)

3. Gdy budujesz zestawy testów BDD i interfejsu użytkownika - reakcja jest znacznie szybsza, jeśli występują proste przerwy, niż czekanie na następny tester

4. Testy BDD i interfejsu użytkownika pozwalają uniknąć wielokrotnego naciskania przycisków, aby sprawdzić wszystkie aspekty, na które zmiana mogła mieć wpływ, i uniknąć konieczności zapamiętywania wszystkich obszarów.

5. Automatyczne kompilacje często wyróżniają się, gdy ktoś zapomniał wpisać kod

6. Testy pomagają uniknąć ponownego pojawiania się błędów.

7. Testy jednostkowe i przyzwoite kpiny będą oznaczały mniej połączonego kodu i będą łatwiejsze do rozwiązania

Pamiętaj, że próbujesz go sprzedać, a nie przekształcić w religię - więc akceptuj małe kroki i staraj się, aby nie występować przeciwko tobie. Dostosowanie i nauczenie się pisania dobrych testów zajmie im również trochę czasu.

Ktoś musi uwierzyć, że istnieje problem, zanim zaakceptuje proponowane rozwiązanie tego problemu.

Zautomatyzowane testy mogą obniżyć koszty naprawy błędów, więc jeśli Twoi koledzy nie wierzą, że koszty naprawy błędów są znaczne lub nadmierne, trudno będzie je przekonać. Jeśli koszty te są wysokie lub nadmierne, ale ludzie nie wierzą, że tak jest, być może trzeba będzie uzyskać przekonujące dane na temat tych kosztów.

Firmy uwielbiają zwiększać wartość i obniżać koszty. Musisz wyjaśnić, w jaki sposób automatyczne testowanie zwiększy wartość, ponieważ powoduje dodatkowe koszty.

Jeśli Twój kod jest modułowy, będzie można go ponownie użyć. Co oznacza, że ​​testy nie muszą być pisane od nowa i możesz po prostu pracować nad tym istniejącym kodem.

Jeśli istnieją starsze projekty, automatyczne testowanie znacznie ułatwia refaktoryzację. W pewnym momencie dług techniczny musi zostać spłacony.

Podany argument dotyczący dokumentacji nie jest zbyt dobry. Różnica między aktualizowaniem testów a aktualizacją dokumentacji to tylko nawyk.

„Potrzebuję pomocy w wyrażeniu swojej wartości zespołowi programistów, analityków, menedżerów i testerów. Za pomocą automatycznych testów nie sądzę, że muszę wprowadzać rozróżnienie między testami jednostkowymi (np. JUnit), BDD ( np. JBehave, Fitness) i UI (Selenium, Watir), ponieważ myślę, że wszystkie zapewniają podobną wartość (ale zachęcamy do napisania odpowiedzi, która się nie zgadza :)) ”

OK, podejmę to wyzwanie;)

Pracuję głównie z programistami i QA, a moje narzędzia to rubin, szyny, testunit, rspec, jaśmin i selen.

Narzędzia BDD / TDD rspec i testunit są częścią programowania. Nie wyłamujesz ich i nie rozmawiasz o nich osobno z zarządem, nie odkładasz ich z powodu braku czasu, włączasz je do wszystkich swoich szacunków czasowych. Jeśli naprawdę popychany, zapytał, ile czasu ludzie mają na wyjaśnienie informatyki i programowania. Nie używam tych testów dla interfejsu

GUI / UI / Jasmine / Selenium. Te są różne. Mam to zrobione przez ludzi QA, którzy mają doświadczenie w programowaniu. Dbamy o to, aby testy były napisane tak, aby były jak najbardziej niezawodne i oparte na treści, a nie na układzie. (Być może nowy) koszt tego należy wyjaśnić jako koszt przesunięty . Zamiast płacić za zepsute oprogramowanie, utraconych klientów i drogie poprawki później, płacisz teraz dużo (relatywnie) za pomocą kilku prostych praktyk.

Myślę, że kluczem jest rozmowa o określonych kategoriach testów, które stworzysz, a nie „testowanie automatyczne” jako całość. To ostatnie może być nieco mgliste i niepokojące, i zbyt łatwo jest wymyślić przykłady, w których byłoby to stratą czasu.

Zawsze zalecam podzielenie testów na 4 grupy (więcej szczegółów tutaj ). Trzymaj się mnie tutaj, za chwilę przejdę do tego, jak to pomaga sprzedawać testy innym.

1. Testy podstawowej funkcjonalności . Tj. W przypadku narzędzia do monitorowania witryn byłyby to testy alertów, które powinny zostać uruchomione dla monitorowanych witryn. Te testy upewniają się, że te rzeczy nigdy się nie psują.
2. Testy dymu całej aplikacji . Na przykład, używając Selenium do nawigacji po wszystkich linkach / przyciskach w aplikacji internetowej i upewnij się, że nie ma błędów z serwera. Te testy pozwalają uniknąć marnowania czasu testerów na ewidentnie zepsute kompilacje.
3. Testy dowolnego delikatnego kodu . Tj. Dla tego starego modułu, którego nikt nigdy nie chce dotknąć, ani złożonego fragmentu kodu, który wydaje się zawsze zawierać w sobie błędy.
4. Testy, które twórcy chcieli napisać, aby wesprzeć swoją pracę . Ponieważ czasami testy są przydatne, gdy coś piszesz, ale nie mieszczą się w powyższych kategoriach.

Dzieląc swoje testy na te kategorie, możesz teraz przeprowadzić inną dyskusję. Weź trzy pierwsze grupy (czwarta i tak zależy od indywidualnych decyzji) i zapytaj, czy ludzie uważają, że testy na te fragmenty kodu byłyby opłacalne? Jeśli nie możesz uzyskać zgody, być może nie uwzględnisz na razie tych testów. Jeśli możesz, tzn. Jeśli ludzie zgadzają się, że testy wokół podstawowych funkcji, które są wykonywane przy każdym zatwierdzeniu, są przydatne, zacznij je dodawać.

Inną grupą, która może się przydać, są testy, które są trudne lub czasochłonne do wykonania ręcznie . Korzyści powinny być dość łatwe do wyjaśnienia, jeśli chodzi o oszczędność ręcznego testowania lub testowanie rzeczy, które pomijane są z powodu braku czasu.