Takto začneš

Zoznam otázok je cennejší než zhrnutie — s ním ideš za analytikom skôr, než začneš testovať.

Tu je požiadavka: [text]. Aplikáciu používajú [kto] a beží v [prostredie].

Zhrň v piatich bodoch, čo sa má po zmene diať. Potom vypíš, čo v požiadavke chýba na to, aby sa dala otestovať: nejednoznačné formulácie, chýbajúce chybové stavy, nepovedané hranice, nepokryté role používateľov.

Nič si nedomýšľaj — čo v texte nie je, daj medzi otázky.

Kritérium, ktoré sa nedá pozorovať, nie je kritérium. Model ich sformuluje, schváliš ich ty.

Toto má funkcia robiť: [opis vlastnými slovami]. Používateľ je [kto] a robí to preto, aby [dôvod].

Navrhni akceptačné kritériá tak, aby sa každé dalo overiť pozorovaním — kto, za akých podmienok, čo urobí a čo je viditeľný výsledok. Zvlášť pridaj kritériá pre chybové a hraničné stavy.

Ak je niečo v mojom opise nejednoznačné, spýtaj sa namiesto domýšľania.

Číslo, kategórie a tvar tabuľky sú polovica promptu. Bez nich dostaneš učebnicu.

Tu je požiadavka: [text]. Prostredie: [kde to beží, aké role, aké jazyky].

Navrhni dvanásť testovacích prípadov — pozitívne, negatívne aj hraničné — v tabuľke Názov / Predpoklady / Kroky / Očakávaný výsledok. Označ, ktoré by si automatizoval a prečo.

Na záver vypíš tri riziká, ktoré by som mal preskúmať ručne. Čo v požiadavke nie je, daj na koniec ako otvorenú otázku.

Odpoveď je checklist pre tvoju kontrolu, nie ortieľ. Aj tak nájde kategóriu, ktorú si vynechal.

Toto sú moje testovacie prípady pre [funkcia]: [zoznam]. Aplikácia robí [čo] a používajú ju [kto].

Aké kategórie testov mi chýbajú? Zoraď diery podľa rizika a pri každej napíš jednou vetou, čo by sa v praxi stalo, keby tam tá chyba naozaj bola.

Nepíš mi späť to, čo už v zozname mám.

„Vygeneruj to kódom“ je rozdiel medzi platnými dátami a dátami, ktoré len vyzerajú platne.

Potrebujem vymyslené testovacie dáta — žiadne skutočné, žiadne z produkcie.

Vygeneruj [koľko] riadkov ako [formát] so stĺpcami [stĺpce a ich formáty]. Mená a adresy z [jazyk či región], vrátane diakritiky. Pridaj hraničné hodnoty: [aké hranice dávajú zmysel].

Kde je potrebný kontrolný súčet alebo väčší objem, vygeneruj dáta kódom, nie odhadom. Ku každému hraničnému riadku pripíš, čo testuje.

Klasika, na ktorú sa v zhone zabúda — a pritom je to pätnásť riadkov, ktoré použiješ znova a znova.

Mám vstupné pole [na čo je, aké má obmedzenia] v [webová aplikácia / mobilná aplikácia].

Daj mi pätnásť problematických vstupov, ktoré by som doň mal skúsiť: dĺžky, špeciálne znaky, emoji, neviditeľné medzery, text sprava doľava, znaky, ktoré rozbíjajú spracovanie.

Ku každému napíš jednou vetou, čo testuje a aké správanie by som mal považovať za správne.

Ukážka jedného vášho bugu spraví z modelu prepisovača. „Označ slovom over“ ukáže diery v tvojom pozorovaní.

Toto sú moje hrubé poznámky z testovania: [poznámky]. Prostredie a verzia: [kde to bolo]. Kde to funguje správne: [referenčné prostredie].

Sprav z nich bug report v sekciách Pozorované správanie / Očakávané správanie / Kroky na zopakovanie. Kroky očísluj, píš vecne.

