Meni

7-stopenjsko praktično izvajanje ročnega preskušanja pred sprostitvijo proizvodnje

7 step practical implementation manual testing before production release

Preizkusite Naš Instrument Za Odpravo Težav

V prejšnjem prispevku te serije o ročnem preizkušanju sem poskušal osvetliti osnove ročnega preizkušanja čim več svetlobe.

Če ste ga zamudili, lahko si ga preberete tukaj .

Upam, da vas je uspelo čim bolj približati iskanim odgovorom.

Ali v tem primeru ne bi radi izvedeli več o praktičnem izvajanju ročnega testiranja, kako ga bolje spoznati in kako v njem dejansko začeti kariero?

Ta članek bo osvetlil vse te vidike.

Izvajanje ročnega testiranja

Začnimo.

Kaj se boste naučili:

Cikel ročnega preskušanja

Razumeti Cikel ročnega preskušanja ali življenjski cikel preizkusa programske opreme (STLC), najprej moramo razumeti življenjski cikel razvoja programske opreme (SDLC), za katerega sem prepričan, da ga že razumete.

Ljudje se nanje sklicujejo ločeno, vendar niso prepričani, ali lahko resnično sobivajo. So tako tesno povezani med seboj. No, tudi v teh ciklih je ustvarjenih toliko različic, ki plujejo v internetnem prostoru, se zelo razlikujejo glede na izbrani razvojni model.

Kot večina svet gre gibčen te dni bom svoje stvari poenostavil okoli Agilea.

7 praktičnih korakov za ročno preskušanje pred izdajo proizvodnje

Izvoli.

Ne pozabite, da govorim o SDLC in STLC.

# 1) Zbiranje zahtev

Faza zbiranja zahtev

Poslovni analitik (oseba / skupina, odgovorna za zbiranje zahtev) dokumentira zahteve. Dokumentirajo zahteve, to je vrhunec, osredotočite se lahko samo na to. Kjer je dokumentirano, je manj pomembno.

Ljudje uporabljajo karkoli za dokumentiranje teh, kar jim ustreza, vendar ne omejeno na tradicionalne platforme, kot je MS word doc, sodobne platforme, kot so Jira / Rally, in new age orodja, kot je Trello.

# 2) Diskusija / izmenjava zahtev

Faza razprave o zahtevah

Potem naj bi poslovni analitik dokumentirane zahteve delil z razvojno skupino, preskusno skupino in ekipo UX (če je potrebno). Običajno se to zgodi na uradnem sestanku, na katerem SPOC (odvisno od celotne skupine ali celotne ekipe) iz vseh treh funkcij izpolnijo in razumejo celotno zahtevo.

V zdravi delovni kulturi se o zahtevah razpravlja z vseh strani in vsak član sestanka lahko postavlja vprašanja in dvome. Ko so odgovori na vsa vprašanja in opravljena potrebna sprememba zahteve, lahko to fazo štejemo za Končano. Tudi to, kar imenujemo ta sestanek / korak in njegova dokumentacija, se razlikuje od podjetja do podjetja.

nadaljnje branje=> Kako pregledati dokument SRS

Ko bomo odgovorili na vsa vprašanja in izvedli potrebne spremembe zahteve, lahko to fazo obravnavamo kot Končano .

Tudi to, kar imenujemo ta sestanek / korak in njegova dokumentacija, se razlikuje od podjetja do podjetja.

Na primer dokumentacija se pokliče ali razčleni kot SRS (specifikacija sistemskih zahtev), dokument dokumenta, epika, uporabniška zgodba, točka zgodbe (po možnosti najmanjša enota zahteve) itd. V podobnih vrsticah se ta sestanek, na katerem se zahteva deli, pokliče kot Zahteva Pogovorni sestanek, negovanje, luknjanje itd., Upam, da razumete mojo točko?

Če pritisnete na te terminologije, da se boste vedno spomnili glavne ideje, ne glede na različna imena.

Objavi ta sestanek, sprožita se dva koraka hkrati, brez posebnega vrstnega reda, glej naslednja dva koraka.

# 3) Oblikovanje

Razvojna skupina začne s svojim tehničnim načrtovanjem takoj, ko se razpravlja o zahtevah in ko ni večjih nerešenih točk. Kaj se naredi v tej fazi, se od podjetja do podjetja spet razlikuje.

Ta faza lahko vključuje, vendar ne omejeno na naslednje naloge:

  • Odločanje o razvojnem pristopu
  • Priprava projektnega dokumenta
  • Oblikovanje diagramov poteka
  • Ocenjevanje prizadevanj
  • Ugotovitev vpliva te nove zahteve na katero koli obstoječo funkcionalnost
  • Treba je popraviti obstoječe podatke itd.

