6 Chyby QA a jak se jim vyhnout

Elkling předával svou moudrost

Sedm let zkušeností v oboru vývoje softwaru v oblasti zabezpečování kvality mi dává klamnou sebevědomí, abych si sedl ve svém houpacím křesle, shromáždil mladíky a začal vyprávět o tom, jak to bylo za starých dobrých časů, o chybách, které jsem udělal a nepříjemně nag na juniorech, abych se poučil z mých chyb. Když jsem všechny vědomě zazářil v praskajícím ohni (ano, teď je oheň, držte krok s fantazií) a já si bezohledně přeji přísný pohled a zahájím své kázání. Zde je šest chyb QA a jak se jim vyhnout!

1. Zapomeňte na větší obrázek

Když jeden začíná jako juniorský tester a má vzrušení z dobře odpočívaného štěněte zlatého retrívra, je nevyhnutelné občas zapomenout na větší obrázek. To je, když junior vyplní moji desku Jira vylepšeními, špatně zarovnanými pixely, ikonami, které jsou mírně mimo střed a chybí středníky, dva týdny předtím, než musím předložit konečného kandidáta na vydání. Je to také nejrychlejší způsob, jak mě vidět hyperventilující. V této fázi potřebuji ujištění, že hlavní funkce fungují, nic není přerušeno, pády jsou vzdálenou pamětí a aplikace je uživatelsky přívětivá a snadno dostupná - nikoli kontrola gramatiky a dokonalost uživatelského rozhraní.

Nejlepší věc na nových testerech je jejich nekonečná dychtivost najít co nejvíce chyb a ukázat se jako cenné. Nejhorší věcí na nových testerech je však jejich nekonečná dychtivost najít tolik chyb ... víte, jak to končí. Někdy mají tendenci soustředit se na drobné malé detaily v nejhorších možných okamžicích. Stanovení priority je něco, co se naučíme a časem začíná člověk pochopit, že je správný čas podat drobnosti a blížící se strašidelný termín pravděpodobně není ten čas.

2. Přidejte problémy na základě vašich pocitů

Myslím, že tato ikona bude vypadat lépe, pokud bude oranžová namísto modré. Mám pocit, že tuto logiku je trochu těžké pochopit, takže mám pocit, že musíme přidat nejméně čtyři další vyskakovací okna. Ne! Junior testeři nedostávají návrhy. Je to příliš drsné? Dobře, zkusím to znovu, juniorští testeři dostanou návrhy ve správný čas správným lidem.

Když začneme s vývojem prvku nebo modulu na začátku projektu, nejprve se vítají všechny návrhy. Kreativně jsme přemýšleli, protože musíme psát podrobné případy a uživatelské scénáře, abychom mohli psát podrobné a úplné testovací případy. To je situace, kdy architekti nebo designéři řešení jsou náchylnější poslouchat návrhy a vzít v úvahu naše nápady.

Pokud si opravdu myslíte, že váš vstup je cenný a provedli jste výzkum, pokračujte a oslňte nás. Pokud jsou však naše pracovní postupy, vykreslování a návrhy již schváleny, implementovány a testovány, je obvykle příliš pozdě na změnu věcí bez ohledu na to, jak skvělé mohou být vaše nápady. A nikdy neukládejte chyby pouze na základě vašich vlastních preferencí.

3. Zapomeňte na existenci svého návrháře

Když už mluvíme o vizualizacích, pracovních postupech a problémech, které se jich týkají, neexistuje rychlejší způsob, jak nepřítele zmlátit svého návrháře, než jít po hlavě a přidat zlepšení své práce nebo ještě horší - chyby týkající se jejich návrhů. Miluji své designéry a velmi věřím v jejich schopnosti, že pokud navrhli funkci jedním způsobem, pak mají velmi dobrý důvod to zálohovat. Vím, kolik úsilí věnují zkoumání různých myšlenek a vím, že jsou obvykle ve velmi úzké spolupráci s klientem a pravděpodobně si jsou více vědomi požadavků klienta na uživatelské rozhraní než já.

Pokud musím být naprosto upřímný, občas udělám tuto chybu a v zápalu okamžiku se rozhodnu přidat něco k prvku, aniž bych nejprve konzultoval svého návrháře. Dělám to s nejlepším úmyslem něco vylepšit, ale můj nejlepší úmysl znamená jen málo, pokud narušuji dohodnutý proces a přidávám neočekávané zpoždění.

4. Piss off vaše devs

