Test INF.04 — zestaw 6

Dlaczego tak

Komentarz blokowy /* … */ obejmuje oba wiersze między znacznikami, więc mnożenie przez 10 i dodawanie 1 nie są wykonywane. W czwartym wierszu wykonuje się x = x * 3, a tekst po // to komentarz jednowierszowy, więc przypisanie 0 jest pominięte. Wynik to 2 · 3 = 6; wartość 63 powstałaby, gdyby komentarz blokowy obejmował tylko pierwszy wiersz.

Dlaczego tak

Komentarz dokumentacyjny w C# zaczyna się od trzech ukośników i zawiera znaczniki XML, takie jak summary, param czy returns – kompilator może zebrać je do pliku XML, z którego korzystają IntelliSense i generatory, np. DocFX. Komentarz z dwoma ukośnikami jest zwykłym komentarzem, nawet jeśli zawiera znaczniki. Znacznik @summary w bloku /* */ przypomina JSDoc, ale C# go nie interpretuje, a #region tylko zwija fragment kodu w edytorze.

Dlaczego tak

Pomoc kontekstowa wyświetla informacje dotyczące elementu, z którym użytkownik właśnie pracuje – zwykle po naciśnięciu F1 – zamiast otwierać spis treści całego podręcznika. ToolTip też dotyczy konkretnej kontrolki, ale jest krótkim dymkiem pojawiającym się po najechaniu myszą, a nie dokumentem pomocy. Samouczek prowadzi krok po kroku przez całe zadanie, a dokumentacja API jest przeznaczona dla programistów.

Dlaczego tak

Instrukcja użytkownika opisuje, jak wykonać zadanie w interfejsie – językiem użytkownika, krok po kroku, z nazwami przycisków i pól widocznymi na ekranie. Opis klas i wzorców projektowych, struktura bazy danych oraz zachowanie interfejsu API należą do dokumentacji technicznej, przeznaczonej dla programistów i administratorów. Użytkownik końcowy nie potrzebuje wiedzieć, jak aplikacja jest zbudowana, aby z niej korzystać.

Dlaczego tak

Instrukcja powinna prowadzić użytkownika w kolejności, w jakiej wykonuje czynności: najpierw sprawdza, czy jego komputer spełnia wymagania, potem instaluje program, uruchamia go i konfiguruje, a następnie poznaje funkcje. Rozdział o rozwiązywaniu problemów i najczęstszych błędach umieszcza się na końcu, bo korzysta się z niego w razie potrzeby. Wymagania podane po instalacji są bezużyteczne, bo użytkownik dowie się o nich za późno.

Dlaczego tak

Dokumentacja wdrożenia opisuje, jak przygotować środowisko i uruchomić aplikację: wymagania programowe, konfigurację (zmienne środowiskowe, połączenie z bazą), kroki instalacji, migracje bazy i sposób wycofania wersji. Makiety i paleta kolorów należą do projektu interfejsu, a notatki ze spotkań – do dokumentacji projektowej. Lista testów jest częścią dokumentacji testów i nie pomaga w instalacji.

Dlaczego tak

Odsetek powodzeń liczy się względem testów wykonanych: 96 / 114 ≈ 0,842, czyli 84,2 %. Nie wykonano 120 − 114 = 6 przypadków, co raport powinien wykazać osobno, np. jako zablokowane. Wynik 80,0 % powstaje po podzieleniu przez liczbę zaplanowanych testów (96 / 120), a liczba 18 to testy wykonane z wynikiem negatywnym, a nie niewykonane.

Dlaczego tak

Cykl TDD opisuje się jako red – green – refactor: najpierw powstaje test nowej funkcji, który nie przechodzi, bo funkcji jeszcze nie ma, potem najprostszy kod spełniający test, a na końcu porządkowanie kodu przy stale przechodzących testach. Pisanie testów po gotowym kodzie to klasyczne podejście, a nie TDD. Refaktoryzacja przed napisaniem kodu nie ma sensu, bo nie ma jeszcze czego porządkować.

Dlaczego tak

Test funkcjonalny sprawdza, co system robi – czy wykonuje właściwą operację i daje oczekiwany wynik. Test niefunkcjonalny sprawdza, jak system działa: wydajność, obciążenie, użyteczność, bezpieczeństwo czy zgodność. Czas odpowiedzi przy określonej liczbie użytkowników to wymaganie wydajnościowe, a koszyk, rabat i e-mail z potwierdzeniem to funkcje sklepu.

Dlaczego tak

Analiza wartości brzegowych sprawdza każdą granicę przedziału oraz najbliższą wartość leżącą po drugiej stronie granicy, bo tam najczęściej występują błędy typu „<” zamiast „<=”. Dla przedziału 18–65 są to 17 i 18 oraz 65 i 66. Zestaw 18, 40, 65 nie sprawdza wartości niepoprawnych, a w zestawie 17, 19, 64, 66 brakuje samych granic 18 i 65.