Skupina UX se lahko v to fazo vključi tudi, ko pride do spremembe uporabniškega vmesnika ali pa je treba razviti nov zaslon. Skupina UX pomaga razvojni skupini in preskusni skupini s prototipom uporabniškega vmesnika za funkcionalnost / funkcijo v razpravi. To je lahko Photoshop dokument, preprosta slika, predstavitev PowerPointa ali kar koli drugega, zaradi česar bo razvojna skupina razumela, kako je treba razvijati zaslone.

Opomba: V najboljšem primeru bi bili ti zasloni ali vsaj njihove osnutke prikazani v razpravi o zahtevah samo zato, da bi ekipa lažje razumela. Označi se na prvotno zahtevo, tako da se nanjo lahko kadar koli sklicuje.

# 4) Preskusni scenarij / oblikovanje testnega primera

Testni scenarij Faza načrtovanja

Vzporedno s fazo načrtovanja preizkusna skupina začne z izdelavo testnih scenarijev in / ali testnih primerov na podlagi obravnavanih zahtev. Ali se testni scenariji vedno najprej napišejo in nato vdrejo v testne primere, nekaj, kar spet ni konstantno.

Po mojem mnenju, ne glede na to, ali dokumentirate testne scenarije ali ne, so vedno na voljo pred testnimi primeri. Testni scenarij je vaša točka, za katero lahko rečete, da vas vodi do nadaljnjih podrobnosti. Ko je pisanje testnih primerov končano, ga lahko delite z ekipo za razvoj, da jim predstavi obseg testiranja, prav tako pa lahko poskrbijo, da razvoj, ki se je zgodil ali dogaja, izpolnjuje pisne testne primere.

Ko je pisanje testnih primerov končano, ga lahko delite z ekipo za razvoj, da jim predstavi obseg testiranja, prav tako pa lahko poskrbijo, da razvoj, ki se je zgodil ali dogaja, izpolnjuje pisne testne primere.

Preizkusni primeri, ko so napisani, jih v najboljšem primeru pregleda vodja preizkusa ali vrstnik z različnih zornih kotov, kot so:

  • Kritje zahtev
  • Pravopisna slovnica
  • Standardi za pisanje testnih primerov (nič drugega kot predloga, ki jo sledi ekipa / podjetje)
  • Združljivost nazaj
  • Združljivost s platformo
  • Referenca podatkov o preskusu
  • Vrste ciljnih testiranj itd.

nadaljnje branje=> Pisanje testnih primerov iz dokumenta SRS

V idealnem primeru se šele po pregledu in potrebnih spremembah posredujejo razvojni skupini.

Ko sem rekel 'ko je pisanje testnih primerov končano', sem enkrat mislil, da so 'vsi testni primeri napisani na podlagi popolnega poznavanja danih zahtev in možnih testnih scenarijev, odkritih do takrat'. Skoraj nemogoče je imeti 100-odstotno pokritost s testnimi primeri na prvi poti.

Napake boste našli pri naključnih (a predvidenih) dejanjih, pri povsem naključnih dejanjih (testiranje opic) in v nekaterih redkih scenarijih. Obstaja verjetnost, da boste nekaj od njih zamudili. In včasih boste morda pogrešali celo zelo osnovne, navsezadnje ste človek. Tu pa vas lahko reši vsaj dober pregled testnih primerov in strukturiran način pisanja testnih primerov.

Pogosto preizkuševalci ali preizkuševalci še naprej dodajajo vedno več testnih primerov obstoječemu delu, ko odkrivajo resnico ali razmišljajo več o zahtevah.

No, nekateri že zdaj dvomite o mojem poznavanju preizkušanja programske opreme, saj neke besede (ki je nekako postala običajna pri preizkušanju programske opreme) še ne uporabljam. Testni načrt kajne?

Naj povem nekaj o tem. Močno verjamem v potrebo po večini informacij, ki so omenjene v testnem načrtu, vendar se mi zdi sporno dokumentiranje vseh na istem mestu in njihovo popolno obveznost.

Kakor koli že, to je povsem ločena tema za razpravo. Težko je deliti informacije, ki ustrezajo vsem, vendar naj poskusim.

Ali vi, vi s svojim testnim vodnikom ali testnim vodičem pripravite testni načrt ali pa dokumentirate zahtevane informacije na različnih mestih.

Nadaljnje branje=> Kako napisati dokument s testnim načrtom

