Praktyka rekrutacji testerów w metodykach klasycznych i zwinnych



Pobieranie 41.86 Kb.
Data10.05.2016
Rozmiar41.86 Kb.
Praktyka rekrutacji testerów w metodykach klasycznych i zwinnych

Michał Kujałowicz

Lufthansa Systems Poland sp. z o.o.

(michal.kujalowicz@lhsystems.com)

Abstract. Rekrutacja to bardzo istotny element tworzenia jakiegokolwiek zespołu. Bardzo często od dobrej rekrutacji zależy powodzenie całego przedsięwzięcia. Rekrutacja testerów jest na tyle szczególna, iż jej podstawowym zadaniem jest weryfikacja predyspozycji i umiejętności miękkich kandydatów, przez co staje się bardzo trudna. Niniejszy artykuł stara się odpowiedzieć na pytanie kogo powinno się rekrutować na stanowiska testerskie i jak taką rekrutację można przeprowadzać. Obejmuje tak kluczowe elementy rekrutacji jak: charakterystyka poszukiwanych osób, strategia rekrutacji, model rekrutacji i dobór osób rekrutujących. Przedstawia również kilka przykładów zadań weryfikujących pozwalających na lepsze poznanie predyspozycji kandydatów.

1Wprowadzenie


Rekrutacja to bardzo istotny element tworzenia zespołu testowego lub projektowego. Bardzo często od dobrej rekrutacji zależy powodzenie całego przedsięwzięcia. Zastanawiające jest, iż wiele firm posługuje się takim samym procesem rekrutacji niezależnie na jakie stanowisko kandydaci są poszukiwani. Często firmy mające doświadczenia w rekrutacji programistów starają się w taki sam sposób rekrutować testerów. Niniejszy artykuł stara się odpowiedzieć na pytanie kogo powinno się rekrutować na stanowiska testerskie i jak taką rekrutację można przeprowadzać. Obejmuje tak kluczowe elementy rekrutacji jak: charakterystyka poszukiwanych osób, strategia rekrutacji, model rekrutacji, dobór osób rekrutujących i zadania weryfikujące. Opis wszystkich powyższych elementów skupiony jest na wyjaśnieniu jak powinny się one różnić w przypadku poszukiwania testerów do metodyk klasycznych i zwinnych. Jest to bardzo ważny aspekt biorąc pod uwagę ilość doświadczeń dostępnych dla metodyk klasycznych przy jednocześnie coraz bardziej rozpowszechnionych metodykach zwinnych. Na początku jednak chciałbym podzielić się porównaniem, które oddaje moje podejście do umiejętności testerów potrzebnych w Agile. Według mnie testy w tych metodykach można przyrównać do dwóch stylów pływania: stylu klasycznego i stylu dowolnego.

Styl klasyczny to metodyki klasyczne. Większość osób nim pływa, bo jest łatwy do nauczenia, pozwala na pływanie bez wysiłku (i zanurzania głowy!) i mamy w nim największe doświadczenie. Styl dowolny to metodyki zwinne. Tu jest już trudniej. Wymaga większej siły, umiejętności i sprawności. Jest szybszy, ale tylko jeżeli jest dobrze wykonywany (spróbujmy wyprzedzić doświadczonego żabkarza płynąc stylem dowolnym nie zanurzając głowy). Podobnie jest z metodykami zwinnymi jeżeli chodzi o testowanie. O ile są one ułatwieniem i usprawnieniem pracy dla programistów to przed testerami stawiają o wiele większe wymagania. Testerzy w Agile muszą być bardziej umiejętni, doświadczeni i świadomi. Musimy posiadać naprawdę dobrych testerów. Co mam na myśli pisząc ‘dobrych’? Na to pytanie będziemy mogli odpowiedzieć jak poznamy wszystkie cechy, jakimi powinien odznaczać się tester oprogramowania.


2Kogo szukamy?


Warunkiem wstępnym przeprowadzenia skutecznej rekrutacji jest zastanowienie się kogo tak naprawdę poszukujemy. Idąc za Sylabusem ISTQB [1] „szukanie awarii w systemie wymaga ciekawości, profesjonalnego pesymizmu, krytycznego spojrzenia, przywiązywania wagi do szczegółów, dobrej komunikacji z programistami i doświadczenia, na którym można oprzeć zgadywanie błędów”. Jeżeli chcielibyśmy spojrzeć na te wymagania na wyższym poziomie to możnaby było je pogrupować wg amerykańskiego modelu KSAO (Knowlegde, Skills, Abilities and Others), czyli wg wiedzy, umiejętności, predyspozycji i innych. Ja, dla uproszczenia, stosuję grupowanie na dwie części: Predyspozycje i Umiejętności oraz Wiedza i Doświadczenie.

