Szkolenia ISTQB

ISTQB Foundation (Poziom podstawowy)

40 pytań wielokrotnego wyboru
każda poprawna odpowiedź to 1 punkt
zdawalność przy 65% poprawnych odpowiedzi (co najmniej 26 punktów)
egzamin trwa 60 minut (lub 75 dla osób zdającyh w języku obcym)

ISTQB Advanced (Poziom zaawansowany)

Każdy z modułów poziomu zaawansowanego (Test Manager, Test Analyst i Technical Test Analyst) posiada niezależny egzamin, który zawiera pytania z odpowiedziami wielokrotnego wyboru
Każda prawidłowo zaznaczona odpowiedź umożliwia zdobycie od 1 do 3 punktów – w zależności od trudności pytania. Poziom zdawalności to 65% prawidłowych odpowiedzi
Tak jak w przypadku egzaminu na poziomie podstawowym, przewidziany jest dodatkowy czas (25%) dla osób zdających w języku obcym

10 pytań rekrutacyjnych które należy zadać testerowi oprogramowania

Testowanie oprogramowania jest związane z wieloma dziedzinami naszego życia. Nie zawsze używamy tych samych technik, narzędzi i podejścia. Z tego względu też ciężko jest jednoznacznie określić wymagania stawiane przyszłym testerom. Z pewnością, wiedza związana z ISTQB będzie tutaj pomocna ale zawsze warto też ocenić logiczne myślenie takiego kandydata. Oto lista przykładowych 10 pytań, które z pewnością możecie spotkać na takiej rozmowie rekrutacyjnej na stanowisko testera oprogramowania. Sporo z nich wykracza poza syllabus ISTQB.



1. Skąd wiemy, że aktualne zachowanie oprogramowania jest poprawne czy jest to błąd?