Dlaczego tak

Testy integracyjne wykonuje się po testach jednostkowych, aby sprawdzić współpracę modułów – przekazywanie danych i wywołania między nimi. Testy jednostkowe sprawdzają pojedyncze moduły lub funkcje w izolacji, a ten etap jest już zakończony. Testy akceptacyjne przeprowadza klient na końcu projektu, a testy dymne to szybkie sprawdzenie, czy nowa wersja w ogóle się uruchamia.

Dlaczego tak

Test obciążeniowy sprawdza działanie systemu przy spodziewanym, typowym lub szczytowym obciążeniu i porównuje wyniki, np. czas odpowiedzi, z wymaganiami. Test przeciążeniowy (stress test) celowo przekracza przewidywane obciążenie, aby znaleźć punkt awarii i sprawdzić, jak system się po niej zachowuje. Testy użyteczności dotyczą wygody obsługi przez ludzi, a testy zgodności – działania w różnych przeglądarkach i systemach.

Dlaczego tak

Status RESOLVED oznacza, że programista uważa sprawę za rozwiązaną, ale poprawkę musi jeszcze sprawdzić ktoś inny – zwykle tester lub zgłaszający. Po potwierdzeniu zgłoszenie otrzymuje status VERIFIED, a jeśli błąd nadal występuje, zostaje ponownie otwarte. Weryfikacja własnej poprawki przez programistę omija kontrolę jakości, a zgłoszeń się nie usuwa, bo stanowią historię projektu.

Dlaczego tak

Identyfikator elementu jest unikalny na stronie i nie zależy od jego położenia, więc lokator By.id przestanie działać tylko wtedy, gdy ktoś zmieni samo id. Bezwzględna ścieżka XPath i selektor z nth-child zależą od struktury dokumentu i przestają działać po dodaniu jednego elementu przed przyciskiem. By.linkText wyszukuje wyłącznie odnośniki a, więc nie znajdzie elementu button.

Dlaczego tak

Prototyp testuje się z udziałem użytkowników: dostają typowe zadania, np. „zarezerwuj wizytę na jutro”, a obserwator notuje błędy, wahania i czas wykonania, często prosząc o głośne komentowanie (think aloud). Już kilka osób pozwala wykryć większość problemów nawigacji. Prototyp nie ma kodu aplikacji, więc testy jednostkowe, obciążeniowe i walidacja HTML nie mają czego sprawdzać.

Dlaczego tak

Środowisko testowe musi mieć znany stan początkowy – ten sam schemat i te same dane testowe – inaczej wynik testu zależy od tego, co zostało po poprzednim uruchomieniu. Kopia produkcji z danymi osobowymi narusza zasady RODO i zmienia się z dnia na dzień, a testy na produkcji mogą uszkodzić prawdziwe dane. Usunięcie bazy sprawia, że test przestaje być testem integracyjnym, bo nie sprawdza współpracy z bazą.

Dlaczego tak

W testowaniu opartym na ryzyku najpierw sprawdza się funkcje, których awaria ma największe skutki i które są najczęściej używane. Błąd w składaniu lub opłacaniu zamówienia oznacza utratę sprzedaży i zaufania klientów, więc ten scenariusz ma najwyższy priorytet. Zdjęcie profilowe, stopka i animacja są potrzebne, ale ich błąd nie zatrzymuje działalności sklepu.

Dlaczego tak

W formacie Given–When–Then (np. w języku Gherkin) Given opisuje warunek początkowy, When – działanie użytkownika lub zdarzenie, a Then – oczekiwany wynik, który test sprawdza. Warunkiem początkowym jest aktywne konto, działaniem trzy błędne hasła, a wynikiem blokada. W pozostałych zapisach oczekiwany wynik trafił do warunku lub działania, więc taki scenariusz nie sprawdza blokady.

Dlaczego tak

Dobre zgłoszenie błędu pozwala go odtworzyć: podaje środowisko (przeglądarkę, system, wersję), kroki prowadzące do błędu oraz wynik oczekiwany i rzeczywisty. Zgłoszenie „płatności nie działają” nie mówi, w jakich warunkach błąd występuje, a określenia „czasami” i „chyba” nie pozwalają go powtórzyć. Wskazanie podejrzanego fragmentu kodu bez kroków odtworzenia to domysł, a nie opis błędu.

Dlaczego tak

