testowanie.net

Jedyna prawdziwa metryka jakości kodu

January 18th, 2010

Humor bardzo środowiskowy.

test_measurement_of_code

Tags: Humor, metryki, Testowanie

Posted in Testowanie | No Comments »

Egzaminy ISTQB ISEB

January 13th, 2010

ISTQB czyli International Software Testing Qualifications Board stworzył ścieżkę certyfikacji testerów oprogramowania.

Pierwszy poziom kwalifikacji Foundation Level został uznany w roku 2006 za zgodny z Foundation Exam oferowanym przez ISEB.

Celem ISTQB było stworzenie ścieżki rozwoju dla testerów pod wspólną nazwą “Certified Tester”.

Certyfikaty ISTQB uznawane są w ponad 50 krajach na całym świecie.

ISTQB oferuje możliwość uzyskania następujących certyfikatów:

Foundation Level (CTFL)
- 1. Podstawy testowania
- 2. Testowanie w cyklu życia oprogramowania
- 3. Statyczne techniki testowania
- 4. Techniki projektowania testów
- 5. Zarządzanie testowaniem
- 6. Testowanie wspierane narzędziami
Advanced Level (CTAL) - Test Manager, Test Analyst, Technical Test Analyst
- 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
Expert Level

Tags: egzaminy, ISEB, istqb, szkolenia, Testowanie

Posted in Egzaminy ISTQB | 1 Comment »

Nowy magazyn o testowaniu oprogramowania

January 8th, 2010

Właśnie dostałem mail z informacją, że wyszedł pierwszy numer Agile Record - The Magazine for Agile Developers and Agile Testers.

Podoba mi się szczególnie jedno zdanie z artykułu “Be the Worst” - ”be the worst of the people you are surrounded by”, or “surround yourself with really great people.”

Oprócz tego, że jest to zasada, którą warto stosować w życiu to w kontekście projektu, rola testera pasuje do obu stwierdzeń powyżej

Magazyn w wersji elektornicznej do pobrania: www.agilerecord.com/agilerecord_01.pdf

Spis artykułów:

Be the Worst
Are All Pigs Equal? – or are some more equal than others?
7 Steps to efficient GUI test automation using Selenium RC with Java
How Agile Methodologies Challenge Testing
Testing in an organisation going agile
Is there such a thing as an Agile tester?
Guerrilla Scrum: How to force organizational change
Quality – An agile point of view
Testability: Investment, not Overhead
The Future of Testing – How Testing and Technology will Change
Agile and Performance testing? “A Contradiction of terms?”
Software Testing Craft
Five tips for successful retrospectives
Still playing planning poker? Stop gambling with your project budget.
Scrum and RUP - A Comparison Doesn’t Go on All Fours
Masthead

Tags: agile, źródła zewnętrzne, magazyn, Testowanie

Posted in Testowanie | No Comments »

Priorytety w testowaniu oprogramowania, analiza ryzyka

January 5th, 2010

Ryzyko w testowaniu oprogramowania można określić procentowo, jako stopień niepewności czy projekt osiągnie założone cele. Ryzyko określa prawdopodobieństwo wystąpienia nieporządanej, zdefiniowanej wcześniej, sytuacji oraz stopień jej wpływu na powodzenie projektu.

Jakie ryzyka wiążą się z zastosowaniem podejścia typu Risk Based Testing?

niesprecyzowana defininicja ryzyka - umieszczanie ryzyk i błędów w jednej grupie
subiektywna ocena wpływu ryzyka na projekt oparta na “pasujących” czynnikach
brak przeglądów listy ryzyk w kolejnych fazach SDLC

Testując oprogramowanie nie da się sprawdzić wszystkich scenariuszy (tak jak nie da się znaleść wszystkich błędów). Dlatego tak ważne jest podjęcie decyzji co testujemy, a czego nie. Na których obszarach aplikacji skupić uwagę, a które uznać za “niezagrożone”. Testowanie np. metodami czarnej skrzynki z użyciem klas równoważności czy wartości brzegowych zapewnia co prawda pokrycie funkcjonalności testami, ale przy okazji powoduje, że liczba przypadków testowych (test cases) rośnie. Co więcej nie wszystkie z nich są tak samo istotne z punktu widzenia jakości systemu, czasu, który mamy na testowanie oraz wymagań klienta.