Predyspozycje i Umiejętności

Oto najważniejsze w moim rozumieniu predyspozycje i umiejętności, którymi powinien wyróżniać się tester oprogramowania:



  • Ciekawość i dociekliwość

  • Dbałość o szczegóły

  • Umiejętność analitycznego myślenia

  • Bardzo dobra komunikacja werbalna i pisemna

  • Asertywność i odwaga

  • Intuicja i krytyczne spojrzenie

  • Zaangażowanie i motywacja

O wiele szerszą listę przedstawia Cem Kaner [2]. Składa się ona z około 80 elementów, z których każdy powinien wybrać te najważniejsze i skupić się na nich w czasie rekrutacji.

Co jest kluczowe dla predyspozycji i umiejętności to fakt, iż są to elementy najtrudniej weryfikowalne w czasie rekrutacji. Tym bardziej należy skupić się na ich doborze i sprawdzeniu u kandydatów.


Wiedza i doświadczenie

Weryfikując wiedzę i doświadczenie zawsze biorę pod uwagę 3 aspekty:



  • Wiedza i doświadczenie testowe

  • Wiedza i doświadczenie techniczne

  • Wiedza i doświadczenie domenowe

Zakres tych trzech elementów zawsze zależał będzie od rodzaju i poziomu testów, które będziemy wykonywać, środowiska i platformy aplikacji poddawanej testom jak i domeny tej aplikacji. Każdy powinien zdefiniować jakie elementy w każdej z tych trzech grup kandydat musi posiadać.
Poprzez wiedzę testową rozumieć można doświadczenie w przeglądach dokumentacji, doświadczenie w tworzeniu testów automatycznych, doświadczenie w testach niefunkcjonalnych itp. Poprzez wiedzę techniczną rozumieć można znajomość systemów operacyjnych, języków oprogramowani i znajomość narzędzi. Wiedza domenowa to znajomość domeny aplikacji, którą będziemy testować, znajomość różnych aplikacji z domeny jak również znajomość prawa i regulacji prawnych w danej domenie.

Kogo w Agile?

Zanim przejdziemy do uszczegółowienia charakterystyk testera do metodyk zwinnych wspomnieć należy o bardzo różnych implementacjach testów w Agile. Przykładowo:



  • Testy w Agile wykonywane są przez developerów

  • Testy w Agile wykonywane są przez niezależny zespół poza sprintami

  • Testy w Agile to w 100% zautomatyzowane unit testy i testy regresyjne

  • Testy w Agile to w większości testy eksploracyjne

Tak naprawdę nie ma jednej dobrej odpowiedzi jak powinny wyglądać testy w metodykach zwinnych. Jak mówi podstawowa zasada testów: Testowanie jest zależne od kontekstu. Nie możemy powiedzieć, że któraś z powyższych implementacji jest zła. Możemy powiedzieć, że nie nadawałaby się do aplikacji, którymi się zajmujemy.

Z powyższych względów porównując w dalszej części rekrutację do metodyk klasycznych i zwinnych będę starał się uwzględniać różne implementacje testów w Agile skupiając się jednak na porównaniu względem formy testów w Agile, którą preferuję:


- Każdy jest odpowiedzialny za testy, ale w zespole są dedykowani testerzy

- Testujemy w oparciu o przypadki testowe stworzone na bazie user stories

- Testy uzupełniane są testami eksploracyjnymi

- Testy regresyjne skupione na automatyzacji testów z poprzednich sprintów


Dla tak zdefiniowanych testów przejść możemy do określenia jaką charakterystykę powinien mieć tester w Agile.

Przede wszystkim powinien odznaczać się wszystkimi predyspozycjami i umiejętnościami, które zdefiniowałem wcześniej. Oznacza to, że to co jest potrzebne w metodykach klasycznych jest konieczne również w metodykach zwinnych. Podejście różnić może się jedynie naciskiem na odpowiednie predyspozycje. To co podkreśliłbym dla Agile to kluczowe znaczenie dobrej komunikacji – zarówno na poziomie biznesowym jak i technicznym. Dodatkowo przy bardzo bliskiej współpracy z developerami bardzo ważne są asertywność i klienckie spojrzenie. Tester musi wiedzieć jak jest jego rola i o jakie aspektu softwareu musi walczyć.

