Testaussuunnitelma on yksityiskohtainen dokumentti, joka kuvaa ohjelmistojen testausalueet ja -toiminnot. Siinä esitetään testistrategia, tavoitteet, testiaikataulu, tarvittavat resurssit (henkilöresurssit, ohjelmistot ja laitteistot), testiarvio ja testitulokset.

milloin win 7 ilmestyi

Testisuunnitelma on jokaisen ohjelmiston testauksen perusta. Se on tärkein toiminta, joka varmistaa kaikkien suunniteltujen toimien luetteloiden saatavuuden sopivassa järjestyksessä.

Testaussuunnitelma on malli ohjelmistotestaustoimintojen suorittamiseen määriteltynä prosessina, jota testauspäällikkö valvoo ja hallitsee täysin. Testisuunnitelman laativat testijohto (60 %), testauspäällikkö (20 %) ja testausinsinööri (20 %).

Testisuunnitelman tyypit

Testisuunnitelmaa on kolmenlaisia

• Master Test Plan
• Vaihetestaussuunnitelma
• Testaustyyppikohtaiset testisuunnitelmat

Master Test Plan

Master Test Plan on eräänlainen testisuunnitelma, jossa on useita testaustasoja. Se sisältää täydellisen testistrategian.

Vaihetestaussuunnitelma

Vaihetestaussuunnitelma on eräänlainen testisuunnitelma, joka koskee mitä tahansa testausstrategian vaihetta. Esimerkiksi luettelo työkaluista, luettelo testitapauksista jne.

Erityiset testisuunnitelmat

Erityinen testisuunnitelma, joka on suunniteltu tärkeimmille testauksille, kuten tietoturvatestaus, kuormitustestaus, suorituskykytestaus jne. Toisin sanoen erityinen testisuunnitelma, joka on suunniteltu ei-toiminnalliseen testaukseen.

Kuinka kirjoittaa testisuunnitelma

Testisuunnitelman tekeminen on testinhallintaprosessin tärkein tehtävä. IEEE 829:n mukaan laadi testisuunnitelma seuraavien seitsemän vaiheen mukaisesti.

• Analysoi ensin tuotteen rakenne ja arkkitehtuuri.
• Suunnittele nyt testistrategia.
• Määrittele kaikki testin tavoitteet.
• Määritä testausalue.
• Määrittele kaikki käytettävät resurssit.
• Suunnittele kaikki toiminnot sopivalla tavalla.
• Määritä kaikki testitulokset.

Testaussuunnitelman komponentit tai attribuutit

Testisuunnitelma koostuu erilaisista osista, jotka auttavat meitä johtamaan koko testaustoiminnan.

Tavoitteet: Se koostuu tiedoista moduuleista, ominaisuuksista, testitiedoista jne., jotka osoittavat, että sovelluksen tarkoitus tarkoittaa sovelluksen käyttäytymistä, tavoitetta jne.

Laajuus: Se sisältää tietoja, jotka on testattava kunkin sovelluksen kanssa. Soveltamisala voidaan jakaa edelleen kahteen osaan:

• Laajuudessa
• Ulos ulottuvuudesta

Laajuudessa: Nämä ovat moduulit, jotka on testattava tarkasti (yksityiskohtaisesti).

Alueen ulkopuolella: Nämä ovat moduuleita, joita ei tarvitse testata tiukasti.

Esimerkiksi , Oletetaan, että meillä on Gmail-sovellus testattavaksi, missä testattavia ominaisuuksia kuten Kirjoita sähköpostit, lähetetyt kohteet, postilaatikko, luonnokset ja ominaisuuksia, joita ei testata kuten auta , ja niin edelleen, mikä tarkoittaa, että suunnitteluvaiheessa päätämme tuotteessa annetun aikarajan perusteella, mikä toimivuus on tarkistettava vai ei.

Nyt miten päätämme, mitä ominaisuuksia ei testata?

Meillä on seuraavat seikat, joiden perusteella voimme päättää, mitä ominaisuutta ei testata:

