Redakcja
4 października 2013
Dojście do kierownika projektu to dla wielu wymarzona ścieżka kariery. Czy ten kierunek rozwoju jest zamknięty dla testerów? Absolutnie nie.
2 października 2013
Testowanie oparte na funkcji wymaga zrozumienia, że nie wszystkie funkcje są równe i nie każda funkcja jest kluczowa dla działania biznesu. Funkcje można dzielić w zależności od krytyczności, obszaru czy wyróżniać funkcje pożądane i niepożądane.
1 października 2013
Ponad dekadę temu, w swoim słowniku ISEB zaproponował, aby rozróżnić błędy od defektów. Błędy popełniają ludzie, a defekty są ich konsekwencją. Choć ISTQB (następca ISEB) jest rozpowszechniony również w Polsce, terminologia ta nie przyjęła się w projektach informatycznych.
30 września 2013
Kolejny zestaw 100 dobrych rad dla jeszcze lepszego testera.
24 września 2013
Każdy kierownik musi w swoim projekcie informatycznym podzielić budżet i zdecydować, ilu będzie programistów, a ilu będzie testerów. Dla części liderów wybór jest oczywisty. Tester jest zbędny - wszystkie środki przeznaczamy na programowanie. Dla wielu jest to trudna decyzja.
18 września 2013
Kiedy możemy powiedzieć, że jesteśmy dobrymi i skutecznymi testerami? Samo wewnętrzne przekonanie nie wystarczy. Trzeba je poprzeć miarami.
17 września 2013
Zadania z definiowania ilości przypadków testowych dla pokrycia instrukcji i decyzji to standardowe pytania z egzaminu ISTQB. W większości są to proste zadania, w których wystarczy zrozumieć pewien schemat. Kiedy jednak w wielu instrukcjach pojawia się ta sama zmienna, trafiamy na coś w rodzaju zagadki logicznej.
16 września 2013
Może niektórym trudno się z tym zgodzić, ale polska szkoła testowania oprogramowania nie istnieje. Nigdy nie istniała. Do tego smutnego wniosku może doprowadzić analiza osiągnięć pojedynczych osób, organizacji czy też firm na rynku zarówno wewnętrznym, jak i zagranicznym.
11 września 2013
Kontynuujemy cykl 100 dobrych rad dla dobrego testera jako tłumaczenie "99 rzeczy, które możesz zrobić, aby stać się lepszym testerem".
10 września 2013
Testowanie oparte na specyfikacji (specification driven) wymaga posiadania specyfikacji, co jak wiadomo nie jest częste w projektach informatycznych.
Testowanie oparte na biznesie (business driven) wymaga zrozumienia aspektu procesu biznesowego (zazwyczaj złożonego) zaimplementowanego w oprogramowaniu. Często wiedza taka nie jest dostępna testerowi.
Może więc coś nowego: testowanie oparte na funkcji (funkcjonalności)?
