Egzamin ISTQB Advanced Level

December 8th, 2010

Advanced Level (CTAL) - Test Manager

Egzamin poprzedzony jest szkoleniem przygotowującym do uzyskania certyfikatu. Jest ono przeznaczone jest dla osób posiadających już certyfikat Foundation ISTQB lub ISEB.

Zakres materiału do opanowania

  1. Definiowanie ogólnych celów testów oraz strategii określających w jaki sposób system ma być przetestowany
  2. Planowanie prac, ustalanie harmonogramu oraz śledzenie wykonywanych zadań
  3. Określanie i organizowanie wymaganych czynności
  4. Wybieranie, pozyskiwanie i przydzielanie odpowiednich zasobów do zadań
  5. Wybieranie, organizowanie i zarządzanie zespołami testerów
  6. Organizowanie komunikacji pomiędzy członkami zespołów testowych oraz pomiędzy testerami i innymi osobami w zespole projektowym
  7. Uzasadnianie decyzji i dostarczanie odpowiednich raportów gdy jest to konieczne

Wymaga praktycznej wiedzy z zakresu zarządzania procesem testowania, analizy oraz znajomości narzędzi używanych w procesie testowania oprogramowania.

Dla każdego poziomu wymagana jest ogólna wiedza z każdego rozdziału, ale w szczegółach są one różne.

Warto pamiętać, że do egzaminu można podchodzić bez szkolenia.

Zakres zagadnień poruszanych na szkoleniu przygotowującym do uzyskania certyfikatu

1. Podstawowe aspekty testowania oprogramowania
2. Proces testowy
3. Zarządzanie testami
4. Techniki testowania
5. Testowanie charakterystyk oprogramowania
6. Techniki przeglądów
7. Zarządzanie incydentem
8. Standardy i usprawnienie procesu testowego (Test Process Improvement)
9. Narzędzia testowe i automatyzacja
10. Budowanie zespołu testowego

Tags: , ,

Egzamin ISTQB Foundation Level

December 8th, 2010

Egzamin poprzedzony jest szkoleniem dla osób zamierzających uzyskać certyfikat Certified Tester Foundation Level.

Zakres zagadnień poruszanych na szkoleniu przygotowującym do uzyskania certyfikatu:

1. Podstawy testowania
Terminologia, co to jest testowanie, dlaczego testowanie jest niezbędne, podstawowe zasady testowania, podstawowy proces testowy, psychologia testowania.

2. Testowanie w cyklu życia oprogramowania
Modele wytwarzania oprogramowania, poziomy testów, typy testów: cele testowania, testowanie w fazie utrzymania.

3. Statyczne techniki testowania
Przeglądy i proces testowy, proces przeglądu, analiza statyczna wsparta narzędziowo.

4. Techniki projektowania testów
Identyfikacja warunków testowych i projektowanie przypadków testowych, kategorie technik projektowania testów, techniki testowania w oparciu o specyfikację czyli czarnoskrzynkowe, techniki testowania w oparciu o strukturę lub białoskrzynkowe, techniki w oparciu o doświadczenie, wybór technik testowych.

5. Zarządzanie testowaniem
Organizacja testowania, planowanie i oszacowanie pracochłonności testów, monitorowanie i nadzorowanie procesu testowego, zarządzanie konfiguracją, ryzyko a testowanie, zarządzanie incydentami.

6. Testowanie wspierane narzędziami
Rodzaje narzędzi testowych, skuteczne użycie narzędzi: potencjalne korzyści i zagrożenia, wdrożenie narzędzi w organizacji.

Materiały przygotowujące do egzaminu Certyfikowany Tester Poziom Podstawowy

ISTQB Certified Tester – Foundation Level


Zapisy na egzaminy

Zapisy na egzaminy otwarte



Tags: , ,

Drugie wydanie magazynu c0re

June 29th, 2010

c0re działa pod patronatem Global Association for Software Quality (GASQ) oraz Stowarzyszenia Jakości Systemów Informatycznych (SJSI). Celem inicjatywy jest wymiana wiedzy z zakresu szeroko pojętej jakości oraz aktywizacja środowiska osób zawodowo zajmujących się tym tematem.

W kwartalniku c0re znajdziecie Państwo publikacje polskich i zagranicznych specjalistów umieszczone w czterech podstawowych sekcjach:

• Inżynieria oprogramowania - tematy związane z: zbieraniem i analizą wymagań, projektowaniem aplikacji, cyklem i metodami wytwarzania oprogramowania, zarządzaniem zmianą, zarządzaniem konfiguracją, etc.
• Testowanie oprogramowania - praktyczne aspekty związane z testowaniem oprogramowania – techniki, metody, narzędzia QA.
• Jakość w projekcie – zapewnienie i kontrola jakości na poziomie procesów występujących w projekcie IT.
• Zarządzanie – dla osób zajmujących się koordynacją projektów testowych, kierowników projektów, liderów procesów.

W tym numerze między innymi:
• Manifest jakości (Tom Gilb)
• Przeciwko certyfikacji (James Bach)
• Hiper produktywne Agile (Ryan Shriver)
• O szkoleniach testerskich (m.in. CTAL) dofinansowanych z PARP
• Artykuły o automatyzacji testów

Magazyn jest do pobrania ze strony www.coremag.eu

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: , , , , , , , ,

Pages: Prev 1 2 3 4 5 6 7 8 9 Next