Menu

Softvérové ​​ručné testovanie, otázky na pohovor pre skúsených profesionálov

software manual testing interview questions

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Najčastejšie otázky týkajúce sa manuálneho testovania na základe scenára pre skúsených profesionálov s podrobnými odpoveďami:

Nedávno som mal túto jedinečnú skúsenosť s Koučovanie QA (10-ročná prax) zúčastniť sa pohovoru klienta Testovanie softvéru s poprednou zábavnou spoločnosťou v Los Angeles. Testovanou stránkou bola jednoduchá webová stránka zameraná na zákazníka (niečo ako televízny kanál online), ktorá obsahovala webové aj mobilné komponenty.

Ručné testovanie softvéru, otázky na pohovor

Poradenská spoločnosť projektovala tomuto klientovi profily pre spoločnosť miestny tester + pozícia koordinátora ale nikto z nich neprešiel testovacím pohovorom. Preto sa rozhodli zbierať Otázky týkajúce sa QA rozhovoru od predošlých účastníkov a dali mi dotazník.

aká je najlepšia herná spoločnosť

Chceli, aby som dal odpovede ďalšiemu kandidátovi a trénerovi byť úspešný v testovacom pohovore QA.

Ručné testovanie otázok na pohovor pre skúsených

Keď som dostal zoznam otázok, bol som prekvapený a zároveň ‚neprekvapený‘. Prekvapení - pretože otázky boli skutočne základné a 10-ročná QA mala na ne vedieť ľahko odpovedať. Nie som tak prekvapený, pretože QA je oblasť IT, ktorá má podľa môjho názoru najviac buriny - ale poďme na to.

Po ukončení cvičenia som si myslel, že by bolo pekné podeliť sa o túto skúsenosť s čitateľmi STH. Pre začiatočníkov to bude dobré vystúpenie naživo. Pre ostatných to bude priateľské pripomenutie toho, aké dôležité základy nie sme akokoľvek skúsení.

Odporúčané čítanie=> 101+ otázok a odpovedí na pohovory týkajúce sa testovania softvéru.

Tu ide…..

Ručné testovanie otázok pri rozhovoroch pre skúsených

9 najbežnejších otázok na pohovor o testovaní softvéru pre začiatočníkov aj skúsených kandidátov:

#Q 1) Aký je proces vytvorenia testovacieho skriptu?

Odpoveď:

Krok 1: je dôkladné pochopenie AUT:

  • Môže to byť dôkladným prečítaním dokumentov s požiadavkami.
  • Pri absencii dokumentov by sme sa mohli pokúsiť pochopiť akýkoľvek referenčný bod, ktorý máme - predchádzajúcu verziu aplikácie alebo drôtové rámy alebo snímky obrazovky.

Krok 2: Po pochopení požiadaviek urobíme zoznam oblastí v tejto aplikácii, ktoré budú musieť byť testované. Inými slovami, identifikujeme požiadavky na test. V tomto kroku sa zameriavame na identifikáciu „Čo“ testovať. Výsledkom tohto kroku je zoznam Testovacie scenáre .

Krok 3: Keď už máme testovacie scenáre, sústredíme sa ďalej na to, ako ich otestovať. Táto fáza zahŕňa napísanie podrobných krokov o tom, ako otestovať konkrétnu funkciu, aké údaje zadať ( Skúšobné údaje ) a aký je očakávaný výsledok.

Po vykonaní týchto 3 krokov sme pripravení na testovanie.

#Q 2) Čo sú polia v správe o chybe?

Odpoveď: Nasledujúce dôležité polia by mali byť zahrnuté v a dobrá správa o chybe :

  1. Jedinečné ID
  2. Popis chyby: krátky popis chyby.
  3. Kroky na reprodukciu: podrobnosti o tom, ako dospieť k chybe, presné údaje o teste, čas zistenia chyby (ak je to relevantné) prostredie: akékoľvek informácie, ktoré pomôžu pri opätovnom výskyte problému
  4. Modul / časť aplikácie (ak je k dispozícii)
  5. Závažnosť
  6. Screenshot
  7. Zodpovedné QA: v prípade akýchkoľvek následných otázok týkajúcich sa tohto problému

#Q 3) Ako otestovať softvér orientovaný na zákazníka?

Odpoveď: S každou aplikáciou, ktorú testujeme, sa snažíme zistiť, či aplikácia spĺňa alebo nespĺňa určitý súbor požiadaviek. Pokiaľ však ide o web zameraný na používateľa, okrem sústredenia na funkčnosť musíme preskúmať aj niekoľko funkcií použiteľnosti, možno do istej miery aj aspekty výkonu a zabezpečenia.

Prvá úroveň testovania je : Spĺňa stránka svoje funkčné požiadavky?

Napríklad, ak sa jedná o stránku správy pôžičiek, musíme sa pozrieť na - či je nový zákazník schopný požiadať o pôžičku, či má existujúci zákazník prístup k svojim informáciám o pôžičke, či je úrok% uplatnený na výšku úveru správny atď.

Ďalšia úroveň testovania je :aké ľahké je použitie stránky, možnosti majú logický zmysel a zodpovedajú očakávaniam používateľa alebo nie.

Napríklad, ak musí užívateľ absolvovať 3-4 obrazovky, aby mohol poskytnúť základné informácie, bude naštvaný, takže je potrebné takéto problémy vyriešiť.

Ďalší príklad po zadaní používateľského mena a hesla môže používateľ kliknúť na kartu, čo znamená, že ovládací prvok by mal prejsť na tlačidlo „Prihlásiť sa“. Ak sa má zrušiť, bude skutočne naštvaný a skúsenosť s používaním stránky je bude kompromitované. Takéto problémy treba chytiť.

Testovanie výkonu v úplnom rozsahu nemusí byť v rozsahu, ale jednoduché situácie, ako napríklad, ako dlho trvá, kým sa zobrazia výsledky vyhľadávania, a koľko času trvá, kým systém načíta informácie o zákazníkovi v špičke - to sú niektoré príklady také veci, ktoré by sme chceli sledovať.

otázky a odpovede na pohovor vedúceho testu

Bezpečnosť - pre stránky, kde je zabezpečené prihlásenie pre prístup na stránku, musí byť testovaná minimálna funkčnosť okolo nich. Napríklad, ak nechám web nečinný dlhšie ako 10 minút, je to automatické odhlásenie alebo nie. Malo by sa zamerať na niečo také základné, ako je to.

#Q 4) Ako prekonať problém, keď nemáte vstupnú dokumentáciu na testovanie?

Odpoveď: AK nie je k dispozícii podrobná štandardná dokumentácia ako BRD a FSD, tester bude musieť závisieť od určitého referenčného bodu.

  • Screenshoty
  • Predchádzajúca verzia aplikácie
  • Drôtené rámy atď

Ďalším faktorom, ktorý nesmierne pomáha, je rozhovor s vývojármi alebo obchodnými analytikmi (ak sú k dispozícii), aby sme v prípade pochybností dostali potvrdenie o našom porozumení alebo objasnenie.

Keď žiadna z týchto situácií nefunguje, môžeme aplikáciu iba konceptualizovať na základe našich predchádzajúcich skúseností s IT aplikáciami a vytvoriť základnú sadu testovacích skriptov. Keď príde testovacia fáza, môžeme nastaviť časť času testovacieho cyklu a urobiť nejaké riadenie testovacích prípadov (vylepšiť už vytvorené skripty), aby sme mali dokument pre ďalšie fázy.

#Q 5) Ako sa dostať maximálna produktivita z offshore tímu?

Odpoveď: Kľúčom je zabezpečiť, aby všetci testujúci vedeli o všetkých moduloch a aby na jednom mieste neexistovala koncentrácia znalostí. Zapojením všetkých do vzájomných recenzií testovacích skriptov, stretnutí s defektmi a relácií KT sa zabezpečí, že každý bude o aplikácii vedieť v čo najlepšej miere.

Podporou koncepcie tímovej práce tiež môžeme dosiahnuť, aby členovia tímu spolupracovali, pomáhali si a pomáhali si pri zvyšovaní produktivity.

Procesu veľmi pomáhajú aj pravidelné následné stretnutia.

#Q 6) Aké sú úlohy a zodpovednosti miestneho koordinátora? Testuje tiež?