Sposobem na zmniejszenie liczby przypadków testowych jest wybranie tych funkcjonalnych obszarów aplikacji, które są najbardziej podatne na błędy oraz tych, których uszkodzenie może spowodować największe koszty.

Gdzie i kiedy spodziewać się największej liczby błędów?

To tylko kilka czynników, które warto wziąć pod uwagę przy ustalaniu zakresu testów aplikacji. Moim zdaniem -ważnych, ale jak zwykle wszystko zależy od kontekstu i danego projektu.

Złożone funkcjonalności.
Złożoność jest jedną z najczęstszych przyczyn powstawania błędów: wiele zmiennych użytych w kodzie, rozłożony na wiele kroków przepływ danych, skomplikowana logika biznesowa, zgromadzenie w jednym module wielu funkcji, których interfejsy wychodzą na zewnątrz.

Obszary systemu, które zostały zmodyfikowane/przepisane.
Testy regresywne powinny załatwić sprawę. Jednak i one mają swoje priorytety, które mogą zmienić się po wprowadzeniu zmian w funkcjonalności. Innego rodzaju zagrożeniem przy wyborze scenariuszy testowych do testów regresywnych jest paradoks pestycydów.

Wiele zmian w pojedyńczym module systemu może być symptomem źle wykonanej analizy. To sygnał aby otworzyć plik z wymaganiami i przypadkami użycia (Use Cases) -jeśli mamy ich zaktualizowaną wersję

Liczba osób zaangażowanych w programowanie/testy.
Im więcej osób jest zaangażowanych w zadanie tym większy nakład środków i czasu na komunikację. Wydłużony przepływ informacji prowadzi do ich zniekształcenia, nadinterpretacji czy pomijania. Może działać to zarówno podczas kodowania jak i przy testach.

Jakość wykonania testów (nie mówię tu o jakości aplikacji, ale o jakości pracy) jest ważniejsza niż odpowiedź na pytanie “Zostało nam trzy tygodnie na testy. Ile dodatkowych osób możemy w nie zaangażować?”. Jedną z metryk (z pewnością nie najlepszą) wydajności testera jest liczba zgłoszonych przez niego błędów.

Trudno jest porównać trójosobowy, doświadczony zespół testowy i zgłoszone przez niego błędy ukryte w architekturze systemu z 10-cioosobową grupą nie-testerów, którzy testują w międzyczasie i chcąc wykonać przypadek testowy, a więc przejść z ekranu A na ekran B, zaglądają np. do kodu aplikacji.

Presja czasu, zarówno przy kodowaniu jak i testach.
Błędne estymacje czasu, problemy w komunikacji, sytuacje nieprzewidziane podczas fazy analizy ryzyka projektu. Wszystko to powoduje opóźnienia zarówno w fazie kodowania jak i testów. Brak czasu jest wrogiem jakości. Skłania do pomijania pierwotnie obranej ścieżki i stosowania skrótów.

Pytania jakie warto zadać przed podjęciem decyzji co testujemy:

które elementy aplikacji mogą zostać przetestowane we wczesnej fazie SDLC?
które części kodu/moduły są najbardziej skomplikowane i dlatego najbardziej narażone na wystąpienie błędów?
która funkcjonalność jest najważniejsza z punktu widzenia zastosowania projektu?
która funkcjonanlość jest najbardziej widoczna dla klienta?
które z testów mają najlepszy współczynnik pokrycia obszarów o wysokim ryzyku do czasu potrzebnego na testowanie?
które z wymagań zostały zmienione lub ogólnie zdefiniowane?
która funkcjonalność ma największy wpływ na bezpieczeństwo aplikacji?
która funkcjonalność ma największy wpływ na finanse?
Które elementy testowanej aplikacji mają największe znaczenie dla klienta?
które aspekty podobnych, ukończonych poprzednio projektów powodowały problemy?
które elementy podobnych, ukończonych projektów powodowały największe problemy w fazie utrzymania (maintenance)?
co programiści uznają na najbardziej narażony na ryzyko element aplikacji?
która część systemu była tworzona pod presją czasu?
jaki rodzaj problemów może spowodować negatywną reakcję klienta?
jaki rodzaj testów może pokryć możliwie najwięcej funkcjonalności?
które z poprzednio wykonanych przypadków testowych powodowały wykrycie błędów? (test case value)