Aby spełnić powyższe wymaganie niewątpliwie potrzebne jest doświadczenie testowe. Według [3] nawet doświadczenie na poziomie ISTQB Advanced Level.

W przypadku Agile kluczowa staje się również wiedza domenowa. Nie ma już obszernych specyfikacji opisujących każdą funkcjonalność. Może stanowić to poważny problem w tak wyspecjalizowanych dziedzinach jak np. lotnictwo.

Jeżeli chodzi o wiedzę techniczną to jest to ściśle zależne od aplikacji, którymi tester ma się zajmować.

3Strategia rekrutacji


Opisane dość obszernie w poprzednim punkcie charakterystyki osoby, której poszukujemy są głównym lecz nie jedynym elementem strategii rekrutacji. Przed rozpoczęciem rekrutacji należy również odpowiedzieć sobie na pytania:
Które z predyspozycji, umiejętności są najważniejsze? Wobec których można podjąć ryzyko, gdy uzyskamy niejednoznaczne wyniki testów/zadań?

Co jest konieczne już teraz? Jakie umiejętności, jaka wiedza?

Co jest konieczne na później i czy możemy w tym obszarze wyszkolić?

Czy pozwalamy sobie na tzw. „Korzystanie z okazji”?


Ostatni przytoczony punkt został dość szeroko podjęty i opisany w [2]. „Korzystanie z okazji” oznacza pójście na ustępstwa bądź podjęcie jakiegoś szczególnego ryzyka przy zatrudnianiu osoby. Ustępstwem może być np. zatrudnienie osoby na 4/5 etatu, lub przychodzącej do pracy o godzinie 11. Szczególne ryzyko natomiast to np. zatrudnienie na stanowisko testera osoby, która chce w przyszłości pracować jako programista. Na tego typu pytania należy odpowiedzieć sobie przed rozpoczęciem rekrutacji.

Kolejnym bardzo ważnym elementem strategii rekrutacji jest dywersyfikacja. Tworząc zespół testerów nie należy się nastawiać na zatrudnienie identycznych osób mających predyspozycje. Podstawa powinna być ta sama, ale warto myśleć, aby posiadać w zespole osoby o różnych mocnych stronach. Przykładowo 1 osobę z wiedzą domenową, 1 osobę po z doświadczeniem w administrowaniu systemów, 1 z doświadczeniem w analizie biznesowej i 1 z umiejętnościami programistycznymi. Warto stworzyć sobie listę cech, które byłyby dodatkowymi atutami kandydatów i uwzględnić je w ogłoszeniach o pracę jak również w samej rekrutacji.


Strategia rekrutacji w Agile?

W przypadku metodyk zwinnych strategia przyjęta w rekrutacji powinna opierać się na implementacji testów, którą zamierzamy zastosować. Na tej podstawie możemy chcieć zatrudnić developerów z predyspozycjami testowymi albo testerów do automatyzowania przypadków testowych albo testerów wyłącznie do testów eksploracyjnych. Na podstawie przyjętego przeze mnie modelu (testy w oparciu o stworzone przypadki testowe, dodatkowo testy eksploracyjne) wynikiem strategii powinno być zatrudnianie osób z doświadczeniem w testowaniu (metodyki klasyczne lub zwinne), które posiadają bardzo dobre umiejętności komunikacyjne i jednocześnie mają doświadczenie ze zmiennymi specyfikacjami wymagań.


4Dobór osób rekrutujących


