Większość testów oprogramowania komputerowego napisałem ponad 25 lat temu. Od tamtej pory wskazałem kilka części książki, które uważam za nieaktualne lub po prostu złe. Zobacz http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Możesz zobaczyć więcej (bieżące wyświetlenia, ale bez wyraźnych wskazówek z powrotem do TCS) na mojej stronie dla kursu testowania oprogramowania Black Box (filmy i slajdy dostępne za darmo), www.testingeducation.org/BBST
Kultura testowa była wówczas w dużej mierze potwierdzająca.
We współczesnych testach podejście do testów jednostkowych jest w dużej mierze potwierdzające - piszemy duże kolekcje testów automatycznych, które po prostu sprawdzają, czy oprogramowanie nadal działa zgodnie z przeznaczeniem. Testy służą jako detektory zmian - jeśli coś w innych częściach kodu i ta część ma teraz problemy, lub jeśli wartości danych, które kiedyś były niemożliwe w rzeczywistym świecie, docierają teraz do aplikacji, detektory zmian uruchamiają się, ostrzegając programista do problemu konserwacji.
Myślę, że sposób myślenia potwierdzającego jest odpowiedni do testowania jednostkowego, ale wyobraź sobie świat, w którym wszystkie testy systemu były potwierdzające (dla osób, które dokonują rozróżnienia, zinterpretuj „testy integracji systemu” i „testy akceptacji”, jak zawarto w moich komentarzach na temat systemu testowanie.) Punktem testowym było potwierdzenie, że program spełniał specyfikacje, a dominującym podejściem było zbudowanie zillionowych (lub co najmniej kilkuset) testów regresji na poziomie systemu, które odwzorowały części specyfikacji na zachowania programu. (Myślę, że potwierdzenie spec-to-zachowanie jest przydatne, ale myślę, że jest to niewielka część większego celu.)
Wciąż istnieją grupy testowe, które działają w ten sposób, ale nie jest to już dominujący pogląd. Tak było. Pisałem z naciskiem i rysowałem ostre kontrasty, aby zwrócić uwagę na ludzi, którzy byli konsekwentnie szkoleni w tym sposobie myślenia. Dzisiaj niektóre ostre kontrasty (w tym ten cytowany tutaj) są nieaktualne. Zostają źle zinterpretowani jako ataki na złe poglądy.
Moim zdaniem testowanie oprogramowania jest empirycznym procesem uczenia się związanych z jakością informacji o produkcie lub usłudze.
Test powinien być zaprojektowany w celu ujawnienia przydatnych informacji.
Nawiasem mówiąc, wtedy nikt nie mówił o testowaniu jako metodzie ujawniania „informacji”. W tamtych czasach testowanie polegało na wykrywaniu (niektórych wersji ...) błędów lub (niektórych wersjach ...) weryfikowaniu (sprawdzaniu) programu pod kątem specyfikacji. Nie sądzę, aby twierdzenie, że testy służą do ujawnienia użytecznych informacji, pojawiło się w słowniku testowym aż do tego wieku.
Wyobraź sobie testy ratingowe pod względem ich wartości informacyjnej. Test, który prawdopodobnie nauczy nas czegoś, czego nie wiemy o oprogramowaniu, miałby bardzo wysoką wartość informacyjną. Test, który najprawdopodobniej potwierdzi coś, czego się już spodziewamy i który został już wielokrotnie udowodniony, miałby niską wartość informacyjną. Jednym ze sposobów ustalenia priorytetów testów jest przeprowadzenie testów o wyższej wartości informacji przed testami o niższej wartości.
Gdybym nadmiernie uprościł tę priorytetyzację, aby przyciągnęła uwagę programisty, kierownika projektu lub kierownika procesu, który nie ma pojęcia o testowaniu oprogramowania, powiedziałbym: „TEST, KTÓRY NIE JEST PRZEZNACZONY DO WYKRYWANIA BŁĘDU, TO STRATY CZASU . ” To nie jest idealne tłumaczenie, ale dla czytelników, którzy nie rozumieją żadnej subtelności lub kwalifikacji, jest to tak bliskie, jak to możliwe.
Wtedy, i widzę to ponownie tutaj, niektórzy ludzie, którzy nie rozumieją testowania, odpowiedzieliby, że test zaprojektowany w celu znalezienia narożnych skrzynek jest stratą czasu w porównaniu z testem dużego wykorzystania ważnej funkcji. Nie rozumieją dwóch rzeczy. Po pierwsze, zanim testerzy znajdą czas na sprawdzenie wartości granicznych, główne zastosowania głównych funkcji zostały już wykonane kilka razy. (Tak, są wyjątki i większość grup testowych zwróci szczególną uwagę na te wyjątki.) Po drugie, powodem testowania z ekstremalnymi wartościami jest to, że program jest bardziej podatny na niepowodzenia z ekstremalnymi wartościami. Jeśli to nie zawiedzie skrajnie, testujesz coś innego. To skuteczna zasada. Z drugiej strony, jeśli NIE powiedzie się to przy ekstremalnej wartości, tester może zatrzymać się i zgłosić błąd lub tester może rozwiązać dalsze problemy, aby sprawdzić, czy program zawiedzie w ten sam sposób przy bardziej normalnych wartościach. Kto zajmuje się rozwiązywaniem problemów (tester lub programista), jest kwestią kultury korporacyjnej. Niektóre firmy budżetują na to czas testera, niektóre programiści, a niektórzy oczekują, że programiści naprawią problemy z przypadkowymi przypadkami, niezależnie od tego, czy są one uogólnione, czy też nie, aby rozwiązywanie problemów nie było istotne. Powszechne nieporozumienie - że testerzy tracą czas (zamiast maksymalizować wydajność) przez testowanie ekstremalnych wartości, to kolejny powód, dla którego „test, który nie jest przeznaczony do ujawnienia błędu, to strata czasu” jest odpowiednią wiadomością dla testerów. Jest to kontrapunkt dla zachęty ze strony niektórych programistów, aby (w efekcie) nigdy nie uruchamiać testów, które mogłyby zakwestionować program. Wiadomość jest uproszczona, ale cała dyskusja jest uproszczona.
Nawiasem mówiąc, „wartość informacyjna” nie może być jedynym systemem ustalania priorytetów. To nie jest moja zasada, kiedy projektuję zestawy testów jednostkowych. To nie jest moja zasada, gdy projektuję testy weryfikacyjne kompilacji (inaczej sprawdzanie poprawności). W obu tych przypadkach bardziej interesują mnie rodzaje zasięgu niż moc poszczególnych testów. Istnieją inne przypadki (np. Duże automatyczne testy, które są tanie w konfiguracji, uruchamianiu i monitorowaniu), w których moc poszczególnych testów jest po prostu nieistotna dla mojego projektu. Jestem pewien, że możesz wymyślić dodatkowe przykłady.
Ale jako ogólna zasada, gdybym mógł podać tylko jedną zasadę (np. Rozmowę z dyrektorem, którego głowa eksploduje, gdy próbuje przetworzyć więcej niż jedno zdanie), byłoby tak, że test niskiej wartości informacyjnej jest zwykle stratą czasu.