my unexpected journey becoming software tester
'Budujete úspěšný život ... každý den ...'
Moje cesta jako testování softwaru začala trochu nečekaně.
Objevil jsem se na prvních kolech pohovoru za předpokladu, že to bude rozvojová příležitost. Abych byl upřímný, jako každý jiný absolvent informatiky jsem byl trochu skeptický ohledně testování.
Ale nakonec jsem se rozhodl to zkusit. Pouze s nadějí, že mi moje zvědavá povaha v této oblasti pomůže.
Nabídku bych nemohl přijmout, aniž bych položil tuto otázku - Dostanu příležitost přejít na vývoj v případě, že mě testování nezajímá? :).
Věřte mi - nikdy mě ani nenapadlo opustit Testování.
jaké je mé uživatelské jméno a heslo k routeru
Když jsem se objevil na technickém kole, nebyl jsem připraven na nic víc než na základní koncept testování softwaru . Myslím, že jediná věc, která mě provedla, byla myšlenka, že jsem hodnocen logicky a ne teoreticky. “
Toto bylo moje první učení v Testování - pochopil jsem, jak jsme ( osvěžovače ) byly hodnoceny.
I dnes používám podobné techniky při najímání osvěžovačů pro svůj tým. Ověřuji jejich logiku, houževnatost a přístup k problému přes cokoli jiného.
Doporučené čtení => 4 důležité věci, které jsem se během své cesty naučil jako manažer testování kvality
Nastoupil jsem do Zycus jako QA Trainee a produkt mi byl přidělen třetí nebo čtvrtý den. Byl to jeden z největších (tehdy byl v koncepci) a nejambicióznějších produktů společnosti. Poté, co jsem se usadil na prvních pár týdnů, už se pro mě nebylo možné vrátit.
Začali jsme jako QA tým dvou lidí a brzy po několika měsících jsem byl jediným, kdo řídil snahy o testování. Za prvních 2 - 2,5 roku sám jsem zaznamenal téměř 3000 defektů napříč různými kategoriemi, jako je Functional, Performance, Security, UI, Usability, Vícejazyčné , Multi-Tenancy atd.
Po značnou dobu před novými přírůstky do testovacího týmu jsem byl proti silnému 15-16 člennému vývojovému týmu. Dokonce i po přidání nebyl poměr QC: Dev příliš zdravý a stále mohu s hrdostí říci, že to byla úspěšná cesta vzhledem ke všemu, co jsme testovali, dodali a zvládli.
Důležitý bod, který zde chci zdůraznit, je - To vše bylo z porozumění Testování v praxi, nejen z teorie.
V oblasti testování softwaru jsem již téměř šest let. Byla to úžasná cesta s tolika různými zážitky a spoustou plodného učení.
V současné době pracuji jako Senior QA Manager a starám se o 5-6 produktů a modulů. Ale to, co mi dává skutečnou radost a štěstí, je vedení týmu více než 30 šťastných a vášnivých testerů.
Samozřejmě mnoho lidí přispělo k mému učení, ale stále mohu říci, že většina mých zkušeností a znalostí prošla těžkou cestou (a pravděpodobně nejlepší cestou), tj. Učením / řešením na vlastní pěst.
'Zkušenost je nejlepší učitel.'
I když to říkám, vůbec tím nechci říci, že vám nebude prospěšné, když se naučíte nebo se budete řídit zdokumentovanými teoriemi o testování softwaru. Věřím, že to všechno určitě pomůže, ale nic nemůže porazit pochopení konceptu v jádru a odvážné řešení problémů.
Věřím, že vás zdokumentované věci nenaučí skutečné testování , i když vám může dát nějaký směr a pak jste na vlastní pěst. Přinejmenším v mém případě se vyskytly problémy, které nemusí být zdokumentovány, aby vyřešily mé přesné problémy, nebo jsem je nemohl najít včas. Moje jediná volba byla porozumět problému / situaci v jádru a reagovat na něj přístupem, který jsem shledal správným.
Příklady - Jak jsem přistupoval v různých situacích
Vysvětlím to pomocí problémů / situací, proti kterým jsem byl, a jak jsem k nim přistoupil.
# 1) Obchodní porozumění je o úroveň výš než porozumění testování
Všichni to víte. Testování není jen testování několika ověření a provedení nějakého ověření.
Jako tester bychom měli vizualizovat každý možný scénář, dokonce i ten nejvzácnější ze vzácných scénářů, bez selhání. Předpokládá se, že vezmeme v úvahu všechna možná testovací data, která skutečný uživatel může používat.
K tomu všemu měli bychom tomu podnikání rozumět naplno.
Nebude špatné, když řeknu, že bychom měli obchodní a uživatelské základně rozumět stejně nebo dokonce více než obchodní analytik.
Měl jsem podobné šance.
Měl jsem porozumět složitým obchodním scénářům v oblasti zadávání zakázek přemýšlejte o nových požadavcích a zvažte je z pohledu uživatele. Měl jsem nejen vypracovat své případy, ale také přispět do fází Požadavek a Návrh každé iterace. Ani zde mi kromě mé schopnosti přemýšlet a uvažovat nepřijel žádný připravený odkaz.
Abychom lépe porozuměli podnikání a lépe navrhli scénáře / případy, nic nefunguje jako pero a papír.
Přečtěte si také => 5 Pro snadnější život musí mít testovací nástroje pro testery
Před odchodem do Diskuse o požadavcích schůzku jsem si předem zapisoval možné pochybnosti / opravy / nejasné body. Zvykl jsem si psát scénáře, které chci vyzkoušet, nebo postavit testovací případy; někdy i kreslení scénářů funguje jako kouzlo.
Když píšete / kreslíte, vstupuje do vaší mysli s lepší srozumitelností a poté vaše mysl pracuje na těchto informacích a vytváří více scénářů a dává lepší srozumitelnost. Takto to pokračuje, dokud nezískáte pocit HOTOVOSTI !!!
# 2) Předvádění proti přesile a pod tlakem
Pracoval jsem na produktu, který byl / je dostatečně velký a složitý, aby tým 30 inženýrů pracoval nepřetržitě po dobu tří dlouhých let, aby se dostal na prodejnou úroveň.
Po většinu počáteční fáze jsem buď byl (sólo) proti týmu 15–20 vývojářů od juniorské, střední a vyšší úrovně, nebo mě doprovázel jeden nebo několik dalších testerů. Všichni neúnavně přidávali do produktu nové funkce, které vyžadovaly stejnou a paralelní pozornost ze strany testování.
Být součástí schůzek s požadavky, psaní případů, jejich provádění, průzkumná kola, údržba serverů, nasazení, nic nebylo volitelné.
Do té doby jsem nevěděl o žádné metodice, nejlepší praxe , kurz nebo kniha, která mi může ukázat řešení těchto problémů. I dnes si nejsem jistý, jestli existuje něco, co vám může přesně pomoci v boji proti pozemským realitám, když jim čelíte.
Dělal jsem spíše agresivně a rychlá kola průzkumného testování (Do té doby jsem si toho jména nebyl vědom) u jednotlivých funkcí jeden po druhém a poté opakujte. Toto řešení funguje čistě na tom, jak rychle můžete posunout své myšlenky a rámovat situace / scénáře.
Samozřejmě to vyžadovalo opravdu rychlou a agresivní práci, ale fungovalo to pro mě.
Co tím myslím agresivní kolo je, zaměřujete jednu věc po druhé (Vyslovte jeden prvek formuláře najednou) a otestujte jej samostatně a ve spojení s dalšími propojenými prvky / věcmi.
Doporučené čtení => Jak být produktivním feťákem (zejména jako tester)
Např. Jak otestovat textové pole.
Zde můžete otestovat:
- Zda přijímá a ukládá data tak, jak jsou
- Ověření datového typu
- Ověření maximální délky
- Zacházení se speciální postavou
- Zpracování XSS
- Vícejazyčné zpracování dat
- Manipulace s prázdnými místy / bez dat
- Chování karty a zadávání kláves
- Zpracování chyb (více prohlížečů)
- Zarovnání uživatelského rozhraní (více prohlížečů)
- Zkopírujte vložit data / přetáhněte data odkazů do textového pole
- Nejdůležitější - chování tohoto pole w.r.t. další propojené prvky (jakékoli obchodní očekávání spojené s tímto polem, jako je vyplnění něčeho v jiném poli na základě údajů v tomto poli)
Dává vám přemýšlení o výše uvedeném testování jistotu, že se v tomto oboru nic moc pokazit nemůže?
Cílení na jednu věc najednou vždy fungovalo pro mě a já jsem také dostával nějaké dokončení práce.
# 3) Když jste proti „neočekávanému“
Která kniha vám podle vás najednou pomůže s „Jak na to“, když máte dělat něco, co jste nikdy předtím neudělali?
Mluvíme-li konkrétně, pak - Žádné.
Vzpomínám si na dobu, kdy jsme v nepřítomnosti našeho vedoucího produktu měli společně s několika dalšími členy Junior a mid-senior nasadit naši aplikaci na ukázku (pro nás tehdy byla výroba) poprvé. Bylo to velmi důležité pro vůbec první ukázku našeho produktu.
Udělali jsme to, ale se spoustou pokusů a omylů. Z toho důvodu neměl nikdo z nás odborné znalosti Linux a shell skriptování . Pamatuji si, že naše oddělení IT vzneslo obavy (vše v dobré víře) u mého tehdejšího manažera, že budu spouštět špatné příkazy na produkčních serverech. Možná to byl jen katalyzátor a shell skriptování / Linux byl můj přirozený zájem, ale za krátkou dobu poté jsem převzal odpovědnost za údržbu a upgrade pěti až šesti prostředí současně.
Shell a Linux mě zaujaly tak dobře, že jsem brzy byl tím, kdo o tom začal provádět interní školení.
# 4) Když se měří váš výkon, vaše zkušenost není
Velmi brzy v mé kariéře jsem se porovnával a měřil s velmi vyvinutými a zkušenými testery v okolí. Věřím, že mnozí z vás určitě zažili podobnou situaci a věděli, co s vámi tato zvláštní očekávání dělají.
Léčba zde byla Posuňte se a vyvíjejte se .
Jedinou cestou vpřed bylo nemyslet na to, jak jsem méně zkušený, neomezovat se světovými standardy měření toho, jak pomalu / rychle bych měl růst / učit se. Neomezuji se na světová kritéria, jak brzy by měl člověk začít vést a jaký titul potřebuje, než to udělá.
Kolem tohoto bodu, musím říci, bez ohledu na to, do jaké oblasti patříte, doporučuji přečíst si Vůdce, který neměl žádný titul, Robina Sharmy. Pomůže vám uvolnit, co ve vás leží. Řekne vám, že vás nikdo kromě vás nemůže zadržet.
otázky k rozhovoru pro vývojáře .net
Pokud musím svázat své zkušenosti několika větami, bude to vypadat takto:
'Abyste byli destruktivním a úspěšným testerem, záleží jen na vaší zvědavosti, pozornosti k detailům, disciplíně, logickému myšlení, vášni pro práci a schopnosti pitvat věci.' Fungovalo to pro mě a pevně věřím, že to bude fungovat pro vás. Pokud máte tyto vlastnosti, musí to pro vás fungovat. “
Čtení tak daleko, pokud si myslíte, že podporuji základní lidské vlastnosti přes hlubší teoretické znalosti, pak to není úplně pravda. Věřím, že s něčím začít a ochutnat úspěch, záleží trochu více na vašich vestavěných kvalitách než na informacích, které jste se naučili. Chcete-li však v jakékoli oblasti zajít daleko, musíte se naučit lekce, zásady a zkušenosti.
I v mém případě jsem se musel do jisté míry naučit terminologie, pojmy, teorie, jak jsem ve své kariéře dosáhl dále. Důvodem je, že jako tester musíte komunikovat s několika lidmi, kteří budou mluvit za těchto podmínek, a musíte tomu porozumět.
Jako vedoucí nebo spolukladač budete mít nového testera pocházejícího z nějaké části světa s vlastní znalostí faktů, definic a terminologie. I zde nemůžete zůstat pasivní vůči těmto věcem; musíte mít předchozí znalosti o maximálních možných věcech použitých / řečených tam venku.
Učení je nevyhnutelné.
Musel jsem se dozvědět více o různých typech testování, jak je provést a způsoby, jak to vysvětlit lidem v mém týmu ve správné fázi. Musel jsem vyhodnotit nové nápady, nástroje a implementovat je. Postupem po žebříčku se stává stejně důležitým i osvojování nových konceptů a metodik.
Přečtěte si více => Průvodce A až Z při výběru nejlepší automatizace
Závěr
Ačkoli je téměř nemožné zapsat si každou důležitou a nepatrnou věc, kterou jsem se za ta léta naučil, je to můj pokus shrnout to do seznamu s odrážkami.
- Testování je velmi těžké definovat. Někdo může provést vynikající testování a nemusí být schopen jej definovat slovy. Je to tak, jak to vidíte.
- Každý může mít svou vlastní definici testování. Můj byl jednoduchý- 'Dostali jste věc - najděte chyby a vylepšete je.'
- Abyste byli destruktivním testerem, nepotřebujete nutně velké teorie, složité matice nebo ISTQB. Musíte být zvědavý , soustředěný a vášnivý, myslí logicky a má schopnost pitvat. Vědět něco navíc neuškodí, ale ne za cenu ztráty jádra.
- Tradiční přístupy / koncepty mají také svůj vlastní význam a mám k nim stejný respekt vzhledem k tomu, že ve světě existuje dobrá část světa, kde je to jen nutnost. Samotné testování se nemůže vyvíjet; k tomu se musí vyvíjet i okolí.
- Jako tester se stává stejně důležitým pro učit se nové nástroje, techniky a metodiky, jak postupujete vpřed . Plánování testů, lepší přístupy k provádění různých typů testování, situační testování.
- Vzhledem k tomu, že testování je plynulé, definice správného přizpůsobení se také výrazně liší od organizace k organizaci. Být destruktivním nebo vynikajícím testerem může být dost dobré na to, abyste dostali šek na výplatu, pokud máte štěstí, nebo to může vyžadovat další znalosti o tom, jak testování funguje v tradičních společnostech. Oba jsou přímo u sebe.např.Najímám lidi podle mé definice testování (což se trochu liší podle zkušeností a profilu kandidáta).
- Jelikož existuje styl kódování, řízení, vaření; existuje také styl testování. Možná vás to nebude bavit, pokud to neděláte po svém. Mám na mysli, že Testování může mít pokyny, ale nemělo by to být tvrdě vázáno mikroprocesy.
- Efektivní vedení by měl přimět svůj tým, aby si místo práce vybral práci. Může to příležitostně změnit, aby zlepšil produkt.
- Pokuste se školit své lidi v oblasti jejich zájmu a tam, kde chcete, aby byli vyškoleni. Spojte myšlenky a úsilí svého týmu s konečným cílem, kterým je „Nejlepší kvalita“.
- Nepokoušejte se své lidi řídit, vést je. Buďte přátelští a přístupní, díky čemuž je práce mnohem jednodušší.
- Každý člen vašeho týmu by měl mít rád práci, kterou dělá, mít vztah k produktu a být laskavý k lidem kolem. Pak vyjdou jen ti nejlepší z nich.
- Svět testování se musí vyvíjet. Značná část světa přechází k praktičtějším přístupům, jako jsou průzkumné testování, kontextové testování (které mnoho lidí dělá, aniž by vědělo, že to je ono), které by se i ostatní měli pokusit vyvinout více technik, jako je
- Mělo by se vytvořit více testovacích komunit a podobně smýšlející lidé by se měli shromáždit ve větším měřítku. Je toho tolik, co je možné sdílet, učit se, přizpůsobovat se a inovovat.
Doufám, že moje zkušenosti a zjištění vám pomohou stát se lepším testerem nebo vám pomohou lépe porozumět testování.
Další čtení => Od začátečníka po profesionála: Kompletní průvodce úspěšnou cestou testovacího profesionála
O autorovi: Tento článek napsal člen týmu STH Mahesh C. V současné době pracuje jako Senior Manager pro zajišťování kvality a má zkušenosti s vedením přední řady testů pro více komplexních produktů a komponent.
Rád se ozvu. Komentujte zde nebo nás kontaktujte. Mnohokrát děkuji za přečtení.
Doporučené čtení
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Úloha pomocníka QA při testování softwaru
- Kurz testování softwaru: Ke kterému institutu pro testování softwaru bych se měl připojit?
- Výběr testování softwaru jako vaší kariéry
- Práce na volné noze se softwarem pro testování technického obsahu Writer
- Některé zajímavé otázky týkající se testování softwaru
- Zpětná vazba a recenze kurzu testování softwaru
- Průvodce dokonalým pokračováním v testování softwaru (s ukázkou obnovení softwaru Tester softwaru)