Tässä opetusohjelmassa selitetään, mikä on testiskenaario sekä testiskenaarion merkitys, toteutus, esimerkit ja mallit:
Mitä tahansa ohjelmiston toiminnallisuutta/ominaisuutta, jota voidaan testata, kutsutaan testiskenaarioksi. Loppukäyttäjän näkökulma otetaan huomioon testiskenaarioita kirjoitettaessa.
Tämä opetusohjelma auttaa sinua vastaamaan kysymyksiin: miksi testiskenaarioita tarvitaan, milloin testiskenaarioita kirjoitetaan ja miten testiskenaariot kirjoitetaan.
Mikä on testiskenaario?
Tarkastellaan hypoteettista tilannetta: Meri on valtava, ja sinun on matkustettava meren poikki merenrannalta toiselle. Esimerkiksi, Mumbain rannikolta Intian rannikolta Colombon rannikolle Srilankan rannikolle.
Voit valita seuraavat matkustustavat:
(i) Lentoyhtiöt: Ota lento Colomboon
(ii) Vesitiet: Matkusta mieluummin laivalla Colomboon.
(iii) Rautatiet: Ota juna Srilankaan.
Nyt testiskenaariot: Matkustaminen Mumbain merenrannalta Colombon merenrannalle on toimivuus, joka on testattava.
Testiskenaarioihin kuuluvat:
- Matkustaminen lentoteitse,
- Matkustaminen vesiteitse tai
- Matkustaminen rautateitse.
Näihin testiskenaarioihin liittyy testitapauksia.
Edellä mainittuja testiskenaarioita varten voidaan kirjoittaa muun muassa seuraavat testitapaukset:
Testiskenaario: Matkustaminen lentoteitse
Testitapauksiin voi sisältyä skenaarioita kuten:
- Lento on aikataulun mukainen.
- Lento ei ole aikataulun mukainen.
- On syntynyt hätätilanne (rankkasade ja myrsky).
Samalla tavalla voidaan kirjoittaa erillinen testitapausjoukko muita jäljellä olevia skenaarioita varten.
Nyt siirrytään teknologisiin testiskenaarioihin.
Kaikki, mitä voidaan testata, on testiskenaario. Näin ollen voidaan todeta, että kaikki testattavat ohjelmistotoiminnot voidaan jakaa useisiin pienempiin toiminnallisuuksiin, ja niitä voidaan kutsua "testiskenaarioksi".
Ennen kuin tuote toimitetaan asiakkaalle, sen laatu on arvioitava ja arvioitava. Testiskenaario auttaa arvioimaan, onko ohjelmistosovelluksen toiminnallinen laatu sopusoinnussa sen liiketoimintavaatimusten kanssa.
Testausskenaario on prosessi, jossa testaaja testaa ohjelmistosovellusta loppukäyttäjän näkökulmasta. Ohjelmistosovelluksen suorituskyky ja laatu arvioidaan perusteellisesti ennen sen käyttöönottoa tuotantoympäristössä.
Testiskenaarion merkitys
- Yhdessä testiskenaariossa voi olla useita testitapauksia. Sitä voidaan pitää suurena panoraamakuvana, ja testitapaukset ovat pieniä osia, jotka ovat tärkeitä panoraaman täydentämiseksi.
- Se on yksirivinen lausunto, ja testitapaukset sisältävät vaiheittaisen kuvauksen, jolla testiskenaariolausunnon tarkoitus täytetään.
- Esimerkki:
Testiskenaario: Suorita maksu käytetystä taksipalvelusta.
Tässä on useita testitapauksia, kuten jäljempänä on esitetty:
(i) Käytettävä maksutapa: PayPal, Paytm, Luotto-/pankkikortti.
(ii) Maksu on suoritettu onnistuneesti.
(iii) Maksu ei ole onnistunut.
(iv) Maksuprosessi keskeytyi kesken.
(v) Maksutapoja ei voi käyttää.
(vi) Sovellus hajoaa tässä välissä.
- Testausskenaariot auttavat näin ollen arvioimaan ohjelmistosovellusta todellisten tilanteiden mukaan.
- Kun testiskenaariot on määritetty, ne auttavat testauksen laajuuden jakamisessa.
- Tätä jakoa kutsutaan priorisoinniksi, joka auttaa määrittämään ohjelmistosovelluksen tärkeät toiminnot.
- Toiminnallisuuksien priorisoitu testaus auttaa suuresti ohjelmistosovelluksen onnistuneessa toteutuksessa.
- Kun testiskenaariot priorisoidaan, tärkeimmät toiminnallisuudet voidaan helposti tunnistaa ja testata ensisijaisesti. Näin varmistetaan, että suurin osa tärkeimmistä toiminnallisuuksista toimii moitteettomasti ja että niihin liittyvät viat kirjataan ja korjataan asianmukaisesti.
- Testiskenaariot määrittelevät ohjelmiston liiketoimintaprosessin kulun, joten sovelluksen testaus on mahdollista alusta loppuun.
Testiskenaarion ja testitapauksen välinen ero
| Testiskenaario | Testitapaukset |
|---|---|
| Testiskenaario on käsite. | Testitapaukset ovat ratkaisuja, joilla tämä käsite todennetaan. |
| Testiskenaario on korkean tason toiminnallisuus. | Testitapaukset ovat yksityiskohtainen menettely korkean tason toiminnallisuuden testaamiseksi. |
| Testiskenaariot johdetaan vaatimuksista/käyttäjätarinoista. | Testitapaukset johdetaan testiskenaarioista . |
| Testiskenaario on 'Mitä toiminnallisuutta testataan'. | Testitapaukset ovat ' Miten toiminnallisuutta testataan '. |
| Testiskenaarioissa on useita testitapauksia. | Testitapaus voi liittyä tai olla liittymättä useisiin testiskenaarioihin. |
| Yksittäiset testiskenaariot eivät ole koskaan toistettavissa. | Yhtä testitapausta voidaan käyttää useita kertoja eri skenaarioissa. |
| Tarvitaan lyhyet asiakirjat. | Tarvitaan yksityiskohtaiset asiakirjat. |
| Testiskenaarion viimeistely edellyttää aivoriihiä. | Tarvitaan yksityiskohtaista teknistä tietämystä ohjelmistosovelluksesta |
| Aikaa säästyy, koska tarkkoja yksityiskohtia ei tarvita. | Aikaavievää, koska jokainen pienikin yksityiskohta on hoidettava. |
| Ylläpitokustannukset ovat alhaiset, koska tarvittavat resurssit ovat vähäiset. | Ylläpitokustannukset ovat korkeat, koska tarvittavat resurssit ovat suuret |
Miksi testiskenaariot ovat välttämättömiä?
Testiskenaariot johdetaan vaatimuksista tai käyttäjätarinoista.
- Esimerkkinä voidaan ottaa taksivarauksen testiskenaario.
- Skenaarioita voivat olla esimerkiksi taksin varausvaihtoehdot, maksutavat, GPS-seuranta, tiekartan näyttäminen oikein tai ei, taksin ja kuljettajan tietojen näyttäminen oikein tai ei, jne. Kaikki nämä skenaariot on lueteltu testiskenaariomallissa.
- Oletetaan, että testiskenaarion tehtävänä on tarkistaa, ovatko paikannuspalvelut päällä, ja jos ne eivät ole päällä, näyttää viestin "Ota paikannuspalvelut käyttöön". Tämä skenaario on jäänyt huomaamatta, eikä sitä ole lueteltu testiskenaariomallissa.
- Sijaintipalvelu"-skenaario synnyttää muita siihen liittyviä testiskenaarioita.
Näitä voivat olla:
- Sijaintipalvelu harmaana.
- Paikannuspalvelu on päällä, mutta internet ei toimi.
- Paikan päällä tarjottavien palvelujen rajoitukset.
- Väärä sijainti näytetään.
- Yhden skenaarion puuttuminen voi merkitä monien muiden mahdollisuuksien menettämistä. ratkaisevat skenaariot tai testitapaukset . Tällä voi olla suuri kielteinen vaikutus Tämä johtaa siihen, että resursseja (määräaikoja) menetetään paljon.
- Testiskenaariot auttavat suuresti tyhjentävän testauksen välttäminen Se varmistaa, että kaikki tärkeät ja odotetut liiketoimintavirrat testataan, mikä auttaa sovelluksen kokonaisvaltaisessa testauksessa.
- Nämä säästävät aikaa. Myöskään paljon yksityiskohtaisempaa kuvausta testitapausten mukaisesti ei tarvita. Testattavista asioista annetaan yksirivinen kuvaus.
- Testiskenaariot kirjoitetaan sen jälkeen, kun ideointikokoukset Näin ollen todennäköisyys, että jokin skenaario (ratkaiseva tai vähäinen) jää huomaamatta, on mahdollisimman pieni. Tämä tehdään pitäen mielessä sekä tekniset seikat että ohjelmistosovelluksen liiketoiminnan sujuvuus.
- Lisäksi testiskenaariot voi hyväksyä joko liiketoiminta-analyytikko Asiakas tai molemmat, joilla on nimenomaista tietoa testattavasta sovelluksesta.
Testausskenaariot ovat siis välttämätön osa SDLC:tä.
Testiskenaarioiden toteuttaminen
Katsotaanpa testiskenaarioiden toteuttamista tai testiskenaarioiden kirjoittamista:
- Epics/Business Requirements muodostetaan.
- Esimerkki Epicistä : Luo Gmail-tili. Epic voi olla sovelluksen tärkein ominaisuus tai liiketoiminnan vaatimus.
- Eepokset jaetaan pienemmiksi käyttäjätarinoiksi sprinttien aikana.
- Käyttäjätarinat johdetaan eepoksista. Nämä käyttäjätarinat on määriteltävä ja sidosryhmien on hyväksyttävä.
- Testiskenaariot johdetaan käyttäjätarinoista tai BRS- (Business Requirement Document), SRS- (System Requirement Specification Document) tai FRS- (Functional Requirement Document) asiakirjoista, jotka on viimeistelty ja määritetty.
- Testaajat kirjoittavat testiskenaariot.
- Nämä testiskenaariot hyväksyy organisaatiosta riippuen tiimipäällikkö, liiketoiminta-analyytikko tai projektipäällikkö.
- Jokaisen testiskenaarion on liityttävä vähintään yhteen käyttäjätarinaan.
- On määriteltävä sekä positiiviset että negatiiviset testiskenaariot.
- Käyttäjätarinat koostuvat Hyväksymiskriteerit, kuten :
- Hyväksymiskriteerit ovat luettelo asiakkaan vaatimusten ehdoista tai tahtotilasta. Hyväksymiskriteerejä laadittaessa otetaan huomioon asiakkaan odotukset ja myös väärinkäsitykset.
- Nämä ovat yksilöllisiä yhdelle käyttäjätarinalle, ja jokaisella käyttäjätarinalla on oltava vähintään yksi hyväksymiskriteeri, jonka on oltava itsenäisesti testattavissa.
- Hyväksymiskriteerit auttavat määrittelemään, mitkä ominaisuudet kuuluvat projektin laajuuteen ja mitkä eivät. Näiden kriteerien tulisi sisältää sekä toiminnallisia että muita kuin toiminnallisia ominaisuuksia.
- Liiketoiminta-analyytikot kirjoittavat hyväksymiskriteerit, ja tuoteomistaja hyväksyy ne.
- Joissakin tapauksissa tuotteen omistaja voi myös itse kirjoittaa kriteerit.
- Testiskenaariot saadaan hyväksymiskriteereistä.
Esimerkkejä testiskenaarioista
#1) Kindle-sovelluksen testiskenaariot
Kindle on sovellus, jonka avulla e-lukijat voivat etsiä e-kirjoja verkosta, ladata ja ostaa niitä. Amazon Kindle antaa e-kirjojen lukijalle todellisen kokemuksen siitä, että kirjaa pidetään kädessä ja luetaan. Jopa sivujen kääntäminen on sovelluksessa hienosti simuloitu.
Kirjataan nyt ylös testiskenaariot. ( Huom: Alla on lueteltu rajalliset skenaariot, jotta saataisiin yleiskäsitys testiskenaarion kirjoittamisesta (siitä voi olla johdettu useita testitapauksia).
| Testiskenaariot # | Testiskenaariot |
|---|---|
| 1 | Tarkista, käynnistyykö Kindle App oikein. |
| 2 | Tarkista, että näytön resoluutio mukautuu eri laitteiden mukaan sovelluksen käynnistämisen jälkeen. |
| 3 | Tarkista, että näytetty teksti on luettavissa. |
| 4 | Tarkista, että zoomaus- ja pienennysasetukset toimivat. |
| 5 | Tarkista, että Kindle-sovellukseen tuodut yhteensopivat tiedostot ovat luettavissa. |
| 6 | Tarkista Kindle-sovelluksen tallennuskapasiteetti. |
| 7 | Tarkista, että lataustoiminto toimii oikein. |
| 8 | Tarkista, että Page Turn -simulointi toimii oikein |
| 9 | Tarkista e-kirjaformaattien yhteensopivuus Kindle-sovelluksen kanssa. |
| 10 | Tarkista Kindle-sovelluksen tukemat fontit. |
| 11 | Tarkista Kindle-sovelluksen käyttämä akun kesto. |
| 12 | Tarkista Kindlen suorituskyky verkkoyhteyden mukaan (Wi-Fi, 3G tai 4G). |
Kustakin edellä mainitusta testiskenaariosta voidaan johtaa useita testitapauksia.
#2) Googlen asiakirjojen hyväksymiskriteerit
Google docs on verkkopohjainen sovellus, jolla voi luoda, muokata ja jakaa Word-dokumentteja, taulukkolaskentataulukoita, dioja ja lomakkeita. Kaikkiin tiedostoihin pääsee käsiksi verkossa selaimella, jossa on internet-yhteys.
Luodut asiakirjat voidaan jakaa verkkosivuna tai tulostusvalmiina asiakirjana. Käyttäjä voi asettaa rajoituksia sille, kuka voi tarkastella ja muokata asiakirjoja. Yhden asiakirjan voivat jakaa ja työstää eri maantieteellisistä sijainneista olevat henkilöt yhteistyössä.
Jäljempänä mainitaan rajalliset testiskenaariot yleisen ymmärryksen vuoksi. Googlen asiakirjojen perusteelliset testiskenaariot voivat olla kokonaan oma aiheensa.
| Hyväksymiskriteerit # | Hyväksymisperusteet |
|---|---|
| 1 | Word, Sheets tai Forms voidaan avata onnistuneesti ilman virheitä. |
| 2 | Malleja on saatavilla asiakirjoja, arkkeja ja dioja varten. |
| 3 | Käytettävissä olevat mallit ovat käyttäjien käytettävissä. |
| 4 | Käytetty malli on muokattavissa (esim. fontit, fonttikoko, tekstin lisääminen, tekstin poistaminen, dian lisääminen). |
| 5 | Jos internet-yhteyttä ei ole tilapäisesti käytettävissä, tiedosto voidaan tallentaa paikallisesti ja ladata, kun internet-yhteys on käytettävissä. |
| 6 | Useiden käyttäjien tekemiä muutoksia ei ylikirjoiteta. |
| 7 | Useat käyttäjät voivat työskennellä yhden asiakirjan parissa. |
| 8 | Tehty työ tallennetaan, jos internet-yhteys katkeaa tiedoston lataamisen aikana. |
| 9 | Jakamisrajoituksia sovelletaan oikein. |
| 10 | Näkymärajoituksen käyttäjät eivät voi muokata asiakirjoja. |
| 11 | Asiakirjat voidaan julkaista internetissä suurelle yleisölle. |
| 12 | Asiakirjoihin tehdyt muutokset tallennetaan aikaleimalla &; tekijän tiedot. |
Testiskenaarioiden määrä on useita ja erittäin suuri Google Docs -ohjelmassa. Tällaisissa tapauksissa sidosryhmät asettavat ja hyväksyvät yleensä vain hyväksymiskriteerit, ja tiimin jäsenet työskentelevät näiden hyväksymiskriteerien parissa. Testitapausten tai pikemminkin testiskenaarioiden kirjoittaminen voi olla uuvuttava tehtävä valtaville sovelluksille.
Näillä hyväksymiskriteereillä on suuri merkitys iteratiivisen prosessin suunnittelussa, eikä niitä pidä koskaan unohtaa. Määrittelemällä ne etukäteen ja etukäteen vältetään yllätykset tai järkytykset sprinttien tai julkaisujen lopussa.
Annettu ennakkoehto.
Kun tehdä toiminto.
Sitten tulos on odotettu.
Formaat Given, When ja Then ovat hyödyllisiä hyväksymiskriteerien määrittelyssä.
Esimerkki testiskenaariomallista
| Käytä Story ID # | Testiskenaarion ID # | Versio # | Testiskenaariot | # Testitapausten lukumäärä | Merkitys |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1.1 | Kin12.4 | Tarkista, käynnistyykö Kindle App oikein. | 4 | Korkea |
| USID12.1 | TSID12.1.2 | Kin12.4 | Tarkista Kindle-sovelluksen tallennuskapasiteetti. | 3 | Medium |
Päätelmä
Kaikessa ohjelmistotestauksessa elinkaaren ymmärtäminen ja testiskenaarioiden laatiminen on erittäin tärkeä osa. Ohjelmiston laatua voidaan parantaa luomalla hyvä perusta testiskenaarioille. Usein testitapausten ja testiskenaarioiden käyttö saatetaan vaihtaa keskenään.
Peukalosääntö on kuitenkin se, että testiskenaariota käytetään useiden testitapausten kirjoittamiseen tai voidaan sanoa, että testitapaukset johdetaan testiskenaarioista. Hyvin määritellyt testiskenaariot takaavat laadukkaan ohjelmiston.