Prezentacja AADays 2016: Dorota Sternalska "Gildia testowa, czyli sposób na koordynację testów" online

 

W wielu dużych projektach nad jednym produktem pracuje więcej niż jeden zespół scrumowy. Coraz bardziej popularny staje się tzw skalowalny agile, np SAFe, NEXUS. Takie rozwiązania jednak niosą ze sobą dodatkowe problemy. Komunikacja szwankuje czasami w obrębie jednego zespołu scrumowego, a co dopiero pomiędzy kilkoma zespołami. Pojawiają się problemy z interakcjami pomiędzy funkcjonalnościami, zależnościami w testach automatycznych. Jak zapewnić jakość produktu i być pewnym, że produkt jest zgodny z wymaganiami i oczekiwaniami klienta? Jak koordynować testy w tak rozproszonym środowisku? Czy w każdym zespole scrumowym potrzebny jest tester? A może wystarczającym rozwiązaniem jest zespół w którym testują jedynie deweloperzy? Albo popularny model gdzie testerzy tworzą jednak osobny zespół scrumowy? Jak stworzyć spójną strategię testową? W swojej prezentacji pokażę jak rozwiązaliśmy to w naszym zespole, gdzie nad jednym produktem pracuje 9 zespołów scrumowych. Opowiem dlaczego taki, a nie inny model testowania został przyjęty, jaką rolę w zespole pełni osoba z perspektywą testową i dlaczego nie jest nazywana przez nas testerem. Postaram się również przybliżyć czym jest i za co odpowiada stworzona przez nas gildia testowa.

Slajdy prezentacji

 

O autorce: W Motoroli pracuje od roku 2010. Z początku zajmowała się testowaniem radiotelefonów w standardzie Tetra. Była również jedną z osób odpowiedzialnych za testy u klienta. Dziś Dorota jest Scrum Masterem oraz osobą odpowiedzialną za testy w swoim zespole scrumowym. Pełni także rolę herszta Gildii Testowej, która koordynuje testowanie pomiędzy ośmioma zespołami scrumowymi. Nie boi się zmian i lubi wyzwania. Zajmuje się również kształceniem w harcerstwie, w którym przez dziesięć lat prowadziła drużynę harcerską. Prywatnie uwielbia podróżować i chodzić po górach.

 

Aplikacje mobilne Agile & Automation Days

 

Zapraszamy do pobrania aplikacji mobilnych Agile & Automation Days.
Znajdziecie w nich najważniejsze informacje o konferencji, w tym:

- agenda wraz z listą ulubionych wystąpień,
- opisy mówców i prezentacji,
- opis konferencji oraz zawodów,
- partnerów,
- miejsce,
- dojazd.

 

ap-apple
ap-windows
ap-play
 
 

TestingCup 2017 - zapowiedź

Już 21.11.2016 podczas Agile & Automation Days dowiemy się więcej szczegółów odnośnie TestingCup 2017.

Robert V. Binder zdobywcą nagrody ISTQB 2016

Doroczna nagroda International Software Testing Excellence Award przyznawana jest za wkład w rozwój testowania oprogramowania. Za rok 2016 otrzymał ją Robert V. Binder

 

Kim jest laureat?

[EN] Mr. Binder is a high-assurance thought leader, serial entrepreneur, and system architect. He recently joined Carnegie Mellon University’s Software Engineering Institute. He is a sought-after speaker and author of the definitive Testing Object-oriented Systems, two other books, and many articles. He is a model-based testing specialist who developed the multi-dimensional testing methodology. He co-chaired the X9 D14 working group adapting the ISO 9001 Quality Management standard to automated trading systems. As a member of IEEE working group P1633, Recommended Practice for Software Reliability Engineering, he drafted sections on software process and risk management. Mr. Binder received the MS in Electrical Engineering and Computer Science from the University of Illinois at Chicago and the BA and MBA from the University of Chicago. He is an IEEE Senior Member, ACM.

 

Komunikat >>

 

Więcej o laureacie

Prezentacja Roberta Bindera.

 

 

Portfolio: http://robertvbinder.com/home/about/resume/

Autor książki "Testowanie systemów obiektowych": http://www.empik.com/testowanie-systemow-obiektowych-binder-robert-v,291147,ksiazka-p

 

Komentarz

Przyznawanie wyróżnienia osobom nierozpoznawalnym w środowisku testerskim obniża rangę samej nagrody. Nie negujemy osiągnięć Pana Bindera choć o jego istnieniu przypomnieliśmy sobie dopiero kiedy stał się laureatem nagrody. Można wskazać dziesiątki osób dużo bardziej zaangażowanych w rozwój testowania i takich, którym nagroda należała się bardziej.

 

 

Planowanie jakości

Obecny rynek, nie tylko usług IT, przykłada dużą wagę do jakości. O jakości mówi się głośno, akcentując jej znaczenie w osiągnięciu satysfakcji klienta oraz sukcesu produktu. Oceniając produkty, stwierdzamy „to jest (nie jest) dobrej jakości”, „oczekuję wyższej jakości” itp. Intuicyjnie rozumiemy znaczenie pojęcia „jakość”, choć nierzadko mamy problemy z podaniem definicji tego terminu. Zanim przejdziemy do planowania jakości w projekcie, warto zdefiniować samo pojęcie jakości.

Istnieje wiele definicji jakości, wśród których najbardziej popularne są następujące:

  • „Jakość to stopień, w jakim zbiór inherentnych właściwości spełnia wymagania.” wg ISO 9000:2001.
  • „Jakość jest to pewien stopień doskonałości.” Platon.
  • „Jakość to zgodność z wymaganiami.” Crosby.

Definicje Platona oraz Crosby’ego wydają się prostsze, w definicji ISO wątpliwości może budzić użycie słowa „inherentny”. „Słownik wyrazów obcych i zwrotów obcojęzycznych“ Kopalińskiego  definiuje to słowo jako „tkwiący w czymś w istocie, strukturze, zasadniczym charakterze czegoś, w naturze, w ustalonych obyczajach; nieodłączny od”. Inherencja oznacza cechę nierozerwalnie związaną z danym pojęciem; cechę, która przesądza o istocie i naturze produktu, bez której produkt nie byłby tym, czym jest.

 

Więcej na stronie IT.PWN.pl >>

Testowanie CRUD

CRUD to czarnoskrzynkowa technika projektowania testów związana z przetwarzaniem danych. Polega na tworzeniu przypadków testowych na podstawie śledzenia cyklu życia danych w systemie. W artykule opisana została podstawowa wersja metody, a także jej rozszerzenia, ponieważ w rzeczywistych projektach najprostsze podejście CRUD może okazać się niewystarczające. Zapraszamy do lektury rozdziału z książki „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia”, która trafi do Państwa rąk już w maju.

Opis metody

Akronim CRUD pochodzi od czterech angielskich słów: create, read, update oraz delete, czyli: stwórz, czytaj, uaktualnij, skasuj. Technika testowania CRUD dotyczy danych. Jest szczególnie pomocna w systemach bazodanowych oraz w aplikacjach, których istotną funkcjonalnością jest przetwarzanie danych. Operacje CRUD spotkać można prawie we wszystkich systemach. Na portalu społecznościowym możemy stworzyć swoje konto, dodać inną osobę do znajomych, usunąć ją z kontaktów, odczytać listę znajomych, zmodyfikować swoje dane itp. W każdej bazie danych podstawowe operacje to CREATE/INSERT, SELECT, UPDATE, DELETE.

Metoda CRUD polega na śledzeniu cyklu życia jakiejś danej, od momentu jej stworzenia do usunięcia. Jest to w pewnym sensie czarnoskrzynkowy odpowiednik białoskrzynkowej metody testowania przepływu danych. W metodologii TMap [117] technika ta nazywa się testowaniem cyklu danych (ang. data cycle test).

Systematyczne podejście CRUD wymaga stworzenia tzw. macierzy CRUD (ang. CRUD matrix), a następnie wyprowadzenia na jej podstawie przypadków testowych. Macierz CRUD może być elementem projektu systemu (i wtedy nie musimy jej sami tworzyć) lub może być wyprowadzona na podstawie specyfikacji funkcjonalnej. Określa ona, w których miejscach systemu jakie operacje na danych są możliwe do wykonania. W wierszach macierzy występują dane (np. poszczególne zmienne, obiekty itd.), natomiast cztery kolumny odpowiadają czterem podstawowym operacjom: C, R, U i D. W poszczególnych polach macierzy umieszcza się elementy systemu (np. ekrany), w których można wykonać określoną operację na określonej danej. Przykład macierzy CRUD jest pokazany na rys.

macierzC

Rysunek 1. Macierz CRUD

Zmienna id może być stworzona w miejscu E1. Miejscem może być np. ekran tworzenia nowego użytkownika. Zmienna id może być odczytana w dwóch miejscach: E2 oraz E3 i skasowana w E1. Zmiennej id nie da się aktualizować (bo np. jest unikalnym, niemodyfikowalnym kluczem). Zarówno imię, jak i nazwisko mogą być stworzone w E2 oraz odczytane i aktualizowane w E4. Zmienna wiek może być stworzona w E3 i aktualizowana w E4. Zmiennych nazwisko, imię i wiek nie można skasować (bo np. podlegają archiwizacji). 