Po zdefiniowaniu pełnej strategii rekrutacji należy odpowiedzieć na pytanie: kto tą rekrutacje będzie przeprowadzał. Z mojego doświadczenia wynika, iż najczęściej stosowany jest dobór oparty na zróżnicowaniu pozycji w firmie. Oznacza to, iż w rekrutacji uczestniczy Kierownik Zespołu (lub Projektu), Doświadczony Tester, Specjalista HR i nierzadko również Dyrektor. Taki dobór wynika z faktu, iż każda z tych osób chce mieć wpływ na to kto będzie pracował w zespole, projekcie czy całej firmie. Podejście takie ma niewątpliwe zalety. Osoby o różnych pozycjach w firmie to osoby o różnych doświadczeniach, oczekiwaniach i spojrzeniach.
Moim zdaniem innym, niemniej ważnym, aspektem jest zróżnicowanie osobowości wśród osób rekrutujących. O ile zazwyczaj nie mamy wpływu na dobór tych osobowości wśród różnych ról o tyle możemy wpływać na nie angażując na najniższym poziomie większą liczbę testerów. Przy organizacji rekrutacji w pełni zgadzam się z pomysłem zawartym w [2], iż w procesie rekrutacyjnym powinien uczestniczyć każdy kto wyraża taką chęć. Oczywiście wszystko w miarę rozsądku. Jeżeli mam 10 osób chętnych to nie te wszystkie osoby będą rekrutowały, ale będą się sukcesywnie wymieniać. Dobierając testerów do procesu rekrutacji możemy oprzeć się na skomplikowanej analizie osobowości. Nie jest jednak to konieczne. Posiadając zespół dokładnie wiemy kto ma jakie spojrzenie i jakie mocne strony. Wystarczy wykorzystać tą wiedzę.

Co zyskujemy poprzez takie podejście? Przede wszystkim mamy mniejsze prawdopodobieństwo porażki. Dodatkowo, jeżeli grupa testerów zadecyduje o zatrudnieniu osoby to nawet podświadomie będzie od pierwszego dnia sprzyjała jej. Co więcej osoba która przyjdzie do pracy będzie już znała część zespołu.

Takie podejście oznacza zdecydowanie większy koszt procesu rekrutacyjnego. Jeżeli jednak zastanowimy się jakie koszty ponosimy przy zatrudnieniu na okres próbny osoby która nie sprawdzi się to jasno wyniknie iż przy malejącej liczbie tzw. ‘porażek rekrutacyjnych’ koszt ten bardzo szybko zwraca się.

5Model Rekrutacji


Wiedząc ile i jakie osoby będą uczestniczyły w rekrutowaniu można zastanowić się jaki model rekrutacji zastosujemy. Na bazie doświadczeń z różnych firm wyróżnić można kilka podstawowych modeli, które pozwoliłem sobie roboczo nazwać:

W modelu ‘Jeden na jednego’ rozmowy zawsze opierają się na rozmowie jednego rekrutującego z jednym kandydatem. Może on być realizowany wieloetapowo – to znaczy w sumie kilka osób rekrutujących rozmawia z kandydatem jedna po drugiej. Zaletą tego modelu jest możliwość wykrycia różnych zachowań kandydata. Przykładowo po rozmowie z kierownikiem zespołu w trakcie rozmowy z jednym z testerów kandydat może zachowywać się o wiele swobodniej. Model ten zdecydowanie wymaga zaufania pomiędzy poszczególnymi rekrutującymi. Jeżeli jeden z nich zdecydowanie nie zgadza się na zatrudnienie to reszta powinna przyjąć decyzję negatywną.
W modelu ‘Wszyscy na jednego’ kilka osób rekrutujących sprawdza jednocześnie jedną osobę rekrutowaną. Zaletą tego modelu jest możliwość przedyskutowania wszystkich odpowiedzi kandydata wspólnie przez wszystkich rekrutujących. Niestety model ten wywołuje w rekrutowanych większy stres i usztywnienie w czasie rozmowy.
Model ‘Wszyscy na wszystkich’ to grupa rekrutujących sprawdzająca grupę rekrutowanych w jednym czasie. Metoda ta znacznie skraca czas poświęcony na jedną osobę, przez co zwiększa ryzyko odrzucenia dobrych kandydatów. Z drugiej strony będąc w grupie kandydaci czują się bezpieczniej i częściej zachowują się swobodnie.
Model typu ‘Assessment Center’ opiera się na sprawdzeniu grupy rekrutowanych w szeregu zadań zbiorowych (np. opracowanie ewakuacji ZOO), w których uczestniczy również kilku rekrutujących. Jest to metoda rozbudowana wymagająca specjalistycznych umiejętności od rekrutowanych. Pozwala dobrze zweryfikować jak kandydaci pracują w grupie i jaką postawę przyjmują przy pracy w zespole. Model sugerowany przy rekrutacji na stanowiska managerskie.

Praktyczny model

Model wykorzystywany przeze mnie do celów rekrutacji opiera się na 3 etapach. Jest on oparty o doświadczenia z rekrutacji opisane w [2] i jest możliwy do zastosowania zarówno w metodykach klasycznych jak i w Agile.

