Menu

Top 10 výzev, kterým testeři čelí na pracovišti a jak je překonat

top 10 challenges testers face workplace

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Výzvy jsou normální. Je to, když se na ně díváte jako na příležitosti, zlatý důl a jako překážky, pozemní důl. Během let jsem měl v IT průmyslu svůj podíl na „příležitostech“.

Někteří přišli s rolí, kterou jsem hrál, jiní obecně. Toto je můj pokus zaznamenat je a oslovit komunitu, abyste zjistili, zda ve vás někdo z vás rezonuje, a možná vám v malé kapacitě pomůže a dá vám vědět, že nejste sami.

Tady je můj seznam 10 nejlepších:

Výzvy, kterým čelí testeři

Co se naučíte:

Top 10 výzev, kterým testeři čelí na pracovišti

# 1) Kultura společnosti:

Toto je čestná první položka na seznamu, protože jsem v odvětví IT služeb měl skákání mezi více klienty, týmy, lokacemi a společnostmi. Miloval jsem, že jsem součástí některých týmů a některých, no, neopakoval bych tu zkušenost.

  • Tým, pro který jsem pracoval, začal v 6 hodin ráno. Další trval na práci do 18 hodin.
  • Jeden přiměl dodavatele vstoupit do budovy jinými dveřmi a další, kteří ani nevěřili v přístup ke kartě.
  • Jeden nás přiměl nechat všechna mobilní zařízení s pamětí, Bluetooth nebo jiným připojením venku, zatímco jiná společnost celý den hrála na pracovišti úžasnou hudbu.
  • Některé společnosti sledují přísnou hierarchii s dosažením statutu jejich generálního ředitele a jiné, které nemají kóje a všichni jsou si rovni.

Časem jsem si uvědomil, že neexistuje žádná správná nebo špatná cesta; je to jen jejich cesta. Vzhledem k času se vždy přizpůsobíme okolnostem, ale pokud tomu tak není, dejte mu nejbližší východ.

# 2) Různá časová pásma:

Zůstáváte v kanceláři nebo nahoře doma před notebookem ve 23:00 nebo 5:00 a snažíte se dohnat své týmy, které jsou geograficky rozloženy? To je až příliš známé, že?

Proti tomuto problému opravdu neexistuje protilátka (Může to být, káva?) Používejte hodiny, které vám ukazují přesný čas na různých místech (fungují také světový čas na vašem smartphonu), dokonalé komunikační protokoly tak, že pro případy, že se nemusíte setkat vyřešeno prostřednictvím e-mailu a procvičte si časové plánování s vědomím časového pásma, abyste se tomuto problému do značné míry vyhnuli.

Doporučené čtení => Na místě - offshore model testování softwaru - nechte ho pracovat za vás

# 3) Mezikulturní rozdíly:

Pracoval jsem v Indii i v USA. Přestože podniková kultura je poměrně neetnická, odkud pocházíme, má dopad na naše chování a porozumění.

dfs a bfs c ++

Například: 'Ahoj jak se máš?' je běžný pozdrav v USA. To nutně neznamená, že chtějí přesně vědět, co v tuto chvíli cítíte. Když jsem však byl v USA nový, myslel jsem si: „Byl jsem právě před chvílí na schůzce s touto osobou. Co by se za tak málo času změnilo? “ :) Dobré pro mě, rychle jsem se učil.

V některých kulturách také mluvení méně naznačuje tichou rozjímání, zatímco v jiných to jednoduše znamená, že je to nudné nebo nemáte co říct.

Když se pokusíte porozumět těmto malým nuancím, rozumíte lidem lépe a můžete fungovat lépe.

Testování / QA specifické výzvy

# 4) Žádná dokumentace:

Klasika. Mnoho týmů stále věří ve verbální komunikaci a uchovává jen málo referenčních materiálů o tom, jak se software stal tím, čím je dnes. Rychlé vývojové cykly to jen zesílily.

Toto je však opravdu jeden z těch případů, kdy se výzvy stávají příležitostmi.

Zapojte se do konverzací se svými vývojovými, obchodními analýzami nebo technickými týmy. Prozkoumejte aplikaci; nastavit reference zaměřené na podobné aplikace a jejich standardy. Pochopte perspektivu koncového uživatele. Získejte dobrodružství s průzkumným testováním.

Chcete-li získat další směr, podívejte se => Jak otestovat aplikaci bez požadavků?

# 5) Nestabilní prostředí:

Týmy QA obvykle trpí horším prostředím, které je nastaveno tak, že musíme být opravdu připraveni co nejlépe využít to, co máme.

Například: Server, který se přetíží a potřebuje několikrát restartovat během testování, protokoly, které je třeba často vyčistit, aby se zajistilo, že nedojde k přetečení atd.

Přeneste tyto problémy do popředí a ujistěte se, že během testování získáte podporu prostředí. U běžně se vyskytujících případů získejte přístup k serverům pomocí kroků k provedení nějaké jednoduché údržby, jako je restart, vymazání front atd.

Doporučené čtení => Jak minimalizovat vady testovacího prostředí

# 6) Nástroje napájené silou:

Někdy víme, že nástroj není vhodný pro danou práci. Nezbývá nám nic jiného, ​​než ji nadále používat, protože klienti / týmy již mají licence a nechtěli by jít na novou, dokud nedojde aktuální licence.

Musel jsem otestovat aplikaci Mainframes na HP QTP bez doplňku Terminal Emulator. V tomto případě jsem měl nástroj, ale ne správnou konfiguraci. Nemohl jsem s tím nic dělat, takže jsem jako řešení musel přepínat mezi normálními a nízkoúrovňovými režimy nahrávání.

Není to zábava, ale naučíte se alternativy. Nebo alespoň dosáhnete definitivního závěru, zda alternativy skutečně fungují nebo ne.

Přečtěte si také => Průvodce A až Z při výběru automatizačního nástroje

# 7) Některé aplikace to prostě neříznou:

Už jste někdy testovali aplikaci a začali si klást otázku: „Jak se to dá nazvat softwarem, když se jedná o stroj na výrobu chyb?“

Měl jsem toto zvláštní privilegium, kde většinu dne šlo o jednoduché hlášení chyb a hlášení dalších chyb. V důsledku těchto chyb se některé oblasti aplikace odříznou. Celé spektrum závažnosti vás odhodí z vaší hry a bude ohromující tam, kde začnete přemýšlet: „Má smysl to, co tady dělám?“

Přesčas jsem se naučil zůstat pevně ve svém rozhodnutí, že software není připraven k testování a odmítnout sestavení. Když už není, už nehledám stříbrnou podšívku.

Další výzvy

# 8) Lidé-vtipy:

Už se vám stalo, že vývojář narazil na stůl konferenční místnosti, jakmile jste vysvětlili závadu? Ano, to se mi stalo. :) Později jsem poznal, že to byla jeho forma vyjádření, a ne zhoršení.

Také jsem měl člena týmu, který zpočátku vypadal jako nespolupracující a hrubý, ale byl opravdu jen plachý. Tato osoba by sotva řekla pár slov nebo se setkala s očima, když byla požádána o aktualizaci stavu. Byl jsem velmi blízko k negativní kontrole výkonu a eskalaci, kdybych si neuvědomil, že stejné podrobnosti od něj lze snadno a komplikovaně obdržet prostřednictvím e-mailu. Nevyhovoval mu rozhovor jeden na jednoho.

Každý je jiný a zaslouží si výhodu pochybností. Nebuďte příliš rychlí na to, abyste posoudili a respektovali hranice.

Přečtěte si také toto => Jak efektivně řídit testovací tým

# 9) Nedostatek zpětné vazby:

Někdy chodíte dny na konci a pracujete na posedlosti nad výstupem, jen abyste zjistili, že to tak nemělo být.

Nebo pracujete ze vzdáleného místa se svým týmem umístěným jinde, kde se cítíte izolovaní a nemáte od koho odrazit své nápady.

Nebo obdržíte zpětnou vazbu, která není úplně užitečná. Řekněme, že jste vytvořili procesní dokument a oni řekli, že to bylo dobré. Nevidíte dokument procesu zveřejněný nebo uvedený do užívání a už vás zajímá, co se s ním stalo. Zpětná vazba „dobrá“ zde tedy nepřinesla nic dobrého a je téměř bez zpětné vazby.

Usilujte o upřímnou zpětnou vazbu a vytvořte komunitu pro diskusi o vašich nápadech. Ne často je to nejjednodušší, ale bez pozitivního posílení, které vám tento krok poskytne, budete demotivováni.

# 10) Předpojaté pojmy:

Víme, že na pracovišti existuje mnoho předsudků týkajících se pohlaví, národnosti atd. Nebudu se zde podrobně zabývat, ale pokud nezačneme nahlížet na svět jako na globální vesnici a všichni si rovní, svět i pracoviště toxický.

O autorovi: Děkujeme členovi týmu STH Swati za sdílení těchto 10 hlavních výzev, kterým testeři čelí.

Teď jsi na řadě.

Které z položek v seznamu jste překvapili nebo kývli hlavou na porozumění? Jakým výzvám jste čelili a jak jste je překonali?

Sdílejte a komentujte!

Doporučené čtení

^