Testowanie oprogramowania - tematy do opracowania

January 25th, 2010

Opublikuj artykuł na wybrany przez siebie temat związany z testowaniem oprogramowania.

  • Masz wskazówki lub wnioski, którymi chciałbyś podzielić się z innymi?  Zapraszam do nadsyłania artykułów. Artykuły podpisane są imieniem i nazwiskiem autora.
  • Szukasz informacji na temat związany z testowaniem oprogramowania? Wpisz swój temat na listę materiałów do opracowania. Artykuł ukaże się niebawem.

Tags: ,

Mity na temat testowania oprogramowania

February 5th, 2010

Przetestowanie całej aplikacji/systemu jest możliwe. Jeśli testy zostaną odpowiednio zaplanowane to możliwe jest znalezienie i poprawienie wszystkich błędów w aplikacji.
Oprogramowanie zawiera coraz więcej linii kodu, staje się coraz bardziej złożone. Coraz więcej aplikacji współpracuje ze sobą w ramach jednego, rozproszonego systemu. Pokrycie testami wszystkich ścieżek przejścia we wszystkich kombinacjach jest niemożliwe choćby z powodu ograniczeń związanych z budżetem i czasem.

Kiedy projekt zakłada, że po ostatniej fazie testów aplikacja będzie wolna od błędów, dział testów staje się odpowiedzialny za każdy problem znaleziony w wersji produkcyjnej. Z kolei próba przetestowania wszystkich aspektów tworzonej aplikacji spowoduje opóźnienie w dostarczeniu wersji produkcyjnej. W rzeczywistości prawie każda aplikacja zawiera błędy. Pytanie, jakiego są one rodzaju i jak często objawiają się w np. niestabilnym działaniu gotowego produktu.

Testy powinny być przeprowadzane w pełni skonfigurowanym środowisku.
Im bardziej środowisko testowe przypomina docelowe środowisko produkcyjne, tym bardziej można polegać na wynikach testów. Jeśli środowisko produkcyjne klienta jest przez niego w pełni kontrolowane, testowanie może odbywać się w jak najbardziej zbliżonych warunkach. Jeśli tak nie jest, testy przeprowadzone w pełni skonfigurowanym środowisku mogą spowodować, że ważne przypadki testowe mogą w ogóle nie powstać.

Testowanie jest potrzebne, aby udowodnić, że oprogramowanie nie zawiera błędów.
Testowanie samo w sobie nie służy do poprawienia jakości aplikacji, ale jest tej jakości miernikiem. Przystępując do testów nie należy robić tego z założeniem, że system działa.

Zazwyczaj przypadki testowe, których wykonanie nie spowodowało wykrycia błędu oznacza się statusami “passed”, “ok”, “tested ok”. Jednak z punktu widzenia testera to właśnie Test Case, który pozwolił na odkrycie błędu jest sukcesem.
Oprogramowanie oprócz tego, że powinno poprawnie wykonywać pożądane i zaimplementowane funkcjonalności, nie powinno pozwalać na operacje, do których wykonywania nie zostało stworzone.

Automatyzacja testów. Jeśli można coś zautomatyzować należy to zrobić.
Automatyzacja jest potrzebna. Oszczędza nam, testerom długich wieczornych godzin spędzonych przy manualnych testach regresywnych. Z kolei estymowana liczba godzin na testy manualne, może skłonić projekt do zainwestowania w automatyzację testów.

Jednak co z czasem spędzonym na nauce narzędzi do testów automatycznych, tworzeniu skryptów i ich aktualizacją? Jedynie odpowiednia kombinacja testów automatycznych, testów eksploracyjnych i manualnych testów wykonywanych na podstawie przypadków testowych może spowodować, że informacja o jakości testowanego oprogramowania będzie kompletna i wiarygodna.

Tags: , , ,

Definicje rodzajów błędów w testowaniu aplikacji

January 25th, 2010
  • Error: niezgodność pomiędzy dostarczonym przes funkcję, zaobserwowanym lub zmierzonym rezultatem jej wykonania, a oczekiwaną wartością. Błędy mogą być powodowane celowo w procesie testowania aplikacji.
  • Failure: niemożność komponentu lub systemu do wykonania operacji w np. określonym w wymaganiach czasie
  • Exeption:  nieobsługiwany wyjątek, który powoduje zawieszenie lub przerwanie działania programu. Wyjątek może pojawić się w związku z adresowaniem pamięci, danymi, wykonaną operacją, przepełnieniem zmiennej, itp.
  • Defect, bug, fault: wada modułu lub systemu, która może spowodować, że moduł lub system nie wykona zakładanej czynności. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub systemu. (za słownikiem terminów testowych 2.0)
  • deviation, incident - każde zdarzenie występujące w procesie testowania, które wymaga zbadania (IEEE 1008)

Tags: , , , , , , , ,

Kiedy zakończyć testowanie aplikacji

January 19th, 2010

Moment zakończenia testów oprogramowania może być trudny do określenia. Współczesne aplikacje są złożone, pracują w rozproszonym środowisku i składają się z wielu współpracujących podsystemów. Teoretycznie testy mogą trwać przez cały  SDLC oraz w fazie utrzymania.
Są jednak czynniki, które pomagają zdecydować o zakończeniu testów:

  • czas (data uruchomienia w środowisku produkcyjnym, data zakończenia testów aplikacji, tzw. deadline)
  • przypadki testowe (test cases) - odpowiedni procent przypadków testowych, których wykonanie nie spowodowało wykrycia błędu.
  • wyczerpanie budżetu na testy
  • pokrycie kodu, funkcjonalności, wymagań w założonym zakresie
  • krzywa wykrywania błędów poniżej założonego wcześniej progu

Kto zatem powinien podjąć decyzję o zakończeniu testowania?

Osobą odpowiedzialną za testy w organizacji jest Test Manager. Z punktu widzenia jakości to on podejmuje decyzję o tym czy system spełnia zdefiniowane wcześniej kryteria jakości, jednak z punktu widzenia projektu informacja ta jest jedną ze składowych, które brane są pod uwagę przed wdrożeniem wersji produkcjyjnej testowanej aplikacji:

  • daty uruchomienia współpracujących systemów
  • cele związane ze sprzedażą
  • sytuacja na rynku i poczynania konkurencji
  • czynniki prawne
  • oczekiwania klienta

Z powyższych wynika, że odpowiedzialnością Test Managera jest dostarczenie informacji nt jakości grupie osób odpowiedzialnych za podjęcie decyzji o “wypuszczeniu aplikacji na rynek”. W małych organizacjach/projektach taką rolę może pełnić Project Manager lub Product Manager. W dużych decyzja może być podejmowana przez grupę osób ze strony biznesu i projektu.

Tags: , , ,

Jedyna prawdziwa metryka jakości kodu

January 18th, 2010

Humor bardzo środowiskowy.

test_measurement_of_code

Tags: , ,

Pages: 1 2 3 4 5 6 7 8 Next