Zautomatyzowane testowanie: objaśnienie jego wartości biznesowej

25

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
orangepips
źródło

Odpowiedzi:

21

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.
Brian Geihsler
źródło
1
+1 dobra odpowiedź. Ciekawy link do artykułu Jamesa Shore'a. Dodałbym The Clean Coder autorstwa Roberta Martina do twojej listy książek. Myślę, że programista stworzył testy interfejsu użytkownika, które powinny obejmować szczęśliwe ścieżki, podczas gdy QA (jeśli istnieje) zapisuje wyjątki. Testy jednostkowe powinny naprawdę dotyczyć wyjątkowych przypadków.
orangepips 30.06.11
@orangepips - Dziękujemy za rekomendację książki. Wadą tego testu interfejsu użytkownika jest szczęśliwa ścieżka, a następnie testy jednostkowe obejmujące wyjątki, ponieważ trudniej jest napisać te testy jednostkowe, jeśli nie wykonuje się testów jednostkowych na wszystko. Testy jednostkowe pomagają zwiększyć testowalność Twojej aplikacji, utrzymując niski poziom sprzężenia, podczas gdy testy interfejsu użytkownika nie wymagają, aby kod pod spodem był luźno sprzężony.
przeznaczone do pisania Testy jednostkowe powinny obejmować wszystko.
orangepips
1
@orangepips - Nie zgadzam się. „Poziom jakości” / Testy akceptacyjne powinny przetestować wszystko, co jest ważne dla użytkownika .. tj. Szczęśliwe ścieżki i alternatywne scenariusze. Testy jednostkowe często wykorzystują symulacje, kody pośredniczące i podróbki ... co oznacza, że ​​istnieje możliwość, że test jednostki szczęśliwej ścieżki powiedzie się, ale gdy wszystkie elementy zostaną połączone, test pełnej ścieżki może się nie powieść. To zbyt duża szansa, aby pozostawić ją losowi.
Gishu,
2
@orangepips - Mój sprzeciw dotyczył QA / Dev Exceptions / Happy divide. Istnieją testy jednostkowe, aby upewnić się, że budujesz je poprawnie. Istnieją testy jakości / akceptacji, aby upewnić się, że budujesz odpowiedni system. Dlatego wszystkie scenariusze istotne dla firmy (np. Ważność karty kredytowej wygasły) powinny zostać przetestowane przez kontrolę jakości przed oznaczeniem jej jako gotowej do wysyłki. Polecam automatyzację testów akceptacyjnych - Zautomatyzuj nudne, rutynowe czynności w 80% +. Do tego dochodzą pomysłowe ręczne testy bez skryptów.
Gishu
9

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.

TafT
źródło
7

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.

Phil Miller
źródło
+1 za pojęcie raportowania i odniesienie do dżuli.
orangepips
„Można ufać komputerowi, że za każdym razem wiernie wykonuje tę samą procedurę testową” Warto pamiętać, że ludzie robią rzeczy w nieoczekiwany sposób. Dość często inny tester wykonuje ten sam zestaw instrukcji w inny sposób. Jest to dobra rzecz, ponieważ zwiększa zasięg testów, więc chociaż automatyzacja testów oszczędza czas i jest świetnym sposobem na sprawdzenie oczekiwanych awarii i regresji, nie może całkowicie zastąpić testów na ludziach.
W takim przypadku wydaje się, że wskazane jest, aby dać ludzkim testerom ogólne listy obszarów do zbadania i rzeczy do wypróbowania, a nie szczegółowe instrukcje, które powinny wiernie powtórzyć.
Phil Miller
4
@TafT: tylko biedni lub nierozsądni nie poddają się testom ręcznym, ale testy ręczne o najwyższej wartości uważam za eksploracyjne, a nie pisane w naturze. Zatem nacisk na automatyzację tego, co może być.
orangepips
5

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ć.

Denis Biondic
źródło
+1 za ciągłą integrację z technicznego punktu widzenia. Nie jestem jednak pewien, jak widzę twoje sugestie ułatwiające rozmowę z personelem nietechnicznym (np. Analitykami). Co myślisz o sprawdzaniu poprawności w wielu przeglądarkach i systemach operacyjnych?
orangepips 30.06.11
Cóż, mogę powiedzieć mojej stronie z punktu widzenia dewelopera o analitykach - nie do końca rozumiem ich role w naprawdę dużych projektach - więc nie ma tam prawdziwej porady. O testach w różnych systemach operacyjnych dla różnych przeglądarek również nie miałem okazji ich wykonać.
Denis Biondic,
2

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.

Gishu
źródło
+1 za dobry post na blogu, aczkolwiek te punkty są tutaj czymś, co należałoby dobrze podnieść. Uderza mnie to, że głównym problemem jest brak programistów, którzy po prostu wykonują ruchy. W związku z tym, w jaki sposób sugerujesz promowanie jakości lub unikanie atmosfery, która temu przeszkadza?
orangepips,
dobry link. Dojrzewanie dowolnego procesu oprogramowania zajmuje dużo pracy. Myślę, że ważną konsekwencją jest również zmniejszenie obrotów, więc masz wystarczająco dużo ludzi z pamięcią organizacji i zaufaniem, aby posunąć się naprzód.
orangepips
1

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.

Morten
źródło
czy to różni się od mojego punktu 1?
orangepips 30.06.11
@orangepips: Nie, tęskniłem za tą częścią. Przepraszam: o) Należy jednak podkreślić
Morten
1

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.


źródło
+1 za komentarz do religii. Myślę, że jest kwestia ustalenia, na co warto pisać automatyczne testy, i oczywiście odpowiedź to nie wszystko. OTO, myślę, że lepiej jest mieć przynajmniej kilka automatycznych testów. Być może prawdziwym kluczem jest uznanie, że przynajmniej w mojej organizacji wąskim gardłem SDLC jest kontrola jakości. Więc mój własny wysiłek jest ukierunkowany na wygładzenie tej krzywej wysiłku poprzez przyjęcie przez część odpowiedzialności tego rozwoju.
orangepips
W odniesieniu do liczby 3) pozwala to na tworzenie statystyk i tworzenie raportów; widocznie może być dużą zaletą. W tym tygodniu wprowadzenie funkcji X spowodowało, że 10 testów zakończyło się niepowodzeniem, które wykryliśmy w czasie Y, dzięki automatycznym testom to dobra „wygrana” dla projektu, a także pomaga udokumentować ryzyko związane z wprowadzaniem nowych funkcji w przyszłości.
1

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.


źródło
1
więc skąd, według Pana, powinny pochodzić informacje?
orangepips
0

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.

Rudolf Olah
źródło
Z mojego doświadczenia wynika, że ​​ponowne użycie kodu to nowa jakość oprogramowania, które nie zostało zaplanowane. Innymi słowy, dopiero po przepisaniu tej samej rzeczy po raz trzeci, czwarty lub piąty naprawdę zrozumiałem, jak sprawić, by można ją było ponownie wykorzystać. Myślę więc, że menedżerowie często czują się przypaleni przez programiści: „daj mi więcej czasu na właściwe zbudowanie tego, co doprowadzi do oszczędności kosztów”, ponieważ w praktyce uważam to za ogólnie fałszywe podejście.
orangepips
0

„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.

Michael Durrant
źródło
0

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.

Rudzik
źródło