Wyszukiwanie bugów w open source: jak zgłaszać problemy, by były naprawiane

Po co w ogóle zgłaszać bugi w open source?

Zgłoszenia błędów jako paliwo rozwoju projektu

Żaden projekt open source, nawet ten najpopularniejszy, nie jest skończony. Kod żyje tak długo, jak długo ktoś go używa – a tam, gdzie są prawdziwi użytkownicy, zawsze pojawiają się bugi. Zgłaszanie bugów w open source to nie „uprzejmość” wobec maintainerów, ale kluczowy mechanizm rozwoju projektu. Dobrze opisane problemy pozwalają zespołowi zobaczyć, gdzie kod spotyka się z rzeczywistością: innymi systemami, nietypowymi konfiguracjami, nieoczywistymi sposobami użycia.

Jedno rzetelne zgłoszenie potrafi uruchomić lawinę zmian: poprawkę w krytycznym miejscu, dopisanie brakującego testu automatycznego, aktualizację dokumentacji czy usprawnienie komunikatów błędów. Nierzadko „zwykłe” issue kończy się refaktoryzacją fragmentu kodu, który latami był tykającą bombą. Z zewnątrz wygląda to jak drobna łatka, ale od środka zmienia jakość całego modułu.

Błędy prowadzą też do ulepszeń wydajności i bezpieczeństwa. Zgłoszenie typu „przy większej liczbie rekordów wszystko zamiera” może odkryć nieefektywny algorytm. Z kolei pozornie niewinny „dziwny błąd uprawnień” bywa początkiem naprawy luki bezpieczeństwa, o której nikt wcześniej nie myślał. To właśnie dlatego maintainerzy tak bardzo cenią dobrze przygotowane bug reporty: pozwalają im inwestować czas tam, gdzie efekt jest największy.

Łowca błędów jako wartościowy kontrybutor

Nie każdy musi od razu pisać kod, żeby realnie pomagać projektowi. Łowcy bugów – osoby, które potrafią wyłapać, odtworzyć i jasno opisać problem – są dla maintainerów na wagę złota. Debugowanie open source dla początkujących zaczyna się często właśnie od zgłaszania błędów: to najprostszy sposób wejścia w świat projektu i zrozumienia, jak działa od środka.

W wielu repozytoriach na GitHubie znajdziesz listy współtwórców, w których uwzględnia się także osoby zgłaszające problemy. Dobrze przygotowane issue na GitHubie jest traktowane jak wartościowy wkład – szczególnie wtedy, kiedy zawiera reprodukcję błędu krok po kroku i minimalny przykład błędu. Czasem jedna osoba, która potrafi świetnie opisywać problemy, odciąża maintainerów bardziej niż kilku średnio zaangażowanych programistów.

Taki wkład ma też bardzo praktyczną stronę: poznajesz ekosystem, narzędzia, procesy, a z czasem – imię i nazwisko z Twojego profilu zaczyna być kojarzone jako „ktoś, kto zgłasza porządne rzeczy”. To miękka waluta, ale bywa bardzo cenna przy rekrutacjach czy budowaniu własnych projektów.

Co z tego ma zgłaszający? Nauka, reputacja i mniej frustracji

Zgłaszanie bugów w open source to świetna szkoła inżynierskiego myślenia. Żeby przygotować rzetelne zgłoszenie, trzeba przejść przez proces: obserwacja, zawężanie problemu, hipotezy, próby, notatki. Po kilku takich „śledztwach” zupełnie inaczej patrzysz na programy, z których korzystasz na co dzień. Zaczynasz rozumieć, dlaczego coś się wywala i gdzie szukać przyczyny.

Dochodzi do tego aspekt czysto praktyczny: jeśli błąd dotyczy narzędzia, z którego korzystasz zawodowo, jego naprawa bezpośrednio zmniejsza Twoją frustrację. Zamiast za każdym razem stosować tę samą brzydką obejściówkę, po prostu pomagasz doprowadzić do poprawki. A im lepiej opiszesz problem, tym większa szansa, że maintainerzy uznają go za priorytet.

Reputacja w społeczności też nie bierze się znikąd. Ktoś, kto potrafi kulturalnie i precyzyjnie komunikować się z maintainerami, szybko zyskuje opinię osoby „zawodnej na plus”. To procentuje, gdy później chcesz np. zgłosić propozycję funkcji, poprosić o review swojej pierwszej łatki albo po prostu nawiązać współpracę.