Informacije, ki bi jih bilo treba v tej fazi popolnoma zamrzniti:

  • Obseg testiranja: Zahteva, povratna združljivost, platforme, naprave itd.
  • Oseba / ekipa, ki bo testirala
  • Ocena preskusnega napora
  • Omejitve: Vse predpostavke ali vnaprej sprejete omejitve.
  • Ljudje dodatno dokumentirajo vstopna merila, izstopna merila, tveganje itd., Za katere menim, da jih v resnici ni treba posebej omenjati, saj bi to moralo biti običajno razumevanje.
    • Merila za vstop (Kdaj začeti s testiranjem): Le malo jih začne, ko je za testiranje na voljo preizkusni del funkcionalnosti. Le malo jih čaka, da bo mogoče preizkusiti celotno funkcionalnost. Ko ugotovimo, da osnovni tok deluje, se začne testiranje.
    • Merila izstopa (Kdaj ustaviti): Kadar ni blokatorja, je mogoče pri preskusu na odprti stopnji ustaviti kritične in večje (izpostavljene udarcem) napake. Ali na sredini, ko je preveč napak, s katerimi se sooča testiranje, lahko ustrezne zainteresirane strani ustavijo.
    • Tveganje : Poslovno tveganje ali funkcionalno tveganje, če se testiranje ne izvede v skladu z dokumentiranim načrtom.

# 5) Razvojna faza

Faza razvoja programske opreme

Razvojna skupina po fazi načrtovanja začne z dejanskim razvojem in preskušanjem enote, ko in ko konča z razvojem preizkusnih kosov zahtev. Funkcionalnost za preskušanje v kosih lahko posredujejo, ko in ko je izvedena, ali pa lahko prenesejo celotno funkcionalnost hkrati.

V idealnem primeru se formalni pregled kode in testiranje belega polja zgodi, preden prenesete razvito funkcionalnost za testiranje. idealno bi bilo, da bi se razvojna skupina poleg zahtev in projektne dokumentacije sklicevala tudi na testne primere, ki jih je zagotovila preskusna skupina.

# 6) Faza testiranja

Kot smo že omenili, se začetek te faze razlikuje od podjetja do podjetja, od ekipe do ekipe.

Skupina za testiranje začne testiranje bodisi, ko je razvit del celotne zahteve, kadar je preizkusljiv (nekaj, kar je mogoče neodvisno preizkusiti), ali ko je razvita celotna zahteva.

spletna mesta za ogled brezplačne anime v angleščini

Naj se v tej fazi podrobneje podrobno pogovorim o pomembnih nalogah:

  • Tester / preizkuševalna skupina začne s preizkusnim krogom (raziskovalno preskušanje in izvajanje pisnih testnih primerov) in zapisovanjem napak
  • Razvojna skupina jih razreši po prioritetah.
  • Nova gradnja (koda) je narejena za okolje, v katerem se izvaja testiranje
  • Odpravljene napake nato preveri preizkuševalec / preskusna skupina in jih označi kot odpravljene
  • Ta cikel se nadaljuje, dokler niso dosežena merila za izhod iz časa.
  • Upoštevajte, da so po potrebi napake označene tudi kot neveljavne, podvojene in jih je mogoče tudi kategorizirati kot izboljšave.

Druga stvar, ki se razlikuje od podjetja do podjetja, je, koliko preskusnih krogov je treba opraviti. Tako kot v nekaterih primerih se prvi krog testiranja izvede na majhnih delih, ko so pripravljeni, nato pa krog preskusa v drugem okolju, ko se razvijejo vse zahteve. Ampak spet sem slišal tudi za ljudi, ki so opravili tri ustrezna polna preizkusna kroga in četrti kot krog zdravja / dima.

Prvi program za več krogov preizkušanja je preizkušanje funkcionalnosti v različnih okoljih, drugi pa preizkušanje od konca do konca, ko se razvijejo vse zgodbe. Sanity round ponavadi hitro pridobi samozavest, ko so vse zgodbe v izdaji razvite in preizkušene neodvisno.

Preberite podrobne korake=> Faza izvedbe testa

# 7) Pregled poslovnega analitika (BA)

Poslovni analitik pregleda zahtevano funkcionalnost bodisi s sklicevanjem na rezultat testa bodisi s sklicevanjem na rezultat testa in poigravanjem z aplikacijo, da dobi dejanski občutek. Ta korak je ponovno podvržen različnim ukrepom med podjetji.

BA lahko pregleda obseg celotne izdaje naenkrat ali v kosih. Odvisno od istega lahko ta korak nastopi pred zadnjim preizkusom zdravstvenega stanja ali po zadnjem krogu preizkušanja zdravstvenega stanja, ki ga opravi preizkusna skupina.

Zgoraj 7 korakov se zgodi, da morajo biti izpolnjene vse uporabniške zgodbe / zahteve, zlasti izdaja (pošiljka). Ko bodo vsi ti koraki izpolnjeni za vse zahteve, naj bi bila izdaja pripravljena za odpremo.

# 8) Pošiljanje / sprostitev

Izdaja je označena kot Pripravljen za odpremo po uspešnem pregledu poslovnega analitika.

Priporočeno branje=> Preskusni postopek sprostitve

Vrste ročnega (beri človeškega) testiranja

No, če se moramo pogovarjati o splošnih vrstah testiranja v številkah, sem nekje našel več 100 vrst testiranja z različnimi imeni . Če sem iskren, nisem dovolj pameten, da bi razumel razliko med vsemi temi vrstami (namenjen besedni igri).

Je naravnost in preprosto: Testiranje funkcionalnosti aplikacije glede na dano zahtevo s človeškimi napori in inteligenco. Nadalje se razdeli na nekaj vrst glede na obseg in agendo testiranja. Vrste, naštete v naslednjem odstavku.

Nadalje se razdeli na nekaj vrst glede na obseg in agendo testiranja. Vrste, naštete v naslednjem odstavku.

Če mi je dovoljeno, naj spregovorim nekaj vrstic človeškega testiranja (kar vsakemu preizkuševalcu priporočam, naj opravi le ročno funkcionalno testiranje). Zdaj se ne zmedite, po mojem mnenju je ročno funkcionalno testiranje podmnožica človeškega testiranja. Ker je toliko stvari, ki jih lahko naredi samo človeški um.

Spodaj je seznam z nekaterimi priljubljenimi in pomembnimi vrstami testiranja, ki jih lahko razvrstimo v človeško testiranje:

  • Ročno funkcionalno preskušanje : Testiranje funkcionalnosti aplikacije glede na dano zahtevo s človeškimi napori in inteligenco. Nadalje se razdeli na kar nekaj vrst glede na obseg in agendo testiranja, kot so sistemsko testiranje, enotno testiranje, dimno testiranje, preizkušanje zdravega stanja, integracijsko testiranje, regresijsko testiranje, testiranje uporabniškega vmesnika itd.
  • Testiranje učinkovitosti : To se uvrsti v nefunkcionalno testiranje, kajne? Toda spet je človek tisti, ki ga izvaja, čeprav izvršitev opravi človek ali orodje. Preizkuševalec mora to preskušanje opraviti vsaj glede na odzivni čas (da ugotovi, ali je sprejemljivo), če naj ne bi uporabljal nobenega orodja za preskušanje obremenitve in vse ostalo.
  • Brskalnik / Testiranje združljivosti platforme: Preskušana aplikacija bi morala izgledati in delovati po pričakovanjih (očitno lahko obstajajo manjše razlike glede na motor brskalnika) med brskalniki in platformami (ali napravami, če gre za mobilno aplikacijo).
  • Testiranje uporabnosti : Najprej se strinjam, da je to velika tema sama po sebi in je običajno v lasti strokovnjakov za testiranje uporabnosti. Še vedno verjamem, da bi morali kot preizkuševalec vsaj poročati ali poudarjati, če se nam zdi kaj manj uporabnega, ali pa bi morali deliti svoje mnenje.
  • Testiranje varnosti : Spet zelo velik tip testiranja in seveda zahteva veliko praktičnega znanja. Preskuševalec se mora poskusiti naučiti in izvesti vsaj osnovne preizkuse, kot so nedovoljeno spreminjanje URL-jev, skriptiranje na več mestih, vbrizgavanje SQL, ugrabitev sej itd., Odvisno od razpoložljivega znanja in kjer koli je to primerno.
  • Testiranje več najemniških pogojev: Če je vaša aplikacija večnajemniška, tj. En primerek, ki vsebuje podatke več odjemalcev, je to preskušanje nujno. To je treba storiti ne glede na izrecno navedbo v zahtevah. Podatki ene stranke, ki se prikažejo drugi, so nekakšen razvojni zločin in preizkušanje kaznivega dejanja.

Opomba: Zgoraj pogledi so moji osebni pogledi. Priporočam vam tudi, da si ogledate obsežen seznam vrst preizkušanja svojega znanja in jim sledite / jih uporabite, če se vam zdi potrebno. Z leti sem razumel, da ne glede na to, ali nekaj uporabljate ali ne, verjamete v nekaj ali ne, bi morali še vedno imeti nekaj znanja o široko uporabljenih konceptih na svojem področju.

To je vse za ta del. Hvala za branje. Delite svoja mnenja / povratne informacije v komentarjih.

V naslednjem in zadnjem delu tega serija vadnic za ročno testiranje , Skušal vam bom pomagati vsem kakšne priprave bi morali opraviti, če želite vstopiti na področje testiranja in kakšni so možni načini, kako priti tja.

Priporočeno branje

^