pro jakýkoli sólový tester doporučuji vést pravidelnou testovací aktivitu bug bash / mob. Je to aktivita, kterou můžete spustit na konci cyklu sprint / feature dev. Pozvete tým, dát si nějaké občerstvení/nápoje dohromady a nechat všechny testovat asi hodinu.
Setup
možná budete chtít, aby se ujistil, že máte dobré zařízení / prohlížeče pokrytí tím, že zajistí každý je nastaven s daty / zařízení před rukou. Možná budete chtít připravit nějaké dokumenty nápovědy, které lidem pomohou začít. Líbí se mi mít mindmap na pokrytí myšlenky připravené před rukou, takže lidé mají vizuální indikátor toho, co testují. Mohl bych také vytvořit spoustu testovacích účtů před rukou a distribuovat je do týmu.
hlášení lehkých chyb
měli byste podporovat hlášení chyb s nízkou hmotností;
- možná lidé píší chyby na sticky notes
- přidat chyby do sdílené tabulky
- nebo zvýšit chyby Jira přímo z Slack pomocí a / jirio vytvořit zkratku chyby
důraz by měl být kladen na hledání chyb, nikoli na to, jak je nahlásit. Vždy můžete vyjasnit problémy dále po bug bash, pokud potřebujete více informací.
co testovat v bug bash
mám 3 krok heuristické pro rozhodování o tom, co testovat (myslet; průvodce nebo pravidlo):
- co se v poslední době změnilo? Změna přináší nové riziko. jaké funkce byly postaveny? Jaký kód byl změněn? Jaké knihovny byly aktualizovány? Zaměřte tým na testování těchto oblastí nejprve
- regresní testování. Mají kontrolní seznam nanejvýš tucet scénářů základních funkcí (možná kolem registrace, platby a hlavní věci, které lidé dělají s vaším produktem). Požádejte lidi, aby zvážili tyto případy při provádění 1), možná požádejte lidi, aby tam dali jméno vedle případu, když ho testují, abyste získali představu o pokrytí
- jaké další testování by mělo/mohlo bychom udělat? Někdy to může mít smysl udělat pen test bug Bash relace nebo testování výkonu bash nebo cross browser test bash, ale to nemusí stát pokaždé
Test ve výrobě
, pokud je to možné; test ve výrobě. Není tam takové prostředí.
ale pokud nemůžete testovat ve výrobě, ujistěte se, že vaše testovací prostředí je stabilní, vaše data jsou nastavena a dali jste svému týmu požadavek „Nedotýkejte se kromě testování bug bash“.
Post Bug Bash
nezapomeňte poděkovat lidem za jejich čas, spočítat chyby a dát slávu svému nejlepšímu lovci chyb. Testování / kvalita je přece týmová odpovědnost. Pošlete e-mail s poděkováním s výsledky a oceněními. Tuto trofej brouka nosorožce v pryskyřici na základně trofeje jsem předal našemu lovci brouků číslo jedna: