minden solo teszter odakinn azt javaslom, vezető rendszeres bug bash/mob tesztelési tevékenység. Ez egy olyan tevékenység, amelyet a sprint/feature dev ciklus végén futtathat. Meghívod a csapatot, hozol egy kis harapnivalót/italt, és mindenkit tesztelsz körülbelül egy órán keresztül.
Beállítás
érdemes meggyőződni arról, hogy jó eszköz/böngésző lefedettséggel rendelkezik, biztosítva, hogy mindenki készen álljon az adatokkal/eszközökkel. Ön is szeretné, hogy készítsen néhány segítséget dokumentumok, hogy segítsen az embereknek az induláshoz. Szeretem, hogy egy mindmap lefedettségi ötletek előtt készített kézzel, így az emberek egy vizuális mutatója, hogy mit tesztelnek. Lehet, hogy létrehozok egy csomó tesztfiókot is, mielőtt átadom őket a csapatnak.
könnyű hibajelentés
ösztönöznie kell a könnyű hibajelentést;
- lehet, hogy az emberek hibákat írnak a cetlikre
- adjon hozzá hibákat egy megosztott táblázathoz
- vagy emelje fel a Jira hibákat közvetlenül a Slack-ből a /jirio hibakeresés létrehozása parancsikon segítségével
a hangsúlyt a hibák megtalálására kell helyezni, nem pedig arra, hogy elkapják őket. Mindig tisztázhatja a problémákat a bug bash után, ha további információra van szüksége.
mit kell tesztelni egy bug bash-ban
van egy 3 lépéses heurisztikám annak eldöntésére, hogy mit kell tesztelni (gondolkodj; útmutató vagy hüvelykujjszabály):
- mi változott mostanában? A változás új kockázatot jelent. milyen funkciók épültek? Milyen kód lett újraírva? Milyen könyvtárakat frissítettek? Fókuszálja a csapatot, hogy először tesztelje ezeket a területeket
- regressziós tesztelés. Legyen egy ellenőrzőlista, amely legfeljebb egy tucat forgatókönyvet tartalmaz az alapvető funkciókról (talán a regisztráció, a kifizetések és a legfontosabb dolgok körül, amelyeket az emberek a termékkel csinálnak). Kérd meg az embereket, hogy fontolja meg ezeket az eseteket, miközben csinál 1), talán kérni az embereket, hogy ott neve mellett egy esetben, amikor tesztelik, így kap egy ötletet lefedettség
- milyen más tesztelés kellene/tudnánk csinálni? Néha lehet, hogy van értelme, hogy nem egy toll teszt bug bash munkamenet vagy a teljesítmény tesztelése bash vagy egy kereszt böngésző teszt bash, de nem kell, hogy megtörténjen minden alkalommal
teszt a termelés
ha tudsz; teszt a termelés. Nincs ehhez hasonló környezet.
de ha nem tudsz tesztelni a gyártásban, győződj meg róla, hogy a tesztkörnyezet stabil, az adatok be vannak állítva, és megadtad a csapatodnak a “Ne érintse meg, kivéve a bug Bash tesztelést” kérést.
post Bug Bash
mindenképpen köszönd meg az embereknek az idejüket, számold fel a hibákat és Adj dicsőséget a legjobb bug vadászodnak. A tesztelés / minőség végül is a csapat felelőssége. Küldj egy köszönöm e-mailt az eredményekkel és a díj trófeákkal. Már kiosztotta ezt a trófeát egy orrszarvú bogár gyanta egy trófea bázis az első számú bug vadász előtt:
