Testujeme software Testujeme software
  • Úvod
  • Blog
  • Nástroje
  • Slovníček
Testujeme software Testujeme software
Testujeme software Testujeme software
  • Úvod
  • Blog
  • Nástroje
  • Slovníček
  • Blog

Software testing očima nováčka, díl I.

  • 24. 2. 2023
  • Vojtěch Camfrla
Total
0
Shares
0
0
0

Rozbiju to, či nerozbiju, to je oč tu běží… Nebo ne?

Opravdu je testování jen o hledání chyb, potažmo škodolibé snaze rozbíjet vývojářům jejich dítka? Opravdu je to jen vstupní krok do světa IT pro lidi, kteří neumí programovat? Opravdu to může dělat každý (a nejspíš to ani není potřeba)?

Softwarové testování je poměrně specifický tím, že je s ním na jednu stranu spojena spousta mylných, leč hluboce zarytých představ, a na stranu druhou si pod tímhle pojmem spousta lidí nedovede vlastně lautr nic představit. Když jsem na pozici testera nastoupil já, v kruhu svých známých jsem odpovídal častěji na „A co teda jako děláš?“ než na gratulace. No, a upřímně bylo často jednodušší odpovědět některým z oněch klišé, protože jakkoliv nad nimi lidi „od fochu“ rádi obracejí oči v sloup, rámcovou představu laikovi zkrátka dají. Bez ohledu na to, že je naše každodenní pracovní realita často všechno, jen ne tak triviální. IT je dnes ale obrovské téma a jsou do něj vyloženě vábeni i lidé z úplně jiných – včetně netechnických – oborů. I mezi mými přáteli se tak našli tací, kterým ledabylá odpověď o hledání chyb nestačila. Takže… co teda jako dělám?

Pokud se o toto téma už nějakou dobu zajímáte a pojmy ze světa vývoje softwaru vám nejsou cizí, o roli testera ve Scrum týmu se skvěle rozepsal už Honza. Nicméně já, jakožto člověk, který měl ještě před pár měsíci pojmy jako Scrum, Agile či regresní testy v (samo)studijních osnovách, bych s dovolením udělal pár kroků zpět. Znovu tu naši práci definuji trochu víc po lopatě a tento cyklus článků věnuji především lidem, kteří o kariéře ve vývoji softwaru teprve uvažují.

Bráno kol a kolem, tester je ve své podstatě kontrolor kvality, který se zároveň přímo podílí na její finální úrovni. V širším kontextu jde o dohled nad tím, že výsledný software odpovídá představám zákazníka. V dílčích detailech se nám pak výše zmíněná definice rozpadá do jednotlivých procedur a kompetencí spadajících do různých fází životního cyklu softwaru. Hodí se říct, že to nechvalně proslulé šťouchání do programu se zdánlivě nekalým úmyslem jej rozbít je pouze jedním z mnoha úkonů, které máme na starost, a mezi kroky, které mu předcházejí či ho bezprostředně následují, je to často ten méně zásadní. Ono je to šťouchání totiž přínosné pouze tehdy, když vím, do čeho šťouchnout, proč šťouchám zrovna do toho a hlavně – když chápu, co takové šťouchnutí (ne)má vyvolat. Jinak řečeno, tester musí v prvé řadě analyzovat, jaké byly vstupní požadavky na funkcionalitu, kterou testuje, aby mohl dojít k závěru, zda její reálná implementace tyto požadavky splňuje.

Samotné testování pak není v žádném případě změť nahodilého „tajtrlíkování“ po uživatelském prostředí daného softwaru, ale přímo vychází z formálních testovacích scénářů, které si tester na základě výše zmíněné analýzy vytvořil. Ideální je pak stav, kdy do vývojového procesu vstupujeme před započetím psaní kódu a validujeme už samotné požadavky a akceptační kritéria dané funkcionality (či „fičury“, chcete-li), aby nedošlo k tomu, že programátor bude sedět u úkolu, který je buď vyloženě nesplnitelný, nebo jeho implementací mohou vzniknout problémy jinde.

Stejně jako při testování z nějakých formálních dokumentů vycházíme, i závěry naší práce musí být pochopitelně nějakým způsobem zaznamenány. Za nejvýmluvnější příklad takových výstupů lze brát reporty o případných nalezených chybách, které musí být přesně tak obsáhlé, konkrétní a srozumitelné, aby daný problém na jejich základě mohl vývojář lokalizovat a opravit. Testerovou prací není poznat, kde je chyba v kódu, taková kouzla mají pod palcem vývojáři. My máme za úkol identifikovat, že daná funkcionalita (případně celá aplikace obecně) se z pohledu koncového uživatele nechová v souladu s očekávaným výsledkem a tento rozkol náležitě zaznamenat.

Rozsah, typy a zaměření testů se plánují na základě analýzy požadavků projektu (ať už technických či personálních) a rizik s nimi spojených, což jsou záležitosti, které kompetenčně připadají spíše seniorům až test manažerům. Není ale neobvyklé, že se i od řadového testera může vyžadovat součinnost. Velké téma samo o sobě je pak tvorba a údržba automatizovaných testů – obor, který ve většině případů (ne však vždy) vyžaduje alespoň základní znalost programování.

Tím se dostáváme k často zmiňované tezi, že pojem „tester“, byť naprosto standardně používaný a rozhodně nikterak pejorativní, je vůči nám lehce nefér, poněvadž svým způsobem bagatelizuje, co naše práce obnáší. Minimálně interně se proto často používají spíše pojmy typu software quality (assurance) engineer a já doufám, že předchozí odstavce dostatečně ilustrují, že to opravdu není jenom proto, že to vypadá líp v životopise.

Nuže, máme zběžnou představu o tom, co práce SQA obnáší „papírově“, tak se můžeme začít bavit o tom, co se (nejen) od nováčků očekává, co ve své pozici mohou očekávat a bez čeho se v práci rozhodně neobejdou.

O tom ale až příště.

Total
0
Shares
Sdílet 0
Tweetnout 0
Sdílet 0
Související témata
  • Ze života
Vojtěch Camfrla

Předchozí článek
  • Blog

Git pro testery – nastavení a první krůčky

  • 9. 2. 2023
  • Jan Zatloukal
Zobrazit článek
Další článek
  • Blog

Jak jsem automatizoval testy, až mě to přestalo bavit – cesta k TestComplete

  • 9. 3. 2023
  • Štěpán Černoch
Zobrazit článek
Mohlo by se vám také líbit
Zobrazit článek
  • Blog

Identifikace UI prvků pro automatické testování

  • Jan Zatloukal
  • 21. 9. 2023
Zobrazit článek
  • Blog

Obsidian – automatizace nad poznámkami 

  • Jan Zatloukal
  • 7. 9. 2023
Zobrazit článek
  • Blog

Organizace souborů a složek při práci s Robot Frameworkem

  • Petr Nagy
  • 10. 8. 2023
Zobrazit článek
  • Blog

Automatizované testování webových aplikací s Robot Frameworkem a RPA.Browser 

  • Jan Zatloukal
  • 27. 7. 2023
Zobrazit článek
  • Blog

Tabulkový diff pomocí Pythonu

  • Jan Zatloukal
  • 29. 6. 2023
Zobrazit článek
  • Blog

Software testing očima nováčka, díl II.

  • Vojtěch Camfrla
  • 15. 6. 2023
Zobrazit článek
  • Blog

Automatické spouštění testů během buildu v GitLabu

  • Aleš Tichý
  • 1. 6. 2023
Zobrazit článek
  • Blog

Automatizované testování Windows aplikací s Robot Frameworkem a RPA.Windows 

  • Jan Zatloukal
  • 18. 5. 2023

Napsat komentář Zrušit odpověď na komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Doporučené příspěvky
  • 1
    Identifikace UI prvků pro automatické testování
    • 21. 9. 2023
  • 2
    Obsidian – automatizace nad poznámkami 
    • 7. 9. 2023
  • 3
    Organizace souborů a složek při práci s Robot Frameworkem
    • 10. 8. 2023
  • 4
    Automatizované testování webových aplikací s Robot Frameworkem a RPA.Browser 
    • 27. 7. 2023
  • 5
    Tabulkový diff pomocí Pythonu
    • 29. 6. 2023
Poslední příspěvky
  • Software testing očima nováčka, díl II.
    • 15. 6. 2023
  • Automatické spouštění testů během buildu v GitLabu
    • 1. 6. 2023
  • Automatizované testování Windows aplikací s Robot Frameworkem a RPA.Windows 
    • 18. 5. 2023
Rubriky
  • Blog (26)
Testujeme software Testujeme software
  • Edhouse.cz
  • Vyšíváme software
  • Zásady cookies (EU)
Testujeme software – vše o testování software | Všechna práva vyhrazena © 2022

Zadejte klíčové slovo a stiskněte Enter.

Spravovat Souhlas s cookies
Abychom poskytli co nejlepší služby, používáme k ukládání a/nebo přístupu k informacím o zařízení, technologie jako jsou soubory cookies. Souhlas s těmito technologiemi nám umožní zpracovávat údaje, jako je chování při procházení nebo jedinečná ID na tomto webu. Nesouhlas nebo odvolání souhlasu může nepříznivě ovlivnit určité vlastnosti a funkce.
Funkční Vždy aktivní
Technické uložení nebo přístup je nezbytně nutný pro legitimní účel umožnění použití konkrétní služby, kterou si odběratel nebo uživatel výslovně vyžádal, nebo pouze za účelem provedení přenosu sdělení prostřednictvím sítě elektronických komunikací.
Předvolby
Technické uložení nebo přístup je nezbytný pro legitimní účel ukládání preferencí, které nejsou požadovány odběratelem nebo uživatelem.
Statistické
Technické uložení nebo přístup, který se používá výhradně pro statistické účely. Technické uložení nebo přístup, který se používá výhradně pro anonymní statistické účely. Bez předvolání, dobrovolného plnění ze strany vašeho Poskytovatele internetových služeb nebo dalších záznamů od třetí strany nelze informace, uložené nebo získané pouze pro tento účel, obvykle použít k vaší identifikaci.
Marketingové
Technické uložení nebo přístup je nutný k vytvoření uživatelských profilů za účelem zasílání reklamy nebo sledování uživatele na webových stránkách nebo několika webových stránkách pro podobné marketingové účely.
Spravovat možnosti Spravovat služby Spravovat dodavatele Přečtěte si více o těchto účelech
Zobrazit předvolby
{title} {title} {title}