10 prostych sposobów, aby programiści znienawidzili cię

Jeśli pracujesz jako tester, możesz wiedzieć coś na temat relacji tester vs. programista. Musimy współpracować, aby projekt szedł naprzód. Oto dziesięć sposobów, aby zniszczyć tę kruchą równowagę.

  1. Zgłaszaj błędy opisane jak najbardziej ogólnie
    • Tytuł: „System nie działa”
    • Opis: „System po pewnym czasie przestaje działać na moim komputerze
    • Priorytet: krytyczny
  2. Programiści często czują się źle, kiedy w ich kodzie zostanie znaleziony błąd. Możesz wzmocnić ten efekt dokładnie wskazując, kto napisał dany fragment kodu.
  3. Krytykuj publiczne.
  4. Przetestuj nieaktualny build. Zgłoś krytyczny błąd. Pozwól programiście spędzić dzień na analizie problemu. Kiedy w końcu zorientuje się, że testowałeś na starej wersji, na pewno zapamięta twoje imię.
  5. Jeśli masz taką możliwość, wskaż sposób poprawienia błędu i wyznacz deadline.
  6. Nalegaj, aby każdy znaleziony przez ciebie błąd został poprawiony. Nawet jeśli czujesz, że nie warto tego poprawiać.
  7. Eskaluj do przełożonych w projekcie. Zaangażuj ich w długie, techniczne dyskusje prowadzone wyłącznie drogą mailową.
  8. Najlepsze zachowaj na koniec. Blokujący dostawę, krytyczny błąd zgłaszaj tuż przed końcem etapu testów. Liczy się efekt WOW i miny deweloperów.
  9. Zgłaszaj zduplikowane raporty błędów. Nie spędzaj swojego czasu na przeglądnięcie listy istniejących defektów.
  10. Przerywaj im regularnie, kiedy kodują. Powrót do rytmu pracy zajmuje średnio 20 minut. Ale to nie twoje minuty.

Cechy testera i programisty

Proces wytwarzania oprogramowania wymaga zaangażowania całej grupy projektowej.
Skupię się jednak na dwóch rolach: testera i programisty. Ten sam projekt – zupełnie różne punkty spojrzenia. Inaczej mówiąc: dwie grupy pomiędzy którymi problemy w komunikacji stanowią źródło zagrożeń dla jakości systemu.

W dobrze dobranym zespole projektowym testerzy i programiści uzupełniają się nawzajem, dostarczając umiejętności, wiedzę i spoglądając na tworzoną aplikację z różnej perspektywy. Typowym błędem jest postrzeganie testerów jako “młodszych programistów”, a co za tym idzie zachęcanie ich do rozwijania umiejętności i nastawienia typowego dla programistów.

W rzeczywistości dobry tester posiada cechy kontrastujące z tymi, których potrzebuje dobry programista. Rozumiejąc to, menedżer może połączyć owe cechy w jeden, dobrze funkcjonujący zespół.

Wielu programistów nie zdaje sobie sprawy jak trudnym zadaniem jest testowanie. Cierpliwość, elastyczność, umiejętność dostrzegania szczegółów i obraz całego mechanizmu działania systemu.
Wielu testerów jest sfrustrowanych, pracując z programistami, którzy uważają testowanie za oraz pracę “drugiej kategorii” lub coś co robić może każdy.

Testerzy potrzebują tego rodzaju wiedzy, który posiadają końcowi użytkownicy systemu. To pozwala im na używanie produktu w sposób w jaki robi to klient zamiast tak jak chciałby tego programista. Dobre pytanie – czy znajomość wewnętrznej architektury aplikacji pomaga czy przeszkadza w przeprowadzeniu testów? Moim zdaniem nie jest konieczna do wykonania testów.

Testerzy powinni przejawiać specyficzny rodzaj ignorancji czy co więcej -naiwności w odniesieniu do testowanego systemu. Programiści nie. Jest to jedną z przyczyn dla której programiści mogą uznać testera za osobę zadającą oczywiste czy wręcz głupie pytania :)
Dobrzy testerzy posiadają wiedzę zarówno na temat wymagań klienta jak i – do pewnego stopnia – działania systemu wewnątrz. Pozwala to spojrzeć na testowany system z innej niż programista strony.

Cechy dobrego testera:
– nie obawia się reakcji na złe wiadomości, które przynosi
– potrafi rozdzielić błąd od osoby, która go popełniła
– informację o znalezionym błędzie potrafi przedstawić w neutralny sposób

