Na którym etapie Agile (SCRUM) powinniśmy zacząć tworzyć testy automatyzacji?

9

Trochę o mnie - jestem ręcznym testerem od prawie 2 lat w środowisku Agile, używając SCRUM (1-2 tygodniowe sprinty). Dlatego chcę wprowadzić testy automatyzacji w mojej pracy przy użyciu Selenium WebDriver (z Javą).

Moje pytanie dotyczy tego, kiedy powinienem ręcznie przetestować funkcjonalność i kiedy powinienem przekonwertować je na testy automatyzacji?

Czytałem i stosuję inne podejście, takie jak:

  1. Po rozpoczęciu nowego sprintu przekonwertuj historie użytkowników na zautomatyzowane skrypty z poprzedniego sprintu LUB;
  2. Konwertuj historie użytkowników w ramach tego samego sprintu.

Wszelkie porady będą mile widziane. Z góry dziękuję.

testing agile scrum selenium test-automation Sójka
źródło
4
Proszę nie umieszczać tego samego pytania na dwóch różnych stronach wymiany stosów. Usuń jeden z nich.
R Sahu
2
Krzyż pisał w sqa.stackexchange.com/questions/27017/... .
R Sahu

Odpowiedzi:

13

Automatyzacja testów (i wszystkie inne testy) powinna być częścią definicji „zrobione” . Ma to na celu wytworzenie potencjalnie nadającego się do wysyłki produktu. Czy możesz wysłać, jeśli nie został przetestowany?

Testowanie powinno również obejmować podejście zespołowe, więc automatyzacja testów nie jest obowiązkiem testerów. Zacznij myśleć o testowaniu tak szybko, jak to możliwe.

Automatyzacja testów jest tak ważna w Agile, ponieważ:

Zwinność organizacyjna jest ograniczona przez sprawność techniczną

Innymi słowy, jeśli jesteś powolny w wprowadzaniu zmian w swoim produkcie, to nie ma znaczenia, w jaki sposób tworzysz zespoły, organizację lub jakie ramy przyjmujesz, powolnie reagujesz na zmiany.

https://less.works/less/technical-excellence/index.html

Jeśli odłożysz testowanie do kolejnej iteracji, zawsze będziesz w tyle. Utrudniając zmianę kierunku produktu, ponieważ trudniej jest zrefaktoryzować i zabezpieczyć zewnętrzne zachowanie produktu. Zautomatyzowane ręczne testowanie jest kluczem do spowolnienia, zautomatyzuj to!

Wielu testerów powie ci, że nie powinieneś zaczynać testowania od końca do końca, dopóki interfejs produktu się nie ustabilizuje. Nie czekaj, zamiast tego dobrze wykorzystaj PageObjects i upewnij się, że twoje testy są możliwe do utrzymania i powierz ich odpowiedzialność za ich tworzenie i naprawę .

Niels van Reijmersdal
źródło
Nie zgadzam się co do pierwszego „powinien”. Definicja gotowego jest czymś, co zespół Scrumowy musi wypracować sam. Jeśli zespół uzna automatyczne testowanie za ważne, uwzględni je jako część swojej definicji. Jednak sam proces nie mówi, że muszą, a nawet że powinni. Jest to coś, co całkowicie zależy od zespołu i nie ma właściwej, złej lub preferowanej odpowiedzi.
aroth
@aroth Zgadzam się z tobą, ale prawie we wszystkich przypadkach budujesz większe oprogramowanie, które chcesz dodać do DoD. Dlatego uważam, że dobrze jest powiedzieć ludziom, że powinieneś, przynajmniej poważnie o tym pomyśleć. Jako tester uważam, że testowanie na końcu przez oddzielny zespół jest pierwszym krokiem do Wagile. Ale tak, są sytuacje lub przypadki, w których testowanie może nawet nie być potrzebne.
Niels van Reijmersdal
2

Kluczową rzeczą jest to, że nie oznaczysz historii jako ukończonej, chyba że napisałeś automatyczne testy dla tej historii.

Wydaje mi się, że 1 nie ma, kiedy piszesz testy dla zadania ukończonego w poprzednim sprincie. co jeśli testy się nie powiodą?

Ewan
źródło
Więc jeśli w jednym tygodniu nowego sprintu żadna historia użytkownika tego sprintu nie jest w stanie, który można przetestować pod kątem regresji, sugerujesz, że OP powinien iść do domu i nic nie robić? Nie brzmi to dla mnie zbyt wydajnie ;-)
Doc Brown
Tester powinien wykorzystać ten pierwszy tydzień, aby zakwestionować specyfikację „hmmmm jako użytkownik spodziewałbym się muzyki w tle na mojej stronie internetowej”. Znajdź błędy w niekompletnych historiach i ogólnie sprawiaj kłopoty. Deweloperzy mogą powiedzieć, że nie mogą zacząć, dopóki nie zostaną napisane plany testów
Ewan
@DocBrown: w pierwszym tygodniu nowego sprintu tester ma niesamowitą pracę do wykonania. Muszą zrozumieć, co budują programiści, współpracując z właścicielem produktu i deweloperami. Muszą współpracować z programistą, aby upewnić się, że kod można przetestować. Mogą rozpocząć pracę nad planem testów automatycznych. Mogą nawet zacząć pisać testy. Jeśli masz odpowiednią strukturę testową, w której testy są pisane z wysokim poziomem abstrakcji, możesz je napisać, zanim kod będzie gotowy.
Bryan Oakley
1

