Sissejuhatus SDET-i intervjuu küsimuste ja vastuste juurde
SDET, tarkvara kujundamise insener testimisel või tarkvara arendamise insener testimisel, tähistab peamiselt tarkvaratootega tehtavat testimist. Tegelikult oli vaja mõnda kandidaati, kes oleks võimeline arendama ja lisaks ka katseid tegema. Selle asutas algselt Microsoft, kuid praegu on teised organisatsioonid sama teadlikud ja nad otsivad tõesti SDET-i asjatundjaid, et nad saaksid kaasata oma toote täieliku väljatöötamise ja läbi viia vajaliku katsetamiskujunduse. selleks individuaalseks arenguks. Organisatsioon saab tutvustada sama ressurssi kahes võtmeülesandes, mis on neile alati kasumlik.
siin käsitleme SDET-i intervjuu populaarsemaid küsimusi.
Kui otsite SDET-iga seotud tööd, peate valmistuma 2019. aasta SDET-i intervjuuküsimusteks. On tõsi, et iga vestlus on erinevate tööprofiilide järgi erinev. Oleme siin koostanud olulised SDET-i intervjuu küsimused ja vastused, mis aitavad teil oma intervjuus edu saavutada.
Selles 2019. aasta SDET-i intervjuuküsimuste artiklis tutvustame 10 kõige olulisemat ja sagedamini küsitavat SDET-i intervjuu küsimust. Need intervjuuküsimused on jagatud kahte ossa:
1. osa - SDET-i intervjuu küsimused (põhilised)
See esimene osa hõlmab põhilisi SDET-i intervjuu küsimusi ja vastuseid.
Q1. Selgitage erinevuste üksikasju tarkvara arendamise inseneri testis (SDET) ja tarkvara käsitsi testimise vahel?
Vastus:
SDET kasutab peamiselt sukeldumiste automatiseerimise testimist. Toote väljatöötamise vahendeid saab automaatselt testida ilma käsitsi sekkumiseta. Seevastu käsitsi katsetamine ei vasta nendele kriteeriumidele üldse.
Q2. Kas kirjutate programmi mis tahes keeles numbri ümberpööramiseks?
Vastus:public class reverseNumber (
public long reverse(long num)
(
long temp=0;
while(num!=0)
(
temp=(temp*10)+(num%10);
num=num/10;
)
return temp;
)
public static void main(String args())
(
long n= 654312;
reverseNumber inp = new reverseNumber();
System.out.println(“Given number is “+ n);
System.out.println(“Reverse of given number is “+inp.reverse(n));
)
)
Q3. Selgitage üksikasjalikult, kuidas saaksime määratleda ad-hoc testimise praeguses IT-valdkonnas?
Vastus:
Juhuslik testimine on üks IT-tööstuses väga populaarsetest testimistest. Selline testimine peamiselt planeerimata ja dokumentideta. Tavaliselt peab see toimima siis, kui mõni ad hoc nõue tuleb kliendilt, arendaja peab selle välja töötama prioriteetsel viisil. Nüüd peab testija seda kohe katsetama ja pakkuma väga väikese aja jooksul korralikke tulemusi. Dokumenteerimine või kavandamine pole selle jaoks alati võimalik, kuid osa organisatsioone hooldas teatud spetsiifilisi tööriistu sedalaadi töö jälgimiseks, eriti lisaarvelduste jaoks.
Liigume järgmiste SDET-i intervjuu küsimuste juurde.
Q4. Kaks suurt märksõna on tavaliselt testijale väga kasulikud, üks on prioriteet ja teine on raskusaste, selgitage nende erinevust üksikasjalikult?
Vastus:
Prioriteet ja tõsidus on mõlemad väga olulised kaks märksõna IT-tööstuses, eriti nende organisatsioonide jaoks, kes on kaasatud pakutavate toodete või kliendi olemasolevate süsteemide tootmistegevustesse. Praegu üritas kogu rabaorganisatsioon järgida ühte konkreetset tööriista, kus käitlemiseks on määratud üks kasutajatoe meeskond. Tavaliselt jõuab lõppkasutaja sellesse vastavasse kasutajatoe meeskonda, et tõstatada oma mure või lõppkasutaja saab oma mure otse selle konkreetse tööriista abil luua. Mõni kasutajatoe inimene analüüsib kõigepealt seda, seejärel annab prioriteedi vastavalt lõppkasutaja mõjule. Kasutajatugi inimene, testija, arendaja ja mõni ajahetk ettevõtluse analüütik tegeleb selle teemaga ja püüab aru saada, milline on selle konkreetse küsimuse täpne mõju, tuginedes sellele, et nad on selle probleemi tõsidusele andnud. Nii et prioriteet määratleb selle teema olulisuse ja raskus on selle probleemi määratletud mõju või hävimisvõime.
Q5. Selgitage üksikasjalikult selgitusi testija või tarkvara arendamise inseneri töökohustuste kohta testimises?
Vastus:
See on tavaline intervjuus küsitav SDET-i intervjuu küsimus. SDET-testija peab praeguses IT-valdkonnas tavaliselt täitma mitmeid kohustusi.
- Kirjutage testimise automatiseerimine ja seadke see sordiplatvormidele, nagu veeb või mobiil.
- Veateate haldamine ja käsitlemine.
- Õige suhtluskanali säilitamine arendaja ja kliendi vahel.
- Testjuhtumite ettevalmistamine ja kohaletoimetamine.
Q6. Mis on ad-hoc testimine?
Vastus:
Ad-hoc testimine on määratletud kui testimine toimub ad-hoc põhimõttel, ilma viiteta ja korralike sisenditeta testjuhtumi jaoks ning ilma plaanide, testimisjuhtumite ja dokumentideta. Seda tüüpi testimise peamine eesmärk on defektide leidmine ja rakenduse katkestamine, rakendades rakenduse erinevaid vooge või juhuslikke funktsioone.
Ad-hoc testimine on mitteametlik viis rakendusest vigade leidmiseks ja seda saavad teha kõik meeskonna liikmed. Ilma testjuhtumiteta on raske vigu leida, kuid mõnikord leitakse ajutise testimise käigus vead, mida me tavapärase testimise või olemasolevate testimisjuhtude kaudu ei leidnud.
Q7. Kas on mõni näide koos üksikasjadega testija (SDET) ressursside testija või tarkvaraarenduse inseneri tüüpilise kogemuse või liigse tööpäeva kohta?
Vastus:
Kolm peamist ülesannet võtab testija jaoks igal päeval alati tohutult aega:
- Projekti nõuete mõistmine.
- Ettevalmistamine ja käivitamine eeldavad testjuhtumeid kliendi eeldatavate funktsioonide põhjal.
- Aruandlus kliendi jaoks välja töötatud üksikute funktsioonide tuvastatud tõrgete kohta arendajale ja uuesti katsetamine pärast arendaja poolt uuesti tarnimist, et tagada eeldatava funktsionaalsuse nõuetekohane edastamine ilma tavaliste vigadeta.
2. osa - SDET-i intervjuu küsimused (täpsemad)
Vaatame nüüd täpsemat SDET-i intervjuu küsimusi ja vastuseid.
Q8. Selgitage mõne eksperdi kommentaari kohta, kuidas üks testija saab otsustada, et tingimusel, et toode on tegelikult eluskeskkonnas liikumiseks valmis?
Vastus:
See on üks kriitilistest otsustest, nii et seda pole kunagi teinud üksik inimene ega nooremad poisid. Ainult arendaja ja testija pole selle otsuse vastuvõtmiseks kaasatud, kõrgem juhtkond on sellesse perioodiliselt kaasatud. Juhtimistestid tagavad peamiselt allpool toodud valideerimise, tagamaks, et toodete tarnimine on veatu:
- Testeri esitatud veateadete kontrollimine. Kuidas viga sai lahendatud ja testija tegi uuesti testimise või mitte.
- Kõigi testijate kirjutatud testimisjuhtude valideerimine selle konkreetse funktsionaalsuse, dokumentatsiooni ja testijalt saadud kinnituse kohta.
- Automaatsete testjuhtumite käitamine tagamaks, et uued funktsioonid ei rikuks olemasolevaid funktsioone.
- Mõnikord valideeritakse testi katvusaruanne, mis tagab, et kogu arenev komponent on kaetud testjuhtumitega.
Q9. Kirjutage programm kahe numbri vahetamiseks ilma temp muutujata?
Vastused:
Programm kahe numbri vahetamiseks ilma temp muutujata on järgmine:public class swap(
public static void main (String args())
(
int x = 20;
int y =30;
System.out.println(“Numbers before swapping”);
System.out.println(“ number x is “ + x);
System.out.println(“number y is “ +y);
// Swapping numbers
x= x+y;
y=xy;
x=xy;
System.out.println(“Numbers after swapping”);
System.out.println(“ number x is “ + x);
System.out.println(“number y is “ +y);
)
)
Q10. Kui keegi vajab testijalt ühte konkreetset vormingut veateateid, siis mida saab testija selle pakkumisel kasutada parimal viisil või lähenemisviisina?
Vastus:
Üks veateade sisaldab tavaliselt järgmist:
- Vea kokkuvõte
- Paljundage samme
- Ühe konkreetse vea eeldatav ja praegune käitumine.
Liigume järgmiste SDET-i intervjuu küsimuste juurde.
Q11. Selgitage üksikasjalikult erinevaid katsetamisviise, mida nimetatakse alfa- ja beetaversiooniks?
Vastus:
Testija tehtud alfatestid tuvastasid vead enne toote viimist elukeskkonda või lõpptarbijale. Beetavea tuvastab tavaliselt lõppkasutaja, kes on toote või rakenduse tegelikud kasutajad.
Q12.Mis on riskipõhine testimine?
Vastus:
Riskipõhine testimine on määratletud kui toote funktsionaalsuse testimine lähtuvalt väljundite prioriteedist. Riskipõhine testimine hõlmab toote oluliste omaduste testimist, millel on äriline mõju, ja nende funktsioonide rikke tõenäosus on väga suur. Toote kõigi funktsioonide prioriteedid seatakse ärinõuete alusel, seejärel testitakse esmatähtsaid funktsioone, seejärel keskmise ja seejärel madala prioriteediga funktsioone. Riskibaaside testimine viiakse läbi siis, kui toote kõigi funktsioonide testimiseks pole piisavalt aega.
Q13. Tavaliselt on sordikatsete juhtumite kaupa ühe konkreetse rühma moodustamiseks saadaval erinevad kategooriad, arvestades nende selgitust?
Vastus:
See on kõige populaarsem intervjuus küsitav SDET-i intervjuu küsimus. Allpool on toodud mõned populaarsed testijuhtumid praeguses IT-tööstuses:
- Funktsionaalne testimine
- Frontendi või kasutajaliidese testimine
- Jõudluse testimine
- Integratsiooni testimine
- Koormustestid või Kasutajate kasutatavuse testimine
- Turvakontroll
Q14. Levinumad väljakutsed, millega üks tarkvaratester tavaliselt silmitsi seisab, see on korralik dokumentatsioon, mida ei säilitata testimiseks. Sel juhul kuidas me saame sellest üle?
Vastus:
See on üks levinumaid stsenaariume, kus dokumentatsioon ei ole igasuguste testijuhtumite jaoks õigesti kättesaadav, kuid nõue peab olema sama ja õigeaegselt kliendile edastatud. Tavaliselt jälgib testija mõnda kliendi edastatud e-kirja, kus kirjeldatakse kõiki nõudeid õigesti, võimaluse korral ekraanipilte rakendusest, kus muudatuste osad on selgelt mainitud, või mõnd esmaspäevast või verbaalset telefonilist vestlust kliendiga, et mõista muudatuste täpset funktsionaalsust. millest piisab kiireks testimiseks ja sama jõudmiseks loodetud ajajoonel.
Soovitatavad artiklid
See on olnud juhis SDET-i intervjuu küsimuste ja vastuste loendisse, et kandidaat saaks neid SDET-i intervjuuküsimusi hõlpsalt lahendada. Selles postituses oleme uurinud populaarsemaid SDET-i intervjuu küsimusi, mida küsitakse sageli intervjuudes. Lisateabe saamiseks võite vaadata ka järgmisi artikleid -
- Andmestruktuur Java intervjuu küsimused
- 10 olulist Kafka intervjuu küsimust
- UI arendaja intervjuu küsimused
- Küberturvalisuse intervjuu küsimused