Narzekanie kontra odpowiedzialne zgłoszenie problemu

Między „nic nie działa, poprawcie to natychmiast” a odpowiedzialnym zgłoszeniem problemu jest przepaść. Narzekanie to wyrzucenie emocji bez próby zrozumienia sytuacji i bez szacunku do czasu innych. Dobre issue jest odwrotnością: zakłada, że po drugiej stronie są ludzie, którzy nie widzą Twojego ekranu, nie znają Twojej konfiguracji i nie siedzą w Twojej głowie.

Odpowiedzialne zgłoszenie zawiera konkrety: wersje, kroki, logi, obserwacje. Zamiast „nic nie działa” pojawia się „wykonuję A, B, C, oczekuję D, otrzymuję E; tutaj są logi i minimalny przykład”. Taka różnica tonu sprawia, że maintainerzy naturalnie mają większą chęć pomocy. Projekty open source są zazwyczaj rozwijane po godzinach – nikt nie ma obowiązku być Twoim supportem 24/7, ale bardzo wiele osób chce pomóc, gdy widzi po drugiej stronie partnera do rozmowy, a nie roszczeniowego klienta.

Co to jest „dobry bug” z perspektywy twórców projektu

Bug, oczekiwane zachowanie, brak funkcji – jak to odróżnić

Pierwsza pułapka przy zgłaszaniu błędu to mylenie kilku różnych zjawisk. Dla maintainerów ogromnie ważne jest, żeby od razu wiedzieli, z czym mają do czynienia:

• Bug – coś ewidentnie nie działa zgodnie z dokumentacją, wcześniejszym zachowaniem lub intencją projektu. Na przykład: dokumentacja mówi, że komenda tool run --dry nie zmienia danych, a w praktyce modyfikuje plik konfiguracyjny.
• Oczekiwane zachowanie – program robi coś, co wydaje się dziwne, ale tak został zaprojektowany. Na przykład: narzędzie nie wspiera jeszcze danej kombinacji flag albo domyślnie obcina długie logi.
• Brak funkcji (feature request) – chcesz, żeby program robił coś, czego nigdy nie obiecywał. To nie bug, tylko propozycja rozwoju, którą zgłasza się zwykle w innym typie issue.

Jeśli zgłaszasz „buga”, który tak naprawdę jest życzeniem nowej funkcji, maintainer musi najpierw odcedzić temat, zamiast od razu zabrać się za analizę. Z tego powodu przed zgłoszeniem warto sprawdzić dokumentację i istniejące zgłoszenia: może to, co widzisz, już zostało opisane jako znane ograniczenie albo planowana funkcja.

Cechy dobrego zgłoszenia z punktu widzenia maintainerów

Z punktu widzenia osoby rozwijającej projekt, dobre issue ma kilka stałych cech. Jeśli nauczysz się je powtarzać, Twoje zgłoszenia będą traktowane poważnie niemal z automatu.

• Odtwarzalność – opis błędu pozwala drugiej osobie powtórzyć go na swoim komputerze lub środowisku. To fundament. „Czasem się wywala” bez dodatkowych informacji nie wystarcza.
• Konkret – są dokładne komendy, wersje, fragmenty logów, dane wejściowe. Zgłoszenie nie opiera się na ogólnikach typu „duży projekt”, „nowa wersja” czy „standardowa konfiguracja”.
• Spokój emocjonalny – ton jest neutralny lub przyjazny, bez oskarżeń, CAPS LOCKA i ironii. Emocje można mieć, ale w bug reportach lepiej je trzymać na wodzy.
• Szacunek do czasu – widać, że zgłaszający wykonał podstawowe kroki: sprawdził, czy to nie duplikat, odtworzył problem, zebrał kluczowe informacje. Maintainer nie musi zadawać pięciu podstawowych pytań, żeby dojść do szczegółów.

Dobre zgłoszenie to trochę jak dobrze przygotowany brief dla programisty. Im lepiej opisane, tym mniejszy koszt wejścia w temat. To właśnie „koszt wejścia” maintainerzy ważą w głowie, kiedy widzą kolejne powiadomienie z nowym issue.

Jak maintainer patrzy na Twoje zgłoszenie

Dla maintainera każde nowe zgłoszenie to decyzja: czy warto w to wejść teraz, za tydzień, czy w ogóle? Podświadomie liczy się kilka czynników: ile czasu zajmie zrozumienie problemu, jakie ryzyko niesie bug, ilu użytkowników dotyka i czy są dane, by w ogóle zacząć debugowanie.

Jeśli issue jest krótkie, ale treściwe (jasny tytuł, kroki, oczekiwane i aktualne zachowanie, środowisko), koszt analizy jest niski. Maintainer może w kilka minut ocenić, czy bug jest krytyczny, czy raczej „do zrobienia przy okazji”. Jeśli jednak zgłoszenie jest emocjonalną ścianą tekstu bez konkretów, musi poświęcić dodatkowy czas na dopytywanie – a wtedy łatwiej odłożyć temat na później.

Rodzaj błędu też ma znaczenie. Problemy z bezpieczeństwem, utratą danych czy regresje w najnowszej wersji zwykle lądują wyżej na liście. Dobrze opisane zgłoszenie automatycznie przesuwa się w górę, bo od razu widać potencjalny wpływ na innych użytkowników. To kolejny powód, by od początku zadbać o jakość informacji.

Dlaczego nie każdy „problem użytkownika” jest bugiem

Część zgłoszeń okazuje się po prostu problemami z konfiguracją lub środowiskiem użytkownika. Przykład z życia: ktoś zgłasza, że narzędzie CLI „psuje pliki konfiguracyjne”. Po kilku pytaniach wychodzi na jaw, że korzysta z bardzo niestandardowego systemu plików, a narzędzie działało poprawnie w zwykłym środowisku. Bug? Z punktu widzenia projektu – niekoniecznie. Bardziej ograniczenie kompatybilności lub brak obsługi egzotycznego przypadku.

Podobnie bywa z uprawnieniami. Użytkownik pisze, że „program nie zapisuje plików, mimo że niczego nie zmieniał”, a w logach pojawiają się komunikaty o braku dostępu do katalogu. To nie błąd programu, tylko konsekwencja ustawień systemu lub zmian w polityce bezpieczeństwa. Zgłoszenie może być nadal wartościowe (bo motywuje do lepszego komunikatu błędu), ale sedno problemu leży poza samym kodem projektu.

Rozróżnienie tych przypadków bywa trudne, ale już sama próba zrozumienia, czy to na pewno bug, pokazuje maintainerom, że podchodzisz do sprawy poważnie, a nie tylko przerzucasz odpowiedzialność za swój system na projekt open source.

Zanim zgłosisz błąd – sprawdź, czy to naprawdę bug

Podstawowe pytania kontrolne przed zgłoszeniem

Zanim dopiszesz kolejne zgłoszenie do listy, zadaj sobie kilka prostych pytań. Ta mała checklista oszczędza czas wszystkim zainteresowanym.

• Czy to kiedykolwiek działało? Jeśli tak, spróbuj przypomnieć sobie, co się zmieniło w międzyczasie: aktualizacja wersji, nowe wtyczki, zmiana systemu, migracja danych.
• Czy błąd występuje zawsze, czy tylko czasami? Jeśli czasami, postaraj się zauważyć wspólny element sytuacji, w których się pojawia: konkretne dane, określona pora, przeciążenie systemu, określone środowisko.
• Czy inni użytkownicy też go zgłaszali? Szybkie wyszukanie komunikatu błędu potrafi rozwiać wiele wątpliwości. Może to już znany problem z obejściem.
• Czy błąd zależy od Twojej konfiguracji? Spróbuj wykonać ten sam scenariusz na „czystym” środowisku lub z domyślną konfiguracją.

Te pytania kierują myślenie w stronę diagnozy, a nie tylko opisu objawu. Bardzo często już na tym etapie odkrywasz, że problem leży zupełnie gdzie indziej niż myślałeś na początku.

Sprawdzenie wersji i zebranie informacji o środowisku

Kolejny krok to solidne zebranie informacji o wersjach i środowisku. Bez tego maintainerzy działają po omacku. Dobrze przygotowane zgłaszanie bugów w open source zawsze zawiera przynajmniej:

• wersję projektu (np. numer wydania, commit, tag),
• wersję głównych bibliotek/rynków (np. Python, Node.js, Java, framework webowy),
• system operacyjny i jego wersję,
• informację, czy to instalacja z paczki, z repozytorium, z obrazu Docker itp.