Nič si nedomýšľaj — čo v poznámkach nie je, označ slovom „over“ a nechaj to v texte. Neuvádzaj príčinu ani vinníka. Drž sa štýlu tejto ukážky: [jeden váš bug].

Chyba, ktorá sa deje občas, sa reportuje najhoršie. Toto z poznámok vytiahne, čo mali tie pokusy spoločné.

Chyba sa deje len občas: [čo sa deje a ako často približne]. Toto som robil pri jednotlivých pokusoch: [poznámky, aj tie neusporiadané].

Nájdi, čo mali úspešné pokusy o zopakovanie spoločné, a navrhni čo najspoľahlivejšiu postupnosť krokov. Zvlášť vypíš podmienky, ktoré som mohol prehliadnuť (poradie, čakanie, dáta, používateľ, prehliadač).

Netvrď, že to funguje — napíš, ako si to mám overiť.

Reťaz udalostí sa lepšie prepisuje do krokov než výpis. A hypotézy sú na overenie, nie do reportu.

Toto je [chybová hláška / výpis z logu], ktorý som videl pri [čo si robil]. Citlivé údaje som odstránil.

Povedz mi po ľudsky, čo sa podľa toho stalo a v akom poradí. Potom daj tri najpravdepodobnejšie miesta, kde to vzniklo, a ku každému napíš, ako to viem ako tester overiť zvonku.

Nepíš mi opravu kódu. Čo z výpisu nevyplýva, označ ako dohad.

Poradie s odôvodnením sa dá obhájiť na porade. Zoznam bez neho nie.

Toto je moja regresná sada: [zoznam testov alebo oblastí]. V tomto vydaní sa mení [čo]. Najviac používaná časť aplikácie je [čo] a najviac bolí, keď padne [čo].

Zoraď testy do troch skupín: musí prejsť pred vydaním, spustím, ak zostane čas, tentoraz vynechám. Pri každom jednou vetou prečo.

Zvlášť vypíš testy, ktoré podľa názvu a krokov pravdepodobne neoverujú nič podstatné.

Odpoveď býva prekvapivo krátka. To je presne ten nález, kvôli ktorému sa to oplatí spýtať.

Tu je jeden z našich automatizovaných testov: [test].

Najprv krok za krokom vysvetli, čo robí a čo naozaj overuje — a čo z toho, čo by človek čakal, neoveruje.

Potom vypíš riziká krehkosti (pevné čakania, závislosť od poradia, krehké lokátory, časové predpoklady) a chýbajúce kontroly, zoradené podľa dôležitosti. Ak pomenuješ funkciu alebo metódu, ktorú v teste nevidíš, označ to.

Posledná veta je najdôležitejšia v celom balíčku: model nič nespustil, overené je len to, čo si mu dal.

Toto je stav testovania pred vydaním: [čo je otestované, čo je otvorené, čo sa nestihlo a prečo].

Napíš tri verzie toho istého zhrnutia: (1) pre vývojový tím, (2) pre projektového manažéra — bez QA žargónu, max 150 slov, (3) do e-mailu k vydaniu, päť viet.

V každej uveď, aké riziko zostáva otvorené a čo treba na jeho zavretie. Netvrď, že niečo je overené — vychádzaj výlučne z toho, čo som napísal.

Prípady pokryjú obrazovku, scenár pokryje cestu. Chyby na prechodoch medzi krokmi inak nikto nenájde.

Používateľ [kto] chce dosiahnuť [cieľ] a prechádza pritom cez [kroky alebo obrazovky, ktoré poznáš].

Napíš tri end-to-end scenáre: bežnú cestu, cestu s prerušením (odhlásenie, zavretie okna, výpadok siete) a cestu s chybou používateľa. Pri každom kroku napíš, čo mám v tom momente skontrolovať.

Označ miesta, kde sa scenár opiera o predpoklad, ktorý som ti nedal.