KKK

Järgmised on Guru99 kogukonna kõige korduma kippuvad küsimused

Kas te ei näe videoid?

Kõik sellel saidil olevad videod on hostitud saidil YouTube ja siia manustatud…
Te olete tõenäoliselt pääseb veebisaidile juurde kohast, kus YouTube on keelatud (teie ettevõte, kolledž või riik, kus YouTube on keelatud)

Proovige videotele juurde pääseda piiramatust keskkonnast.
Sa EI videote vaatamiseks tuleb registreeruda.

Ma ei saanud projekti kohta meili

Pange tähele, et projekti e-kirju saadetakse 24-tunnise intervalliga. Seega, kui tellisite neljapäeval kell 10, saate järgmise meili reedel kell 10.

Palun kontrollige oma rämpsposti või rämpsposti Mailkasti. Kui kasutate Gmaili, kontrollige Promovahekaart

Meie süsteemil pole e-kirjade uuesti saatmise funktsiooni. Kui te ikka e-kirju ei jälgi, tellige sisu hankimiseks muu e-posti ID-ga.

Kui mul on rakenduses viga, kes otsustab vea tõsiduse ja prioriteedi?

Tõsidus Defekt määrab probleemi tuvastaja (testija), prioriteedi aga isik, kes on seotud probleemi lahendamisega (arendajad).

Testijana saate defekte prioriteediks seada, mille testimisjuht tavaliselt üle vaatab. Arendajad otsustavad pärast analüüsimist, kas tegemist on kõrge prioriteediga või madala prioriteediga defektiga. Enamasti teeb selle arendaja, kuid ka testija võib selle tõsiduse selgitamiseks sellesse kaasata. Pärast arutelu jõuavad juhid järeldusele.

Raskusaste on põhiliselt seotud rakenduse või toote funktsionaalsusega. Kuigi prioriteet on see, kuidas arendaja saab selle vea või defekti kohe parandada. Prioriteet on olemuselt dünaamiline ja see muutub vastavalt stsenaariumile, samas kui tõsidus on olemuselt staatiline.

Mida teete, kui süsteemiga seotud funktsionaalseid spetsifikatsioone/dokumente pole?

  • Esmalt proovige ärianalüütikute või VKEdega valdkonnast aru saada. Süsteemi mõistmiseks tehke uurimuslikku testimist.
  • Kui projektil pole Business Analyst või VKEd, rääkige sarnaste süsteemide kallal töötanud inimestega.
  • Äritegevuse mõistmiseks rääkige kasutajate kogukonnaga
  • Uurige sarnase toote spetsifikatsiooni Internetist või PMO-st
  • Otsige sama tüüpi rakendustarkvara ja mõistke funktsioone
  • Otsige olulisi äristsenaariume, alternatiivseid dokumente ja rakendusteemalisi artikleid
  • Küsige arendajatelt selgitust kõigi moodulite kohta
  • Kasutajate ajaloolised andmed, rakendused ja funktsioonid
  • Ärge testige rakendust tehniliselt, esmalt testige oma rakendust ainult kasutaja vaatenurgast

Mida saab testija teha, kui ta leiab paar päeva enne väljaandmist saate katkestamise probleemi?

  • Kinnitage ja kinnitage Defekt uuesti ning võimalusel dokumenteerige viga või defekt, mõju ja võimalik lahendus.
  • Pöörake sellele oma juhi tähelepanu ja arutage seda meeskonnaga, kuna selline etenduse peataja pole nädal enne selle vabastamist meeskonnale teadmata.
  • Kui defekt jõuab teie juhi ja kõrgemate testimisasutusteni, peate võib-olla neile oma seisukoha avaldama, nii et olge oma seisukohaga põhjalik, kuna see võib avaldamist mõjutada.
  • Kui arutelu teid toetab, on teie aeg tõusta ja särada. Kui ei, siis saate selle päeva õppetunni kaasa võtta. Jätkake õppimist.

Miks valite tarkvara kvaliteedi tagamise valdkonna?

Kvaliteetsete projektide pakkumiseks lõppkasutajatele või kliendile on testimine kohustuslik, olenemata sellest, mis kodeerimise see hõlmab. Tarkvara QA mitte ainult ei logi vigu, vaid pakub ka nendele vigadele lahendusi.

Kvaliteedikontrolli valdkonnas peaksid testijad olema teadlikud testitava rakenduse kõigist funktsioonidest, mis võimaldab tal teada saada erinevates keskkondades välja töötatud erinevatest rakendustest, isegi mõnest programmeerimise põhikontseptsioonist. Teadmised on testimise ajal laiemad, kuid programmeerimise ajal on need kitsad. Arendaja võib arendada vaid väikest osa kogu rakendusest ega pruugi olla rakendusest kui tervikust teadlik. Antud juhul tundsin QA (testija) rolli huvitavam.

Ei leidnud vastust?

Võta meiega ühendust