Warto spisać to w jednym miejscu, najlepiej jako blok kodu w zgłoszeniu. Zamiast ogólnego „najświeższa wersja” dodaj konkretne numery. „Najświeższa” u Ciebie nie musi oznaczać tego samego, co u maintainerów – możesz mieć cache, niestandardowe repozytorium albo wersję z gałęzi rozwojowej.

Prosty przykład: w projektach node’owych polecenie node -v, npm -v albo pnpm -v, a także wersja samego pakietu z package.json lub npm list. W świecie Pythona – python --version, pip show nazwa-pakietu, a do tego informacja, czy używasz virtualenv, conda, czy globalnej instalacji. Im precyzyjniej to opiszesz, tym łatwiej będzie porównać Twoje środowisko z innymi.

Problem lokalny kontra błąd w samym projekcie

Jednym z najtrudniejszych rozróżnień jest to między problemem lokalnym a realnym bugiem w projekcie. Problem lokalny to wszystko, co wynika ze specyfiki Twojego środowiska: nietypowych uprawnień, firewalli, sieci VPN, antywirusa, specyficznego sprzętu, konfiguracji systemu plików. Program może w takim środowisku zachowywać się nieprawidłowo, ale na większości instalacji działać w porządku.

Dobrym testem bywa uruchomienie narzędzia w innym, możliwie prostym środowisku. Na przykład:

• inna maszyna (fizyczna lub wirtualna),
• czysty kontener Docker z minimalną konfiguracją,
• inne konto użytkownika z domyślnymi ustawieniami.

Minimalny przykład kontra „mój cały system się wywala”

Kiedy już upewnisz się, że coś faktycznie działa nie tak, jak powinno, pojawia się kolejne pytanie: czy potrafisz to pokazać w możliwie prosty sposób? Zamiast opisywać scenariusz „na mojej ogromnej monolitycznej aplikacji”, spróbuj znaleźć minimalny przykład, który też powoduje błąd. To trochę jak z hałasującym samochodem – mechanik szybciej znajdzie problem, jeśli potrafisz pokazać dźwięk przy konkretnym manewrze, a nie tylko „czasem coś trzeszczy”.

Minimalny przykład to okrojona wersja twojego przypadku: mniej plików, mniej zależności, prostsza konfiguracja. Często w trakcie jego budowania odkrywasz sam, gdzie leży przyczyna – bo usuwając kolejne elementy nagle błąd znika.

• Masz problem z biblioteką front-endową? Spróbuj zredukować go do małej aplikacji z jednym komponentem.
• API odsyła dziwną odpowiedź? Przygotuj prosty skrypt, który robi dokładnie jedno żądanie z konkretnymi danymi.
• Narzędzie CLI się wykrzacza? Zastanów się, która pojedyncza komenda wywołuje problem i czy da się pominąć całą resztę pipeline’u.

Jeśli minimalny przykład jest niemożliwy (bo np. problem wynika z integracji wielu systemów), opisz przynajmniej, które kroki są absolutnie konieczne, a które tylko „towarzyszą” błędowi. Dla maintainera to ogromna różnica, czy musi odpalić trzy serwisy i pięć kontenerów, czy wystarczy jeden.

Polowanie na duplikaty – jak szukać istniejących zgłoszeń

Dlaczego duplikaty zgłoszeń męczą maintainerów

Wyobraź sobie, że dostajesz co tydzień to samo pytanie na maila. Odpisywanie po raz dwudziesty piąty brzmi już mniej kusząco, prawda? Tak właśnie wyglądają duplikaty issue z perspektywy osoby prowadzącej projekt. Każde kolejne zgłoszenie tego samego problemu rozprasza dyskusję, rozbija historię diagnozy i utrudnia późniejsze szukanie rozwiązania innym użytkownikom.

Co gorsza, część duplikatów nie zawiera żadnych nowych informacji, więc nie przyspiesza rozwiązania. To trochę jak dopisywanie „+1, też mam ten problem” w osobnym zgłoszeniu, zamiast dołączenia się do istniejącego wątku. Jeśli poświęcisz parę minut na porządne poszukanie, zwiększasz szansę, że maintainer będzie miał czas na faktyczną naprawę, a nie na „sprzątanie” zgłoszeń.

Jak skutecznie przeszukiwać issue na GitHubie i nie tylko

