Redakcja
Na dowolny system informatyczny składa się zestaw funkcjonalności (functionality) czy też funkcji (functions), które w wielu systemach wyglądają dokładnie tak samo. Przykładem może być funkcja logowania się czy otwierania pliku. Zgodnie z regułą, że wszystko już zostało wymyślone możemy założyć, że dowolna funkcja oprogramowania została już przynajmniej raz w innym systemie użyta. Istnieje więc również duża szansa, że doświadczony tester spotkał ją już w innym systemie. Wiedza ta może mu pomóc w przetestowaniu danej funkcji w obecnym projekcie.
Odpowiedni zestaw funkcji ułożony w kolejności może składać się na proces biznesowy. Zrozumienie funkcji jest więc podstawą do zrozumienia procesu, gdzie nawet brak tej wiedzy można kompensować poprzez testy pojedynczej funkcji oraz, co kluczowe w procesie, styku funkcji.
Brak specyfikacji można kompensować wiedzą na temat tego jak dana funkcja działa w innym systemie. Bolączką większości projektów jest nieaktulana lub też nieistniejąca specyfikacja. Przeprowadzenie testów można więc realizować bazując na doświadczeniu z podobnego systemu lub systemów, które mają wbudowane znane nam funkcje.
Testowanie takie możnaby nazwać testowaniem opartym na funkcji (function driven testing).
Czy TOnF będzie techniką? Nie. Ponieważ nie jest to pojedyncza metoda weryfikacji oprogramowania.
Czy TOnF będzie metodą? Również nie. Trudno określić jedną metodę do weryfikacji oprogramowania.
Czy w takim razie TOnF będzie podejściem do testowania (strategią)? Tak. Można założyć, że testowanie zorientowane na funkcjonalność będzie strategią, która próbuje z jednej strony utylizować umiejętności i wiedzę testera oprogramowania. Z drugiej strony kompensuje brak wiedzy biznesowej. Próbuje więc rozwiązać standardowe problemy testerskie.
Czy w testowaniu opartym o funcje powstają przypadki testowe czy jest to raczej testowanie dynamiczne (eksploracyjne)? Strategie mają to do siebie, że można je próbować adaptować do projektu. Jeśli zakładamy, że w projekcie muszą powstać przypadki testowe to one powstają. Jeśli wystaczry nam podejście bardziej zorientowane na uruchomienie testów bez budowy formalnej specyfikacji wtedy przechodzimy do eksploracji. Należy pamiętać, że to jak testujemy funkcję jest związane silnie ze specyfiką danej funkcji. Zakładamy więc, że kontekst testowania uwzględni kontekst funkcji.
Czy TOnF jest więc czymś nowym? Nie. Podejścia oparte na funkcjach pojawiają się w innych metodykach i strategiach, ale zazwyczaj próbują adaptować się do każdego typu projektu. Testowanie oparte na funkcji jest samo w sobie pokryciem kluczowych aspektów poprawności działania oprogramowania i elementem wyjścia do dalszych działań jak automatyzacja, testowanie odbiorowe czy też akceptacja. Testowanie funkcjonalne samo w sobie nigdy nie było traktowane jako strategia. Jest to jedynie typ testów pojawiający się we wszystkich innych strategiach. Brakuje sensownego wytłumaczenia czym jest w taki rodzaj testowania, który poprawność funkcji ma weryfikować.
Testowanie oparte na funkcji odnosi się zarówno do funkcji pojedynczego komponentu jak i funkcji w zintegrowanym systemie. Nie jest więc zależne od poziomu testów, ani nie pokazuje jednoznacznie kto ma je przeprowadzać. Ma jednak braki, które należy kompensować poprzez dodanie testowania cech oprogramowania. Jest wiadomym, że testowanie wydajności czy też niezawodności to testowanie użycia pewnej funkcji, ale użycie to musi dodatkowo uwzględniać ilość użyć i czas użycia. Zrozumienie kluczowych funkcji jest więc otwarciem na definiowania realistycznych scenariuszy testowania, nie jest jednak właściwym testowaniem niefunkcjonalnym.
"Testowanie oparte na funkcji" można traktować jako kolejną próbę pokazania wartości testowania, która uwzględnia kontekst biznesowy użycia funkcji. Wielu członków projektowych czy też sponsorów projektu zarzuca testerom zbytnią orientację na rzeczach nieważnych lub też błahych projektowo / biznesowo. Otwarcie się na funkcję jako podstawową składową oprogramowania może być nowym otwarciem na testowanie.