Funkcja test.each tworzy osobny test dla każdego wiersza danych, podstawiając jego wartości do nazwy testu i do parametrów funkcji. Wierszy są trzy, więc Jest zgłosi trzy testy o nazwach dodaj(2, 3) = 5, dodaj(0, 0) = 0 i dodaj(-1, 1) = 0. Wynik 9 powstaje, gdy liczy się pojedyncze wartości zamiast wierszy, a 1 – gdy całą konstrukcję traktuje się jak jeden test.

Dlaczego tak

Każde wywołanie funkcji kończy się jedną instrukcją return, a są trzy różne ścieżki: p ≥ 90 daje „bdb”, 50 ≤ p < 90 daje „zal”, a p < 50 daje „nzal”. Wystarczą więc trzy przypadki, np. p = 95, 60 i 30. Dwa testy pokryją najwyżej dwie z trzech ścieżek, a czwarty test nie zwiększy pokrycia, bo innych ścieżek w funkcji nie ma.

Dlaczego tak

Test akceptacyjny porównuje działanie aplikacji z uzgodnionymi kryteriami – każde z nich musi być spełnione dosłownie: format pliku i komplet kolumn. Plik CSV ma właściwe kolumny, ale inny format niż wymagany XLSX. Wartość netto zamiast brutto oraz brak kolumny ilość to także niezgodności, które klient może słusznie odrzucić przy odbiorze.

Dlaczego tak

Słowo „deprecated” oznacza, że element jest przestarzały i niezalecany – nadal działa, ale autorzy zapowiadają jego usunięcie („will be removed in the next major release”). W nowym kodzie należy więc użyć zalecanego zamiennika, który dokumentacja zwykle podaje obok. Metoda nieukończona byłaby opisana jako „experimental” lub „preview”, a prywatna jako „private” lub „internal”.

Dlaczego tak

Pierwsze zdanie, „Version 2.4 focuses on stability”, wyraża główną myśl, a kolejne ją rozwijają: poprawiono 37 awarii (crashes) i zmniejszono zużycie pamięci. Ostatnie zdanie mówi, że nowe funkcje pojawią się dopiero w wersji 3.0. Liczba 37 dotyczy naprawionych awarii, a nie nowych funkcji, a starsze urządzenia zyskały na mniejszym zużyciu pamięci, a nie straciły wsparcie.

Dlaczego tak

Zdanie „Copy .env.example to .env and set DATABASE_URL before starting the server” wprost wskazuje czynność wykonywaną przed startem serwera: skopiowanie pliku przykładowego i ustawienie zmiennej z adresem bazy. „Node.js 20 or later” oznacza wersję 20 lub nowszą, a nie starszą. DATABASE_URL to nazwa zmiennej konfiguracyjnej, a słowo „before” wyklucza uruchomienie serwera przed konfiguracją.

Dlaczego tak

Drugie zdanie przeczy oczekiwaniu wynikającemu z pierwszego – test przeszedł w Windows, ale nie w macOS – więc potrzebny jest spójnik wyrażający kontrast: „However” (jednak). „Therefore” (dlatego) wprowadza skutek, a niepowodzenie w macOS nie wynika z sukcesu w Windows. „Moreover” (ponadto) dodaje informację w tym samym kierunku, a „For example” wprowadza przykład.

Dlaczego tak

Najpierw trzeba pobrać repozytorium („Clone”), potem dodać zmienione pliki do poczekalni („Stage”, git add), następnie utrwalić je w commicie („Commit the staged changes”), a na końcu wysłać gałąź na serwer („Push”). Commit przed dodaniem plików byłby pusty, bo commit obejmuje tylko zmiany w poczekalni. Wysłanie gałęzi przed commitem nie przeniesie nowych zmian na serwer.

Dlaczego tak

Stos działa według zasady LIFO (last in, first out) – element dodany jako ostatni jest zdejmowany jako pierwszy, jak talerze ułożone jeden na drugim. Opis „the first element added is the first one removed” dotyczy kolejki (queue, FIFO). Elementy wskazujące na następny tworzą listę jednokierunkową (linked list), a wyszukiwanie po kluczu z funkcją skrótu to tablica mieszająca (hash table).

Dlaczego tak

Instrukcję w języku angielskim formułuje się w trybie rozkazującym, a czasownik złożony „back up” oznacza „wykonać kopię zapasową”; „before you install” określa kolejność. Zdanie „Install the update, and then back up your data” jest poprawne gramatycznie, ale odwraca kolejność czynności. Trzecie zdanie używa czasu przeszłego, więc nie jest poleceniem, a czwarte zawiera błąd („make a back”) i zmienia kolejność („after”).

Dlaczego tak

Stanowisko wyraża się zwrotami typu „I think”, „In my opinion”, a uzasadnienie wprowadza „because”, „since” lub „as” – pierwsze zdanie zawiera oba elementy. Drugie zdanie podaje fakty historyczne i licencyjne bez żadnej opinii. Trzecie jest pytaniem o opinię innych, a czwarte poleceniem wykonania czynności, więc żadne z nich nie wyraża stanowiska autora.