Aha, devs může být zastrašující, devs může být dráždivý, devs může být arogantní a nevrlý. Ale devs jsou vždy váš nejlepší přítel, vždy! Takže zkuste to nejlepší a vytvořte si důvěryhodný vztah. Jdeš a broušíš se, dokud tě nesnášejí, troufám si říci, že tě mám rád. Protože happy devs = happy QAs. I když musíte slyšet tisíckrát „to není chyba, je to funkce“, kousnete si jazyk a vytrváte. Pokud nevěříte něčemu, co vám říká váš dev, můžete jít k nadřízenému a požádat o druhý názor. V ideálním případě je však nejlepší udržovat důvěryhodné partnerství. Musíte důvěřovat jejich zkušenostem a pak budou důvěřovat vaší kompetenci. Je to krásná symbióza, ale křehká.

Devs musí důvěřovat, že máte své záda, že i když chcete rozbít jejich kód, děláte to s nejlepším úmyslem a pro větší dobro. A musíte věřit, že někdy, velmi zřídka, je chyba skutečně funkcí. :)

Nejrychlejší způsob, jak vyrazit dev btw, je, když otestujete napůl provedený modul a přidáte spoustu chyb o věcech, které ještě nejsou implementovány. Dejte jim čas, nespěchejte a snažte se udržet své nadšení, dokud nebudou hotovi s jejich částí a vaše část může začít.

5. Předpokládejme, že jste příliš dobrý na dokumentaci

Ahhh, to jsem v kostce. Nejnáročnějším úkolem pro mě je psaní testovacích případů nebo úprava stávajících novými scénáři hran a informacemi, které jsem během testování odhalil. Když nashromáždíte určitou dynamiku a vyzkoušíte důvěru, začnete vynechávat základy. Časem se ocitnete příliš pod tlakem, abyste se obtěžovali podle šablony kontrolního seznamu, takže to děláte pamětí beze stop vašich výsledků. Ve své schopnosti jste si jisti, že zapomenete, že každé testování musí mít viditelnou stopu. Obzvláště, pokud projekt řešíte sami a víte o něm každý malý detail, zapomínáte na potřebu dokumentovat, a to se tak snadno vrátí a kousne vás do tushie.

Za to jsem vinen a nejdéle jsem přeskočil některé kroky, abych měl více času na další úkoly. V některých případech však vaše upřímné slovo nezáleží, pokud nemáte dokument, který vás zálohuje. Pokud například řeknete, že něco je regrese, protože dříve fungovala bezchybně, a pak vás někdo požádá, abyste jim o tom prokázali a nemůžete, vypadá to neprofesionálně. Nikdy nevíte, kdy budete převedeni na jiný projekt nebo někdo jiný musí převzít vaši práci, a toto někoho jiného bude úplně ztraceno, pokud jste nedokončili svou papírovou část.

6. Nedělat základy

Řekněme, že váš projekt je mobilní aplikace podporovaná pro Android a iOS. Tester junior kontroluje telefon Android a vidí selhání. Junior je extatický, pád je velký problém, takže si pospíší, aby jej přidali co nejdříve do Jiry a spustili alarm. Zapomínají se na všechny další kroky, které je třeba udělat před přidáním chyby, zejména důležitého. Před přidáním problému je trochu práce. První věcí je zkontrolovat duplikáty registračního systému, ať už to je cokoli. Nikdo nemá rád duplikáty a nutí vás vypadat nedbalě! Druhým je zkontrolovat na několika dalších místech a zjistit, zda se jedná o problém specifický pro zařízení, platformu nebo obecný problém. Proto by měli lépe zkontrolovat tablet se systémem Android a poté iOS zařízení atd. Také by bylo užitečné shromáždit některé protokoly, aby si vývojář mohl ušetřit čas a pokusit se o reprodukci a rychlou kontrolu protokolů. Je také užitečné vidět, jak často dokážete problém reprodukovat, děje se to pokaždé nebo trochu náhodněji. Izolujte přesné kroky k danému problému a také zkontrolujte možná předchozí sestavení a verze, abyste zjistili, zda se jedná o nově zavedenou regresi, nebo zda tam byla a stále chybí.

Tyto chyby jsou běžnou součástí cesty QA a jsou přirozeným krokem k procesu učení. Nyní, když jsem po cestě prošel tento vzácný náklad dědictví, dejte mi prosím vědět v komentářích níže, pokud jste vinni některou z těchto chyb, nebo možná existují ještě více neodpustitelné hříchy QA, které jsem zmeškal.