21 września 2019, 15:55
Aneks A Odpowiedzi na pytania
Rozdział 1
1. Czy w opisanym przykładzie powstania błędu roku 2000-ego programista popełnił jakiś błąd? Nie - o ile specyfikacja produktu nie stwierdzała, że produkt ma działać również po roku 2000-ym. Tester powinien szukać i znaleźć ten błąd. Zespół powinien podjąć decyzję, czy należy go naprawić.
2. Prawda czy falsz: to ważne, jakim słowem firma albo zespół nazywa problem w programie. Fałsz. To nie jest ważne, ale używane określenie odzwierciedla charakter zespołu testowego i jego podejście do znajdowania, raportowania i naprawiania problemów.
3. Dlaczego sprawdzenie tylko tego, że program działa tak jak powinien, nie jest wystarczające? Zwykle to tylko połowa zadania testowego. Użytkownicy nie zawsze postępują zgodnie z instrukcją i testerzy powinni sprawdzić, co się stanie kiedy użytkownik postąpi wbrew instrukcji. Poza tym, tester powinien podchodzić do przedmiotu testowania z nastawieniem „muszą to złamać”, inaczej trudniej będzie mu znajdować błędy.
4. O ile droższe jest naprawienie błędu znalezionego już po wypuszczeniu produktu niż błędu znalezionego na samym początku projektu? Od 10-u do 100-u i nawet więcej!
5. Jakie cele mają testerzy? Celem testowania jest znajdowanie błędów tak wcześnie jak to tylko możliwe i upewnienie się, że zostały naprawione.
6. Prawda czy fałsz: dobry fachowiec w dziedzinie testowania nieugięcie dąży do doskonałości. Fałsz. Dobry tester powinien wiedzieć, że doskonałość jest nieosiągalna i umieć rozpoznać, kiedy produkt jest dostatecznie dobry.
7. Podaj kilka przyczyn, dla któych największym źródłem błędów programu jest zwykle specyfikacja produktu.
Często specyfikacji nawet nie ma - pamiętajmy, że czego nie da się powiedzieć, nie da się też zrobić. Poza tym często, nawet jeśli specyfikacja istnieje, jest niedokładna, wciąż się zmienia i nie jest znana przez cały zespół projektowy.
Rozdział 2 1.Wymień kilka czynności, które powinno się wykonać zanim programiści zaczną pisać pierwsze linijki kodu programu. Zespół projektowy musi rozumieć wymagania klienta i opisać funkcje produktu w specyfikacji wymagań. Należy sporządzić dokładny harmonogram tak, by zespół zawsze wiedział, ile pracy już wykonano i ile jeszcze pozostało. Należy zaprojektować architekturę systemu i jego konstrukcję, a testerzy powinni zacząć planować swoją pracę.
2. Jakie są złe strony formalnej, zamkniętej specyfikacji wymagań? Kiedy sytuacja rynkowa zmienia się np. z powodu wypuszczenia produktu przez konkurencję lub zmieniających się potrzeb klienta, brakuje elastyczności by móc dostosować do niej powstające oprogramowanie.
3. Jaka jest najlpesza cecha modelu skokowego wytwarzania oprogramowania?
Jest prosty. Kropka.
4. Skąd wiadomo – przy użyciu metody prób i błędów – kiedy oprogramowanie jest gotowe do wypuszczenia? Brakuje w tej metodzie jednoznacznych kryteriów wyjściowych, dopóki ktoś - lub harmonogram - nie powie że pora już zakończyć.
5. Czemu model kaskadowy może być niewygodny? Tak samo jak łososiowi, trudno jest płynąć pod prąd. Każdy krok jest dyskretnym, oddzielnym procesem następującym po swoim poprzedniku. Jeśli doszło się do końca i odkryło, że coś powinno było być zrobione inaczej wcześniej, jest zbyt późno, by się cofnąć.
6. Dlaczego testerzy często wolą model spiralny od innych? Jest się zaangażowanym w proces wytwórczy bardzo wcześnie i ma się możność wczesnego znajdowania błędów, co zaoszczędza projektowiczas i pieniądze.
Rozdział 3 1.Pamiętając, że programu nie da się przetestować w całości, co należy wziąć pod uwagę podejmując decyzję czy można już zaprzestać testowania? Nie istnieje jedyna, poprawna odpowiedź, kiedy należy przestać testować. Każdy projekt jest inny. Oto przykłady informacji, którą trzeba wziąć pod uwagę przy podejmowaniu decyzji: czy nadal znajduje się dużo błędów? czy rodzaj i ilość wykonanych dotąd testów jest satysfakcjonująca? czy zgłoszone błędy zostały ocenione i czy podjęto decyzje, które mają być naprawione, a które nie? Czy dokonano walidacji produktu wobec wymagań użytkowników?
2. Uruchom Kalkulator w Windowsach. Napisz 5,000-5= (przecinek jest istotny). Przyjrzyj się wynikowi. Czy jest to błąd? Dlaczego? Otrzymana odpowedź wynosi 0, a nie 4995, jak można by się spodziewać. Dzieje się tak dlatego, że przecinek zostaje automatycznie zamieniony na znak dziesiętny. To, co zostało obliczone to 5.000 - 5 = 0, a nie 5000-5=4995. Aby zdecydować, czy jest to błąd, należy porównać to działanie ze specyfikacją produktu. Może jest tam napisane, że przecinki będą zmieniane na punkt dziesiętny. Należy również dokonać walidacji tej cechy wobec wymagań użytkowników. Trzeba stwierdzić, czy większośc użytkowników oczekuje takiego zachowania się progamu, czy też jest ono mylące.
3. Przy teście gry, np. symulatora lotu albo symulatora ruchu miejskiego, co należy przetestować w pierwszym rzędzie – trafność czy precyzję? Celem symulatora jest, aby grający znalazł się w szcztucznym środowisku, które naśladuje rzeczywiste wydarzenia. Pilotowanie w symulatorze lotu powinno dawać wrażenia zbliżone do pilotowania w rzeczywistości. Posługiwanie się się symulatorem miasta powinno odzwierciedlać sprawy, które dzieją się w rzeczywistym mieście. Najważniejsze jest więc to, jak trafnie symulator odddaje rzeczywistość. Czy samolot zachowuje się jak Boeing 757, czy jak awionetka? Czy kształty gmachów przypominają mistop, które symulator ma naśladować? Kiedy trafność jest osiągnięta, można pokusić się także o dokładność. Tak właśnie odbywał się rozwój komputerowych gier symulacyjnych w ciągu ostatnich lat.
4. Czy możne istnieć produkt informatyczny wysokiej jakości, ale o niskiej niezawodności? Jaki można podać przykład?
Tak, ale zależy to od oczekiwań klienta względem jakości. Niektórzy ludzie kupują sportowe samochody, o których uważa się, że są wysokiej jakości ze względu na przyśpieszenie, szybkość, styl i wykończenie. Często te właśnie samochody są notorycznie zawodne: często się psują, a ich naprawy są bardzo kosztowne. Dla właścicieli ta wysoka zawodność nie wpływa na ocenę przez nich jakości.
5. Czemu programów nie da się przetestować całkowicie? Każdy program - prócz najmniejszych i najprostszych - ma zbyt wiele możliwych wartości danych wejściowych, zbyt wiele rodzajów danych wyjściowych i zbyt wiele możliwych ścieżek przez program, by dało się przetestować je wszystkie. Ponadto specyfikacje oporgramowania często są subiektywne i dają się rozmaicie interpretować.
6. Jeśli testując program w poniedziałek znajduje się błąd co godzinę, jak często należy oczekiwać błędów we wtorek? Bierze się tu pod uwagę dwie zasady. Pierwsza - ilość błędów jeszcze pozostających w systemie jest wprost proporcjonalna do ilości błędów już znalezionych - oznacza, że nie zdarzy się, by przyszedłszy do pracy we wtorek nieoczekiwanie i cudownie odkryć, że program stał sie doskonały. Paradoks pastycydów głosi, że wykonując te same zadania testowe raz za razem, w końcu przestanie się przy ich pomocy znajdować nowe błędy, dopóki nie doda się nowych zadań testowych. Uwzględniwszy działanie obu zasad, należy się spodziewać niezmienionego lub nieznacznie zminiejszonego tempa znajdowania nowych błędów.
Rozdział 4 1.Czy można dokonać testu specyfikacji metodą „szklanej skrzynki”? Tak, o ile tester zaangażowany jest w sam proces tworzenia specyfikacji. W tym celu tester mógłby uczestniczyć w zebraniach grup użytkowników, badaniach użyteczności oraz zebraniach działu sprzedaży, aby zdobyć orientację w przebiegu procesu planowania funkcji produktu. Istnieje jednak ryzyko, że uczestnictwo w tych zebraniach ułatwi testerowi przyjęcie później podświadomie założenia, że specyfikacje są poprawne.
2. Podaj kilka przykładów standardów albo reguł dla oprogramowania pod Winowsami albo dla Macintosha. Na Macintoshu usunięte pliki trafiają do „Trash Can”, a w Windowsach - do „Recycle Bin”. Naciśnięcie F1 zawsze powoduje wyświetlenie „Pomocy”.
Menu „Plik” jest w Windowsach zawsze po lewej stronie paska funkcyjnego .
Wybranie „Pomoc, Na temat” powoduje wyświetlenie danych na temat praw autorskich, licencji i wersji programu.
Ctrl+X powoduje wycięcie, Crtl+C skopiowanie, a Ctrl+V wklejenie.
3. Wyjaśnij, jaki błąd znajduje się w powniższym zdaniu ze specyfikacji wymagań: Wybranie przez użytkownika opcji „Upakuj dane” spowoduje że program zagęści listę danych do najmniejeszej możliwej objętości przy użyciu metody macierzy Hoffmana. Użyte jest tutaj określenie „najmniejszy możliwy”. Nie da się go przetestować, ponieważ nie jest ani dokładne, ani wyrażone liczbowo. Specyfikacja powinna dokładnie określić, jaki poziom zagęszczenia jest wymagany.
Ponadto sformułowanie zawiera w sobie definicję sposobu rozwiązania, wyjaśnia jakim algorytmem posłuży się ta funkcja. Ta informacja nie powinna znajdować się w specyfikacji wymagań. Użytkownik nie jest zainteresowany tym, w jaki sposób odbywa się zagęszczenie, tylko tym że w ogóle się odbywa.
4. Wyjaśnij, czemu testera powinno zaniepokoić poniższe zdanie ze specyfikacji wymagań: Oprogramowanie pozwoli na 100 milionów jednoczesnych połączeń, chociaż zwykle nie będzie stosowanych więcej niż 1 milion połączeń. Łatwość testowania. Nie ma znaczenia, że typowe użycie wynosi 1 milion połączeń - jeśli specyfikacja określa, że 100 milionów ma być możliwe, trzeba będzie przetestować 100 milionów. Tester będzie albo musiał znaleźć sposób przetestowania tak wielkiej liczby połączeń, albo skłonić autora specyfikacji do tego, by zmniejszył maksymalną liczbę połączeń tak, by była bliższa ilości typowej.
Rozdział 5 1.Prawda czy fałsz: czy da się wykonywać dynamiczne testowanie metodami czarnej skrzynki bez specyfikacji produktu albo specyfikacji wymagań?
Prawda. Technika ta nazywa się testowaniem eksploracyjnym, co polega w gruncie rzeczy na tym, że jako specyfikację stosuje się sam program. Nie jest to doskonała metoda, ale w krytycznej sytuacji może działać całkiem nieźle. Największym ryzykiem jest to, że nie odkryje się brakujących funkcji.
2. Kiedy testuje się zdolność programu do robienia wydruków, jakie ogólne, negatywne zadania testowe są właściwe? Można spróbować dokonać wydruku kiedy w drukarce nie ma papieru albo kiedy papier się pogniótł. Można też drukarkę wyłączyć, odłączyć od źródła prądu albo odłączyć kabel między komputerem i drukarką. Można spróbować wydruku przy niskim poziomie farby, lub nawet po zupełnym wyjęciu kartusza z farbą. Żeby znaleźć wszystkie możliwości, można poszukać w podręczniku drukarki wszelkich opisanych błędnych sytuacji i usiłować je wszystkie stworzyć lub zasymulować.
3. Wystartuj Notatnik Windows i wybierz funkcję Drukuj z menu Plik. Pojawia się wtedy okno dialogowe pokazane na rysunku 5.12. Jakie warunki brzegowe istnieją dla funkcji Zakres w dolnym, lewym rogu okna? Kiedy wybierze się opcję Strony, pola Od i Do są aktywne. Narzucającymi się warunkami brzegowymi będą wartości 0 i 99999, największa i najmniejsza wartość, którą daje się wprowadzić do tych pól. Nie będzie od rzeczy przetestować również wewnętrzne warunki brzegowe takie jak 254, 255, 256 oraz 1023, 1024 i 1025. Istnieje jeszcze inna wewnętrzna granica. Spróbujmy zlecić wydrukowanie stron 1- 8 z 6-stronicowego dokumentu. Zwróćmy uwagę, że w tym wypadku oprogramowanie musi zaprzestać drukowania na stronie 6-ej ponieważ brak jest danych, a nie dlatego, że otrzymało taką komendę. Zastanówmy się nad innymi możliwymi warunkami tego typu.
4.Mamy pole do wprowadzania 10-cyfrowego kodu pocztowego, jak na rysunku 5.13. Jakie klasy równoważności można zastosować do jego testowania? − Poprawne 5-cyfrowe kody. Poprawny oznacza że składa się on z cyfr, a nie że jest to autentyczny kod - chociaż to mogłaby być inna klasa równoważności.
− Poprawne 9-cyfrowe (9 cyfr i myślnik) kody.
− Krótkie 5-cyfrowe.
− Krótkie 9-cyfrowe.
− Długie 5-cyfrowe. Na przykład 8 cyfr bez myślnika. Hmm, czy to nie jest ta sama klasa co krótkie 9-cyfrowe?
− Długie 9-cyfrowe. Może nie dać się wpisać więcej niż 9 cyfr i myślnika, ale należy spróbować.
− Myślnik z złym miejscu.
− Więcej niż jeden myślnik.
− Znaki nie będące ani cyframi, ani myślnikiem.
5.Prawda czy fałsz: przejście wszystkich stanów programu gwarantuje również, że przeszło się wszystkie przejścia między nimi. Fałsz. Wyobraźmy sobie odwiedzenie 50 miast w całym kraju. Można zaplanować trasę tak, żeby prowadziła przez każde miasto, ale niemożliwe jest przejechanie wszystkich dróg łączących te miasta, bo to oznaczałoby przejechanie wszystkich dróg w całym kraju.
6.Istnieje wiele sposobów rysowania diagramów przejścia stanów, ale każdy z nich pokazuje trzy rzeczy. Jakie? − Każdy stan w którym może znaleźć się oprogramowanie.
− Dane wejściowe lub warunki, powodujące przejście z jednego stanu do kolejnego.
− Warunki, zmienne lub dane wyjściowe, które powstają kiedy wchodzi się lub wychodzi ze stanu.
7.Podaj niektóre z wartości zmiennych w stanie początkowym Kalkulatora Windowsów. Wstępnie wyświetlona wartość i wewnętrzna zmienna zawierająca wynik cząstkowy ustawione są na zero. Rejestry pamięci (przyciski MC, MR, MS i M+) są wyzerowane. Schowek systemowy (tam, gdzie składuje się dane podczas wycianania, kopiowania i wklejania) jest niezmieniony.
Inną zmienną charakteryzującą stan początkowy jest lokalizacja Kalkulatora na ekranie. Jeśli uruchomić jednocześnie kilka kopii Kalkulatora, łatwo zauważyć, że są położone na ekranie w różnych miejscach (przynajmniej w Windows 95/98). Można wykonac ćwiczenie w testowaniu eksploracyjnym i spróbować domyślić się, co kieruje położeniem Kalkulatora na ekranie.
8.Co robi się z programem, chcąc odkryć błędy w synchronizacji w czasie (wyścig)?
Należy wykonywać wiele rzeczy na raz. Mogą one mieć ze sobą coś wspólnego, jak na przykład jednoczesne pisanie z tej samej aplikacji na dwóch różnych drukarkach. Mogą być również niezależne, jak naciskanie klawiszy w czasie wykonywania przez program obliczeń. W obu wypadkach chce się wywołać sytuację, w której oprogramowanie „ściga się” samo ze sobą w czasie wykonywania funkcji.
9.Prawda czy fałsz: jednoczesne wykonywanie testowania na obciążenie i na przeciążenie jest niedopuszczalne. Fałsz. Nie ma „testów poniżej pasa”. Celem pracy testera jest znajdować błędy.
Rozdział 6 1.Wymień kilka korzyści wynikających ze stosowania statycznego testowania metodami szklanej skrzynki. Stayczne testowanie metodami szklanej skrzynki pozwala znajdować błędy we wcześniejszych fazach cyklu wytwarzania, dzięki czemu ich szukanie jest mniej czasochłonne, a naprawy - mniej kosztowne. Testerzy wykonujący te testy nabierają doświadczenia w tym, jak oprogramownaie działa, jakie ma słabsze obszery i ryzyka, a także mogą stworzyć lepszą, roboczą współpracę z programistami. O statusie prjektu można poinformować wszystkich członków zespołu uczestniczących w testowaniau.
2. Prawda czy fałsz: statyczne testowanie metodami szklanej skrzynki pozwala znaleźć zarówno brakujące elementy jak i problemy. Prawda. Można się o to spierać, ale zapewne brakujące elementy są ważniejsze niż inne problemy, a statyczne testowanie szklanej skrzynki pozwala na ich wczesną identyfikację. Kiedy kontroluje się kod wobec standradów oraz starannie analizuje go w trakcie formalnych przeglądów, znalezienie brakujących elementów jest bardzo prawdopodobne.
3. Jakie są kluczowe elementy formalnych przeglądów? Proces. Ścisłe stosowanie się do opisanego procesu jest tym, co różni formalny przegląd och dwóch kumpli, którzy patrzą sobie nawzajem na kod.
4. Oprócz poziomu formalizmu, jaka jest zasadnicza różnica między inspekcjami a innymi rodzajami przeglądów?
Główna różnica: podczas inspekcji kto inny niż autor prezentuje objekt podlegający inspekcji. Zmusza to jeszcze jedną osobę do starannego zrozumienia kodu lub dokumentacji, podlegających inspekcji. Jest to o wiele bardziej skuteczne niż zwyczajne szukanie błędów.
5. Jeśli programista został poinformowany, że wolno mu używać nazw zmiennych nie dłuższych niż osiem znaków i wszystkie muszą zaczynać się dużą literą, czy mamy do czynienia ze standardem czy z regułą? Byłby to standard. Gdyby mu zezwolono na używanie nie mniej niż ośmiu znaków, ale zlecane byłyby krótkie nazwy, byłaby to reguła.
6. Czy listę kontrolną do przeglądów kodu opisaną w tym rozdziale powinno się przyjąć jako standard waszego zespołu do weryfikacji kodu? Nie! Podano ją tylko jako ogólny przykład. Jest w niej kilka dobrych zadań testowych, które warto wziąć pod uwagę przy testowaniu kodu, ale przed wybraniem standardu do własnego użytku należałoby zbadać i poczytać również inne standardy.
Rozdział 7 1.W jaki sposób znajomość wewnętrznych mechanizmów działania programu wpływa na to, jak i co należy przetestować? Testując tylko metodami czarnej skrzynki, nie będzie się wiedziało, czy zadania testowe dostatecznie pokrywają wszystkie części oprogramowania i czy niektóre zadania nie są zbyteczne. Doświadczony tester może zaprojektować dosyć skuteczny zestaw zadań testowych tylko metodami czarnej skrzynki, ale nie będzie wiedzieć na pewno jak dobry jest ten zestaw bez niejakiego udziału metod szklanej skrzynki.
2. Czy jest różnica między dynamicznym testowaniem metodami szklanej skrzynki, a lokalizowaniem i usuwaniem błędów? Oba te procesy zachodzą na siebie, lecz celem testowania metodami szklanej skrzynki jest znajdowanie błędów, zaś celem usuwania błędów jest ich naprawa. Część wspólna to izolowanie i lokalizacja - poszukiwanie gdzie dokładnie i dlaczego błąd się pojawia.
3. Jakie są dwa główne powody, dla których testowanie jest niemal niewykonalne w modelu skokowym wytwarzania oprogramowania? Jak można im zaradzić?
Kiedy oprogramowanie trafia w ręce testera od razu w jednym, wielkim kawałku, jest trudne lub wręcz niemożliwe stwierdzenie, dlaczego następuje jakaś awaria - jest to jak szukanie igły w stogu siana. Po drugie, błędów jest zwykle tak wiele, że jedne mogą przesłaniać drugie. Łapie się jeden błęd i krzyczy „mam cie!”, by w chwilę poóźniej odkryć, że program nadal zawodzi. Motodyczna integracja i testowanie modułów pozwala znajdować i naprawiać błędy zanim dobrze się ukryją albo spiętrzą jedne na drugich.
4. Prawda czy fałsz: jeśli projektowi brakuje czasu, można przeskoczyć testowanie modułów (jednostkowe) i przystąpić od razu do tesowania integracyjnego. Fałsz! O ile oczywiście produkt nie składa się z jednego tylko modułu.
5. Jaka jest różnica między namiastką testową a sterownikiem testowym? Namiastkę testową stosuje sie przy integracji i testowaniu odgórnym. Zastępuje ona nie istniejący jeszcze moduł niższego poziomu. Dla wyższego poziomu namiastka wygląda i zachowuje się tak jak prawdziwy modul niższego rzędu.
Sterownik jest odwrotnościa namiastki i stosuje się go przy integracji oddolnej. Jest to kod testowy, który zastępuje oryginalny kod wyższego rzędu aby skuteczniej wypróbować moduły niższego rzędu.
6. Prawda czy fałsz: zawsze należy najpierw skonstruować zadania testowe metodami czarnej skrzynki. Prawda. Najpierw projektuje się zadania testowe na podstawie przypuszczalnego zachowania się programu. Następnie stosuje się metody szklanej skrzynki aby sprawdzić i udoskonalić te zadania testowe.
7. Która jest najlepsza spośród trzech opisanych w tym rozdziale metod pomiaru pokrycia? Dlaczego? Pokrycie warunków logicznych jest najlepsze, ponieważ zawiera w sobie pokrycie rozgałęzień i pokrycie instrukcji. Wiemy, że wszystkie warunki zawierające logikę decyzyjną - takie jak instrukcje if - then, zostają zweryfikowane, jak również biegnące od nich rozgałęzienia i wszystkie linie kody źródłowego.
Jaka jest najpoważniejsza trudność testowania metodami szklanej skrzynki, zarówno statycznego jak i dynamicznego?
Łatwo stać się stronniczym. Spojrzy się na kod i powie „Aha, widzę, tego nie trzeba testować, kod napisany jest w tym miejscu poprawnie.” W rzeczywistości, powtarzamy być może ten sam błąd, co programista i eliminujemy niezbędne zadania testowe. Ostrożnie!
Rozdział 8 1.Jaka jest różnica między komponentem a urządzeniem peryferyjnym? Mówiąc ogólnie, komponent to sprzęt w jakimś sensie znajdujący się wewnątrz PC. Urządzenie peryferyjne zaś jest poza PC. Ta granica może jednak dla pewnych rodzajów sprzętu być bardzo niewyraźna.
2.Jak odróznić, czy błąd jest ogólnym problemem, czy też wyłącznie błędem konfiuracji? Należy powtórzyć te same kroki, które spowodowały awarię, na różnych konfiguracjach. Jeśli awaria nie występuje na wszystkich, mamy zapewne do czynienia z błędem konfiguracji. Jeśli awaria pojawia sie niezależnioe od konfiguracji, mamy zapewne do czynienia z błędem ogólnym. Nie bądźmy jednak pochopni. Może się zdarzyć błąd konfiguracji występujący w całej klasie równoważności. Na przykład może się zdarzyć, że jakiś błąd pojawia się tylko na drukarkach laserowych, ale nie na na atramentowych.
3.Jak można zagwarantować, że program nigdy nie będzie miał błędów konfiguracji? To takie podstępne pytanie. Musiałoby sie wysyłać oprogramowanie i sprzęt razem jako jeden produkt, oprogramowanie działałoby tylko na tym sprzęcie, a sprzęt musiałby byc dokładnie zapieczętowany, bez żadnego interfejsu do świata zewnętrznego.
4.Prawda czy fałsz: klonowana karta dzwiękowa nie musi być poddana testowaniu konfiguracji. To zależy. Klonowany sprzęt ma zwykle identyczną konstrukcję jak oryginał, tylko inną nazwę i inną obudowę. Zwykle są funkcjonalnie w 100% idnetyczne, ale czasem programy obsługi mogą się różnić i mieć mniejszy lub większty zakres dostępnych funkcji.
5.Oprócz wieku oraz popularności, jakie inne kryteria można zastosować jako podstawę podziału na klasy równoważności? Na przykład rejon albo kraj pochodzenia, gdyż niekiedy sprzęt - taki jak odtwarzacze CD - działa tylko z z płytami kompaktowymi z tego samego rejonu. Inna możliwość to rodzaj konsumenta albo branża. Niekiedy sprzęt jest charakterystyczny tylko dla jednej branży. Mogą być jeszcze inne kryteria, zelżnie od rodzaju oprogramowania.
6. Czy dopuszczalne jest wypuszczenie programu mającego błędy konfiguracji? Tak. Nigdy nie da się naprawić wszystkich błędów. Jak zawsze w testowaniu, decyzja zawiera w sobie element ryzyka. Zespół musi zdecydować, co jest się w stanie naprawić, a co nie. Pozostawienie jakiegoś rzadkiego błędu, który ujawnia się tylko na rzadko spotykanym sprzęcie, nie będzie trudne. Zwykle jednak decyzje tego typu nie będą równie proste.
Rozdział 9 1.Prawda czy fałsz: każde oprogramowanie musi być w jakimś stopniu poddane testownaiu kompatybilności. Fałsz. Bywają rzadko spotykane typy oprogramowania, które występuje tylko w jednej wersji i z niczym nie ma żadnej interakcji. Dla pozostałych 99 procent programów testowanie kompatybilności będzie jednak koniecznością.
2. Prawda czy fałsz: Kompatybilność jest cechą produktu, która może być spełniona w różnym stopniu. Prawda. Poziom kompatybilności produktu zależy od potrzeb użytkowników. Jest zwykle zupełnie dopuszczalne, by np. program do przetwarzania tekstu nie był kompatybilny z formatem plików programu konkurencyjnego, lub żeby nowy syystem opoeracyjny nie pozwalał na korzystanie z jakiegoś rodzaju programów rozrywkowych. Tester powinien ułatwic podejmowanie tego typu decyzji, dotarczając dane na temat tego, ile pracy wymagłaby weryfikacja danego typu kompatybilności.
3. Jak należy podejść do zadania przetestowania kompatybilności wszystkich formatów plików dla danego produktu? Najpierw trzeba zbadać, czy format plików używanych przez program zgodny jest z jakimś istniejącym standardem. Jeśli tak, testuje się na zgodność ze standardem. Należy też wyróżnić klasy równoważności dla możliwych programów, które będą pisały lub czytały pliki testowanego programu. Przygotowuje się dokumenty testowe, zawierające reprezentatywne próbki typów danych, które testowany program będzie zapisywał i ładował. Musi się przetestować przesyłanie tych plików między testowanym programem oraz innymi programami.
4. W jaki sposób testuje się kompatybilność wprzód (z kolejnymi, następnymi wersjami programu)?
Testowanie kompatybilności wprzód nie jest łatwe - nie da się przecież przetestować czegoś, co jeszcze nie istnieje! Rozwiązaniem jest testowanie według tak dokładnej specyfikacji, że może ona styać się standardem. Ten standard wówczas zapewni, że to co testujemy będzie kompatybilne wprzód.
Rozdział 10 1.Jaka jest różnica między tłumaczeniem a ulokalnieniem? Tłumaczenie dotyczy wyłącznie aspektów językowych - tłumaczenia słów. Ulokalnienie bierze pod uwagę obyczaje, konwencje i kulturę regionu, dla którego dokonuje się ulokalnienia programu.
2. Czy musi się znać język, aby móc testować produkt poddany ulokalnieniu? Nie, ale ktoś w zespole testowym powinien posługiwać się płynnie tym językiem. Można testować np. części programu, które nie zależą od języka, ale znajomość języka pozwala pracować skuteczniej.
3. Co to jest rozszerzanie tekstu i jakie błedy powoduje? Rozszerzenie tekstu występuje przy tłumaczeniu z jednego języka na inny. Długość ciągów znaków może wówczas wzrosnąć nawet o 100 procent i więcej. Teksty w oknach dialogowych, przyciskach itd, które dotąd pasowały do ich wielkości, przestają pasować. Część tekstu może zostać odcięta lub przesunięta do następnej linii. Może nawet zdarzyć się awaria programu spowodowana tym, że dłuższy tekst nie mieści się w przeznaczonej dla niego pamięci i niszczy inne dane.
4. Podaj kilka dziedzin, w których rozszerzony zbór znaków może spowodować kłopoty. Kolejnośc posortowanych w kolejności alfabetycznej słów i zwrotów, konwersja z małych na duże litery i odwrotnie, i inne ogólne kwestie dotyczące wyświetlanych tesktów i wydruków.
5. Dlaczego tekstowe ciągi znaków należy trzymać poza kodem? Ulokalnianie jest o wiele łatwiejsze, jeśli osoba dokonująca przekładu musi przerobić tylko plik tekstowy, a nie kod programu. Ułatwia to również pracę testową, ponieważ wiadomo, że kod ulokalnionej wersji jest identyczny z kodem wersji oryginalnej.
6. Wymień kilka rodzajów formatów danych, które mogą się różnić w różnych ulokalnionych wersjach programu.
Miary takie jak funty, cale i galony. Czas w formacie 24 i 12-godzinnym. Oznaczenie waluty i wiele, wiele innych.
Rozdział 11 1.Pawda czy fałsz: każdy rodzaj oprogramowania ma interfejs użytkownika i dlatego musi być przetestowany pod kątem użyteczności. Prawda. W końcu nawet najgłębiej wbudowane oprogramownaie ma jakąś interakcję z użytkownikiem. Pamiętajmy, że interfejs użytkownika może być tak prosty jak przełącznik i żaróweczka lub tak skomplikowany jak symulator lotów. Nawet jeśli program jest tylko jednym modułem kodu, ma interfejs - w postaci zmiennych i parametrów - dostępny programiście.
2. Czy konstrukcja interfejsu użytkowanika jest nauką czy sztuką? Po trosze jedno i drugie. Wiele interfejsów użytkownika, które przetestowano starannie w laboratoriach i poddano rygorystycznej analizie, okazała się kompletmym niewypałem na rynku.
3. Jeśli nie istnieją jednoznaczne kryteria poprawności interfejsu użytkownika, w jaki sposób można go testować? Tester oprogramowania powinien sprawdzić, czy interfejs spełnia siedem ważnych kryteriów: że jest zgodny ze stadardami, że jest intuicyjny, spójny, elastyczny, wygodnmy, poprawny i użyteczny.
4. Wymień znane ci przykłady źle zaprojektowanego albo niespójnego interfejsu użytkkowanika. Odpowiedź będzie zależała od rodzaju produktu, który się weźmie pod uwagę, ale zastanówmy się nad tym przykładem: czy da się nastawić godzinę na radio samochodowycm bez użycia podręcznika?
Niektóre okna dialogowe Windows mają przycisk OK po lewej i przycisk Anuluj po prawej, podczas gdy inne mają Anuluj po lewej i OK po prawej. Kto się przyzwyczai do jednego układu i kliknie nie patrząc, może zmarnować swoja wcześniejszą pracę!
Czy nie zdarzyło się każdemu niechcący rozłączyć rozmowę telefoniczną, nacisnąwszy omyłkowo niewłaściwy klawisz telefonu przy próbie np. połącznie innej rozmowy?
5. Jakie cztery rodzaje inwalidztwa wpływają na dostępność oprogramowania? Wzrokowe, słuchowe, ruchowe i ograniczenia poznawcze.
6. Na co należy przede wszystkim zwrócić uwagę przy testowaniu oprogramowania pod kątem dostępności dla niepełnosprawnych? Na to, co dotyczy klawiatury, myszy, dźwięków i wyświetlania. Jeśli oprogramowanie zostało napisane na platformę, która wspiera dostępność dla niepełnosprawnych, testowanie będzie łątwiejsze niż wówczas, gdy dostępność trzeba było zaprogramować w całości w aplikacji.
Rozdział 12 1.Uruchom program Paint w Windows (zobacz rysunek 12.4) i poszukaj przykładów dokumnetacji którą należałoby przetestować. Co można znaleźć? Oto kilka przykładów: istnieje pomoc w formie małych okienek z opisami, pojawiających się, kiedy kursor przesuwa się nad narzędziem. Wybranie „Na temat” z menu „Pomoc” wyświetla okno z informacją na temat praw autorskich i licencji. Naciśnięcie F1 wsytartowuje interakcyjny system pomocy, gdzie można czytać podręcznik, wybierać z indeksu albo szukać określonych słów. Jest również jeszcze inna funkcja pomocy - na przykład wybrawszy „Edytuj kolory” z menu „Kolory”, a potem kliknąwszy na ikonę „?” na pasku tytułowym, a w końcu kliknąwszy na jeden z kolorów, orzymuje się pomoc na temat wybierania i tworzenia kolorów.
2.Indeks pomocy w programie Paint w Windows zawiera ponad 200 haseł począwszy od dodać własne kolory1, skończywszy na zmiana wielkości obrazu. Czy należy sprawdzić, czy każde z haseł indeksu porwadzi do właściwego rozdziału? Jak należałoby postąpić w przypadku 10000 haseł w indeksie? Każde zadanie testowe jest problemem ryzykownej decyzji. Jeśli ma się czas, by skontrolować wszystkie hasła, można to zrobić. Jeśli nie zdąży się przetestować wszystkich, trzeba będzie sporządzić klasy równoważności, o których się sądzi, że trzeba je przetestować. Można oprzeć swoje decyzje na uzyskanej od programistów inforamcji o tym, jak działa system indeksacji pomocy. Można porozmawiac z autorem tekstów i dowiedzieć się, jak hasła zostały wygenerowane. Można wreszcie wypróbować po jednym haśle na każdą literę, albo 2 hasła, albo 4 itd. Można nawet zaczekać, aż przeczyta się rozdział 14-y „Automatyczne testowanie i narzędzia do testowania”.
3.Prawda czy fałsz: testowanie komunikatów o błędach jest częścią testowania dokumentacji.
1 Po angielsku adding custom colors jest na litere “a” (przy tłumacza).
Prawda, ale komunikaty o błędach to coś więcej niż dokumentacja. Zawartość komunikatu trzeba przetestować tak jak dokument, ale wymuszenie pojawienia się komunikatu i kontrola, czy właściwy komunikat został wyświetlony, jest testowaniem kodu.
4. Jakie są trzy podstawowe powody, dla których których test dokumentacji przyczynia się do poprawy ogólnej jakości produktu informatycznego? Ulepszona użyteczność, wyższa niezawodność i mniejsze koszty serwisu.
Rozdział 13 1.Jakie podstawowe elementy strony WWW można łatwo przetestować technikami czarnej skrzynki? Statyczne elementy, podobne do multimedialnego oprogramowania na dysku CD-ROM: tekst, grafikę i dołączneia.
2. Co to jest testowanie metodami „szarej skrzynki”? Testowanie metodami szarej skrzynki ma miejsce wtedy, kiedy zerka się na kod i używa uzyskaną w ten sposób informację, aby skuteczniej testować. Różni się to od testowania metodami szklanej skrzynki tym, że zammiast skomplikowanego, wymagającego kompilacji języka, takiego jak C++, mamy do czynienia z prostym kodem skryptowym. Również nie bada się kodu aż tak szczegółowo, jak przy testowaniu metodami szklanej skrzynki.
3. Dlaczego możliwe jest zastosowanie metod szarej skrzynki do testowania witryn WWW? Ponieważ większość stron WWW zbudowana jest głównie z łatwodostępnego kodu HTML, języka znaczników, a nie z programu.
4. Dlaczego program do wyszukiwania błędów pisowni nie gwarantuje poprawnej pisowni na stronie WWW? Program jest w stanie znaleźć błędy tylko w zwyklym tekście, a nie - w graficznym tekście albo w tekście generowanym dynamicznie.
5. Wymień parę ważnych zagadnień, które trzeba wziąć pod uwagę przy testowaniu konfiguracji i kompatybilności witryn WWW.
Platforma sprzętowa, system operacyjny, przeglądarka WWW, wtyczki programowe, opcje i ustawienia przeglądarki, rozdzielczość wideo, głębia kolorów, wielkośc tekstu i szybkość modemu.
6.Które z opisanych przez Jakoba Nielsena 10 głównych błędów witryn WWW spowodowałyby błędy kompatybilności i konfiguracji? Niepowściągliwe posługiwanie się najnowszą technologią. Istniejący sprzęt i oprogramowanie „nie lubią”, kiedy puszcać na nich po raz pierwszy najnowsze technologie. Nie było wprawdzie o tym mowy wprost w rozdziale, ale przypusczalnie dało się odpowiedź wywieść z podanych informacji.
Rozdział 14 1.Wymień kilka korzyści stosowania narzędzi do testowania i automatyzacji testowania. Mogą skrócić czas, jaki zajmuje wykonywanie zadań testowych. Mogą uczynić testerów skuteczniejszymi, dając im więcej czasu na planowanie testowania i wytwarzanie zadań testowych. Są bezbłędne, precyzyjne i niegdy sie nie męczą.
2.Jakie są możliwe wady automatyzacji i jakie możliwe trudności trzeba wziąć pod uwagę przy podejmowaniu decyzji o zastosowaniu narzędzi i o automatyzacji? Ponieważ oprogramowanie ulega zmianom, zmieniać muszą się także narzędzia. Istnieje ryzyko wpadnięcia w pułapkę, że najwięcej czasu trzeba w końcu poświęcić na konstruowanie narzędzi i automatyzacji, zaniedbując samo testowanie. Łatwo też zaufać automatyzacji w zbyt dużym stopniu. Nie da się niczym zastąpić testowania samemu.
3.Jaka jest różnica między narzędziem a automatyzacją? Narzędzie testowe pomaga testować, ulatwiając wykonanie zadania, które wcześniej trzeba było wykonywać ręcznie. Automatyzacja to również narzędzie, które potrafi działać bez ludzkiej interwencji. Wyobraźmy sobie piłę motorową i młotek, które same budują dom, kiedy cieśla śpi.
4.Jakie są podobieństwa i różnice między analizatorem a generatorem zaburzeń? Oba te typy narzędzi umożliwiają wgląd w oprogramowanie w miejscach normalnie niedostępnych dla użytkownika. Analizatory są nieintruzyjne i pozwalają tylko zobaczyć to, co sie odbywa. Generator zaburzeń jest intruzyjny - pozwala nie tylko obserwować, ale także sterować przebiegiem wydarzeń. Można przy jego pomocy wykonywać zadania testowe, których normalnie nie dałoby się wykonać metodami dostępnymi zwykłemu użytkownikowi.
5.Prawda czy fałsz: narzędzie intruzyjne jest najlepsze, ponieważ działa najbliżej testowanego oprogramowania. Fałsz. Intruzyjnośc lub nieintruzyjność nie czyni narzędzia dobrym lub złym. Rodzaj testowanego oprogramowania i rodzaj zadania testowego, które ma się wykonać, określają rodzaj narzędzia, które pasuje najlepiej.
6.Jaki jest jeden z najprostszych, ale skutecznych, sposobów automatyzacji testowania? Nagrywanie i odgrywanie czynności klawiatury i myszy jest najprostszym typem automatyzacji, która skutecznie znajduje błędy.
7.Wymień kilka funcji, które warto dodać do rozwiązania opisanego jako odpowiedź na porzednie pytanie, aby uczynić automatyczne testy jeszcze skuteczniejszymi. Proste programowanie czynności programu testującego zamiast ich nagrywania. Zdolność robienia przerw oraz oczekiwania na reakcję programu na dane wejściowe. Niektóre typy prostej weryfikacji, pozwalającej stwierdzić, czy wynik testu był poprawny, czy nie.
8. Na czym polega wyższość „bystrych małp” nad „głupimi małpami” i nad nagranymi automatycznie makroprogramami? „Bystre małpy” znają tabelę stanów oprogramowania, tak że wiedzą, gdzie się znajdują i co w tej sytuacji można zrobić.
Rozdział 15 1.Opisz paradoks pestycydów i w jaki sposób zaangażowanie nowych osób w testowanie może mu zapobiec. Paradoks pestycydów (opisany w rozdziale 3-im „Testowanie oprogramowania w rzeczywistości”) jest to sytuacja, która może nastąpić, kiedy testuje się oprogramowanie wciąż przy użyciu tych samych zadań testowych lub tych samych testerów. Wydaje się, jakby oprogramowanie stopniowo wytwarzało sobie odporność na te testy, ponieważ nie znajdują one już żadnych nowych błędów. Jeśli zmienić zadania testowe lub zaangażować nowych testerów, znów zacznie się znajdować nowe błędy. Oczywiście, błędy były tam przez cały czas, a nowe zadania testowe tylko zdołały je ujawnić.
2. Jakie są możliwe korzyści programu testowania beta? Wielu nowych ludzi zaczyna posługiwać się programem. Jest to także dobra metoda znajdowania błędów kompatybilności i konfiguracji.
3. Z czym należy zachować ostrożność planując testowanie beta? Test beta nie zastąpi zorganizowango, metodycznego, planowego testowania - nie jest skuteczny do znajdowania wszystkich typów błędów. Musi się wiedzieć, kim są testerzy beta jeśli chodzi o ich doświadczenie, sprzęt i motywację, aby móc mieć realistyczne oczekiwania, czego po nich można się spodziewać.
4. Jeśli pracuje się w małym przedsiębiorstwie robiącym oprogramowanie, czy warto przekazać test konfiguracji innej fimie? Koszty bieżące i potrzebne inwestycje, aby zaopatrzyć laboratorium do testowania konfiguracji są bardzo wysokie i nieosiągalne dla małej firmy lub projektu.
Rozdział 16 1.Po co jest plan testowania? Parafrazując definicję ANSI/IEEE, celem planu testowania jest określenie zakresu, metodyki, środków i harmonogramu testowania oraz zidentyfikowanie przedmiotów testowania, funkcji, któee będzie się testować, czynności do wykonania, osób za nie odpowiedzialnych oraz ryzyka związanego z tym planem. Mówiąc krótko, aby opowiedzieć reszcie projektu i uzyskać jego zgodę na to, jak do cholery zespół testowy właściwie zamierza wziąć się za robotę.
2. Dlaczego istotny jest proces planowania, a nie sam plan? Ponieważ wszelkie zagadnienia i kwestie określone w planie testowania wpływaja na resztę projektu, albo są pod wpływem reszty projektu. Istotne jest, by wszyscy zrozumieli oraz zgodzili się na treść planu. Sporządzenie papierowego dokumentu w zaciszu swego pokoju i umieszczenie go na półce tam, gdzie inni go nie znajdą, jest nie tylko marnowaniem czasu, ale wręcz zagrożeniem dla projektu.
3. Dlaczego zdefiniowanie celów jakości i niezawodności oprogramowania jest ważną częścią planowania testowania? Ponieważ jeśli tego nie zrobić, każdy będzie miał inne pojęcie na temat tego, co się rozumie pod pojęciem jakości i niezawodności. Ponieważ będą różne, nie da się ich wszystkich osiągnąć na raz.
4. Co to są kryteria wejścia i kryteria wyjścia?
Są to wymagania, które muszą zostac spełnione, by móc przejść z jednej fazy testowania do następnej. Nie wolno zakończyć jednej fazy, dopóki kryteria wyjścia nie zostały spełnione. Nie wolno rozpocząć nowej fazy, dopóki kryteria wejścia nie zostały spełnione.
5. Wymień kilka typowych rodzajów zasobów potrzebnych do testowania, które bierze się pod uwagę podczas planowania. Ludzie, sprzęt, biura i laboratoria, oprogramowanie, firmy wykonujące testy na zlecenie i inne.
6. Prawda czy fałsz: harmonogram powinien zawierać dokładne daty, tak żeby nie ulegało żadnej wątpliwości, kiedy dana faza testowania ma sie zacząć i kiedy skończyć. Fałsz. Ponieważ testowanie zależy w ogromnym stopniu od innych aspektów projektu (na przykład nie da się zacząć testować czegoś, co jescze nie zostało zakodowane), harmonogram testowania najkorzystniej jest sformułować względem dat dostaw, a nie w czasie kalendarzowym.
Rozdział 17 1.Jakie są cztery powody, aby planować zadania testowe? Organizacja, powtarzalność, możliwość śledzenia oraz dowód wykonania testów.
2. Co to jest test metodami ad hoc? Jest to testowanie bez planu. Jest łatwe i przyjemne, ale nie jest zorganizowane, nie jest powtarzalne, nie da się śledzić jego przebiegu ani wyników, a kiedy już jest zakończone, nie ma żadnych dowodów na to, że zostało wykonane.
3. Czemu służy specyfikacja grup zadań testowych? Celem specyfikacji grupy zadań testowych jest opisanie testów, które mają być wykonane na jednej określonej funkcji. Specyfikacja ta definiuje w ogólnym zarysie tę funkcję i planowany sposób jej testowania. Identyfikuje zadania testowe (ale nie specyfikuje ich szcegółowo) oraz kryteria zaliczenia/niezaliczenia.
4. Co to jest specyfikacja zadań testowych? Ten dokument określa rzeczywiste wartości danych wejściowych oraz oczekiwane wyniki zadań testowych. Zawiera też listy szczególnych wymagań dotyczących środowiska i sposobu wykonywania testów oraz zależności między zadaniami testowymi.
5. Jakich innych metod - oprócz tradycyjnej formy pisemmnego dokumentu - można używać do opisu zadań testowcyh? Table, macierze, listy, wykresy graficzne - cokolwiek najskuteczniej prezentuje zadania do wykonania wobec autora, pozostałych testrów i wobec reszty zespołu projektowego.
6. Po co jest specyfikacja procedur testowych?\ Jej celem jest opisanie wszystkich kroków niezbędnych do wykonania zadań testowych, włącznie z tym jak przygotować, uruchomić, przeprowadzic oraz zamknąć test. Zawiera też wyjasnienia, co robić w razie niezalicznenia testu.
7. Jak szczegółowa powinna być procedura testowa? Nie ma jednoznacznej odpowiedzi na to pytanie. Zależy to w dużym stopniu od tego, kto będzie korzystał z procedury. Zbyt mała ilość szczegółów spowoduje, że procedura będzie niejednoznaczna, a sposób jej realizacji zależny od intepretacji. Zbyt wiele szczegółów może spowodować, że wykonanie testów będzie odbywać się nadzwyczaj nieelastycznie i powoli. Stosowny poziom szczegołowości zależeć powinien od branży, od przedsiębiorstwa, od projektu i wreszcie od specyfiki zespołu testowego.
Rozdział 18 1.Podaj kilka powodów, dla których błąd może nie zostać naprawiony. Nie ma już czasu w harmonogramie, to nie był naprawdę błąd, jest to zbyt ryzykowne, nie opłaca się skórka za wyprawę, raport błędu był niewłaściwie sporządzony.
2. Jakie są podstawowe zasady pisania raportów o błędach tak, aby zmaksymalizować szansę, że zostaną naprawione? Należy je zapisać jak najszybciej. Błąd należy opisać jak najlepiej, starając się by opis był jak najkrótszy, unikalny, oczywisty i ogólny, oraz pozwalający na powtórzenie błędu. Należy powstrzymać się od wygłaszania osądów i ocen w opisie blędu. Należy śledzić dalsze losy raportu.
3. Podaj kilka technik izolowania i odtwarzania błędu.
Notować wszystko co się robi i starannie to analizować. Posługiwać się metodami szklanej skrzynki aby szukac sytuacji "wyścigu", warunków brzegowych, przecieków pamięci i innych tego typu kłopotów. Sprawdzać, czy awaria zależy od stanu, w jakim znajduje się oprogramowanie, jak na przykład stan początkowy albo inny niż początkowy. Brać pod uwagę zależność od zasobów, a nawet możliwość błędów w sprzęcie jako przyczyny awarii.
4. Wyobraźmy sobie, że testując Kalkulator Windows otrzymujemy następujące wyniki: 1+1=2, 2+2=5, 3+3=6, 4+4+9, 5+5=10 i 6+6=13. Napisz stosowny tytuł raportu i opis błędu. Tytuł: dodawanie dwóch liczb parzystych daje wynik o jedność za duży.
Opis:
Zadanie testowe: proste dodawanie
Warunki startowe: uruchomić Wersję 1.0 Kalkulatora.
Kroki dla odtworzenia: dodajemy pary liczb parzystych takich jak 2+2, 4+4 i 10+10. Próbujemy też dodawać pary liczb nieparzystych takich jak 3+3, 5+5 i 13+13 oraz pary mieszane (liczba parzysta i nieparzysta), takie jak 1+2, 5+6 i 12+13.
Oczekwiane wyniki: poprawna odpowiedź dla wszystkich par liczb
Rzeczywiste wyniki: dla par liczb parzystych, wynik jest za duży o jedność, np. 2+2=5, 4+4=9, 10+10=21 i tak dalej.
Dodatkowa informacja: nie zostało to przetestowane wyczerpująco, ale błąd pojawił się w dużej ilości przypadków od 2+2 do 65536. Błąd nie wydaje się występować dla par liczb nieparzystych i dla par miesznaych.
5. Jaką wagę i priorytet nadałbyś błędowi literowemu w nazwie firmy na pierwszym ekranie aplikacji? Przypuszczalnie wagę 3 (drobniejszy problem) oraz priorytet 2 (musi być naprawiony przed wypuszczeniem).
6. Jakie są trzy podstawowe fazy cyklu życiowego błędu i dwa często stosowane stany dodatkowe? Otwary, Rozwiązany i Zamknięty to stany podstawowe. Do Analizy oraz Odroczony to dwa możliwe dodatkowe stany.
7. Podaj kilka powodów, dla których system śledzenia błędów z użyciem bazy danych jest znacznie bardziej użyteczny niż system oparty na papierowych raportach. Na pierwszy rzut oka daje się zobaczyc historię życiową błędu - nawet jeśli była złożona. Aktulany stan błędu widzi się natychmiast. Błędów nie daje się zgubić ani zaniedbać równie łatwo.
Rozdział 19 1.Czemu - wykorzystując dane pomiarowe z bazy danych ze znalezionymi błędami - liczenie tylo i wyłącznie ilości blędów znalezionych jednego dnia lub obliczenie średniej ilości błędów znajdowanych dziennie nie dałoby wystarczającgo obrazu stanu projektu? Ten pomiar nie daje kompletnego obrazu sytuacji. Może właśnie była testowana najbardziej złożona część programu, a może część napisana przez najbardziej doświadczonego programistę, czy też odwrotnie - przez początkującego programistę. Testowany kod mógł być testowany już wcześniej przy innej okazji lub zupełnie nowy.
2.Uzupełniając odpowiedź na pytanie 1-e, jakie inne dane pomiarowe warto wziąć pod uwagę, aby trafnie i skutecznie mierzyć jakość własnej, osobistej jakości pracy jako testera? Srednią ilość błędów znajdowanych dziennie. Łaczną sumę błędów znalezionych od początku do obecnej chwili. Stosunek ilości błędów naprawionych do wszystkich znalezionych. Stosunek ilości błędów o wadze 1 (albo priorytecie 1) do ilości wszystkich znalezionych błędów. Średni czas od statu Rozwiązany do stanu Zamknięty.
3.Jak wyglądałoby pytanie postawione bazie danych (wolno użyć dowolnego formatu i składni „pseudojęzyka”), które miałoby wydobyć z niej wsztystkie rozwiązane błędy, przypisane Terry’emu, w projekcie CalcU-Lot, wersja 3.0? Produkt EQUALS Calc-U-Lot AND Wersja EQUALS 3.0 AND Status EQUALS Rozwiązany AND Przypisany EQUALS Terry
4.Jeśli tempo znajdowania nowych błędów słabnie (jak na rysunku 19.8) i wszyscy bardzo się cieszą, że projekt zbliża się do celu, jakie mogą być powody (wymień kilka), że liczby kłamią, tj. że stan produktu/projektu wcale nie jest dobry, mimo że błędów znajduje się coraz mniej?
Mogło się zdarzyć, że program był przekazywany do testowania stopniowo i nie cały został jeszcze prztestowany - może wypłaszczenie dotyczy tylko pierwszej fazy. Testerzy mogli być zajęci testowaniem regresyjnym i zamykaniem błędów, a nie szukaniem nowych błędów. Mógł to być wyjątkowo ciepły i słoneczny tydzień albo testerzy mogli być na wakacjach.
Rozdział 20 1.Czemu istnieją koszty testowania, związane z kosztami osiągnięcia jakości? Ponieważ - niezależnie od tego, jak doskonały jest proces wytwórczy - testowanie trzeba wykonać co najmniej jeden raz, aby móc dokonać weryfikacji produktu względem jego specyfiakcji oraz walidacji względem wymagań użytkowników. Jeśli nie znalazło się żadnych błędów, to wspaniale, ale koszty planowania, konstruowania i wykonywania testów wchodzą w skład kosztów osiągnięcia jakości.
2. Prawda czy fałsz: zespół testowy jest odpowiedzialny za jakość. Falsz! Testowanie ma za zadanie poszukiwanie blędów. Nie testerzy spowodowali, że w programie sa błędy. Testerzy nie są w stanie zagwarantować, że po zakończeniu testów w programie na pewno nie ma już żadnych błędów.
3. Czemu niełatwo jest spełnić wszystkie wymaganaia, które implikuje tytuł inżyniera zapewnienia jakości? Ponieważ tytuł implikuje odpowiedzialność za jakość produktu. Kto jest gotowy ponieść tę odpowiedzialność?
4. Czemu korzystne jest, by grupa odpowiedzialna za test lub zapewnienie jakości była podporządkowana bezpośrednio kierownictwu firmy? Jeśłi zespół testowy podporządkowany jest kierownikowi produkcji lub kierownikowi projektu, ma miejsce konflikt interesów między znajdowaniem błędów a zbudowaniem oprogramowania oraz dotrzymaniem harmonogramu.
5. Na jakim poziomie CMM będzie firma, która spełniła warunki standardu 9000-3 dla oprogramowania?
Będzie ona zapewne na poziomie 3-im CMM, być może ocierając się o niektóre wymagania dla poziomu 4-ego. Nie jest na poziomie 2-im, ponieważ poziom 2-i dotyczy tylko projektu. Poziom 3-i dotyczy całej organizacji czy przedsiębiorstwa. Na poziomie 4-ym pojawia sie staystyczna kontrola procesów.
Rozdział 21 1.Szukając na Internecie pracy związanej z testowaniem, jakich słów należy szukać startując przeszukiwarkę? Nazwy roli i opisy funkcji testerów oprogramowania są różnorodne, należy więc szukać określeń "test oprogramowania" (software test), "testowanie oprogramowania" (software testing), "zapewnienie jakości" (quality assurance) oraz "QA".
2.Wymień dwa sposoby, jak można miec do czynienia z testowaniem oprogramownaia przed jego wypuszczeniem na rynek. Testowanie beta i testowanie użyteczności.
3.Jakie są cele testera oprogramowania? Celem testera jest znajdowanie błędów, znajdowanie ich jak najwcześniej oraz dopatrzenie, by zostały naprawione.