Mając stworzoną macierz CRUD, możemy przystąpić do tworzenia przypadków testowych. W najprostszej formie są one po prostu przekształconą macierzą CRUD, w której z każdym miejscem w systemie związany jest jeden przypadek testowy. Przypadki dla macierzy z rys.1. zostały pokazane w tabeli Tabela 8.1.

Tabela 8.1. Przypadki testowe wyprowadzone z macierzy CRUD

 

PT1

PT2

PT3

PT4

Warunek wstępny

E1

E2

E3

E4

Akcja 1

Stwórz id

Stwórz nazwisko

Stwórz wiek

Odczytaj nazwisko

Akcja 2

Usuń id

Stwórz imię

Odczytaj id

Odczytaj imię

Akcja 3

 

Odczytaj id

 

Aktualizuj nazwisko

Akcja 4

 

 

 

Aktualizuj imię

Akcja 5

 

 

 

Aktualizuj wiek

 

Przypadki testowe opisują czynności do wykonania w każdym z miejsc systemu. Na przykład PT3 polega na tym, że gdy znajdujemy się na ekranie E3, to najpierw tworzymy zmienną wiek, a następnie odczytujemy id

W tabeli nie opisaliśmy oczekiwanych wyników, gdyż w podejściu CRUD zwykle są one definiowane w naturalny sposób: jeśli akcja polega na stworzeniu obiektu, oczekiwanym wynikiem jest stworzenie tego obiektu itd.

Rozszerzenie metody

W poprzednim podrozdziale opisaliśmy bardzo prostą wersję metody CRUD. W rzeczywistych projektach takie podejście może nie wystarczać. Można rozważać następujące rozszerzenia CRUD:

  • uwzględnienie kolejności wykonywania operacji;
  • uwzględnienie związków ilościowych pomiędzy operacjami a danymi;
  • rozważenie tzw. pytań reporterskich w stosunku do operacji (kto, co, gdzie, kiedy, dlaczego, jak, jak dużo?).

Pierwsze rozszerzenie uwzględnia kolejność wykonywania operacji w ramach danego przypadku testowego. Na przykład dla przypadku PT2 z tabeli Tabela 8.1 możemy najpierw stworzyć imię, potem odczytać id, a na końcu stworzyć nazwisko. Każdy przypadek można zatem rozbić na kilka „podprzypadków” testowych, zawierających ten sam zbiór operacji, ale w różnej kolejności. Takie podejście może jednak spowodować eksplozję liczby testów[1].

W drugim rozszerzeniu każda operacja może być wykonana na kilka sposobów, z uwzględnieniem relacji ilościowych pomiędzy operacjami a obiektami. Sposoby te są opisane w tabeli Tabela 8.2.

Tabela 8.2. Różne realizacje możliwych operacji CRUD

Operacja

Możliwe realizacje

Create

  • Stwórz jedną, nową instancję danej
  • Stwórz instancję danej będącą duplikatem innej danej
  • Stwórz więcej niż jeden element naraz (jeśli to możliwe)

Read

  • Odczytaj jeden element
  • Odczytaj więcej niż jeden element
  • Odczytaj element, który nie istnieje
  • Odczytaj elementy w określonej ilości lub formacie (np. posortowane, przefiltrowane, pasujące do określonego wzorca, wszystkie, zadaną liczbę rekordów itp.)

Update

  • Aktualizuj jeden element
  • Aktualizuj więcej niż jeden element
  • Aktualizuj elementy pasujące do danego wzorca
  • Aktualizuj nieistniejący element

Delete

  • Usuń jeden istniejący element
  • Usuń więcej niż jeden element
  • Usuń elementy pasujące do danego wzorca
  • Usuń nieistniejący element

W podejściu trzecim poza samym faktem wykorzystywania operacji testujemy również warunki, w jakich to się odbywa. W szczególności:

  • Kto. Jaki użytkownik może wykonać daną operację? Jakie musi mieć uprawnienia?
  • Co. Jaki typ operacji jest możliwy? Czy oprócz operacji poprawnych jest dopuszczane wymuszenie operacji niepoprawnej? Co ze znakami specjalnymi, pustymi wartościami pól, długimi łańcuchami znaków itd.?
  • Kiedy. Kiedy dana operacja może zostać wykonana? Jaki jest skutek operacji żądanych w czasie niedostępności systemu?
  • Dlaczego. Jaki jest cel wykonania danej operacji? Czy można wykonać operację w złej wierze (np. kwestie bezpieczeństwa)?
  • Jak. W jaki sposób są wykonywane operacje? Czy przez polecenia z klawiatury, plik wsadowy, wybór operacji z graficznego interfejsu użytkownika?

[1] Dla przypadku zawierającego  akcji liczba możliwych ustawień tych operacji wynosi