Idealnie byłoby napisać automatyczne testy w tym samym sprincie, w którym napisany jest kod. Kod nie powinien być uważany za „zrobiony”, dopóki nie zostaną napisane testy automatyczne, a do końca sprintu należy doprowadzić kod do stanu „gotowe”.

Powinieneś rozpocząć proces pierwszego dnia sprintu, współpracując z programistą, aby zrozumieć kod i pomóc mu zrozumieć twoje potrzeby jako testera. Na przykład, jeśli tworzysz strony internetowe, możesz pomóc im zrozumieć potrzebę dodawania unikalnych identyfikatorów dla każdego elementu strony, z którym musisz wchodzić w interakcje.

Pamiętaj, że w scrumie Twoim zadaniem nie jest pisanie testów. Twoim zadaniem jest współpraca z zespołem, aby osiągnąć cele sprintu. Oznacza to komunikację i współpracę, które powinny mieć miejsce bardzo wcześnie w sprincie. Możesz rozpocząć pracę nad projektami testów i planami testów na długo zanim kod będzie gotowy do przetestowania.

Bryan Oakley
źródło
0

Jeśli zamierzasz przeprowadzić test automatycznie, równie dobrze możesz utworzyć testy z góry. Pomoże Ci to określić, jakiego zachowania się spodziewasz, i zachęci Cię do myślenia jak klient, co ostatecznie sprawi, że twoje oprogramowanie będzie bardziej użyteczne. Będziesz korzystać z testu natychmiast po wdrożeniu funkcjonalności.

Martin Maat
źródło
1
To nie działa z narzędziami do testowania interfejsu użytkownika, takimi jak Selenium. Potrzebujesz działającego i stabilnego interfejsu użytkownika, aby móc tworzyć testy.
Doc Brown
@DocBrown: Nie sądzę, że to musi być prawda. Jeśli podasz mi specyfikację nowej strony internetowej, mogę rozpocząć (a może i zakończyć!) Pisanie automatycznych testów przed napisaniem strony. Musisz po prostu współpracować z programistą, aby oboje uzgodnić, jaka jest struktura strony, jakie są identyfikatory elementów i tak dalej.
Bryan Oakley
0

Możesz to zrobić, ale zazwyczaj chcesz ukierunkować testy regresji za pomocą testów automatyzacji. Oznaczałoby to, że wykonałbym manual, dopóki nie upewnisz się, że jest wystarczająco solidny, aby być testem regresji. Może to być w trakcie sprintu dla niektórych funkcji i może być w trakcie sprintu dla innych funkcji.

błazen
źródło
0

Jak stwierdzono w innej odpowiedzi , kiedy występuje testowanie, powinno być częścią definicji „zrobione” . Jednak nie zgadzam się z niektórymi z tych odpowiedzi, więc chciałem rozszerzyć się o doświadczenia, które spotkałem.

W naprawdę zwinnym środowisku każdy jest w stanie zrobić wszystko. Nie byłoby nikogo w 100% poświęconego testowaniu, rozwijałbyś także umiejętności pomagające w podstawowej pracy z interfejsem użytkownika, czy coś innego. Jednak rzadko żyjemy w idealnym świecie.

To, co poleciłbym, to podejście hybrydowe. Jeśli chodzi o twoją definicję ukończenia, powiedziałbym, że ręczne testowanie powinno być częścią sprintu, w którym jest zakodowana praca. Wiesz, że działa, a wszelkie błędy można natychmiast zgłosić, ewentualnie naprawić, przed zakończeniem sprintu, abyś mógł zaplanować następny jeden. Koncentrując się na testowaniu ręcznym, zapoznasz się z tym, co powinien zrobić kod. Na początku następnego sprintu, gdy możesz nie mieć tak wiele do zrobienia, możesz skonfigurować automatyczne testy, które mogą być uruchamiane w ramach procesu kompilacji, aby zapobiec błędom regresji.

krillgar
źródło
Nigdy nie widziałem sprintu, w którym nie było już wiele do zrobienia w obecnych celach sprinterskich pierwszego dnia. Pisanie testów automatycznych wymaga współpracy i planowania, które powinny rozpocząć się w pierwszej godzinie pierwszego dnia sprintu.
Bryan Oakley