W rekrutacji uczestniczy 3-4 Testerów i Kierownik testów. Model zakłada zarówno wywiad z kandydatem, wypełnianie testów jak i praktyczne zadania. W trakcie rekrutacji staramy się przede wszystkim zweryfikować predyspozycje i umiejętności miękkie a w dalszym kroku wiedzę i doświadczenie.

Rekrutacja składa się z 4 części:



  1. Wstępna kwalifikacja

  2. Etap I – wywiad i testy

  3. Etap II – sesja zadaniowa

  4. Spotkanie podsumowujące i decyzja

W czasie wstępnej kwalifikacji Kierownik Testów i jeden z Testerów weryfikuje CV i inne dostępne dokumenty. Są one sprawdzane zarówno pod kątem zawartości merytorycznej, ale również pod kątem formy i uporządkowania. Ważnym elementem tej części jest również wyszukanie dodatkowych informacji na temat kandydata. Nieocenionym źródłem jest tu Internet a sprawdzenie to pozwala na zweryfikowanie prawdziwości części informacji zawartych w CV. W przypadku dużej liczby kandydatów zorganizowana może być dodatkowa rozmowa telefoniczna.

Etap I opiera się na wywiadzie z kandydatem. Uczestniczy w nim Kierownik Testów i jeden z Testerów. W trakcie spotkania zadawane są pytania mające na celu zweryfikowanie informacji zawartych w CV. Jednym z ważnych elementów jest weryfikacja umiejętności posługiwania się językiem obcym. W trakcie etapu I kandydat wypełnia również testy na spostrzegawczość, umiejętności analityczne, umiejętności techniczne a także test z wiedzy o testach oprogramowania w przypadku, gdy takie jest wymagane.


Etap II to sesja zadaniowa skupiona na weryfikacji predyspozycji i umiejętności miękkich. Opiera się ona o 4-5 zadań praktycznych przeprowadzanych przez Testerów (każde przez innego). W zależności od liczby osób aplikujących może być przeprowadzana dla jednego lub grupy kandydatów. W przypadku grupy jest możliwość wykorzystania zadania typu Assessment Center. Po każdym z zadań Tester przekazuje opinię tylko Kierownikowi.
Spotkanie podsumowujące ma na celu zebranie spostrzeżeń wszystkich osób zaangażowanych (z kierownikiem włącznie). Istotna jest tu konieczność wypracowania decyzji, która byłaby decyzją wszystkich osób.

6Przykładowe zadania


Przedstawione zadania opierają się po części na propozycjach zawartych w [2] jak również na pomysłach moich kolegów po fachu jak i własnych .

Zadanie 1. Przedstawienie kandydatowi aplikacji, którą będzie się zajmował

Kandydat siada wraz z jednym z Testerów. W pierwszym kroku rekrutujący przedstawia aplikację, którą kandydat będzie się zajmował. Jednocześnie bardzo dokładnie obserwuje: czy kandydat zadaje pytania, jakie pytania to są, czy rozumie to, co jest mu przedstawiane, czy notuje. W drugim kroku rekrutujący prosi kandydata o wykonanie prostego zadania – np. wprowadzenie i przeliczenie pojedynczego lotu. W czasie zadania kandydat może pytać rekrutującego o poszczególne kroki.

Zadanie ma sprawdzić czy Kandydat jest dociekliwy, czy rozumie aplikację o tematyce lotniczej na podstawowym poziomie i czy potrafi się uczyć.

Zadanie 2. Poznanie aplikacji bez dokumentacji

Kandydat dostaje instrukcje jak uruchomić pewną aplikację. Dostaje czas na to, aby przeanalizować ją i dowiedzieć się jak ta aplikacja działa metodą prób i błędów. Aplikacją może być dowolną aplikacją freeware ściągniętą z Internetu bądź też jedną z prostszych aplikacji, którą się zajmujemy.

Zadanie ma sprawdzić czy kandydat jest dociekliwy, drążący, dbający o szczegóły i potrafi zrozumieć aplikację bez posiadania dokumentacji na jej temat. Zadanie bardzo istotne w przypadku metodyk zwinnych.

Zadanie 3. Wymyślenie przypadków testowych do specyfikacji/user stories.

