Test Like Google: Best Practices from Industry Giants (03.29.24)

Sledovaním ich metód a prístupov v pracovných tokoch sa môžeme od priemyselných gigantov veľa naučiť.

Ako sa im darí udržiavať proces testovania softvéru v miliónoch kódových riadkov?

Ako organizujú pracovný tok s tisíckami inžinierov zabezpečovania kvality?

Ako zvládajú rozšírenie projektu?

Skúsenosti spoločností ako Google alebo Spotify môžu pomôcť zlepšiť procesy testovania v malých spoločnostiach a tímy.

Pozrime sa podrobnejšie na to, ako testujú obri.

Google: dôležitosť pokrytia kódom

Napriek tomu mnoho technikov argumentuje o dôležitosti takejto miery efektívnosti testovania softvéru ako pokrytie kódu. Špecialisti zo spoločnosti Google trvajú na tom, že údaje o pokrytí kódu môžu byť cennými informáciami na vyhodnotenie rizík a úzkych miest v testovacej činnosti. Carlos Arguelles, Marko Ivanković a Adam Bender zdieľajú osvedčené postupy týkajúce sa pokrytia kódu:

  • Pokrytie kódu môže pomôcť znížiť počet chýb a zlyhaní. Skúsenosti technikov QA z Googlu ukázali, že zvyšujúce sa pokrytie kódom vedie k zmenám v prístupoch a postojoch k testovaniu. Tímy, ktorých primárnym cieľom je pokrytie kódu, majú tendenciu robiť lepšie testovateľné svoje produkty. Píšu efektívnejší kód na testovanie, aby dosiahli ciele testovania jednoduchšie a menej časovo náročné.
  • Pomocou testovania mutácií zabezpečte vysoké pokrytie testom. Kompletné pokrytie kódu môže byť zbytočné a nezaručuje vysoko kvalitné pokrytie testu. Vysoké percento pokrytia kódom neznamená, že všetky funkcie boli testované správne. To znamená, že kód bol celkovo testovaný. Na zaistenie vysokej kvality pokrytia testom odporúčajú odborníci spoločnosti Google používať testovanie mutácií. Táto metóda zahŕňa implementáciu malých zmien kódu a kontrolu toho, ako ich testovacie sady identifikujú.
  • Percento pokrytia kódom závisí od mnohých faktorov. Nemali by sme sa usilovať o vysoké pokrytie kódom, ale nízke pokrytie vedie tiež k veľkému počtu zlyhaní. A otázkou je, aké je konkrétne pokrytie kódu pre konkrétny systém? Pri odpovedi na túto otázku by sme mali zvážiť také veci, ako je kritickosť, zložitosť a frekvencia zmeny kódu. Pokrytie kódu je obchodné rozhodnutie a mali by ho definovať vlastníci produktu.
  • Analyzujte, čo pokryť. Nemôžeme získať 100% pokrytie kódu, takže technici QA by to mali dodržiavať sú zahrnuté najcennejšie časti kódu. Tím vývojárov by mal diskutovať a nemyslieť na to, koľko riadkov kódu je pokrytých, ale čo konkrétne je to pokryté.
Spotify: spoľahlivá stratégia

Spotify je rýchlo rastúca spoločnosť. Bola založená v roku 2008 so 150 zamestnancami. V roku 2019 počet zamestnancov stúpol na 4 405. Spotify dnes slúži asi 300 miliónom používateľov na celom svete, čo z neho robí najpopulárnejšiu streamovaciu službu na svete.

Môžeme sa naučiť lekcie o tom, ako Spotify rozširuje svoje testovanie a vývojové procesy.

  • Stanovte produktové ciele pre tím QA. Spotify má tímy s rôznymi funkciami. Každý tím má ciele a súbor osobitných zručností potrebných na dosiahnutie týchto cieľov. Štruktúra tímu závisí od cieľov. Niektoré tímy teda pozostávajú iba z vývojárov a niektoré majú vývojárov a testerov. Testéri teda úzko spolupracujú s vývojovým tímom a zameriavajú sa na primárne ciele produktu. Takýto prístup umožňuje spoločnosti Spotify efektívne škálovať vývojový proces.
  • Testovanie automatizácie je nástroj, ale nie všeliek. Manažér testovania a vývoja v Spotify Kristian Karl tvrdí, že softvérových testerov nemožno nahradiť automatizáciou. Testovanie si vyžaduje ľudské skúsenosti a znalosti. Automatizačné testovanie je robustný nástroj na urýchlenie procesu, ľudia sa však rozhodujú a analyzujú automatizované správy. Spotify používa automatizáciu ako jeden z nástrojov na škálovanie. Umožňuje testerom ponechať rutinu pre algoritmy a zamerať sa na ciele produktu.
SpaceX: neustále testovanie je nevyhnutné

SpaceX je inovatívna spoločnosť známa pre komerčnú vesmírnu dopravu, opakovane použiteľný systém vypúšťania a vysoká účinnosť.

Nicholas Chaillan, vedúci softvéru pre letectvo, uviedol, že systém vývojového oddelenia SpaceX je päťkrát efektívnejší ako spoločnosti s klasickým pracovným tokom. Ako sa SpaceX vyrovnáva s takýmto výkonom v procese testovania?

DevOps a agilné prístupy umožňujú technikom SpaceX QA poskytovať testovanie hromadnej automatizácie. Počas vývojového cyklu poskytujú testeri nepretržité testovanie, aby získali okamžitú spätnú väzbu a eliminovali existujúce riziká. Preto pracujú proaktívne, často a včasne.

Spoločnosť vyvinula stratégiu implementácie nepretržitého testovania do procesu vývoja.

  • Stanovte prioritu hodnoty. Rovnako ako Google, aj SpaceX odporúča používať metriky pokrytia kódu, aby ste pochopili, čo by ste mali automatizovať a čo nie. Pomáha optimalizovať nepretržité testovanie a zdokonaľovať aktivity, ktoré sa už podnikajú.
  • Kľúčom je automatické komplexné testovanie. Urobte z analýzy vplyvu súčasť neustálej integrácie. Umožňuje spoločnostiam analyzovať, ako môže pridanie nových funkcií alebo zmena kódu ovplyvniť celkový systém alebo niektoré jeho časti.
  • Tím by mal mať stabilné a ľahko replikovateľné testovacie prostredie. Nástroj ako Virtual Machine Snapshot vám môže pomôcť uložiť stav údajov, vrátiť sa k testovaniu alebo pokračovať v práci.
  • Na analýzu správ o testovaní používajte umelú inteligenciu a strojové učenie. AI - nástroje založené na urýchlení nasadenia a optimalizácii procesu testovania.
  • Vybudujte robustnú architektúru nepretržitej integrácie. Hlavnou výhodou systému CI sú krátke obdobia medzi zostavením a testami kódu. . Nepretržité testovanie musí byť zapojené do procesu vývoja a musí zahŕňať potrebné typy testovania.
  • Zhrnutie

    Každá spoločnosť má svoju stratégiu, postup a prístupy k testovaniu. Každý tím vyberá a upravuje proces testovania na základe konečných cieľov a schopností produktu. Hlavnou úlohou každého špecialistu je myslieť na klienta a koncového používateľa, prispôsobiť sa novým požiadavkám a prijať skúsenosti najlepších v odbore.


    YouTube Video: Test Like Google: Best Practices from Industry Giants

    03, 2024