Redakcja
Przez lata twórcy kursu zbierali informacje zwrotne na temat slajdów i wykładów wideo. Stało się dla nich jasne, że istnieje potrzeba zaktualizowania wyglądu i stylu dla wszystkich materiałów BBST®. Zaczęli więc pracować nad nowym wyglądem serii BBST®, najpierw z nowym logo, dalej kontynuując pracę z innymi materiałami. Modernizacja kursu online, takiego jak BBST®, przypomina pracę architekta, który chce przeprojektować piękne wnętrze. Nie chodzi tylko o to, aby wnętrze wyglądało nowocześnie i estetycznie (choć jest to bardzo ważna część), ale także by było praktyczne. Cyklicznie udostępniane są więc nowe, poprawione wersje wykładów wideo BBST® Foundations.
Zakres zmian w wersji 3.0:
- Zmiana niektórych linków i zalecanych lektur
- Przeglądy i edycje niektórych treści slajdu, aby odzwierciedlić obecne podejście instruktażowe
- Drobne modyfikacje definicji, przykładów i innych stwierdzeń, zgodnie z sugestiami ulepszeń zebranymi przez Cem Kanera na przestrzeni lat
Pamiętaj, by rejestrując się na kurs skorzystać z naszego kodu rabatowego [5% zniżki] dostępnego dzięki temu linkowi bbst.courses [https://bbst.courses/?wpam_id=13]
Poniżej prezentujemy udostępnione dotychczas wykłady Cema Kanera.
Jeśli angielski nie jest Twoją mocną stroną, wypróbuj automatyczne tłumaczenie filmów. Czasami wychodzi komicznie, ale często można zrozumieć sens.
W ustawieniach wybierz "Napisy"
Teraz wybierz "Przetłumacz automatycznie"
Z listy języków wybierz "Polski".
BBST® Foundations 3.0 Wykład 1 - Wprowadzenie i podstawowe definicje.
W pierwszym wykładzie Cem Kaner przedstawia przegląd internetowych kursów Black Box Software Testing i wprowadza niektóre definicje, powszechnie używane w dziedzinie testowania. Cem Kaner mówi o niejednolitej terminologii związanej z testowaniem. Na przykład niektórzy ludzie myślą, że test nie jest testem, chyba że istnieje wyrocznia (oczekiwany wynik, który powie ci, czy test został zaliczony, czy nie). Testowanie bez oczekiwanego wyniku jest dla nich niekompetentne. Dla nich naturalne jest włączenie oczekiwanych wyników do definicji „testu”. Jednak inni testerzy uważają, że eksploracja produktu (w tym testowanie bez wiedzy o tym, co się stanie) jest całkiem przydatna. Inni uważają, że istnieje wiele możliwych wyroczni dla tego samego testu oraz, że doświadczony tester będzie koncentrował się na różnych potencjalnych błędach (rozważ różne wyrocznie) w różnym czasie. Dla tych ludzi wybór wyroczni jest czymś odrębnym od podstawowej idei testu.
W ostatniej części wykładu wideo dowiesz się więcej o quizach i egzaminach dostępnych podczas udziału w zajęciach online BBST® Foundations.
https://www.youtube.com/watch?v=8LqCal3yH2U
BBST® Foundations 3.0 Wykład 2 – Strategia
W drugim wykładzie BBST® Foundations, Cem Kaner opowiada o tym, dlaczego testerzy testują, czego próbują się nauczyć i jak mogą organizować swoją pracę, aby osiągnąć swoją misję. Mówi o misji testowania oraz o tym, jak różne cele prowadzą do różnych strategii testowania. Cem Kaner definiuje testowanie jako empiryczne poszukiwanie informacji o produkcie oraz o tym, że związane jest z jakością i realizowane jest w imieniu naszych interesariuszy. Kluczowi interesariusze często mają różne potrzeby. Testerzy muszą dostosować sposób testowania (co robią, jakich narzędzi używają, jak ustalają priorytety w czasie), aby sprostać tym potrzebom. Testerzy muszą również dostosować się do praktycznych realiów projektu, takich jak budżet, harmonogram, umiejętności personelu i dostępność odpowiednich narzędzi. Zasadniczo strategia testowania odzwierciedla to podwójne dostosowanie do potrzeb kluczowych interesariuszy i praktycznych realiów projektu.
Cytaty:
"Traktuję testy jako eksperymenty. Szukam danych. Oprócz przeprowadzania eksperymentów testerzy zbierają dane z innych źródeł, takich jak pomoc techniczna i konkurencyjne produkty. Pomagają nam one zrozumieć, co powinien robić produkt, abyśmy mogli zaprojektować eksperymentować skuteczniej, lepiej nadać sens naszym wynikom".
"Nie projektujesz eksperymentu, aby potwierdzić coś, co już wiesz. To bezcelowe. Zaprojektuj eksperyment, aby podważyć to, w co wierzysz. Projektuj eksperymenty, które mogą się nie powieść".
"Informacje - czego dowiadujemy się z naszych testów - niekoniecznie są błędami. Chcemy dowiedzieć się wszystkiego o jakości oprogramowania, które będzie przydatne dla naszych interesariuszy".
"Zestaw możliwych testów dowolnego nietrywialnego programu jest nieskończony. Nie możesz uruchomić ich wszystkich. Dlatego zadaniem projektanta jest stworzenie stosunkowo niewielkiego podzbioru tych testów, które ujawnią większość najbardziej znaczących błędów".
"Praca z różnymi technikami pomaga myśleć o programie na różne sposoby, co prowadzi do różnych błędów".
https://www.youtube.com/watch?v=ffJfFWQ4B8o
BBST® Foundations 3.0 Wykład 3 - Wyrocznie
W trzecim wykładzie Black Box Software Testing Course Foundations 3.0, Cem Kaner mówi o wyroczniach i o tym, jak są one wykorzystywane jako heurystyka, aby pomóc testerom określić, czy oprogramowanie przeszło pomyślnie testy.
Trzy wnioski z wykładu 3-ciego, o podstawach BBST®:
- Żaden test nie ma jednej prawdziwej lub pełnej wyroczni. Najlepsze, co możemy osiągnąć, to pewne zrozumienie.
- Możemy opisać proces podejmowania decyzji, gdzie program prawdopodobnie zdał lub nie zdał testu, jako wynik porównania i zidentyfikować kilka powszechnie używanych komparatorów. Proces zastosowany w tym porównaniu obejmuje ludzką ocenę.
- Warto zebrać wiele bardzo szczegółowych wyroczni w celu wsparcia automatyzacji testów.
Cytaty:
"Problem polega na tym, że kiedy używamy mechanizmu do sprawdzania poprawności wyniku testu, nie ma gwarancji, że będzie on poprawny. Zamiast tego, porównując wynik testu z wynikiem oczekiwanym, musimy dokonać oceny. A nasz osąd jest omylny".
"Każde narzędzie wspomagające podejmowanie decyzji, które czasami jest błędne, ale nadal przydatne, jest heurystyczne. Wszystkie wyrocznie są heurystykami. Są omylne, ale są przydatne".
"Błędem, który popełnia wielu testerów, jest traktowanie heurystyki tak, jakby były to reguły, a nie wytyczne".
"Aby ocenić wynik testu, warto pomyśleć o ryzyku lub konsekwencjach".
"Heurystyka spójności zależy od Twojej wiedzy. Często nie uzyskasz tej wiedzy z łatwego w użyciu źródła, takiego jak dobrze napisana specyfikacja, będziesz musiał ją zdobyć samodzielnie".
"Traktowanie wyroczni jako heurystyki daje nam większą swobodę myślenia o odpowiedziach częściowych. Pomyślmy o wynikach, które są podejrzane lub mało prawdopodobne, a nie koniecznie błędne".
https://www.youtube.com/watch?v=a3m1MtAFJJM
BBST® Foundations 3.0 - Wykład 4 - Podstawy i zakres programowania
Ta lekcja przedstawia informacje o podstawowej obsłudze i przechowywaniu danych, aby pomóc testerom myśleć o wielowymiarowym problemie pokrycia testowego w bardziej wyrafinowany sposób. Jej celem jest poprawienie umiejętności testerów w zakresie informatyki i zbudowanie pomostu pomiędzy materiałem omówionym do tej pory, a bardziej technicznymi zagadnieniami w lekcjach 5 i 6. Tematy zawarte w tym wykładzie będą również stanowić podstawę dla kursu testowanie domenowe.
Lekcja 4 wprowadza kilka tematów z podstaw informatyki:
- Jak komputery przechowują liczby i tekst? Co to znaczy przepełnić pamięć zarezerwowaną dla danych?
- Jak komputery wykonują arytmetykę? Podstawy binarnego przechowywania danych i obliczeń binarnych.
- Natura arytmetyki zmiennoprzecinkowej. Dlaczego obliczenia zmiennoprzecinkowe wprowadzają błędy? Dlaczego testerzy muszą być tego świadomi?
- Główne typy danych.
- Główne struktury kontrolne w programach. Przerwania i wyjątki oraz kilka przykładów, jak programy wpadają w kłopoty.
Ta lekcja pokazuje, że pokrycie jest wielowymiarowe. Wyjaśnia, jakie rodzaje pokrycia należy brać pod uwagę i jak można je ocenić.
Cytaty:
"Programiści, aby osiągnąć 100% pokrycia kodu, który piszą, prawdopodobnie znajdą o wiele więcej błędów niż programiści, którzy nie myślą o pokryciu, gdy wykonują swoje testy".
"Jako tester czarnej skrzynki, nigdy nie znalazłem narzędzi pomocnych w pokryciu strukturalnym i nie jestem pewien, czy prowadziły mnie one we właściwym kierunku. Istnieją lepsze rodzaje pokrycia, z którymi można pracować jako tester czarnej skrzynki."
"Kiedy mierzysz czyjąś wydajność, osoba mierzona robi rzeczy, które sprawiają, że wygląda lepiej według tej miary. "
"Mierzenie pokrycia kodu jest kiepskim sposobem, aby powiedzieć, jak blisko jesteś do końca pracy. Wywieranie presji na ludzi, aby zwiększali swoje pokrycie, jest kiepskim sposobem na dążenie do ukończenia projektu."
"Wiedza, że osiągnąłeś 90% pokrycia gałęzi nie mówi ci, jak dokładnie przetestowałeś lub jak dobry jest produkt. To niekoniecznie sprawia, że pokrycie gałęzi jest złą rzeczą. To tylko czyni go złym dla celów decydowania, jak bardzo twoje testy są kompletne."
"Testując czarnoskrzynkowo, łatwo jest przeoczyć pewne rzeczy. Istnieje mnóstwo raportów z pomiarów pokrycia pokazujących, że plan testowy projektu osiągnął tylko 35% pokrycia kodu. Kiedy zidentyfikujesz te 65%, które przeoczyłeś, możesz zaprojektować testy, aby wypełnić luki, które uważasz za ważne. Do tego właśnie służy pokrycie."
https://www.youtube.com/watch?v=Yd8PfKto-CQ
BBST® Foundations 3.0 - Wykład 5 - Niemożność przeprowadzenia kompletnych testów
"Czas potrzebny na wykonanie zadania związanego z testowaniem jest nieskończenie większy niż czas, który jest dostępny" - Cem Kaner, BBST Foundations Lecture 5
Ta lekcja bada złożoność określania, kiedy testowanie jest zakończone i dlaczego cel pełnego testowania jest nieosiągalny. Niektórzy ludzie przychodzą na kurs wierząc, że mogą osiągnąć pełne testowanie poprzez osiągnięcie kompletnego pokrycia strukturalnego. Ta lekcja pokazuje, jak błędny jest to pogląd.
Lekcja 5 - Wprowadzenie do lekcji
Dwie kluczowe definicje:
- Dwa testy są różne, jeśli jeden test ujawni błąd, który drugi test by przeoczył.
- Aby osiągnąć pełne testowanie, musisz uruchomić każdy test.
Dwa kluczowe przykłady:
- W przykładzie MASPAR, testerzy musieli przetestować wszystkie możliwe wejścia, aby znaleźć dwa błędy w funkcji.
- W przykładzie z przepełnieniem stosu Telenova, sprawdzenie wszystkich gałęzi i stwierdzeń oraz niezależnych podścieżek było niewystarczające. Aby odtworzyć błąd zabijający system, testerzy musieli stworzyć sekwencje tak długie i tak złożone, że niemożliwe byłoby znalezienie wszystkich takich błędów w laboratorium.
Jeden wniosek:
- Kompletne testowanie jest niemożliwe, a zatem całe testowanie wiąże się z kompromisami. Testowanie obejmuje wiele zadań, takich jak projektowanie i przeprowadzanie testów, pisanie efektywnych raportów błędów, dokumentowanie pomysłów na testy, tworzenie narzędzi testowych, itd. Ilość czasu potrzebna do wykonania tych wszystkich zadań jest nieskończenie większa niż czas, którym dysponują testerzy. Masz czas tylko na małą próbkę tej pracy, a czas, który poświęcisz na jedno zadanie, nie będzie już dostępny dla pozostałych. Nieelastyczne dyrektywy, takie jak "Musisz zapisać oczekiwany wynik dla każdego testu", są nierozsądne, ponieważ wymagają ogromnej ilości pracy nad jednym zadaniem testowym bez rozważenia, jakie inne zadania testowe pozostaną w wyniku takiego działania niewykonane.
https://www.youtube.com/watch?v=AXL40gqWM5Y
BBST® Foundations 3.0 - Wykład 6 – Pomiar
Ta lekcja omawia wyzwania miar w testowaniu oprogramowania i wprowadza temat metryk oprogramowania.
Dowiesz się o czterech kluczowych pojęciach:
- Pomiar: empiryczne, obiektywne przypisanie liczb do atrybutów obiektów lub zdarzeń zgodnie z regułą wywodzącą się z modelu lub teorii z zamiarem ich opisania.
- Trafność konstrukcyjna: podstawa przekonania, że dana miara rzeczywiście opisuje daną cechę.
- Miary zastępcze: miara zastępcza przypisuje liczby do atrybutów, ale bez korzyści płynących z modelu lub teorii, na której się opiera.
- Dysfunkcja pomiaru: ludzie optymalizują swoje zachowanie, aby poprawić wyniki, które otrzymują, gdy są mierzeni.
Lekcja przedstawia dwa przykłady związane z liczeniem błędów. Jednym z nich jest ryzyko użycia liczby błędów do mierzenia umiejętności testerów. Drugi to ryzyko użycia liczby błędów na tydzień jako miary postępu projektu, a w szczególności użycia tego w połączeniu z modelem statystycznym, który łatwo udowodnić, że jest całkowicie nieważny.
Cytaty:
"Pierwszą rzeczą, którą należy zrozumieć na temat mierzenia jest to, że nie chodzi o liczenie. Wiedza o tym, ile gałęzi pokryliśmy, ile testów przeprowadziliśmy czy ile błędów znaleźliśmy, nie odpowiada na pytania, na które chcemy uzyskać odpowiedź. Te pytania to pytania typu:
Jak dobry jest ten produkt? lub
Ile testów nam jeszcze zostało? lub
Jak kompetentny jest ten programista?".
"Używamy liczby błędów jako zastępstwo dla wszelkiego rodzaju miar. Jak dobry jest tester, jak dobry jest programista, jak blisko jest skończenia programu, jak dobry jest program, jak drogie będzie wsparcie techniczne i tak dalej."
"[...] jeśli firmy mierzą produktywność testerów poprzez liczenie ich raportów błędów, testerzy będą spędzać dużo czasu na raportowaniu dużej ilości błędów. To jest właśnie to, za co są nagradzani. Ale nie będą spędzać zbyt wiele czasu na działaniach, które nie zwiększają bezpośrednio liczby błędów."
"Gdybyśmy mierzyli wartość testera liczbą błędów, w końcu zmieniłby swoje testowanie, tak by poprawić swoje statystyki. W rezultacie, moi pracownicy nigdy nie znaleźliby kilku z najważniejszych błędów, które zgłosiliśmy, błędów, które albo zostały znalezione przez tego testera, albo przez innych testerów, którzy byli przez niego szkoleni lub inspirowani."
https://www.youtube.com/watch?v=GEt10KhoTfQ
