Problémy s automatizací testů a moderní kontrolou kvality

Jaké jsou některé běžné problémy s automatizací testů v agile a DevOps?

Moderní vývoj softwaru a QA se příliš zaměřují na automatizaci testů a nedostatečně na průzkumné testování.

Vydáváme kvalitnější software s více automatizovanými testy? Myslím, že ne!


Nedávno jsem narazil na příspěvek na sociální síti, který řekl

To, co dnes vidím na většině událostí testování a QA, je většinou DevOps, Continuous Integration a Test Automation.


I když je to všechno velmi pěkné, vidím automatizaci mnoha mizerných testovacích případů.



Vidím několik chyb hlášených během integračních testů a funkčních testů, i když jsou všechny automatizované.

V UAT uživatelé nacházejí stále více a více chyb, protože testovací týmy je v předchozích fázích nedokážou identifikovat.

Pokud nebudeme učit lidi, jak psát dobré testovací případy, skončíme s plně automatizovanými…


A moje interpretace ... je „kecy“. :-)

Podívejme se, co je opravdu se děje ve světě moderní QA a automatizace testů.



Problémy s moderní QA

Většina „automatizace testů“ v rámci agilního vývoje je v zoufalém stavu. Softwarový průmysl nalévá obrovské částky peněz na najímání „Test Automation Experts“ hlavně proto, aby získal pocit jistoty, že software, který vytvářejí, je vysoce kvalitní. Přesto se během UAT vyskytnou znatelné chyby a / nebo další problémy nebo se dostanou do produkčního prostředí. Tak o co jde?

Poznámka:Test Automation, mám většinou na mysli CIBULE Automatizace testů.

Automatizované testování je nyní srdcem každého moderního procesu vývoje softwaru. Jeho účelem je Pomoc dodávat vysoce kvalitní software opakovaně, ale je to opravdu tak?


Testují stále testeři?

Pravdou je, že ve většině agilních týmů testeři již netestují.

Ruční testování ztratilo svou ctnost díky vývojovým postupům a kulturám, jako jsou agilní a DevOps , které vytvořily předěl v prostoru QA - ti, kteří dokážou kódovat a ti, kteří neumí.

Často jste slyšeli věci jako: „Jsem 100% automatizační technik“ nebo „80% automatizace 20% manuální“, nebo ještě hůře, „Nesnáším manuální testování“. Šokující!

V DevOps jsme vedeni k přesvědčení, že vše by mělo být automatizováno. Není zde místo pro manuální zásah, např. ruční testování.


V dnešní době se většina testerů v agilním týmu snaží udržet krok s požadavkem „Test Automation“. Existuje tlak na automatizaci každého příběhu ve sprintu a není dostatek času na důkladné průzkumné testování.

Problém, zejména v agilním vývoji, spočívá v tom, že QA přebírají příběh uživatele a automatizují jeho akceptační kritéria. Jejich hlavním a jediným zaměřením je přitom zápasit se svými omezenými schopnostmi kódování, jen aby zvládli test.

Přirozeně to vytváří úzké zaměření, když vás zajímá pouze automatizace testu a jeho absolvování v kanálu sestavení. To jen dokazuje, co funguje v kritériích přijetí - správné nebo špatné - a máte tendenci zapomínat na celkový obraz.

Pokles v ručním testování

Stále více „tradičních testerů“ přechází na „agilní testování“ tím, že absolvují lekce kódování a stávají se techničtějšími.


Nechápejte mě špatně; to je všechno dobré. Věřím, že jako testeři bychom se měli vždy snažit učit se novým a vznikajícím technologiím, abychom zůstali vynalézaví. Pokud chceme testovat systém na vysoké úrovni kvality, měli bychom rozumět technologickému zásobníku.

Skutečným důvodem, proč většina manuálních testerů využívá tyto iniciativy, je však obecná víra, že „automatické testování“ je lepší než manuální testování a hej, kódování je zábava, že?

Poznámka:Při ručním testování jsem NE odkazující na starý školní způsob sledování skriptu a provádění kroků. Mám na mysli takzvané „průzkumné testery“ - ty, kteří provádějí skutečné testování a jsou zvědaví zkoumat chování systému pomocí zajímavých a promyšlených scénářů.

Bohužel se zdá, že na trhu průzkumných testerů dochází k velkému poklesu. To je zcela evidentní. Spusťte na libovolném pracovním místě IT několik vyhledávacích dotazů pro „manuální tester“ a „automatizační tester“ a výsledek si sami prohlédněte.



Problémy s automatizací testů

Nyní se podívejme, proč většina úsilí v oblasti automatizace testů nepřináší žádnou hodnotu.

Časté chyby, které vidím opakovaně:

  • Nesprávné očekávání automatizovaných testů
  • Automatizace testů ve špatné vrstvě, ve špatný čas a pomocí nesprávných nástrojů
  • Automatizace zbytečných testů
  • Zanedbávání důležitých oblastí
  • Chybějící klíčové scénáře

Špatná očekávání