• Kuten yllä näemme auta ominaisuuksia ei testata, koska sen on kirjoittanut ja kehittänyt tekninen kirjoittaja ja tarkistanut toinen ammattimainen kirjoittaja.
• Oletetaan, että meillä on yksi sovellus, jolla on P, Q, R ja S ominaisuuksia, joita on kehitettävä vaatimusten perusteella. Mutta täällä S-ominaisuuden on jo suunnitellut ja käyttänyt joku muu yritys. Joten kehitystiimi ostaa S:n kyseiseltä yritykseltä ja integroi sen lisäominaisuuksiin, kuten P, Q ja R.

Nyt emme tee S-ominaisuuden toiminnallista testausta, koska sitä on jo käytetty reaaliajassa. Mutta teemme integraatiotestauksen ja järjestelmätestauksen P-, Q-, R- ja S-ominaisuuksien välillä, koska uudet ominaisuudet eivät ehkä toimi oikein S-ominaisuuden kanssa, kuten alla olevasta kuvasta näkyy:

• Oletetaan, että tuotteen ensimmäisessä julkaisussa on kehitetty elementtejä, kuten P, Q, R, S, T, U, V, W…..X, Y, Z . Nyt asiakas toimittaa vaatimukset uusille ominaisuuksille, jotka parantavat tuotetta toisessa julkaisussa ja uudet ominaisuudet ovat A1, B2, C3, D4 ja E5.

Sen jälkeen kirjoitamme laajuuden testisuunnitelman aikana nimellä

Laajuus

Testattavat ominaisuudet

A1, B2, C3, D4, E5 (uudet ominaisuudet)

P, Q, R, S, T

Ominaisuudet, joita ei testata

W…..X, Y, Z

Siksi tarkistamme ensin uudet ominaisuudet ja jatkamme sitten vanhoilla ominaisuuksilla, koska se saattaa vaikuttaa uusien ominaisuuksien lisäämisen jälkeen, mikä tarkoittaa, että se vaikuttaa myös vaikutusalueisiin, joten teemme yhden kierroksen regressiotestausta P, Q , R…, T ominaisuudet.

Testausmenetelmä:

Se sisältää tietoja erilaisten testausten, kuten toiminnallisen testauksen, integraatiotestauksen ja järjestelmätestauksen, suorittamisesta sovelluksessa. Tässä päätämme minkä tyyppistä testausta; suoritamme eri ominaisuudet sovellusvaatimuksen perusteella. Ja tässä pitäisi myös määritellä, millaista testausta käytämme testausmetodologioissa, jotta kaikki, kuten johto, kehitystiimi ja testaustiimi, ymmärtävät helposti, koska testausehdot eivät ole vakioita.

Esimerkiksi, itsenäiseen sovellukseen, kuten Adobe Photoshop , suoritamme seuraavan tyyppisiä testejä:

Savutestaus → Toimintatestaus → Integrointitestaus → Järjestelmätestaus → Adhoc-testaus → Yhteensopivuustestaus → Regressiotestaus → Globalisaatiotestaus → Esteettömyystestaus → Käytettävyystestaus → Luotettavuustestaus → Palautustestaus → Asennus- tai asennuksen poistotestaus

Ja oletetaan, että meidän on testattava https://www.jeevansathi.com/ sovellus, joten suoritamme seuraavan tyyppisiä testejä:

Lähestyä

Tätä attribuuttia käytetään kuvaamaan sovelluksen kulkua testauksen aikana ja myöhempää käyttöä varten.

Voimme ymmärtää sovelluksen kulun seuraavien näkökohtien avulla:

Kirjoittamalla korkean tason skenaarioita Kirjoittamalla vuokaavion

Kirjoittamalla korkean tason skenaarioita

Esimerkiksi , oletetaan, että testaamme Gmail sovellus:

• Kirjaudu Gmailiin - lähettää sähköpostin ja tarkistaa, onko se Lähetetyt-sivulla
• Kirjaudu sisään …….
• ……
• .........

Kirjoitamme tämän kuvaamaan lähestymistapoja, jotka on otettava tuotteen testaamiseen ja vain kriittisiin ominaisuuksiin, joissa kirjoitamme korkean tason skenaarioita. Tässä emme keskity kattamaan kaikkia skenaarioita, koska kyseinen testausinsinööri voi päättää, mitä ominaisuuksia on testattava vai ei.

Kirjoittamalla vuokaavion

Vuokaavio on kirjoitettu, koska korkean tason skenaarioiden kirjoittaminen vie vähän aikaa, kuten alla olevasta kuvasta näkyy:

Luomme vuokaavioita saadaksemme seuraavat edut, kuten:

• Peitto on helppoa
• Yhdistäminen on helppoa

Lähestymistapa voidaan jakaa kahteen osaan, jotka ovat seuraavat:

• Ylhäältä alas -lähestymistapa
• Alhaalta ylös -lähestymistapa

Oletus

Se sisältää tietoa ongelmasta tai ongelmasta, joka saattaa ilmetä testausprosessin aikana, ja kun kirjoitamme testaussuunnitelmia, varmistetut oletukset tehdään, kuten resurssit ja tekniikat jne.

Riski

Nämä ovat haasteita, jotka meidän on kohdattava testataksemme sovellusta nykyisessä julkaisussa, ja jos oletukset epäonnistuvat, siihen liittyy riskejä.

Esimerkiksi, hakemuksen vaikutus, julkaisupäivä siirtyy.

Lievennyssuunnitelma tai varautumissuunnitelma

Se on varasuunnitelma, joka on valmis voittamaan riskit tai ongelmat.

Katsotaanpa yksi esimerkki oletukselle, riskille ja varautumissuunnitelmalle yhdessä, koska ne liittyvät toisiinsa.

Missä tahansa tuotteessa oletus Teemme niin, että kaikki kolme testiinsinööriä ovat paikalla tuotteen valmistumiseen asti ja jokaiselle heistä on määritetty eri moduulit, kuten P, Q ja R. Tässä skenaariossa riski voisi olla niin, jos testiinsinööri jättäisi projektin kesken sen.

java-skanneri seuraavaksi

Siksi valmiussuunnitelma jokaiselle ominaisuudelle määritetään ensisijainen ja alisteinen omistaja. Joten jos yksi testiinsinööri lähtee, alainen omistaja ottaa tämän ominaisuuden haltuunsa ja auttaa myös uutta testausinsinööriä, jotta hän ymmärtää heille osoitetut moduulit.

Oletukset, riskit ja lievennys- tai varasuunnitelmat ovat aina tarkkoja itse tuotteessa. Erityyppiset riskit ovat seuraavat:

• Asiakkaan näkökulma
• Resurssien lähestymistapa
• Tekninen lausunto

Rooli ja vastuu

Se määrittelee täydellisen tehtävän, joka koko testausryhmän on suoritettava. Kun suuri projekti tulee, niin Testipäällikkö on henkilö, joka kirjoittaa testisuunnitelman. Jos pieniä projekteja on 3-4, testipäällikkö osoittaa jokaisen projektin jokaiselle testijohdolle. Ja sitten testijohto kirjoittaa projektin testisuunnitelman, joka hänelle määrätään.

Katsotaanpa yksi esimerkki, jossa ymmärrämme testipäällikön, testijohdon ja testiinsinöörien roolit ja vastuut.

Rooli: Testipäällikkö

Nimi: Ryan

Vastuu:

• Valmistele (kirjoita ja tarkista) testisuunnitelma
• Järjestä tapaaminen kehitystiimin kanssa
• Järjestä tapaaminen testausryhmän kanssa
• Järjestä tapaaminen asiakkaan kanssa
• Järjestä yksi kuukausittainen stand up -kokous
• Allekirjoita julkaisutiedote
• Eskalaatioiden ja ongelmien käsittely

Rooli: Testijohto

Nimi: Harvey

Vastuu:

• Valmistele (kirjoita ja tarkista) testisuunnitelma
• Järjestä päivittäin stand up -kokous
• Tarkista ja hyväksy testitapaus
• Valmistele RTM ja raportit
• Määritä moduulit
• Käsittelyaikataulu

Rooli: Testausinsinööri 1, testausinsinööri 2 ja testausinsinööri 3

java luokkakaavio

Nimi: Louis, Jessica, Donna

Määritä moduulit: M1, M2 ja M3

Vastuu:

• Kirjoita, tarkista ja suorita testiasiakirjat, jotka koostuvat testitapauksista ja testiskenaarioista
• Lue, tarkista, ymmärrä ja analysoi vaatimus
• Kirjoita sovelluksen kulku
• Suorita testitapaus
• RTM vastaaville moduuleille
• Vian seuranta
• Valmistele testin suoritusraportti ja välitä se testijohdolle.

Ajoittaa

Sitä käytetään selittämään työskentelyn ajoitusta, mikä on tehtävä, vai tämä attribuutti kattaa milloin jokaisen testaustoiminnon tulisi tarkalleen alkaa ja päättyy? Ja tarkat tiedot mainitaan myös jokaisesta testaustoiminnasta tiettynä päivänä.

Siksi, kuten alla olevasta kuvasta näemme, tietylle toiminnalle on aloitus- ja lopetuspäivämäärä; jokaiselle tietyn koontiversion testaamiselle on määritetty päivämäärä.

Esimerkiksi

• Testitapausten kirjoittaminen
• Toteutusprosessi

Vian seuranta

Se tehdään yleensä työkalujen avulla, koska emme voi seurata jokaisen vian tilaa manuaalisesti. Kommentoimme myös, kuinka kommunikoimme testausprosessin aikana tunnistetuista virheistä ja lähetämme ne takaisin kehitystiimille ja miten kehitystiimi vastaa. Mainitsemme tässä myös virheiden, kuten korkean, keskitason ja alhaisen, prioriteetin.

Seuraavat ovat eri näkökohtia vian seurannasta:

Tekniikat vian jäljittämiseksi
…..
……
……
……Virheenseurantatyökalut
Voimme kommentoida työkalun nimeä, jota käytämme virheiden jäljittämiseen. Jotkut yleisimmin käytetyistä virheenseurantatyökaluista ovat Jira, Bugzilla, Mantis ja Trac jne.<Vakavuus
Vakavuus voi olla seuraava:
Blocker tai showtopper
…..
….. (Selittää se esimerkillä testisuunnitelmassa)
Esimerkiksi , moduulissa on vika; emme voi mennä pidemmälle testaamaan muita moduuleja, koska jos vika on estetty, voimme jatkaa muiden moduulien tarkistamista.
Kriittinen
……
….. (Selitä se esimerkillä testisuunnitelmassa)
Tässä tilanteessa viat vaikuttavat liiketoimintaan.
Suuri
….
…. (Selitä se esimerkillä testisuunnitelmassa)
Pieni
…..
….. (Selittää se esimerkillä testisuunnitelmassa)
Nämä viat ovat niitä, jotka vaikuttavat sovelluksen ulkonäköön ja tuntumaan.Prioriteetti
Korkea P1
…..
Keski-P2
…..
Matala-P3
…..
…..
P4

Siksi luokittelemme sen luokkiin P1, P2, P3 ja P4 bugien prioriteetin perusteella liike high, medium ja low.

Testiympäristöt

Nämä ovat ympäristöt, joissa testaamme sovellusta, ja tässä meillä on kahden tyyppisiä ympäristöjä, jotka ovat ohjelmisto ja laitteisto kokoonpano.

The ohjelmiston konfigurointi tarkoittaa eri yksityiskohtia Käyttöjärjestelmät kuten Windows, Linux, UNIX ja Mac ja erilaisia Selaimet Kuten Google Chrome, Firefox, Opera, Internet Explorer , ja niin edelleen.

Ja laitteiston kokoonpano tarkoittaa tietoa eri kokoisista RAM, ROM ja prosessorit .

Esimerkiksi

• The Ohjelmisto sisältää seuraavat:

Palvelin

Huomautus: Yllä olevat palvelimet ovat palveluita, joita testausryhmä käyttää sovelluksen testaamiseen.

Asiakas

Huomautus: Yllä olevat tiedot sisältävät eri käyttöjärjestelmät ja selaimet, joissa testausryhmä testaa sovellusta.

• The Laitteisto sisältää seuraavat:

Palvelin : Sun StarCat 1500

Testausryhmä voi käyttää tätä palvelinta sovelluksensa testaamiseen.

Asiakas:

Siinä on seuraava kokoonpano, joka on seuraava:

Huomautus: Se tarjoaa testausryhmän muodostavien testausinsinöörien järjestelmien kokoonpanon.

Ohjelmiston asennusprosessi
……
…..
…..