Większość większych projektów korzysta z podobnych mechanizmów zgłaszania błędów: GitHub Issues, GitLab Issues, JIRA, własne bugtrackery. Niezależnie od narzędzia, zasada jest ta sama – nie ograniczaj się do jednego prostego hasła w wyszukiwarce.

Pomaga kilka prostych trików:

• Używaj fragmentów komunikatów błędu – najlepiej kilku słów, a nie całego loga. Często ktoś już raportował problem z tym samym komunikatem.
• Próbuj różnych słów kluczowych – zamiast tylko „crash przy eksporcie PDF”, spróbuj też „export pdf error”, „pdf output empty”, „export fails”. Ludzie różnie opisują ten sam objaw.
• Filtruj po etykietach – wiele projektów oznacza zgłoszenia np. jako bug, question, duplicate, wontfix. Przejrzenie samych bugów często szybciej prowadzi do celu.
• Szukaj w zamkniętych zgłoszeniach – część problemów została już rozwiązana albo świadomie zamknięta z wyjaśnieniem. Domyślnie wyszukiwarka pokazuje tylko otwarte issue, więc dodaj filtr „is:closed” lub odpowiednik w danym narzędziu.

Czasem pojedyncze slowo robi różnicę. Ktoś zgłosił „segfault przy imporcie dużych danych”, a ty szukasz „crash przy ładowaniu pliku”. Technicznie to to samo, ale wyszukiwarka nie zawsze to skojarzy. Jeśli pierwsza próba nie daje wyników, poświęć jeszcze chwilę na inną kombinację haseł – to często najtańsza inwestycja czasu w całym procesie.

Kiedy dopisać się do istniejącego issue zamiast tworzyć nowe

Jeśli znajdziesz zgłoszenie, które brzmi bardzo podobnie do twojego problemu, pojawia się pytanie: dopisać się czy zakładać nowe? Prosta reguła brzmi: jeśli objawy i kontekst są niemal identyczne, lepiej kontynuować istniejący wątek.

W komentarzu do istniejącego issue możesz dorzucić:

• informację o swojej wersji środowiska (czasem to pomaga zawęzić problem do konkretnej platformy),
• dodatkowy, jasny scenariusz reprodukcji, jeśli oryginalny opis jest skąpy,
• potwierdzenie, że bug wciąż występuje w najnowszej wersji, jeśli zgłoszenie jest starsze.

Są natomiast sytuacje, w których jednak lepiej założyć nowe issue i tylko podlinkować stare. Dzieje się tak, gdy:

• objawy są podobne, ale występują w innym module lub przy zupełnie innych krokach,
• stare zgłoszenie dotyczyło bardzo starej wersji i zostało zamknięte, a ty widzisz coś podobnego w nowszej – może to być nowa regresja, a nie dokładnie ten sam bug,
• projekt jasno prosi, żeby nie wskrzeszać bardzo starych wątków (tzw. necro-posting) i w razie wątpliwości zakładać nowe zgłoszenie z referencją.

Krótka notka w stylu „Wygląda jak duplikat #1234, ale dotyczy wersji 3.2.0 i środowiska X” bardzo ułatwia życie maintainerom. Widać, że nie otwierasz tematu w ciemno.

Jak porządnie odtworzyć błąd – reprodukcja krok po kroku

Dlaczego bez powtarzalnego scenariusza trudno ruszyć z miejsca

Programista, który dostaje zgłoszenie „czasem się sypie” jest w podobnej sytuacji co lekarz słyszący „czasem mnie coś boli”. Co ma z tym zrobić? Bez powtarzalnego scenariusza debugowanie opiera się na zgadywaniu, co mogło pójść nie tak. Dlatego w świecie open source tak często powtarza się pytanie: „Czy możesz podać dokładne kroki, żeby to odtworzyć?”.

Reprodukcja to opis działań, które – wykonane krok po kroku – prowadzą do błędu na czystym lub możliwie prostym środowisku. Nie musi być perfekcyjna, ale powinna być na tyle dokładna, żeby drugi człowiek, który nie zna twojego projektu, mógł ją powtórzyć.

Jak zapisywać kroki reprodukcji, żeby były czytelne

Nawet prosty scenariusz można zapisać chaotycznie albo klarownie. Cel jest prosty: osoba czytająca ma czuć się trochę jak przy dobrym przepisie kulinarnym – wystarczy trzymać się punktów, żeby dojść do tego samego efektu.

Przydatny schemat kroków wygląda np. tak:

1. Opis środowiska startowego (np. „nowo utworzony projekt X z domyślnymi ustawieniami”).
2. Konkretny zestaw komend lub akcji w GUI.
3. Opis danych wejściowych (np. struktura pliku, który importujesz, albo przykładowy JSON).
4. Oczekiwany rezultat.
5. Rzeczywisty rezultat (łącznie z komunikatem błędu, jeśli jest dostępny).

Zamiast ogólnego „otwieram projekt i się crashuje”, lepiej napisać:

1. Tworzę nowy projekt poleceniem `mytool init`.
2. Dodaję plik `config.yml` z minimalną zawartością (patrz niżej).
3. Uruchamiam `mytool build`.
4. Oczekiwanie: build się kończy, generując plik `output.bin`.
5. Rzeczywistość: narzędzie kończy się błędem `NullReferenceException` (pełny stacktrace poniżej).

Radzenie sobie z błędami, które występują „tylko czasami”

Błędy, które pojawiają się losowo, są najbardziej frustrujące – zarówno dla użytkownika, jak i maintainerów. Jednak nawet one rzadko są naprawdę „magiczne”. Zwykle istnieje jakiś wspólny mianownik, który można odkryć.

Przy takich problemach pomagają pytania pomocnicze:

• Czy błąd częściej występuje przy dużym obciążeniu (wiele równoległych procesów, duży ruch sieciowy)?
• Czy pojawia się tylko po dłuższym czasie działania aplikacji, a nie tuż po starcie?
• Czy zależy od typu danych (np. bardzo duże pliki, nietypowe znaki, konkretne formaty)?
• Czy wiąże się z akcjami typu „sleep / standby / hibernate” systemu?

Tworząc zgłoszenie, możesz uczciwie napisać, że błąd nie jest w pełni powtarzalny, ale opisać warunki, które zwiększają jego szansę wystąpienia. To już coś, z czym da się pracować. Z czasem, gdy pojawi się więcej podobnych raportów, maintainerzy mogą połączyć kropki.

Zbieranie dowodów: logi, zrzuty ekranu, przykładowe dane

Jakie logi są przydatne, a jakie tylko zaśmiecają zgłoszenie

Logi to często najcenniejsze źródło informacji dla osoby debugującej błąd. Problem w tym, że wielu użytkowników albo nie dołącza ich wcale, albo wkleja kilkaset linii niezwiązanego tekstu. Złoty środek polega na wyborze fragmentów, które faktycznie coś mówią o problemie.

Pomocne wskazówki:

• Zacznij od fragmentu zawierającego komunikat błędu i kilka–kilkanaście linii przed nim. To zwykle wystarczy jako pierwszy trop.
• Jeśli aplikacja ma różne poziomy logowania, spróbuj uruchomić ją w trybie debug lub verbose i wklej tylko tę część, która obejmuje jeden nieudany scenariusz.
• Wytnij ewidentnie nieistotne fragmenty (np. powtarzające się co sekundę „heartbeat ok”), zaznaczając, że zostały skrócone, np. [... powtarzające się logi serwera usunięte ...].
• Zamiast wklejać ogromny log w treści, rozważ wrzucenie go jako załączony plik lub gist, a w zgłoszeniu podaj tylko kluczowe fragmenty.

Jeśli masz wątpliwość, czy logi zawierają wrażliwe dane (tokeny, maile użytkowników, numer klienta), przeleć je szybko i zamaskuj takie elementy, np. zastępując je stałym wzorcem <TOKEN>. Lepiej poświęcić minutę na taką redakcję, niż później żałować wycieku.

Zrzuty ekranu i nagrania ekranu – kiedy pomagają

Zrzuty ekranu świetnie sprawdzają się przy problemach interfejsu użytkownika: źle wyrównane elementy, brakujące przyciski, błędne tłumaczenia, dziwne zachowanie po kliknięciu. Słowo „dziwnie się przesuwa” może znaczyć tysiąc rzeczy, natomiast screen bardzo szybko ustala, co konkretnie jest nie tak.

Dobre zrzuty ekranu:

• pokazują pełny kontekst okna (a nie tylko mały wycinek, jeśli to możliwe),
• mają zaznaczone najważniejsze miejsce (np. strzałką, obramowaniem) – można to zrobić najprostszym edytorem gra