Před časem jsem napsal příspěvek na blogu proč byste chtěli automatizovat test ? Pokud jste si ji ještě nepřečetli, stojí za to si ji přečíst.

Shrnutí tohoto článku spočívá v tom, že automatizujete testy, které chcete pravidelně spouštět. Podle definice jsou to vaše regresní testy, které potvrzují, že systém stále funguje.

Pokud však automatizované kontroly naleznou spoustu regresních problémů, zpochybnil bych dovednosti vývojářů a vývojový proces. Automatizované testy uživatelského rozhraní by neměly být [zadržovány na úkor] nebo [kompenzovány] za mizerné kódování.

Špatná vrstva, špatné nástroje a špatný čas

Většina „testovacích automatizačních techniků“ v agilních týmech sleduje příběh uživatele a automatizuje jeho akceptační kritéria. Většinou se to děje kombinací selenu a okurky.

Moderní webové aplikace jsou nyní jasně rozděleny mezi backend a frontend. Backend se většinou skládá z řady webových služeb REST nebo API se snadno dostupnými koncovými body.

Logiku aplikace lze otestovat na vrstvě API. Většina techniků automatizace testů se však uchýlí k ověření funkčnosti ve vrstvě uživatelského rozhraní, což je přinejlepším těžkopádné.

Existují testovací nástroje, například Karate a Rest-Assured, které zjednodušují testování API. Během vývoje bychom měli tyto nástroje využívat. Je smutné, že někteří inženýři automatizace testů o tom ani nevědí základy HTTP , natož aby mohl psát scénáře testování API.

Pokud jde o automatizaci testů uživatelského rozhraní, Cypřiš je skvělý nástroj. Je to spíše nástroj TDD pro front-end vývojáře. Vývojáři dostanou velmi rychlou zpětnou vazbu o chování nových komponent uživatelského rozhraní.

Karate i Cypress slouží jako „vývojové testovací nástroje“, tj. Nástroje, které řídí a podporují vývoj. Oba jsou lehké, snadno se integrují a mohou poskytnout důvěra v rozvoj .

Pak můžeme použít selen nebo cypřiš k navržení jen hrstky scénářů, které procvičují systém end-to-end. Tyto scénáře tvoří naši lehkou regresní sadu a poskytují důvěra v kontinuitu podnikání .

Docela často slyším věci jako: „počkáme, než je funkce plně vyvinutá a stabilní, než provedeme automatizované testy“. Každý vědomý tester ví, že chyby nových funkcí převyšují regresní chyby. Existuje větší šance na nalezení problémů s aktuální vyvíjející se funkcí než stabilní funkce.

Pokud se chystáte trávit čas automatizací testů, proveďte je paralelně s vývojem, když mohou poskytnout větší hodnotu.

Automatizace zbytečných testů

Neautomatizujte každý „test“ jen kvůli tomu. Vložte do hry nějaký proces myšlení. Prostudujte si architektonické diagramy na vysoké a nízké úrovni. Zeptejte se, co se může pokazit. Prozkoumejte integrační body a vyhledejte potenciální body selhání.

Přijměte v automatizaci přístup založený na riziku, jak byste (doufejme) udělali s celkovým přístupem k testování. Jaká je pravděpodobnost selhání něčeho a jaký je dopad selhání? Pokud je odpověď vysoká, pak by tyto scénáře měly být automatizovány a provedeny při každém sestavení.

V každém sprintu často skončíme psaním automatizovaných testů kolem příběhů uživatelů pro tento sprint a zapomeneme na integraci s dalšími funkcemi. Existují buď slabé, nebo žádné integrační testy.

Pamatujte, že automatizace „testů“ nějakou dobu trvá. Mějte také na paměti, že automatizací testu opravdu netestujete, pouze pouze kontrolujete, zda daná funkce splňuje některá kritéria přijatelnosti.

Vy nemůže automatizovat testování, ale můžete také automatizovat kontrolu známých faktů.

Proto pokaždé, když strávíte automatizováním „testu“, myslete na čas, který ztrácíte netestováním!

Zanedbávání důležitých oblastí

Vidím stále více této nedbalosti od zrodu kultury DevOps.

V DevOps je doručovací kanál spolu s nasazovacími skripty páteří vývoje a doručování softwaru, přesto se sotva někdy otestují.

Za posledních několik let bych mohl snadno říci, že jsem viděl mnohem více „environmentálních problémů“ než funkčních chyb. Problémy s prostředím, jako jsou problémy se serverem CI, skripty nasazení, testovacím prostředím atd.

Problémy životního prostředí mají vážný dopad na vývoj a testování. Spotřebovávají spoustu času pro vývojáře a DevOps a masivně zpomalují proces nasazení, přesto však není třeba uvažovat o testování, a tak předcházet těmto problémům.

Přijímáme je pouze jako součást dodávky moderního softwaru.

Vynakládáme spoustu úsilí na automatizaci funkčního chování a zcela ignorujeme „věci“, na kterých záleží nejvíce. Ještě horší je, když se musíte spolehnout na testy selenu, abyste zjistili, zda nasazení fungují nebo ne!