Odpoveď: Koordinátor na mieste je kontaktným bodom pre offshore tím a pre klienta v prípade akýchkoľvek informácií týkajúcich sa zákazky na testovanie.

Táto práca zahŕňa:

najlepší operačný systém pre notebook zadarmo
  • KT za do zahraničia a klientom
  • Príprava prostredia na vyskúšanie všetkých
  • Skúšky zdravého rozumu, skúšky dymu
  • Testovanie - kľúčová funkčnosť.
  • Recenzia chyby - nájdená zahraničným tímom
  • Priradenie chyby príslušnému dev
  • Prezentácia metrík
  • Poskytuje sa odhlásenie

Áno, musí to vyskúšať aj miestny koordinátor.

#Q 7) Nekonzistentné chyby - Prečo to na mieste môže nájsť, ale offshore nemôže a naopak - Ako túto situáciu vyriešiť?

Odpoveď: Každá chyba musí byť zaznamenaná a analyzovaná - či už sa vyskytne na mieste alebo na mori, či už je opakovateľná alebo nie. Skutočnou pridanou hodnotou pre prácu testera je, keď sa zapojíme do procesu analýzy hlavných príčin chyby a nebudeme ju iba hlásiť.

Niektoré zo spôsobov, ako môžeme túto situáciu vyriešiť, sú:

  • Všetci členovia tímu na mieste a na mori by sa mali riadiť pravidlom, že pri každej chybe, s ktorou sa stretneme, je potrebné urobiť snímky obrazovky - opakovateľné alebo nie.
  • Ak existujú protokoly, systémové súbory alebo niečo podobné, mohlo by nám to pomôcť nájsť akýkoľvek dôkaz o probléme - mali by sme sa ho pokúsiť nájsť.
  • Napriek všetkým týmto krokom, ak stále nemôžeme povedať, prečo a kedy sa problém vyskytne, mali by sme ho vývojárovi nahlásiť rovnako - s čo najväčším počtom informácií.

#Q 8) Testovanie súvisiace s videom / zvukom - Čo to zahŕňa?

Odpoveď: Ako otestovať aplikáciu obsahujúcu video alebo zvuk?

Tu je potrebné vziať do úvahy dôležité body:

  • Úrovne prístupu (obmedzené alebo nie - kontrolované pomocou hesla)
  • Rôzne druhy prostredí
  • Kompatibilita s prehľadávačmi
  • Rozlíšenie obrazovky
  • Rýchlosti internetového pripojenia
  • Konkrétne možnosti videa - napríklad prehrať, zastaviť, vypnúť zvuk atď.
  • Video podľa veľkosti
  • Odozva na videá - komentáre (obmedzenia dĺžky a počtu komentárov, ktoré môžu trvať)
  • Videoodpovede na videá
  • Rozhranie so sociálnymi sieťami - interoperabilita
  • Rýchlosť ukladania do vyrovnávacej pamäte
  • Vkladanie videa

#Q 9) ​​Testovanie mobilných aplikácií - čo to stručne obsahuje?

Odpoveď: Testovanie mobilných aplikácií Dôležité testovacie scenáre:

  • Skontrolujte, či aplikácia funguje dobre s viacerými operátormi a viacerými zariadeniami.
  • Použiteľnosť funkcií na obrazovke mobilného telefónu.
  • Testujeme na rôznych mobilných platformách - napríklad Android a iOS.
  • Inštalácie, odinštalovanie, spustenie aplikácie v sieti a bez nej, testovanie funkčnosti.
  • Sieťové pripojenia - Wi-Fi, 2G atď.
  • Na ladenie je možné použiť protokoly v konfiguračnom nástroji iOS pre iPhone pre Android Monitor.bat.

To bolo ono. Teraz to nebolo také jednoduché.

Na záver ešte zopakujem filozofiu na STH - poznajte dobre základy, ostatné automaticky nasledujú.

Na záver dúfam, že toto úsilie bude pre našich čitateľov prospešné a zmysluplné. Dajte nám vedieť nižšie v sekcii komentárov o tom, ako sa nám darilo.

Autor: Tento príspevok píše náš člen tímu STH Swati Seela.

Odporúčané čítanie

^