Kehitystiimi antaa asetukset ohjelmiston asentamiseen. Jos kehitystiimi ei vielä tarjoa prosessia, kirjoitamme sen testisuunnitelmaan Task-Based Development (TBD) -muodossa.

Sisään- ja poistumiskriteerit

Se on välttämätön ehto, joka on täytettävä ennen testausprosessin aloittamista ja lopettamista.

Osallistumiskriteerit

Osallistumisehdot sisältävät seuraavat ehdot:

• Valkoisen laatikon testaus on saatava päätökseen.
• Ymmärrä ja analysoi vaatimus ja valmistele testiasiakirjat tai kun testiasiakirjat ovat valmiit.
• Testitietojen pitäisi olla valmiita.
• Rakenna tai hakemus on valmisteltava
• Moduulit tai ominaisuudet on osoitettava eri testausinsinööreille.
• Tarvittavien resurssien on oltava valmiina.

Poistumiskriteerit

Poistumiskriteerit sisältävät seuraavat ehdot:

• Kun kaikki testitapaukset on suoritettu.
• Suurin osa testitapauksista on oltava läpäissyt .
• Riippuu virheiden vakavuudesta, mikä tarkoittaa, että esto- tai suuria bugeja ei saa olla, kun taas joitain pieniä bugeja on.

Ennen kuin aloitamme toiminnallisen testauksen, kaikki edellä mainitut Osallistumiskriteerit tulee noudattaa. Kun olemme suorittaneet toiminnalliset testaukset ja ennen kuin teemme integraatiotestauksen, sitten Poistumiskriteerit Toiminnallista testausta kannattaa seurata, koska poistumiskriteerien prosentit päätetään tapaamisessa sekä kehitys- että testipäällikön kanssa, koska heidän yhteistyöllään prosenttiosuus voidaan saavuttaa. Mutta jos toiminnallisen testauksen poistumiskriteereitä ei noudateta, emme voi jatkaa integraatiotestaukseen.

Tässä vakavuuden perusteella virheen aiheuttama tarkoittaa, että testaustiimi olisi päättänyt jatkaa eteenpäin seuraavissa vaiheissa.

Testaa automaatiota

Tässä päätämme seuraavasta:

• Mikä ominaisuus on automatisoitava eikä automatisoitava?
• Mitä testiautomaatiotyökalua aiomme käyttää missä automaatiokehyksessä?

Automatisoimme testitapauksen vasta ensimmäisen julkaisun jälkeen.

Tässä herää kysymys, että millä perusteella me tahtoa päättää mitä ominaisuuksia on testattava?

Yllä olevassa kuvassa, kuten näemme, yleisimmin käytettyjä ominaisuuksia on testattava uudestaan ​​​​ja uudestaan. Oletetaan, että meidän on tarkistettava Gmail-sovellus, jossa tärkeimmät ominaisuudet ovat Kirjoita viestit, lähetetyt viestit ja postilaatikko . Testaamme siis näitä ominaisuuksia, koska manuaalisen testauksen suorittaminen vie enemmän aikaa ja siitä tulee myös yksitoikkoista työtä.

Nyt, miten päätämme, mitä ominaisuuksia ei testata?

Olettaa apu Gmail-sovelluksen ominaisuutta ei testata uudestaan ​​​​ja uudestaan, koska näitä ominaisuuksia ei käytetä säännöllisesti, joten meidän ei tarvitse tarkistaa sitä usein.

Mutta jos jotkin ominaisuudet ovat epävakaita ja niissä on paljon virheitä , mikä tarkoittaa, että emme testaa näitä ominaisuuksia, koska niitä on testattava uudelleen ja uudelleen manuaalisen testauksen aikana.

Jos on ominaisuus, jota on testattava usein , mutta odotamme kyseisen ominaisuuden vaatimuksen muutosta, joten emme tarkista sitä, koska manuaalisten testitapausten vaihtaminen on mukavampaa kuin automaatiotestikoodin muutos.

Tehon arvio

Tässä suunnittelemme jokaisen tiimin jäsenen ponnistuksen.

Testi Toimitettava

Nämä ovat testaustiimin tuotoksia, jotka luovutimme asiakkaalle tuotteen mukana. Se sisältää seuraavat:

Testisuunnitelma Testitapaukset Testaa komentosarjoja RTM (Requirement Traceability Matrix) Vikaraportti Testin suoritusraportti Kaaviot ja mittarit Julkaisutiedot

Kaaviot ja mittarit

Kaavio

Tässä keskustelemme tyypeistä kaavioita lähetämme ja toimitamme myös näytteen jokaisesta kaaviosta.

Kuten näemme, meillä on viisi erilaista kaaviota, jotka osoittavat testausprosessin eri näkökohdat.

Kaavio1: Tässä näytämme kuinka monta vikaa on tunnistettu ja kuinka monta vikaa on korjattu kussakin moduulissa.

python-ohjelmat

Kaavio 2: Kuvassa 1 näkyy, kuinka monta kriittistä, suurta ja pientä vikaa on tunnistettu jokaiselle moduulille ja kuinka monta on korjattu vastaaville moduuleille.

Kaavio3: Tässä kaaviossa edustamme rakentaa viisas kaavio , mikä tarkoittaa, että jokaisessa versiossa kuinka monta vikaa jokaiselle moduulille on tunnistettu ja korjattu. Moduulin perusteella olemme määrittäneet virheet. Me lisäämme R näyttääksesi vikojen määrän P:ssä ja Q:ssa, ja lisäämme myös S näyttääksesi P:n, Q:n ja R:n viat.

Kaavio4: Testijohto suunnittelee Virhetrendianalyysi kaavio, joka luodaan joka kuukausi ja lähetä se myös johdolle. Ja se on aivan kuin ennustus, joka tehdään tuotteen lopussa. Ja täällä voimme myös arvioi virheenkorjaukset kuten voimme havaita sen kaari on suuntaus ylöspäin alla olevassa kuvassa.

Kaavio 5: The Testipäällikkö on suunnitellut tämän tyyppisen graafin. Tämän kaavion tarkoituksena on ymmärtää virheiden arvioinnissa oleva aukko ja todelliset esiintyneet viat, ja tämä kaavio auttaa myös parantamaan virheiden arviointia tulevaisuudessa.

Mittarit

Kuten yllä, luomme virheenjakaumakaavion, joka on kuvassa 1, ja yllämainittujen tietojen avulla suunnitellaan myös mittarit.

Esimerkiksi

Yllä olevassa kuvassa säilytämme kaikki tietyn projektin testausinsinöörit ja kuinka monta vikaa on tunnistettu ja korjattu. Voimme käyttää näitä tietoja myös tuleviin analyyseihin. Kun uusi vaatimus tulee, voimme päättää, kenelle tarjotaan haastava ominaisuus testaukseen aiemmin löydettyjen vikojen määrän perusteella yllä olevien mittareiden mukaan. Ja meillä on parempi tilanne tietää, kuka osaa käsitellä ongelmallisia ominaisuuksia erittäin hyvin ja löytää maksimimäärän vikoja.

Julkaisuilmoitus: Se on asiakirja, joka laaditaan tuotteen julkaisun yhteydessä ja jonka testauspäällikkö allekirjoittaa.

Alla olevassa kuvassa näemme, että lopullinen tuote on kehitetty ja otettu käyttöön asiakkaalle, ja viimeisin julkaisunimi on Beeta .

The Julkaisuilmoitus koostuu seuraavista:

• Ohjekirja.
• Luettelo vireillä olevista ja avoimista vioista.
• Luettelo lisätyistä, muokatuista ja poistetuista ominaisuuksista.
• Luettelo alustasta (käyttöjärjestelmä, laitteisto, selaimet), jolla tuotetta testataan.
• Alusta, jolla tuotetta ei ole testattu.
• Luettelo nykyisen julkaisun korjatuista virheistä ja luettelo edellisen julkaisun korjatuista virheistä.
• Asennusprosessi
• Ohjelmiston versiot

Esimerkiksi

Olettaa, että Beeta on sovelluksen toinen julkaisu ensimmäisen julkaisun jälkeen Alpha on ilmestynyt. Osa viasta, joka tunnistettiin ensimmäisessä julkaisussa ja joka on korjattu myöhemmin julkaistussa. Ja tässä osoitamme myös luettelon äskettäin lisätyistä, muokatuista ja poistetuista ominaisuuksista alfajulkaisusta betaversioon.

Sapluuna

Tämä osa sisältää kaikki mallit tuotteessa käytettäville asiakirjoille, ja kaikki testiinsinöörit käyttävät vain näitä malleja projektissa säilyttääkseen tuotteen yhtenäisyyden. Täällä meillä on erilaisia ​​​​malleja, joita käytetään koko testausprosessin aikana, kuten:

• Testitapausmalli
• Testitapauksen tarkistusmalli
• RTM-malli
• Virheraporttimalli
• Testin suoritusraportti

Katsotaanpa yksi esimerkki testisuunnitelmaasiakirjasta

Sivu 1

Sivu3-sivu18

Sivu-20

Sivulla 1 täytämme ensisijaisesti vain Versiot, kirjoittaja, kommentit ja arvioima kenttiin, ja kun johtaja on hyväksynyt sen, mainitsemme yksityiskohdat Hyväksytty ja hyväksymispäivämäärä kentät.

Useimmiten testisuunnitelman hyväksyy testauspäällikkö, ja testiinsinöörit vain tarkistavat sen. Ja kun uudet ominaisuudet tulevat, muokkaamme testisuunnitelmaa ja teemme tarvittavat muutokset Versio kenttään, ja se lähetetään sitten uudelleen tarkastettavaksi, päivitettäväksi ja johtajan hyväksyttäväksi. Testisuunnitelma on päivitettävä aina, kun muutoksia on tapahtunut. Sivulla 20 Viitteet määritä tiedot kaikista asiakirjoista, joita aiomme käyttää testisuunnitelman laatimiseen.

Huomautus:

Kuka kirjoittaa testisuunnitelman?

• Testijohto → 60 %
• Test Manager → 20%
• Testausinsinööri → 20 %

Siksi, kuten ylhäältä voimme nähdä, että 60 %:ssa tuotteesta testisuunnitelman on kirjoittanut testijohto.

Kuka arvioi testisuunnitelman?

• Testijohto
• Testipäällikkö
• Testin insinööri
• Asiakas
• Kehitystiimi

Testausinsinööri tarkastelee testisuunnitelmaa moduulin näkökulmasta ja testipäällikkö tarkastelee testisuunnitelmaa asiakkaan mielipiteen perusteella.

Kuka hyväksyy testisuunnitelman?

• Asiakas
• Testipäällikkö

Kuka kirjoittaa testitapauksen?

• Testijohto
• Testi-insinööri

Kuka arvioi testitapauksen?

java-merkkijonon muunnos int:ksi

• Testi-insinööri
• Testijohto
• Asiakas
• Kehitystiimi

Kuka hyväksyy testitapaukset?

• Testipäällikkö
• Testijohto
• Asiakas

Testisuunnitelman ohjeet

• Kutista testisuunnitelmasi.
• Vältä päällekkäisyyksiä ja redundanssia.
• Jos uskot, että et tarvitse jo mainittua osiota, poista se ja jatka eteenpäin.
• Ole tarkka. Kun esimerkiksi määrität ohjelmistojärjestelmän testiympäristön osaksi, mainitse ohjelmistoversio pelkän nimen sijaan.
• Vältä pitkiä kappaleita.
• Käytä luetteloita ja taulukoita aina kun mahdollista.
• Päivitä suunnitelma tarvittaessa.
• Älä käytä vanhentunutta ja käyttämätöntä asiakirjaa.

Testisuunnitelman merkitys

• Testisuunnitelma antaa suuntaa ajattelullemme. Tämä on kuin sääntökirja, jota tulee noudattaa.
• Testisuunnitelma auttaa määrittämään tarvittavat toimet testattavan ohjelmistosovelluksen laadun validoimiseksi.
• Testisuunnitelma auttaa ihmisiä ymmärtämään testin yksityiskohtia, jotka liittyvät ulkopuoliseen, kuten kehittäjiin, yritysjohtajiin, asiakkaisiin jne.
• Tärkeät näkökohdat, kuten testiaikataulu, testausstrategia, testin laajuus jne. dokumentoidaan testisuunnitelmaan, jotta johtoryhmä voi tarkistaa ne ja käyttää niitä uudelleen muissa vastaavissa projekteissa.