Dlaczego tak

Przyjęta w projektach (m.in. w Git) konwencja zaleca pierwszy wiersz do około 50 znaków, w trybie rozkazującym – tak jakby kończył zdanie „If applied, this commit will…” – i konkretnie opisujący zmianę. „Fixed some stuff” jest w czasie przeszłym i nic nie mówi o zmianie. Długie zdanie w czasie Present Perfect Continuous jest opowieścią, a nie podsumowaniem, a „fixing...” nie zawiera żadnej informacji.

Dlaczego tak

Styl formalny unika skrótów myślowych i form ściągniętych (can't, tmrw), stosuje pełne zdania i zwroty grzecznościowe, np. „I regret that…” oraz „I will be unable to attend”. Zdania z „sorry” i „catch you later” są poprawne w rozmowie z kolegą, ale zbyt potoczne wobec klienta. Ostatnie zdanie, „deal with it”, jest niegrzeczne w każdej sytuacji.

Dlaczego tak

Pytanie „Is there anything else I can help you with today?” to typowe zamknięcie rozmowy z klientem: upewnia się, że sprawa jest załatwiona, i daje okazję do zgłoszenia innego problemu przed pożegnaniem. „Good morning, IT support…” otwiera rozmowę. „Could you hold the line” prosi o chwilę oczekiwania w trakcie rozmowy, a „put you through” oznacza przełączenie do innego działu.

Dlaczego tak

Aby odtworzyć błąd, programista potrzebuje kroków, które do niego prowadzą, oraz informacji o środowisku – pytanie o wykonywaną czynność („What were you doing when it crashed”) i wersję aplikacji („which app version”) dostarcza obu. Pytanie o powód instalacji i opinię o aplikacji nie dotyczy błędu. Pytanie „Are you sure…?” podważa słowa klienta i nie wnosi żadnych danych technicznych.

Dlaczego tak

Uprzejmy brak zgody zaczyna się od docenienia zdania rozmówcy („I see your point”), następnie wprowadza własną propozycję („but I'd rather…”) i podaje powód („the tests aren't finished”). Druga odpowiedź wyraża pełną zgodę, a trzecia jest pytaniem o opinię, którą kolega już wyraził. Czwarta to brak zgody, ale bez uzasadnienia i w formie odbieranej jako niegrzeczna.

Dlaczego tak

Propozycja negocjacyjna uczciwie wskazuje ograniczenie i od razu oferuje rozwiązanie korzystne dla obu stron: najważniejsze funkcje w żądanym terminie, a resztę później („we could ship the core features then and the rest by May 20”). Zgoda na całość dzięki nadgodzinom byłaby obietnicą bez pokrycia, a odpowiedź „That's impossible” zamyka rozmowę zamiast ją prowadzić. Pytanie o termin jest zbędne, bo klient już go podał.

Dlaczego tak

Uprzejmą prośbę w języku angielskim buduje się z „Could you…?” lub „Would you mind…?”, słowa „please” i zwrotu zostawiającego rozmówcy swobodę, np. „when you're free”. Tryb rozkazujący („Review… now”) i „You must…” brzmią jak polecenie przełożonego. Pytanie „Why haven't you…?” jest odbierane jako wyrzut, a nie prośba.

Dlaczego tak

Na czacie zespołu stosuje się styl nieformalny: powitanie imieniem („Hi Tom”), krótkie zdania i swobodne podziękowanie. Zwroty „Dear Sir or Madam”, „To whom it may concern” i „hereby inform” należą do oficjalnej korespondencji z nieznanym adresatem. „Yours faithfully” to formalne zakończenie listu, które w ogóle nie pasuje do początku wiadomości.

Dlaczego tak

Ikona z trzech poziomych kresek przypomina kształtem hamburgera i w dokumentacji interfejsów nazywa się „hamburger menu” lub „hamburger icon”. „Kebab menu” to trzy pionowe kropki, które zwykle otwierają menu dodatkowych akcji, więc łatwo je pomylić. „Breadcrumb” to ścieżka nawigacji, np. „Home > Products > Laptops”, a „toggle switch” – przełącznik włącz/wyłącz.

Dlaczego tak

„Access denied” to „odmowa dostępu”, a „you do not have sufficient permissions to perform this operation” – „nie masz wystarczających uprawnień do wykonania tej operacji”. Komunikat nie mówi nic o haśle: chodzi o uprawnienia konta, a nie o uwierzytelnienie. Pozostałe tłumaczenia odwracają znaczenie („Dostęp przyznany”) albo dotyczą zupełnie innego problemu, jakim jest brak połączenia z siecią.