Takie pytanie pomaga określić, czy kandydat odwołuje się do jakiejkolwiek dokumentacji. A co jeśli nie mamy oficjalnej dokumentacji? Byćmoże ze względu na swoje doświadczenie i znajomość oprogramowania to tester określa co jest dobre a co nie - bywają też takie odpowiedzi:) Często w projektach agile dokumentacja jest na tyle uboga, że np. obecność na codziennych stand-up`ach to główne źródło wiedzy o aktualnych zmianach w oprogramowaniu.

2. Na co nalezy zwrócić uwagę przy zgłaszaniu błędu?

Jedno z pytań teoretycznych. Wiadomo, jest to tytuł, kroki do zreprodukowania, aktualny rezultat, wersja oprogramowania itd. Warto tutaj wskazać na konfigurację środowiska na jakim występuje błąd, czy próbowaliśmy go zreprodukować w innym środowisku, byćmoże na innej wersji językowej oraz na dokładną wersję oprogramowania z możliwym zrzutem ekranu albo filmem.

3. Jak postępować z informacją, że u mnie działa?

Co zrobimy w takiej sytuacji? Z pewnościa nie pozostawimy bez odpowiedzi:) Dobrze jest upewnić się, czy programista reprodukuje defekt na tym samym środowisku i postępuje dokładnie krok po kroku z naszymi instrukcjami. Byćmoże jest jakas nieznaczna różnica która ma wpływ na ostateczny rezultat. Zdarza się też, że programiści nie używają wersji instalacyjnej oprogramowania, ale budują je z kodu. Niezależnie od tego, o ile to oczywiście możliwe, dobrze jest testować na środowisku które jest jaknajbardziej zbliżone do tego w którym pracuje klient.

4. Jakie wyróżniamy typy testów, czym się różnią?

Często ludzie mylą rodzaje testów z poziomami testów i wymieniają tutaj testy modułowe, integracyjne, systemowe i akceptacyjne. W tym przypadku należy wymienić testy funkcjonalne (co oprogramowanie robi), niefunkcjonalne (jak oprogramowanie to robi), strukturalne (jak robi to co robi) i te związane ze zmianą (retesty + regresja).

5. Od czego zależy ryzyko projektowe i co się na nie składa?

Trzeba w tym miejscu wymienić wpływ i możliwość wystąpienia błędu. Ocena wpływu to zadanie analityka testów (business value) podczas gdy ocena możliwości wystąpienia błędu to zadanie dla technicznego analityka testów (technical impact). Dobrze jest tu także opisać jak wygląda identyfikacja ryzyk, różnice pomiędzy ryzykiem projektowym, a produktowym i co robimy żeby je zminimalizować.

6. Co zrobić gdy nie jesteśmy pewni czy mamy do czynienia z błędem?

Zawsze warto poszukać jakiś twardych dowodów na które możemy się powołać przy zgłaszaniu błędu. Niestety nie zawsze jest to jasne - i co właśnie wtedy. Można zasięgnąc wiedzy u programistów, project/product managera, product ownera i innych. Często bywa tak, że zastana sytuacja jest nie do zaakceptowania, np. oprogramowanie/strona www otwiera się minutę bądź dłużej ale nie znajdziemy w wymaganiach informacji o czasie potrzebnym na otwarcie. Pamiętajcie wtedy, że zawsze można zgłosić defekt powołując się na użytkownika ze zdrowym rozsądkiem (tzw. 'reasonable end user') który najnormalniej nie będzie czekał.

7. Różnica między weryfikacją a walidacją

Weryfikacja sprawdza czy produkt jest zaprojektowany właściwie i odbywa się już od samego początku procesu rozwoju oprogramowania. Z kolei walidacja określa czy system posiada funkcje określone w wymaganiach a w szczególności czy spełniają one wymagania klienta. Weryfikacja odpowiada nam na pytanie "Czy właściwie budujemy nasz produkt?", a walidacja "Czy budujemy właściwy produkt"?

8. Czy tester jest odpowiedzialny za jakość oprogramowania?

Tak i nie, to znaczy bezpośrednio jego praca polega na sprawdzaniu czy w oprogramowaniu występują błędy ale on ich nie naprawia i nie decyduje o wydaniu oprogramowania na rynek. Jak nie tester to kto? Można się tu skłonić ku stwierdzeniu, żę jest odpowiedzialny za jakoś softu na równi z programistami. Jednak tak naprawdę wszyscy zaangażowani w proces wytwarzania oprogramowania są odpowiedzialni za produkt końcowy. Co z tego, że znajdziemy błędy oprogramowania jeśli ich nie naprawimy i produkt z błędami zostanie świadomie wydany na rynek.

9. Kiedy należy skończyć testować oprogramowanie? Podaj przykłady.

wystarczające pokrycie wymagań - wykonaliśmy poprawnie 95% testów pokrywających wszystkie wymagania,
zagęszczenie defektów - występuje nie więcej niż 5 defektów przypisanych do każdego z rozdziału wymagań,
koszt - testy trwają już 2 miesiące i nie możemy sobie pzwolić na dalsze testy,
ramy czasowe - testy są przewidziane na 3 miesiące i ani dnia dłużej,
ryzyko sprowadzone jest do akcpetowalnego poziomu - znamy błędy występujące w oprogramowaniu i je akceptujemy

10. Jaka jest różnica pomiędzy firmware, a software?

Oba określenia mają związek z hardwarem czyli fizycznymi elementami urządzeń (np. komputer, CPU, Ram). Software jest to oprogramowanie takie jak chociażby Windows7, Saper czy MS Office które instalujemy na danym urządzeniu. Z kolei firmware jest to oprogramowanie wbudowane takie jak np. BIOS i nie może być bezpośredio odinstalowane tak jak każde inne oprogramowanie.

Co oznacza weryfikacja? Na czym polega weryfikacja oprogramowania?

Weryfikacja ma za zadanie sprawdzić czy produkt jest zaprojektowany właściwie. Sprawdza czy dostarczamy wszystkie funkcje wymagane przez klienta. Odbywa się już na początku procesu rozwoju oprogramowania. Obejmuje ona wszelkie spotkania, przeprowadzanie przeglądów (nieformalny, inspekcja itp), ocenę dokumentacji wymagań i dostępnej specyfikacji. Weryfikacja odpowiada nam na pytanie: Czy właściwie budujemy nasz produkt? Czy korzystamy z właściwych danych, we właściwy miejscu i we właściwy sposób? Ma za zadanie wykazać spójność, kompletność i poprawność oprogramowani na każdym etapie oraz pomiędzy etapami cyklu rozwoju oprogramowania.

Co to jest testowanie end-to-end ?

Testy end-to-end jest metodologią stosowaną do sprawdzenia, czy aplikacja działa zgodnie z założeniami od samego początku do końca. Celem przeprowadzania testów typu end-to-end jest identyfikacja zależności między systemami i zapewnienie prawidłowej informacji między różnymi elementami systemu i systemami zewnętrznymi. Testowanie end-to-end polega na upewnieniu się, że zintegrowane składniki aplikacji działają zgodnie z oczekiwaniami. Cała aplikacja jest testowana w rzeczywistym scenariuszu, takim jak komunikacja z bazą danych, siecią, sprzętem i innymi aplikacjami. Przykładem takiego testu jest sprawdzenie poprawności przygotowanej transmisji video online. Testowanie obejmie wszystko, od pasma do mikrofonów. Uruchomienie takiego testu jest jedynym pewnym sposobem wykrycia problemów, które mogą pojawić się podczas transmisji na żywo. Taki test nauczy nas również jak rozwiązać podobny problem 'w locie'.

Czym są statyczne techniki testowania?

Statyczne techniki testowania oprogramowania polegają na przeprowadzaniu przeglądów, sprawdzaniu dokumentów projektowych a także na analizie statycznej czyli automatycznej analizie kodu bez jego uruchamiania. Główną różnicą między statycznymi a dynamicznymi technikami testowania jest to, że w statycznych nie uruchamiamy kodu.

Co to jest test zgodności oprogramowania?

Test zgodności oprogramowania jest to rodzaj niefunkcjonalnego testowania oprogramowania. Jest związany z szeroko pojętymi normami, które firma wytwarzająca oprogramowanie musi spełniać. Takie testy są przeprowadzone w celu znalezienia odchyleń od wymaganych standardów.

Innymi słowy mówiąc, takie testy określają, czy wdrażamy i spełniamy określone standardy. Takie testy powinny być przeprowadzane z zachowaniem szczególnej ostrożności. Test zgodności odpowiada na pytanie czy istnieją jakieś wady w implementacji standardów w naszym projekcie oraz czy musimy przeprowadzić dalszą analizę w celu poprawienia implementacji standardów.

Błąd, defekt, awaria

Błąd jest to inaczej ludzka pomyłka, która powoduje defekt (błąd w oprogramowaniu) w kodzie lub dokumentacji a to z kolei może spowodować awarię oprogramowania czyli wykonania niepożądanych akcji. Defekty w oprogramowaniu mogą powodować awarie, ale nie każdy defekt oprogramowania tak się objawia.

Defekty pojawiają się ze względu na możliwość ludzkiej pomyłki, pracujemy pod presją czasu, ze zmieniającym się środowiskiem i infrastrukturą. Jeśli spodziewany rezultat odbiega od aktualnego rezultatu, to oznacza, że mamy do czynienia z defektem. Tak samo jeśli rezultat odbiega od oczekiwań klienta – jest to defect. Z kolei jeśli takie defekty nie zostaną poprawnie zidentyfikowane i oprogramowania z błędem zostanie wydane i wykona niespodziewaną czynność to spowoduje to awarie. Awaria może być także spowodowane uwarunkowaniami środowiskowymi takimi jak magnetyzm, pola elektromagnetyczne czy zmienna temperatura

Co jest celem testowania oprogramowania?

Testowanie oprogramowania posiada różne cele i przeznaczenia. Główne cele testowania oprogramowania są następujące:
Znajdowanie usterek, które mogą zostać utworzone przez programistę podczas opracowywania oprogramowania
Uzyskanie zaufania i dostarczenie informacji o poziomie jakości
Zapobieganie wadom
Wzrost pewności, że końcowy wynik spełnia wymagania biznesowe i użytkowników
Upewnienie się, że spełnia specyfikację wymagań biznesowych i specyfikację wymagań systemu
Uzyskanie zaufania klientów, zapewniając im produkt wysokiej jakości

Testowanie oprogramowania jest wymagane do sfinalizowaniu aplikacji lub produktu w zależności od potrzeb biznesowych i użytkowników. Bardzo istotne zatem jest, aby mieć wystarczające pokrycie testowe, tak żeby całkowicie przetestować aplikację i upewnić się, że działa dobrze i zgodnie ze specyfikacją.

Istnieją różne punkty widzenia odnośnie testowania i dlatego w zależności od tego jakie testy są wykonywane bierzemy pod uwagę inne cele. Przykładowo w testach bezpośrednio związanych z rozwojem oprogramowania (np. modułowe, integracyjne i systemowe) głównym celem może być spowodowanie jak największej liczby awarii, dzięki czemu można ustalić, które wady oprogramowania zostały zidentyfikowane.

W testach akceptacyjnych głównym celem może być potwierdzenie, że system działa zgodnie z oczekiwaniami, aby uzyskać pewność, że spełnia stawiane mu wymagania. W niektórych przypadkach głównym celem testowania może być ocena jakości oprogramowania (bez zamiaru ustalenia usterek), przekazywanie informacji zainteresowanym stronom ryzyka wypuszczenia systemu w określonym czasie. Testy regresyjne często obejmują testowanie które ma za zadanie sprawdzenie, czy podczas wprowadzania zmian nie wprowadzono żadnych nowych wad. Podczas testów operacyjnych głównym celem może być ocena charakterystyk systemu, takich jak niezawodność czy dostępność.

Skąd biorą się defekty i awarie podczas testowania oprogramowania?

Defekty i awarie wynikają głównie z:
Błędów w specyfikacji, projektowaniu i wdrażaniu oprogramowania i systemu
Błędnego użycia systemu
Warunków środowiskowych
Umyślne szkody
Potencjalne konsekwencje wcześniejszych błędów

Błędy w specyfikacji i projekcie oprogramowania

Specyfikacja jest w zasadzie pisemnym dokumentem opisującym funkcjonalne i niefunkcjonalne aspekty oprogramowania, używając np tekstu, wstępnego wyglądu oprogramowania. Do testowania specyfikacji nie ma potrzeby posiadania kodu. Bez kodu możemy przetestować specyfikacje. Około 55% wszystkich błędów występujących w produkcie jest z powodu błędów opisanych w specyfikacji. Dlatego testowanie specyfikacji może zaoszczędzić znaczne koszty poniesione w przyszłości lub w późniejszych etapach produktu.

Błędnego użycia systemu

Błędy w użyciu systemu lub produktu lub aplikacji mogą powstać z następujących powodów: Niewystarczająca znajomość produktu lub oprogramowania dla testera. Tester może nie być świadomy funkcjonalności produktu, a zatem podczas testowania produktu mogą wystąpić pewne wady lub awarie. Brak zrozumienia funkcjonalności programowania przez programistę. W oparciu o ich zrozumienie, funkcja, którą opracują, może nie odpowiadać specyfikacjom. Może to spowodować defekt lub awarię.

Warunki środowiskowe

Ze względu na nieprawidłowe ustawienie środowiska testowego mogą zostać zgłaszane defekty lub awarie. Zgodnie z najnowszymi badaniami zaobserwowano, że około 40% czasu testera jest poświęcane problemom ze środowiskiem, co ma ogromny wpływ na jakość i wydajność jego pracy. W związku z tym wymagane są odpowiednie środowiska testowe w celu zapewnienia jakości i terminowości dostarczenia produktu klientom.

Umyślne szkody

Wady i awarie zgłoszone przez testerów podczas testowania produktu lub aplikacji mogą wyniknąć z powodu umyślnego uszkodzenia, które nie jest związane ze sprawdzaniem poprawności działania aplikacji ale z celowym działaniem testera.

Potencjalne konsekwencje wcześniejszych błędów

Błędy wykryte we wczesnych fazach rozwoju zmniejszają nasz koszt produkcji. Stąd bardzo ważne jest, aby znaleźć błąd na wcześniejszym etapie. Można to zrobić przeglądając dokumenty specyfikacji lub instrukcje. Obniżenie ilości defektów w przyszłości spowoduje obniżenie kosztów wytwarzania oprogramowania.