testowanie.net

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

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ązania:

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.

Tags: klient, Komunikacja w zespole, Testowanie, wymagania

Posted in Testowanie | No Comments »

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

Tags: tesowanie aplikacji, testowanie oprogramowania

Posted in Testowanie | No Comments »

Analiza wymagań metodą FURPS

Zbieranie wymagań jest pierwszym krokiem do właściwego testowania. Czynność ta jest wspierana przez metodę klasyfikacji FURPS. Angielski akronim rozszyfrowujemy następująco:

• Functionality- funkcjonalność w rozumieniu zestawu funkcji uwzględniająca również bezpieczeństwo (ang. security)
• Usability - użyteczność jako zestaw wizualnych aspektów oprogramowania
• Reliability - niezawodność, będąca mierzona np. częstością występowania błędów
• Performance - wydajność aplikacji określana również jako czas odpowiedzi lub użycie zasobów
• Supportability - nie dająca się łatwo przetłumaczyć “wspieralność” uwzględniająca zdolność aplikacji do instalacji na różnych platformach, łatwość testowania itd.

Zgodnie z metodologią testowania w FURPS możemy wyróżnić wymagania funkcjonalne ukryte za pierwszą literką (F) oraz niefunkcjonalne (URPS).
Istnieją różne wersje FURPS, które są modyfikacjami związanymi ze specyfiką pracy w danej firmie. Zazwyczaj oznacza się je jako FURPS+.

Do czego potrzebne są wymagania?

• Definiowanie zakresu projektu
• Estymacja kosztów
• Budżetowanie
• Szczegółowe planowanie projektu
• Projektowanie systemu
• Testowanie systemu
• Dokumentacja i podręczniki użytkownika

testerzy.pl

Tags: analiza wymagań, RURPS, wymagania

Posted in Testowanie | No Comments »

Testowanie oprogramowania FAQ

Jaka jest różnica pomiędzy Zapewnieniem Jakości (Quality Assurance) a Testowaniem?

Testowanie jest zorientowane na “wykrywanie”. Testowanie oznacza uruchomienie systemu w określonych warunkach, ze zdefiniowanymi danymi wejściowymi oraz analizę rezultatów testów.

Zapewnienie Jakości oznacza stosowanie procesu wg którego wytwarzane jest oprogramowanie. Monitorowanie owego procesu oraz jego usprawnianie. Upewnianie się, że stosowane są zdefiniowane wcześniej procedury i standardy. Zapewnienie jakości jest zorientowane na “zapobieganie”.

Czym jest analiza wpływu (Impact analysis) i jaką ma rolę w testach aplikacji?

Analiza wpływu polega na zrozumieniu efektu dokonywanej zmiany w kontekście jej wpływu na proces testowy.

Analiza wpływu jest wymagana kiedy:

1. pojawia się zmiana w wymaganiach
2. następuje zmiana istniejącej funkcjonalności aplikacji
3. do testowanego systemu dołączany jest nowy moduł lub nowa funkcjonalność

Analiza wpływu pozwala odpowiedzieć na pytania:

1. które moduły lub funkcjonalności zostaną dotknięte przez zmianę?
2. w jaki sposób zostaną dotknięte?
3. jakie przypadki testowe muszą zostać stworzone, aby pokryć nowe funkcjonalności lub moduły?
4. jakie przypadki testowe muszą zostać stworzone, aby pokryć interakcje pomiędzy nowymi, a istniejącymi modułami systemu?
5. czy nowy moduł/funkcjonalność wymaga innych narzędzi testowych lub treningu?
6. jaki wpływ na estymacje czasu testów i zasoby ma nowy moduł?
7. jak wprowadzenie nowego modułu wpływa na datę zakończenia testów?

Tags: testowanie oprogramowania, zapewnienie jakości

Posted in Testowanie | 3 Comments »

Informacja zwrotna w zespole testerskim

Udzielanie informacji zwrotnej jest ważną umiejętnością. Otwartość, szczerość, zaufanie - wszystkie te cechy są znakami firmowymi wysoko wykwalifikowanego zespołu i dojrzałej organizacji. Umiejętność udzielania oraz otrzymywania informacji zwrotnej jest kluczowym aspektem dobrych relacji w zespole.

Co zapewnia dobry przepływ informacji zwrotnej:

• zapobieganie przemianie małych problemów w problemy, którymi nie da się zarządzać
• budowanie zaufania w relacjach pomiędzy członkami zespołu
• wspieranie osobistego i profesjonalnego rozwoju
• dostarczanie informacji na temat osobistych osiągnięć osób w grupie
• wyjaśnianie nieporozumień
• jest to też sposób na rozpoznanie i potwierdzenie umiejętności kompunikacyjnych poszczególnych członków zespołu

Jak więc udzielić komuś informacji w efektywny sposób?

Upewnij się, że twoją intencją jest raczej pomoc i wsparcie niż oskarżanie czy rozliczanie. Dowiedz się najpierw jak sytuacja o której zamierzasz mówić wygląda z punktu widzenia drugiej osoby.

Bądź konkretny tak bardzo jak to tylko możliwe. Opisz zachowanie, sytuację, które zaobserwowałeś. Unikaj personalnych odniesień, powtarzania zasłyszanych opinii, unikaj ogólnych stwierdzeń i generalizowania.

“Ja widziałem..”, “ja słyszałem..”, “ja czuję, że..” - opisz wpływ sytuacji, którą opisujesz na ciebie: “Kiedy ty… poczułem, że…”.

Bądź szczery w swoich komentarzach. Nie mów, że coś jest dobre, jeżeli nie wierzysz w to.

Ważne jest, aby mówić zarówno o rzeczach, które ci się podobają jak i o tych, które wg ciebie wymagają usprawnienia. Spróbuj zakończyć pozytywnym stwierdzeniem i zachęć do odpowiedzi na twoje komentarze.

Członkowie zespołu zazwyczaj nie zatrzymują informacji dla siebie bez powodu.  Przyczyną może być niewiedza o tym, że inni potrzebują danej informacji lub wyobrażanie sobie co może się stać, kiedy informacja zostanie przedstawiona na forum grupy.

Potencjalne przyczyny braku komunikacji. Członkowie zespołu:

• zakładają, że inni są świadomi zmian i problemów, które występują
• mają problem z ocenieniem, które informacje są na tyle znaczące, aby podzielić się nimi
• mają niewiele okazji do komunikowania i wymiany informacji
• unikają zgłaszania potencjalnych problemów z obawy przed opinią osoby czarnowidzącej
• obawiają się syndromu “zabić posłańca”
• nie są świadomi, że dzielenie się informacjami jest jednym z ich obowiązków wobec grupy

Tags: feedback, Komunikacja w zespole

Posted in Komunikacja w zespole | No Comments »