Komunikacja, tester i programista

Testerzy nie powinni unikać konfrontacji. Przynoszenie “złych” wiadomości to ich praca, jednak nie zawsze jest to dobrze przyjmowane. Czasami trudno jest określić przyczynę błędu. Czy jest to błąd w wymaganiach, kodzie czy w dokumentacji. Zdarza się, że błędu nie ma, jednak tester nie jest pewien jak interpretować działanie aplikacji.

Niezależnie od przyczyny – zadaniem testera jest zgłoszenie problemu. Niektórzy z nas mogą iść o krok dalej wskazując błąd ORAZ programistę aby skłonić go do lepszej pracy. To nie pomaga. Spekulowanie – kto, w jakim miejscu i kiedy, zrobił błąd, jest złe z dwóch powodów:
– szukanie winnych nie pozwala skupić się na pracy
– to źródło konfliktów w grupie

Bug priority vs. bug severity

Zgłaszając błąd aplikacji, oprócz jego opisu, wersji środowiska, zrzutu ekranu czy załączników, określamy również jego priorytet i wpływ na działanie aplikacji.

Defect severity – określa jak bardzo krytyczny dla aplikacji jest zgłaszany błąd.
Defect priority – oznacza jak pilne jest poprawienie błędu.

Opis na przykładzie:
1. High Severity and Low Priority : Testujemy aplikację bankową generującą raporty tygodniowy, miesięczny i roczny. W raporcie rocznym jest błąd, który powoduje generowanie niewłaściwych danych. Jest to błąd krytyczny (high severity) jednak może zostać poprawiony w następnej wersji aplikacji (low priority).

2. Low Severity and High Priority : Błąd ortograficzny na głównej stronie popularnego serwisu internetowego. Pomimo, że nie ma on wpływu na funkcjonowanie strony, może przyczynić się do obniżenia wizerunku witryny.

3. High Severity and High Priority : Ponownie aplikacja bankowa. Tym razem błąd występuje w raporcie tygodniowym. Oprócz zagrożenia dla poprawności generowanych wyników, decydujący jest czas od zgłoszenia do naprawy błędu.

4. Low Severity and Low Priority : Błąd ortograficzny występuje na podstronie o oglądalności kilku wejść na miesiąc.

Testy ad-hoc, eksploracyjne

Ten typ testów przeprowadzany jest bez tworzenia formalnego Test Planu czy pisania przypadków testowych. Testy typu ad-hoc pomagają planować zakres i czas trwania innych rodzajów testów, pomagają także testerom nauczyć się aplikacji przed rozpoczęciem zaplanowanych, innych rodzajów testów. Jest to najmniej formalna metoda testowania.

Testy ad-hoc (eksploracyjne) oznaczają jednoczesne poznawanie testowanej aplikacji, przygotowywanie dokumentacji testowej i wykonywanie testów. Oznacza to, że testerzy przystępują do pracy bez przygotowanych wcześniej przypadków użycia (test cases), ale za to z wyznaczonym celem. Testy oprogramowania tą metodą pozwalają na odkrycie nowych, zależności pomiędzy np. modułami systemu. To z kolei może wpłynąć na przyjętą strategię testowania i akcje podejmowane w kolejnych iteracjach testów.

Jednym z najlepszych powodów do stosowania tego rodzaju testów jest “odkrywanie”. Czytanie wymagań czy specyfikacji (jeśli istnieje) nie daje kompletnego obrazu działania systemu. Również dokumentacja użytkownika (pliki help, tutoriale) nie oddaje całkowicie tego w jaki sposób system działa i jak zachowuje się w określonych sytuacjach.

Testy metodą ad-hoc pozwalają na znalezienie “dziur” w strategii testowania i ujawnienie np. brakujących przypadków testowych (Test Cases).

Błędy znalezione przy testowaniu metodą ad-hoc są często sygnałem o istnieniu całych klas nieopracowanych przypadków testowych. To z kolei sugeruje dokonanie analizy przyczyn powstania błędu w testowanej części aplikacji.

Drugim zastosowaniem techniki ad-hoc jest określanie priorytetów dla poszczególnych przypadków testowych. Funkcjonalności, które działają poprawnie podczas testów ad-hoc, mogą otrzymać niższy priorytet lub zostać odłożone podczas fazy formalnych testów.

Jednym z problemów związanych z testami eksploracyjnymi są metryki, a właściwie ich brak. Zazwyczaj projekt jest zainteresowany informacją na temat postępu testów (procentowym pokryciem testami funkcjonalności, ilością wykonanych przypadków testowych, których przecież nie ma, itp.) wyrażoną choćby w postaci cyfr. Rozwiązaniem mogą być np. organizowane okresowo sesje na których zespół testowy wraz z osobami zainteresowanymi takimi informacjami, przedstawia i dyskutuje bieżącą sytuację. Taka forma pomiaru sprawdza się w projektach prowadzonych wg metodologii Agile.

Jak efektywnie zgłaszać błędy

Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem?
Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach.

Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.

W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.

Po znalezieniu defektu.
– Zapisz tę informację od razu jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.

– Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.

– Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.

– Nie wyolbrzymiaj znaczenia błędu w opisie.

– Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.

Testy regresywne

Celem przeprowadzania testów regresywnych jest upewnienie się, że aplikacja działa po dokonaniu w niej modyfikacji, poprawieniu błędów lub po dodaniu nowej funkcjonalności.

Cecha: powtarzalność

Co dają testy regresywne:

  • Wyszukanie błędów powstałych w wyniku zmian kodu/środowiska.
  • Ujawnienie wcześniej nie odkrytych błędów.
  • Jest to dobry kandydat do automatyzacji ze względu na swoją powtarzalność.

Iteracyjne metodologie oraz krótkie cykle w których dostarczane są kolejne funkcjonalności powodują, że testy regresywne pozwalają upewnić się czy nowe funkcjonalności nie wpłynęły negatywnie na istniejące już i działające części systemu.

Testy regresywne mogą być przeprowadzane dla kompletnego produktu lub jego części.  Jeżeli pomiędzy cyklami testów nie można przeprowadzić pełnych testów regresywnych aplikacji (koszty, czas), przypadki testowe, które włączamy do testu, powinny być dobierane na podstawie:

  • Jakie błędy zostały poprawione, jakie rozszerzenia czy zmiany zostały wprowadzone
  • Których obszarów aplikacji zmiany te dotyczą najbardziej
  • Jaki jest wpływ wprowadzonych zmian na inne części systemu

Testy regresywne powinny być przeprowadzane po smoke testach lub testach typu sanity. Ten typ testów pozwala upewnić się czy otrzymana nowa wersja aplikacji jest “testowalna” i czy warto zaczynać z nią pracę.

Kiedy należy przestać testować

Testować potencjalnie można bez końca. Nie możemy jednak kontynuować testów do momentu znalezienia ostatniego błędu w systemie. To oczywiście niemożliwe.

W pewnym momencie należy przerwać i dostarczyć system do klienta. Pytanie brzmi, kiedy uznać, że oprogramowanie jest wystarczająco dobrze sprawdzone.

Testowanie mieści się pomiędzy budżetem projektu, czasem na jego realizację i jakością dostarczanego rozwiązania. Project Triangle

Pesymistyczny scenariusz zakłada przerwanie testowania w momencie, kiedy jeden z trzech wymienionych zasobów ulegnie wyczerpaniu.

Przykłady:

  • zbliżająca się data wypuszczenia oprogramowania na rynek
  • wyczerpany budżet projektu
  • upłynięcie czasu przeznaczonego na testy Alfa, Beta
  • założony procent wykonanych przypadków testowych uzyskał status “passed”.
  • pokrycie kodu/funkcjonalności/wymagań, osiągnęło założony poziom
  • liczba wykrywanych błędów spadła poniżej zakładanego progu

W optymistycznej wersji zakończenie testów następuje gdy:
– oprogramowanie spełnia założone wymagania jakości
– korzyści z kontynuowania testów przestają rekompensować koszty ponoszone na testowanie

Przykłady:

  • częstotliwość występowania błędów jest na akceptowalnym (wystarczająco niskim) poziomie
  • pokrycie kodu,funkcjonalności,wymagań osiągnęło pożądany procent
  • liczba wykonań przypadków testowych, ukończonych sukcesem jest na pożądanym poziomie

Bumper Stickers for Software Testers