Do zadania konieczne są 2 specyfikacje/ 2 zestawy user stories z domeny, którą się zajmujemy – dotyczące podobnej funkcjonalności a jednak nie identyczne.

W pierwszym kroku kandydat otrzymuje specyfikacje. Może zadawać pytania i jego zadaniem jest wymyślenie przypadków testowych dla tej specyfikacji.

W następnym kroku rekrutujący przedstawia jakie przypadki testowe możnaby jeszcze dla tej specyfikacji wymyślić. Następnie kandydat ma za zadanie wymyślić przypadki testowe dla drugiej specyfikacji.

Zadanie ma sprawdzić jak kandydat rozumie tematykę specyfikacji, czy uczy się na podstawie wskazówek od osoby rekrutującej i wyciąga wnioski na temat tego jak należy testować.

Zadanie 4. Dokumentacja dowolnego błędu w systemie operacyjnym, w którym pracujemy np. Unix.

Rekrutujący pokazuje kandydatowi pewien błąd, który występuje w systemie operacyjnym Unix. Następnie prosi o reprodukcję tego błędu i stworzenie raportu błędu na czystej kartce papieru.

Następnie rekrutujący pokazuje kandydatowi inny błąd w tym samym systemie operacyjnym i prosi o reprodukcję błędu i stworzenie raportu błędu, ale w formularzu wymuszającym pewną strukturę (PRECONDITIONS, ACTIONS, EXPECTED RESULTS, REAL RESULTS)

Zadanie ma sprawdzić czy kandydat radzi sobie w danym systemie operacyjnym, czy kandydat jest szczegółowy przy dokumentowaniu swojej pracy i czy potrafi ocenić co jest ważne z punktu widzenia programisty


Zadanie 5. Umiejętności komunikacyjne

Zadanie opiera się na odegraniu kilku sytuacji. Rekrutujący wprowadza Kandydata w pewną sytuację, a następnie prosi o odegranie pewnej roli. Zadanie ma sprawdzić umiejętności komunikacyjne kandydata, czy potrafi w jasny sposób przekazać informację, czy potrafi w umiejętny sposób mówić o błędach innych osób.


Przykładowe sytuacje:

Znalazłeś błąd. W jaki sposób przekażesz go programiście w bezpośredniej rozmowie.

Oto fragment opisu funkcjonalności oprogramowania. Opowiedz, w jaki sposób działa to oprogramowanie.

Oto opis pewnego problemu. W jaki sposób przekazałbyś ten problem w 2 zdaniach


7Podsumowanie


Rekrutacja testerów nie jest łatwym zagadnieniem. Nie wystarczy przygotować testów weryfikujących nasze umiejętności programowania. Musimy zmierzyć się ze znalezieniem osoby o konkretnych predyspozycjach i umiejętnościach miękkich – szczególnie w przypadku metodyk zwinnych. Jak wiemy weryfikacja właśnie takich umiejętności jest najtrudniejsza.

W artykule starałem się przedstawić informacje i doświadczenia, które nabyłem w trakcie wykorzystywania i usprawniania procesu rekrutacji w różnych firmach. Część z osób czytających ten artykuł może stwierdzić: ‘co w tym odkrywczego?’ lub ‘przecież właśnie to robie rekrutując u siebie’. Być może tak jest niemniej bardzo ważne jest, aby pomyśleć dobrze o wszystkich przedstawionych tu aspektach przed rozpoczęciem całego procesu i dobrać je tak aby możliwie zminimalizować prawdopodobieństwo porażki. Dla rekrutującego o wiele większym grzechem jest przyjąć osobę, która się nie nadaje niż nie przyjąć osoby, która sprawdziłaby się świetnie. Zachęcam wszystkich do przemyślenia tego zdania i Waszego procesu rekrutacji i do znalezienia optimum.




8Źródła


  1. Stowarzyszenie Jakości Systemów Informatycznych: Certyfikowany tester. Plan poziomu podstawowego. Wersja 1.0 (http://www.sjsi.org/webgears//files/sjsi/File/Sylabus.pdf)

  2. Cem Kaner: Recruiting software testers. (Tutorial session) Software Testing Analysis & Review Conference (STAR) West , San Jose, CA, May 2000.

  3. Eric van Veenendall: SCRUM & Testing: Back to the Future. Testing Experience Magazine, September 2009.

  4. Lisa Crispin, Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley Professional. December 30, 2008




©absta.pl 2016
wyślij wiadomość

    Strona główna