Chybějící klíčové scénáře

Scénáře jsou králem! Koneckonců jsou to scénáře, které odhalují chyby.

Do výroby často uniká vážný problém, protože na tento konkrétní scénář nikdo nepomyslel. Na počtu provedených automatických testů nezáleží. Pokud scénář nebyl vymyslen nebo testován, sodův zákon nám říká, že je v něm chyba.

Bohužel ve většině agilních vývojových prostředí není této důležité činnosti „Scénářový workshop“ věnováno dostatečné úsilí.



Problémy s procesem

Podívejme se, jak se výše uvedené problémy projevují v typickém scénáři vývoje:

  • Vlastník produktu píše uživatelské příběhy s žádnými nebo minimálními kritérii přijetí.
  • Nedostatek času věnovaného relacím upřesnění příběhu k projednání různých scénářů uživatelského příběhu.
  • Kritéria přijetí jsou interpretována jako přejímací zkoušky - Ano, je mezi nimi rozdíl !
  • Testeři automatizují pouze kritéria přijetí v uživatelských příbězích, většinou pomocí selenu a / nebo okurky.
  • Automatizované testování je téměř vždy odpovědností „automatizačních testerů“.
  • Vývojáři nemají tušení, co je zahrnuto v testovacích balíčcích, nebo dokonce neví, jak provádět automatické testy.
  • Automatizované testy jsou přidávány do stále se rozšiřujícího „regresního balíčku“, takže jejich pokaždé trvá déle a déle.
  • Automatizované funkční testy uživatelského rozhraní jsou integrovány do kanálu sestavení, což je dobré, ale…

Vývojář prosazuje jednoduchou změnu a musí počkat 30 minut, než se automatizované testy změní na zelenou, než bude možné nasadit novou funkci nebo opravu chyby do výroby. 30minutové čekání je pouze v případě, že testy projdou poprvé. Pokud selžou kvůli problémům s testováním nebo prostředím, může to trvat déle.

Jelikož probíhají automatizované testy a QA vyšetřuje náhodná selhání, vývojář a / nebo vlastník produktu ověřili novou implementaci a rádi ji vydají, ale nemohou, protože sestavení není zelené.

Po nějaké době buď sestavení zezelená, nebo bude vedení frustrováno neúspěšnými testy a rozhodne se přesto vydat. Potom BOOM, po několika minutách výroby, došlo k nárůstu 500 chyb serveru.

Selhání infrastruktury

Zdá se, že selhání vykazují podobný vzorec

  • Selhání v integračních bodech.
  • Selhání komunikace s aplikacemi třetích stran.
  • Webové služby nejsou „nahoře“ a selhávají požadavky na koncové body API.
  • Chybná konfigurace na jednom z virtuálních počítačů nebo uzlů, což má za následek občasné problémy.

A přesto neexistuje žádný proces pro kontrolu těchto problémů jako součást procesu vývoje nebo dodání.

Inženýři automatizace testů se zaměřují na automatizaci funkčních testů. Neexistuje žádný důraz na výkon, zabezpečení nebo odolnost. A určitě neexistuje testování infrastruktury!



souhrn

Nastal čas přesunout naše zaměření z automatizace funkčních testů, které mají malou šanci zachytit funkční problémy, na vážnější a běžnější problémy životního prostředí, které trápí vývoj.

Automatizace testů, pokud je provedeno špatně nebo bez myšlenkového procesu , je ztráta času a nikomu neposkytuje žádnou hodnotu. Mizerné automatizované testy mohou znamenat obrovské náklady na údržbu a bránit vývoji. Jediným řešením je nakonec binování testů.

Při vývoji moderního softwaru je většina úsilí „Test Automation Engineers“ vynakládána na boj s automatizačním kódem a na to, aby „testy“ fungovaly, místo aby se soustředily na správné testování a zkoumání systému.

Doslova není dostatek času na psaní automatizačního kódu a provádět průzkumné testování. Automatizujeme příběh za příběhem a zapomínáme na integrační testy, zapomínáme na celkový obraz.

Často skončíme s prováděním mnoha automatizovaných testů, ale průzkumné testování najde většinu chyb. Potom zpětně napíšeme automatický test na chyby, které byly nalezeny průzkumným testováním, abychom zachytili regresní chyby.

Měli bychom být selektivní v tom, co automatizovat, a posuzovat naše rozhodnutí na základě rizika. Co se může pokazit, jaká je pravděpodobnost, že se to pokazí, a jaký bude dopad na uživatele nebo firmu, pokud se pokazí?

Pokud podnikáte v oblasti „Test Automation“, nepoužívejte prosím selen k testování funkčnosti API nebo komponent uživatelského rozhraní. Místo toho použijte Selenium k automatizaci jen hrstky užitečných a kritických scénářů pro zajištění důvěry v kontinuitu podnikání před každým vydáním.

A konečně, pokaždé, když strávíte automatizováním „testu“, myslete na čas, který ztrácíte netestováním!

Další čtení: