Menu

Softwarové manuální testování Dotaz na rozhovor pro zkušené profesionály

software manual testing interview questions

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

Nejčastěji kladené otázky na základě ručního testování na základě scénáře pro zkušené profesionály s podrobnými odpověďmi:

Nedávno jsem měl tuto jedinečnou zkušenost Koučování QA (10 let zkušeností) k účasti na pohovoru klienta Testování softwaru s přední zábavní společností v Los Angeles. Testovaným webem byl jednoduchý web zaměřený na zákazníka (něco jako online televizní kanál), který měl webové i mobilní komponenty.

Softwarové manuální testování Dotazy na rozhovor

Poradenská společnost projektovala tomuto klientovi profily pro tester na místě + pozice koordinátora ale žádný z nich se nedostal do procesu testovacího rozhovoru. Rozhodli se tedy shromáždit Otázky QA rozhovoru od předchozích účastníků a dali mi dotazník.

jak třídit pole int v java

Chtěli, abych dal odpovědi dalšímu kandidátovi a koučovi osoba, aby byla úspěšná v testovacím QA rozhovoru.

Ruční testování otázek na pohovoru pro zkušené

Když jsem dostal seznam otázek, byl jsem překvapen a zároveň ‚nepřekvapen '. Překvapen - protože otázky byly opravdu základní a 10 let zkušeností s QA by na ně mělo být snadné odpovědět. Není to tak překvapené, protože QA je oblast IT, která má podle mého názoru nejvíce plevelů - ale pojďme se do toho pustit.

Po dokončení cvičení jsem si myslel, že by bylo hezké sdílet tuto zkušenost s čtenáři STH. Pro začátečníky to bude dobrá živá expozice. Pro ostatní to bude přátelská připomínka toho, jak důležité základy jsou bez ohledu na to, jak jsme zkušení.

Doporučené čtení=> 101+ otázek a odpovědí na rozhovory o testování softwaru.

Tady je ... ..

Ruční testování Dotaz na rozhovor pro zkušené

9 nejčastějších otázek týkajících se testování softwaru QA pro začátečníky i zkušené kandidáty:

#Q 1) Jaký je proces vytvoření testovacího skriptu?

Odpovědět:

Krok 1: je důkladně porozumět AUT:

  • Může to být důkladným přečtením dokumentů s požadavky.
  • Při absenci dokumentů bychom se mohli pokusit pochopit jakýkoli referenční bod, který máme - předchozí verzi aplikace nebo drátové rámy nebo snímky obrazovky

Krok 2: Po pochopení požadavků vytvoříme seznam oblastí v této aplikaci, které budou muset být testovány. Jinými slovy, identifikujeme požadavky na test. V tomto kroku se zaměříme na identifikaci „Co“ testovat. Výsledkem tohoto kroku je seznam Testovací scénáře .

Krok 3: Jakmile máme testovací scénáře, soustředíme se dále na „Jak“ je otestovat. Tato fáze zahrnuje psaní podrobných kroků o tom, jak otestovat konkrétní funkci, jaká data zadat ( Testovací data ) a jaký je očekávaný výsledek.

Po dokončení těchto 3 kroků jsme připraveni k testování.

#Q 2) Jaká jsou pole ve zprávě o chybě?

Odpovědět: Následující důležitá pole by měla být zahrnuta do a dobré hlášení o chybě :

  1. Jedinečné ID
  2. Popis defektu: krátký popis chyby.
  3. Kroky pro reprodukci: podrobnosti o tom, jak se dostat k chybě, přesné údaje o testu, čas, kdy byla zjištěna závada (je-li k dispozici)
  4. Modul / část aplikace (pokud existuje)
  5. Vážnost
  6. Snímek obrazovky
  7. Odpovědné QA: v případě jakýchkoli následných otázek týkajících se tohoto problému

#Q 3) Jak otestovat software orientovaný na zákazníka?

Odpovědět: U jakékoli aplikace, kterou testujeme, zkoušíme zjistit, zda aplikace splňuje určitou sadu požadavků. Ale pokud jde o web zaměřený na uživatele, kromě soustředění na funkčnost musíme také prozkoumat několik funkcí použitelnosti, možná do jisté míry také aspekty výkonu a zabezpečení.

První úroveň testování je : Vyhovuje web funkčním požadavkům?

Například, pokud se jedná o web pro správu půjček, musíme se podívat na - jsou noví zákazníci schopni požádat o půjčku, jsou stávající zákazníci schopni získat přístup k informacím o své půjčce, je úrok% aplikovaný na částku půjčky správný atd.

Další úroveň testování je :jak snadné je použití webu, možnosti dávají logický smysl a splňují očekávání uživatele nebo ne.

Například, pokud uživatel musí projít 3-4 obrazovkami, aby mohl předložit základní informace, bude naštvaný, takže takové problémy musí být vyřešeny.

Další příklad, po zadání uživatelského jména a hesla může uživatel kliknout na kartu - což znamená, že ovládací prvek by měl přejít na tlačítko „Přihlásit se“, místo toho, pokud se má zrušit, bude uživatel opravdu naštvaný a zkušenost s používáním webu je bude kompromitováno. Takové problémy je třeba chytit.

Testování výkonu v úplném rozsahu nemusí být v rozsahu, ale jednoduché situace jako, jak dlouho trvá, než se zobrazí výsledky vyhledávání a kolik času trvá, než systém načte informace o zákazníkovi ve špičce - to jsou některé příklady na co bychom chtěli dávat pozor.

Bezpečnostní - u webů, kde je zabezpečené přihlášení pro přístup na web, musí být otestována jeho minimální funkčnost. Například, pokud nechám web nečinný déle než 10 minut, je to automatické odhlášení nebo ne. Na něco tak základního by se mělo zaměřit.

#Q 4) Jak překonat problém, kdy nemáte vstupní dokumentaci pro testování?

Odpovědět: Pokud není k dispozici podrobná standardní dokumentace jako BRD a FSD, tester bude muset záviset na určitém referenčním bodě.

  • Screenshoty
  • Předchozí verze aplikace
  • Drátové modely atd

Dalším faktorem, který nesmírně pomáhá, je mluvit s vývojáři nebo obchodními analytiky (jsou-li k dispozici), abychom v případě pochybností získali potvrzení o našem porozumění nebo vysvětlení.

Když žádná z těchto situací nefunguje, můžeme jen konceptualizovat aplikaci na základě našich předchozích zkušeností s aplikacemi IT a vytvořit základní sadu testovacích skriptů. Když přijde fáze testování, můžeme nastavit část času testovacího cyklu a udělat nějakou správu testovacích případů (zdokonalit již vytvořené skripty), abychom měli dokument pro další fáze.

https www google comyoutube to mp3

#Q 5) Jak se dostat maximální produktivita z offshore týmu?

Odpovědět: Klíčem je zajistit, aby všichni testeři věděli o všech modulech a aby na jednom místě neexistovala žádná koncentrace znalostí. Zapojení všech do vzájemného hodnocení testovacích skriptů, vadných schůzek a relací KT zajistí, že každý bude aplikaci znát v nejvyšší možné míře.

Podporou konceptu týmové práce také můžeme zajistit, aby členové týmu spolupracovali, pomáhali si a pomáhali si navzájem pro lepší produktivitu.

Proces velmi pomáhá také pravidelné následné schůzky.

#Q 6) Jaké jsou role a povinnosti místního koordinátora? Testuje také?

Odpovědět: Koordinátor na místě je kontaktním místem pro offshore tým a pro klienta ohledně jakýchkoli informací týkajících se zakázky testování.

Tato práce zahrnuje:

  • KT za do offshore a klientům
  • Připravte prostředí, abyste vše otestovali
  • Testování zdravého rozumu, testování kouře
  • Testování - klíčová funkčnost.
  • Recenze chyby - nalezena offshore týmem
  • Přiřazení chyby příslušnému vývojáři
  • Prezentace metrik
  • Poskytování odhlášení

Ano, i místní koordinátor musí testovat.

#Q 7) Nekonzistentní chyby - Proč to mohou na místě najít, ale offshore ne a naopak - Jak řešit tuto situaci?

Odpovědět: Každá chyba musí být zaznamenána a analyzována - ať už se vyskytne na místě nebo na moři, ať už je opakovatelná nebo ne. Skutečnou přidanou hodnotou pro práci testera je, když se zapojíme do procesu analýzy kořenových příčin kvůli chybě, místo abychom ji jednoduše nahlásili.

Některé způsoby, jak můžeme tuto situaci vyřešit, jsou:

  • Všichni členové týmu na místě a na moři by se měli řídit pravidlem, že pro každou chybu, se kterou se setkáme, je třeba pořídit snímky obrazovky - opakovatelné nebo ne.
  • Pokud existují protokoly, systémové soubory nebo něco podobného, ​​mohlo by nám to pomoci najít jakýkoli důkaz problému - měli bychom se ho pokusit najít.
  • Navzdory všem těmto krokům, pokud stále nemůžeme říct, proč a kdy k problému dojde - měli bychom to nahlásit vývojáři stejně - s co největším množstvím informací.

#Q 8) Testování související s videem / zvukem - Co to zahrnuje?

Odpovědět: Jak otestovat aplikaci s videem nebo zvukem?

Zde je třeba vzít v úvahu důležité body:

  • Úrovně přístupu (omezené nebo ne - řízené heslem)
  • Různé druhy prostředí
  • Kompatibilita s prohlížeči
  • Rozlišení obrazovky
  • Rychlost připojení k internetu
  • Specifické možnosti videa - například přehrávání, zastavení, ztlumení atd.
  • Video podle velikosti
  • Odpověď na videa - komentáře (omezení délky komentáře a počtu komentářů, které může trvat)
  • Videoodpovědi na videa
  • Rozhraní se sociálními sítěmi - interoperabilita
  • Rychlost ukládání do vyrovnávací paměti
  • Vkládání videa

#Q 9) ​​Testování mobilních aplikací - co to stručně obsahuje?

Odpovědět: Testování mobilních aplikací Důležité testovací scénáře:

  • Zkontrolujte, zda aplikace funguje dobře s více operátory a více zařízeními.
  • Použitelnost funkcí na mobilní obrazovce.
  • Testování na různých mobilních platformách - například Android a iOS.
  • Instalace, odinstalace, spuštění aplikace se sítí a bez sítě, testování funkčnosti.
  • Síťová připojení - Wi-Fi, 2G atd.
  • K ladění lze použít protokoly v konfiguračním nástroji iOS pro iPhone pro Android Monitor.bat.

To bylo vše. Nyní to nebylo tak jednoduché.

otevírání souborů .jar ve Windows 10

Na závěr zopakuji filozofii na STH - znáte dobře základy, zbytek následuje automaticky.

Závěrem doufám, že toto úsilí bude pro naše čtenáře přínosné a smysluplné. Dejte nám prosím vědět níže v sekci komentářů o tom, jak jsme postupovali.

Autor: Tento příspěvek napsal náš člen týmu STH Swati Seela.

Doporučené čtení

^