Zbiór sentencji i cytatów na temat roli i pracy testera.

  • Ask me about my latest bug.
  • Honk if you love to crash software.
  • My other car is a bug.
  • Have you hugged your software tester today?
  • Software Testers: Always looking for trouble.
  • Software Testing is Like Fishing, But You Get Paid.
  • Software Testers: “Depraved minds…Usefully employed.” ~Rex Black
  • Software Testing: Where failure is always an option.
  • Software Testing: When Your System Actually Has to Work
  • Software Quality: Don’t ship without it.
  • I don’t make software; I make software better.
  • Improving the world one bug at a time.
  • Software Testing: You make it, we break it.
  • Software Testers don’t break software; it’s broken when we get it.
  • Software Testers: We break it because we care.
  • To err is human; to find the errors requires a tester.
  • If developers are so smart, why do testers have such job security?
  • My software can beat up your software.
  • A good tester has the heart of a developer…in a jar on the desk.
  • Test is my copilot.
  • If your software works, thank a tester.
  • Old Model-Based Testers Never Die; They Just Transition to a Higher State.
  • Life is too short for manual testing.
  • Friends don’t let friends do capture-replay.
  • Support spec-based testing: Be code-dependent no more!
  • People should think and machines should test.
  • Test never sleeps.
  • Visualize Great Software
  • Trust, But Verify.
  • Pertempto ergo sum – I test, therefore I am.
  • Testers don’t like to break things; they like to dispel the illusion that things work. ~ Kaner, Bach, Pettichord
  • I came, I saw, I found lots of #$@% bugs in your %$#@ spaghetti code!
  • I test, therefore it works.
  • Testers don’t go to work to make friends.
  • Bad Code is Not Bad, Its Just Misunderstood.
  • Test everything. Hold on to that which is good.” – 1 Thessalonians 5:21
  • Brain on, eyes open…test.” ~ James Whittaker
  • There’s always one more bug.
  • Testing…a target-rich environment.
  • It did what? Well, it’s not supposed to do that.
  • My software never has bugs. It just develops random features.
  • The Definition of an Upgrade: Take old bugs out, put new ones in.
  • We break software so you don’t have to.
  • I used to build software…now I break it! Its a lot more fun!!
  • We travel fast and we travel light – let’s hunt some bugs!
  • Bugs, bugses, we finds them, Preciousss.
  • Software Testing: That Which Does Not Kill Us, Still Hurts A Lot
  • We don’t find bugs by chance , we create them by choice
  • Ashes to ashes, dust to dust, and more bugs to squash!
  • Our job is tell you your baby is ugly!
  • Your code is buggy and your mom dresses you funny.
  • Does your mother know what kind of code you write?
  • Just test it
  • To test, or not to test — there is no question
  • Be verwy verwy quiet, I am hunting defects
  • Passion-driven testing: Making every line of code feel dirty.
  • Software Testing is a second-childhood: You broke it, and I’m telling.
  • Code-Coverage Testing: Making every line of code feel dirty and used.
  • All code is guilty, until proven innocent.
  • Siamese Twins- Developers and Testers
  • If it ain’t broke, you’re not trying hard enough.
  • Only certainties in life: Death, taxes and bugs in code!
  • Bug-Checking Is Brutally Cool! – Doonesbury
  • Testing Delayed is Testing Denied
  • Bugs are that which, when you stop believing in them, don’t go away.
  • Those are the bugs, if you don’t like them…I have others
  • Development is what you’re capable of doing. PM determines what you do. Testing determines how well you do it.
  • Development and testing are indispensable to each other.
  • Only certainties in life: Death, taxes and bugs in code!
  • Faith is fine in private life, but poison in software testing.
  • Testing is organised skepticism.
  • Testers do it over and over.
  • Software Entomologist: Get bugs or die trying!
  • Project Managers want it to work. Developers try to make it work. Customers hope it works. Testers know how it works.
  • Software Testers – We succeed where others fail!
  • I’m a Software Tester. Bug me all you want!
  • Credit the Developer, Debit the Tester.
  • If it works, its the developer, if not it’s QA
  • Hate the Tester,Love the programmer
  • Down QAs, Up Developers
  • Breakage is our business… and business is good.
  • It’s Automation, Not Automagic!
  • It compiled on your system, but it committed suicide on mine!
  • Test it now or test it later, either way it’s gonna be tested.
  • Semper Pertemptum: Always Testing
  • Keep on Testin’
  • You build it, we break it!
  • Software Testing, not just a checkbox on your project plan.
  • Software Testing, we save the best for last.
  • Software Testing, we crash so you don’t burn
  • Quality Assurance, we take the blame so you don’t have to.
  • We don’t create defects, we just find yours.
  • My defect was a showstopper on build .645!
  • I saved our customers from the showstopper in build .645!
  • Software Testers Always go to Heaven … they’ve already had their share of Hell!
  • Old testers never die, they just regress.
  • SQA: We eat bugs for breakfast.
  • Software testers: we don’t get headaches – we’re just carriers.
  • Got quality?
  • QA Princess — Breaking hearts, breaking code!
  • Hard on software but soft on programmer.
  • Honk if you believe in bug free code, or the Easter bunny.
  • Have bug?, will find!
  • Development Is Like A Box of Chocolates, Testers Never Know What They Are Going To Get!!
  • A tester is for life, not just Christmas.
  • I brake for blue screens of death.
  • In bugs we trust.
  • Software Testing: The Bug Stops Here.
  • In God we trust, and for everything else we test.
  • If you can read this sticker it passed the usability test
  • Exploratory Tester: Spec’s are for wimps
  • The great tragedy of Testing: the slaying of a beautiful hypothesis by an ugly fact.
  • A bug in the hand is better than one as yet undetected.
  • And on the seventh day, He shipped.
  • Any sufficiently advanced bug is indistinguishable from a feature.
  • Software Testing … because computers are only human.
  • Seeking out complexity is the essence of bug finding.
  • Bugs are not an option: they’re bundled with the software!
  • Agile Testers of the world UNIT!
  • If you can read this sticker it passed the usability test
  • Exploratory Tester: Specs are for wimps
  • The great tragedy of Testing: the slaying of a beautiful hypothesis by an ugly fact.
  • When the testing gets tough, switch to test generation.
  • Quando omni flunkus testerati (When all else fails, try testing.)
  • Software testing – because computers are only human.
  • Every morning is the dawn of a new error.

Źródło: www.stickyminds.com/se/S8299.asp

Pięć problemów występujących w SDLC

Problem:

  1. niewystarczająco zdefiniowane wymagania – jeśli wymagania są niejasne, niekompletne, zbyt ogólne lub nietestowalne, na pewno pojawią się problemy
  2. nierealistyczny time plan projektu – zbyt wiele pracy zaplanowanej w zbyt krótkich przedziałach czasu
  3. niewystarczająca ilość testów – nikt nie wie jakiej jakości jest system, dopóki klient nie zacznie zgłaszać problemów.
  4. zmiany po zatwierdzeniu specyfikacji – mała z punktu widzenia klienta zmiana, może oznaczać zmianę koncepcji działania całego systemu. To oznacza dodatkową pracę, koszty oraz konieczność przeplanowania zadań.
  5. brak komunikacji – jeśli programiści nie wiedzą czego oczekuje klient (np. z powodu braku wymagań), lub klient zmienia wymagania w trakcie trwania projektu, czas zaplanowany na kodowanie, testowanie jest przeznaczany na wyjaśnianie.

Rozwiązanie:

  1. zdefiniowane wymagania – jasne, kompletne, szczegółowe, spójne logicznie oraz testowalne wymagania, które zostaly zaakceptowane przez wszystkie strony. W projektach prowadzonych wg metodyk lekkich, niezbędna jest ciągła koordynacja  wymagań z udziałem klienta.
  2. realistyczne estymacje czasu – zapewnienie odpowiedniej ilości czasu na planowanie testów, tworzenie przypadków testowych, testowanie, poprawę i retesty błędów, zmiany (change requests), raporty i dokumentację -zarówno tworzenie jak i czytanie. Zespół powinien mieć szansę na ukończenie projektu bez efektu wypalenia się.
  3. testowanie w odpowiednim momencie – rozpoczęcie testów na wczesnym etapie SDLC, retesty po poprawie błędów, testy regresywne po zmianach w bieżącej wersji systemu.
  4. trzymanie się zdefiniowanych wymagań – kiedy ruszy kodowanie, pojawią się zmiany, które zazwyczaj oznaczają dodatkową pracę w ustalonym na początku zakresie godzin. Dobrą praktyką jest komunikowanie konsekwencji takich zmian i jeśli są one niezbędne -reestymacja czasu na testy.
  5. komunikacja – tam gdzie ma to sens, pomagają przeglądy i inspekcje. Narzędzia do pracy grupowej: email, repozytorium błędów i dokumentacji. Wersjonowanie. Aktualne wersje dokumentów projektowych. Oraz najważniejsze – bezpośredni kontakt członków zespołu.