Yksi tämän päivän testausympäristön keskeisistä väärinkäsityksistä on, että tuotannossa testaaminen edellyttää vain kolmea taitokokonaisuutta: prosessiosaamista, automaattisten testaustyökalujen tuntemusta ja häiriötilanteiden hallintakykyä. Nämä ovat tärkeitä, mutta silmiinpistävästi puuttuu – ei ainoastaan tästä luettelosta vaan myös rekrytoivien esihenkilöiden ajattelusta – asia, jonka luulisi olevan kaikkein perustavanlaatuisin:
Kyky suunnitella käytännöllinen testi tuotantoympäristöihin.
Olisi koomista, ellei se olisi niin huolestuttavaa, että lähes mikään organisaatio ei priorisoi keskeisten laadunvarmistustaitojen asiantuntemusta toteuttaessaan tuotannossa testaamisen strategioita.
Suoritetaanpa testi manuaalisesti tai automaation avulla tuotannossa olevassa järjestelmässä, sinun on ensin osattava suunnitella testi, joka tuottaa hyödynnettävää tietoa häiritsemättä käyttäjäkokemusta, eikö niin?
Olisi koomista, ellei se olisi niin huolestuttavaa, että lähes mikään organisaatio ei priorisoi testisuunnittelun asiantuntemusta toteuttaessaan tuotannossa testaamisen strategioita. Suoritetaanpa testi manuaalisesti valvotussa ympäristössä tai automaation avulla tuotannossa olevassa järjestelmässä, sinun on ensin osattava suunnitella testi, joka tuottaa hyödynnettävää tietoa häiritsemättä käyttäjäkokemusta, eikö niin?
Testisuunnittelun asiantuntemuksen jättämiseen pois tuotannossa testaamisen lähestymistavasta liittyy yksi ilmeinen ongelma:
Eikö ole olennaista tietää, että tuotantoympäristössäsi testejä toteuttava henkilö ymmärtää, millainen testi on merkityksellinen?
Koska huonosti suunniteltujen testien automatisointi tuotannossa tuottaa epäluotettavaa dataa nopeammin ja lisää tarpeetonta riskiä? Eikä tuotannossa epäpätevällä tavalla testaaminen ”ketterästi” vaikuta minusta todelliselta parannukselta, paitsi ehkä scrum masterin näkökulmasta.
Testisuunnittelun merkitys ja kurinalaisuus, erityisesti tuotannossa testaamisen yhteydessä, olisi pitänyt elvyttää jo kauan sitten. Pitäkää tätä panoksenani tähän pyrkimykseen.
Mikä on olennaista tehokkaassa tuotannossa testaamisessa?
Ensimmäinen askel kohti tuotannossa testaamisen hallintaa on tehdä muutamia olennaisia erotteluja, jotka ovat epäilemättä useimmille laadunvarmistuksen parissa työskenteleville jo intuitiivisesti tuttuja, mutta joita esitetään tuotantotestauksen yhteydessä harvoin järjestelmällisesti.
Tarkastellaan näitä perustavanlaatuisia käsitteitä, jotka muuttavat lähestymistapaasi tuotannossa testaamiseen.
Eksplisiittinen ja implisiittinen toiminnallisuus tuotantoympäristöissä
Aloitetaan kriittisestä erottelusta eksplisiittisen ja implisiittisen toiminnallisuuden välillä tuotannossa testattaessa.
Ensimmäinen tarkoittaa sitä, mitä useimmat meistä ajattelevat ”toiminnallisuudella”. Sillä viitataan ominaisuuksiin ja kyvykkyyksiin, jotka tuote on määritellyt muodollisesti ja joiden muodollinen määrittely ohjaa niiden toteuttamista tuotekehityksessä. Tuotannossa testattaessa nämä eksplisiittiset toiminnot ovat yleensä valvonta- ja havainnointityökalujen keskiössä.
Tämän vuoksi eksplisiittisen toiminnallisuuden testaaminen tuotannossa saattaa vaikuttaa suoraviivaiselta, mutta kuten myöhemmin näemme, näin ei ole edes tarkasti määriteltyjen ominaisuuksien kohdalla. Eksplisiittisen toiminnallisuuden vähintäänkin tarjoama täsmällisyys helpottaa tuotantotestien muodostaman rakenteen rakentamista sen ympärille (tai tällaisen rakenteen illuusion luomista).
Implisiittinen toiminnallisuus tuotantoympäristössä on aivan eri asia.
Se koostuu käyttäjän tai ympäristön syötteisiin liittyvistä käyttäytymistavoista ja vastauksista, joita ei ole määritelty tai ennakoitu muodollisesti. Puutteellinen tuotannon implisiittisen toiminnallisuuden testisuunnittelu on ylivoimaisesti useimpien tuotteen käyttöönoton jälkeen havaittujen kriittisten virheiden lähde (toinen lähde on puutteellinen testaus poikkeavissa laitteisto-, ohjelmisto- ja laiteympäristöissä).
Toisin sanoen:
Implisiittisen toiminnallisuuden testaaminen tuotannossa edellyttää huomattavaa kekseliäisyyttä ja mielikuvitusta. Se on tuotantotestausstrategioiden aidosti luova osa.
Implisiittisen toiminnallisuuden testaaminen tuotantoympäristöissä edellyttää tiettyä pirullista oveluutta, jotta siinä voi kehittyä hyväksi, eikä sitä valitettavasti voi opettaa tavanomaisten laadunvarmistusprosessien avulla.
Mikään ketterä menetelmä tai automaattisen testauksen viitekehys ei opeta sinulle, miten implisiittistä toiminnallisuutta testataan tuotannossa tehokkaasti, mutta asianmukainen testisuunnittelu voi kannustaa siihen.
Miten siis määrittelet testisuunnittelustrategian tuotantoympäristösi implisiittiselle toiminnallisuudelle? Onneksi se on mahdollista. Ennen kuin siirrymme suoraan tähän kysymykseen, tarkastellaan vielä muutamia olennaisia erotteluja, jotka ovat ratkaisevia tehokkaassa tuotannossa testaamisessa.
Positiivinen ja negatiivinen testaus
Keskeinen huomio: Sekä positiivinen että negatiivinen testaus tuotannossa edellyttävät erityishuomioita, jotka ulottuvat perinteisiä laadunvarmistuksen lähestymistapoja pidemmälle.
Useimmat laadunvarmistuksen parissa työskentelevät ymmärtävät näiden kahden testaustyypin peruseron:
- Positiivinen testaus tuotannossa: Sen varmistaminen, että ominaisuudet toimivat suunnitellusti tuotantoympäristöissä
- Negatiivinen testaus tuotannossa: Sen strateginen testaaminen, miten järjestelmä reagoi odottamattomiin syötteisiin häiritsemättä oikeita käyttäjiä
Miksi tuotantotestaus on erilaista
Vaikka nämä erot ovat käsitteellisesti selkeitä, tuotannossa testaaminen tuo mukanaan ainutlaatuisia haasteita:
- Suuremmat panokset: Poikkeustapaukset vaikuttavat oikeisiin asiakkaisiin ja liiketoiminnan toimintaan
- Todellisen maailman monimutkaisuus: Käyttäjien toiminta noudattaa harvoin ennustettavia malleja
- Liiketoiminnan jatkuvuus: Testaus ei saa häiritä normaalia toimintaa
Määrityksiä pidemmälle
Määritykset tarjoavat harvoin kaikkea, mitä tehokas tuotantotestaus edellyttää:
Liiallinen riippuvuus määrityksestä – olipa se peräisin tuote- tai suunnittelutiimiltä – rajoittaa ajatteluasi. Tämä on erityisen ongelmallista tuotannossa testattaessa, sillä todellisen maailman käyttötavat poikkeavat usein määrityksistä.
Tämä havainnollistaa sitä, mitä kutsun "empiiriseksi harhaluuloksi": odotetaan, että jokin kertoo nimenomaisesti, mitä pitää tehdä, ennen kuin asia voidaan ymmärtää.
Onnistunut testisuunnittelu tuotantoympäristöihin edellyttää:
- Toiminnallisuuden parametrien asianmukaista määrittelyä
- Loogista ajattelua siitä, mikä on mahdollista
- Sekä käyttäjien että ympäristön vuorovaikutusten huomioimista
Esimerkki todellisesta maailmasta: odottamaton toiminta
Ohjelmistojen liitukaudella (eli 80-luvulla) testasin asiakirjojen muunto-ohjelmistoa ja löysin yllättäviä ominaisuuksia:
Näytä kuva
Klassinen esimerkki: WordPerfectissä saattoi lisätä rivivälikomennon keskelle kappaletta niin, että se vaikutti vain seuraaviin riveihin. Näin syntyi kappaleita, joissa oli kaksi erilaista riviväliä.
Nykyaikaisia vastineita tuotannossa testattaessa:
- Odottamattomat käyttäjäoikeuksien yhdistelmät pilvisovelluksissa
- Ennalta arvaamattomat API-pyyntöjen sarjat mikropalveluarkkitehtuureissa
- Kilpailutilanteet suuren samanaikaisuuden ympäristöissä
Tarkastellaan nyt kolmea keskeistä parametria, jotka terävöittävät tuotantotestausmenetelmääsi:
1. Ominaisuuksien laajuuden testaus
Määritelmä: Sen tunnistaminen, miten käyttäjät saattavat ottaa ominaisuuksia käyttöön yhteyksissä tai tavoilla, joita suunnitteluvaiheessa ei koskaan kuviteltu.
Miksi sillä on merkitystä testauksessa
Kaikkia rajoitteita ei ennakoida kehityksen aikana. Tuotantoympäristöissä tällä laiminlyönnillä voi olla vakavia seurauksia.
Yksinkertaista validointia pidemmälle
Kun testaat tuotannossa, ota huomioon nämä rajat:
Muista: Ominaisuuden validointi tuotannossa ei tarkoita vain sen vahvistamista, että se toimii suunnitellusti, vaan myös sen varmistamista, ettei sitä voida käyttää tarkoittamattomilla tavoilla, jotka saattavat vaikuttaa järjestelmän vakauteen tai turvallisuuteen.
Have an account? Log In
2. Työnkulun keskeytysten testaus tuotantojärjestelmissä
Varoitus: Tämä lähestymistapa olettaa, että testaat jo määriteltyjä työnkulkuja tuotannossa. Jos et vielä tee niin, käsittele nämä perusteet ensin!
"Onnellista polkua" pidemmälle
Kun testaat tuotannossa, tutki seuraavia kriittisiä työnkulkujen häiriöitä:
✅ Keskeytyneet työnkulut: Prosessi aloitetaan, mutta sitä ei koskaan saateta loppuun
✅ Perutut toiminnot: Käyttäjä peruu toiminnon nimenomaisesti kesken prosessin
✅ Uudelleen käynnistetyt prosessit: Käyttäjä yrittää samaa toimintoa useita kertoja
✅ Paluu aiempiin vaiheisiin: Käyttäjä palaa aiempiin vaiheisiin erilaisilla syötteillä
Tuotantotestauksen toteutusvinkkejä
Käytä ominaisuuslippujen kaltaisia tekniikoita hallitaksesi näiden testien käyttöönottoa turvallisesti tuotantoympäristöissä.
Sovellukset todellisessa maailmassa
Ammattilaisen vinkki: Näitä tilanteita kuvataan harvoin määrityksissä, mutta ne edustavat todellista käyttäytymistä tuotannossa.
3. Suoritusten järjestys tuotantotestauksessa
Haaste: Tuotantojärjestelmissä, joissa suoritetaan useita prosesseja samanaikaisesti, toimintojen järjestys voi johtaa odottamattomiin virheisiin, joita on vaikea toistaa testiympäristöissä.
Kaksi kriittistä suoritusjärjestystä koskevaa mallia
Edeltävät vaikuttavat olosuhteet
Näytä kuva
- Määritelmä: Tapahtumat, joiden on tapahduttava ennen virheen aiheuttavaa prosessia
- Ominaisuudet: Saattaa ilmetä vasta tiettyjen tapahtumaketjujen jälkeen, joiden luonnollinen toteutuminen kestää päiviä
- Esimerkki tuotannosta: Käyttäjän käyttöoikeuksia muokataan → välimuisti vanhenee → tiettyä ohjelmointirajapintaa kutsutaan
Myöhemmät vaikuttavat olosuhteet
- Määritelmä: Virheet, jotka tulevat ilmi vasta myöhempien vuorovaikutusten kautta
- Ilmeneminen: Virhe pysyy piilossa myöhempään toimintoon asti
- Esimerkki tuotannosta: Tietojen korruptoituminen tapahtuu huomaamatta, kunnes raportti luodaan
Miksi tämä on niin haastavaa?
Tuotannon toimintojärjestyksen testauksen laajuuden määrittäminen edellyttää:
- Järjestelmän vuorovaikutusten syvällistä tuntemusta
- Monimutkaisten prosessien tilasiirtymien mallintamista
- Sekä tarkoitettujen että tahattomien tilayhdistelmien ymmärtämistä
"Kuten yksittäisen kappaleen kaksi erilaista riviväliarvoa, nämä odottamattomat tilat voivat aiheuttaa vakavaa tuhoa tuotantoympäristöissä."
Toimintojärjestyksen testauksen olennaiset työkalut tuotannossa
- Kaaostekniikan työkalut hallittujen virheiden tarkoitukselliseen aiheuttamiseen
- Havainnointityökalut tilanmuutosten seuraamiseen järjestelmien välillä
- Hajautettu jäljitys pyyntöjen kulkujen seuraamiseen mikropalveluissa
Yhteenveto: Toimintojärjestykseen liittyvät ongelmat ovat yksi merkittävimmistä vakavien virheiden lähteistä nykyaikaisissa tuotantojärjestelmissä. Aseta tämä näkökulma testausstrategiassasi etusijalle.
Lopputulos
Ominaisuusliput muuttavat tuotannossa testaamisen riskialttiista käytännöstä hallituksi ja dataohjatuksi prosessiksi. Erottamalla käyttöönoton julkaisusta ja tarjoamalla välittömät palautusmahdollisuudet ne luovat turvaverkon, jonka ansiosta tiimit voivat validoida ohjelmiston todellisissa olosuhteissa vaarantamatta käyttökokemusta tai järjestelmän vakautta.
Ominaisuuksien hallinta-alustat tuotantotestauksessa
Ominaisuuksien hallinta-alustat ovat muuttaneet tuotannossa testaamisen riskialttiista hankkeesta hallituksi ja järjestelmälliseksi prosessiksi. Monet organisaatiot eivät kuitenkaan hyödynnä näitä työkaluja tehokkaasti osana testiensuunnittelustrategiaansa.
Tuotannon riskienhallinnan kehitys
Perinteiset tuotannossa testaamisen lähestymistavat perustuivat kaksijakoisiin päätöksiin – ominaisuus oli joko käytössä kaikilla tai ei kenelläkään. Ominaisuuksien hallinta-alustat muuttavat tämän toimintamallin perusteellisesti:
- Yksityiskohtainen hallinta: Testaa ominaisuuksia tiettyjen käyttäjäsegmenttien kanssa sen sijaan, että ottaisit ne käyttöön kaikille tai et kenellekään
- Välitön korjaaminen: Poista ongelmalliset ominaisuudet käytöstä ilman koodin käyttöönottoja tai palautuksia
- Vaiheittainen käyttöönotto: Lisää käyttäjien altistumista asteittain reaaliaikaisten suorituskykytietojen perusteella
Yksinkertaisten ominaisuuslippujen tuolla puolen
Vaikka perusmuotoinen ominaisuuksien liputus on ollut käytössä jo vuosia, nykyaikaiset ominaisuuksien hallinta-alustat tarjoavat kriittisiä ominaisuuksia, jotka muuttavat tuotantotestausta:
Kun ominaisuuksien hallinta-alustat integroidaan asianmukaisesti testiensuunnittelustrategiaasi, ne mahdollistavat:
- Kohdennetun riskien rajaamisen – Rajoita uusien ominaisuuksien näkyvyyttä tietyille käyttäjäsegmenteille
- Validoinnin oikeilla käyttäjillä – Testaa todellisten käyttäjien kanssa synteettisen testidatan sijaan
- Välittömän korjaamisen – Käsittele ongelmia ilman hätäkäyttöönottoja tai palautuksia
Integrointi havainnointityökaluihin
Ominaisuuksien hallinta-alustojen todellinen voima tulee esiin, kun ne integroidaan havainnointi- ja valvontajärjestelmiin:
Perinteinen lähestymistapa:
- Ongelmat havaitaan täyden käyttöönoton jälkeen
- Testitulosten manuaalinen tarkistaminen
- Välikohtausten jälkikäteisanalyysi
Ominaisuuksien hallinnan integrointi:
- Ominaisuuden aktivoinnin ja järjestelmän mittareiden korrelointi
- Automaattinen suorituskyvyn valvonta ominaisuuslippukohtaisesti
- Reaaliaikainen näkemys ominaisuuksien vaikutuksista
Vaikutus todellisessa maailmassa: tuotannossa tapahtuvan testauksen muuttaminen
Ominaisuuksien hallinta-alustoja käyttöön ottavat organisaatiot raportoivat merkittävistä hyödyistä:
- Välikohtausten vakavuuden väheneminen: "Voimme testata ominaisuuksia tuotannossa hyvissä ajoin ennen markkinointijulkaisua. Jos ominaisuus aiheuttaa ongelmia julkaisupäivänä, voimme vain poistaa sen käytöstä hätäpysäytystoiminnolla – palautuksia ei tarvita." — Chris Guidry, tekniikan varatoimitusjohtaja, O'Reilly Media.
- Julkaisusyklien nopeutuminen: IBM:n, TrueCarin ja muiden johtavien yritysten tiimit hyödyntävät ominaisuuksien hallintaa tuotannossa testaamiseen ja nauttivat siitä, mitä he kuvaavat "turvallisiksi, huomaamattomiksi julkaisuiksi".
- Testikattavuuden paraneminen: Ominaisuusliput paljastavat reunatapauksia, joita on mahdotonta simuloida hallituissa ympäristöissä.
Käytännön toteutus testien suunnittelussa
Jotta ominaisuuksien hallinta-alustat voidaan sisällyttää tehokkaasti testien suunnittelustrategiaan:
- Suunnittele tarkistuspisteet, jotka vastaavat ominaisuuslippujen siirtymiä
- Luo varaskenaariot jokaiselle ominaisuuslipulla varustetulle komponentille
- Määritä suorituskykynnysarvot, jotka käynnistävät ominaisuuden automaattisen käytöstä poistamisen
- Määritä segmenttikohtaiset testitapaukset käyttäytymisen vahvistamiseksi eri käyttäjäryhmissä
- Dokumentoi lippujen riippuvuudet ketjuuntuvien häiriöiden estämiseksi
Ominaisuuksien hallinta-alustat eivät korvaa harkittua testien suunnittelua – ne vahvistavat sitä. Tuotannossa tapahtuvan testauksen laatu riippuu edelleen olennaisesti siitä, kuinka hyvin testit on suunniteltu.
Yleiset vältettävät sudenkuopat
Vankasta ominaisuuksien hallinnasta huolimatta useita haasteita on edelleen:
- Lippuvelka - Hylätyt tai unohdetut liput, jotka aiheuttavat teknistä velkaa
- Riittämätön valvonta - Lippujen tilan ja järjestelmän suorituskyvyn välisen yhteyden määrittämättä jättäminen
- Liiallinen itsevarmuus - Tuotantoa edeltävän testauksen ennenaikainen vähentäminen
- Lippujen keskinäiset riippuvuudet - Monimutkaisten ja vaikeasti vianmäärityksessä käsiteltävien suhteiden luominen
Lopputulos
Ominaisuuksien hallinta-alustat tarjoavat tehokkaita ominaisuuksia tuotannossa testaamiseen, mutta ne on integroitava harkitusti osaksi yleistä testien suunnittelustrategiaa. Eniten arvoa saavuttavat organisaatiot eivät ainoastaan ota näitä työkaluja käyttöön – ne miettivät perusteellisesti uudelleen, miten testien suunnittelu toimii ominaisuuslipuilla varustetussa ympäristössä.
Kun ominaisuuksien hallinta toteutetaan asianmukaisesti osana kattavaa testien suunnittelua, se muuttaa tuotannossa tapahtuvan testauksen välttämättömästä pahasta kilpailueduksi.
Tuotannossa testaamisen työkalut: toteutuksen haasteet
Vaikka ominaisuusliput ja hallinta-alustat muodostavat tuotannossa testaamisen perustan, laajempi työkaluekosysteemi tuo mukanaan omat toteutuksen haasteensa. Oikeiden työkalujen valinta ja määrittäminen edellyttävät tiimin valmiuksien, järjestelmäarkkitehtuurin ja organisaation tarpeiden huolellista huomioimista.
Valvonta- ja havainnointityökalut
Tehokas tuotannossa testaaminen riippuu kattavasta näkyvyydestä järjestelmän toimintaan:
- Sovellusten suorituskyvyn valvonta (APM)
Hyödyt: Tarjoaa yksityiskohtaista tietoa suorituskyvystä koko sovelluspinoon liittyen.
Haasteet: Edellyttää usein merkittävää instrumentointia ja voi tuottaa liikaa dataa, joka kuormittaa pienempiä tiimejä. - Lokienhallintajärjestelmät
Hyödyt: Olennaisia virheenkorjauksessa ja rikosteknisessä analyysissä tuotannossa tapahtuvan testauksen aikana.
Haasteet: Voi tuottaa valtavia määriä dataa ilman asianmukaisia suodatus- ja indeksointistrategioita. - Hajautettu jäljitys
Hyödyt: Tarjoaa päästä päähän -näkyvyyden mikropalveluarkkitehtuureissa.
Haasteet: Toteutuksen monimutkaisuus kasvaa huomattavasti heterogeenisissä ympäristöissä, joissa käytetään useita teknologiakokonaisuuksia.
Hälytysten hallintajärjestelmät
Asianmukainen hälytysten määrittäminen on ratkaisevan tärkeää uusia ominaisuuksia tuotantoympäristössä testattaessa:
- Hälytysten yhdistämisalustat
Hyödyt: Kokoavat useiden valvontajärjestelmien ilmoitukset yhteen.
Haasteet: Soveltuvat erinomaisesti häiriötilanteiden hallintaan, mutta voivat olla häiritseviä, jos niitä ei määritetä huolellisesti hälytysten aiheuttaman väsymyksen välttämiseksi. - Häiriötilanteiden reagointijärjestelmät
Hyödyt: Sujuvoittavat viestintää tuotannon häiriötilanteissa.
Haasteet: Tehokas käyttö edellyttää tarkasti määriteltyjä toimintaohjeita ja integraatiopisteitä; voivat aiheuttaa ylimääräistä työtä yksinkertaisissa käyttöönotoissa.
More Articles
Käyttöönotossa huomioitavat seikat
Kun tuotantoympäristössä testaamiseen otetaan käyttöön työkaluja, tiimien tulisi arvioida seuraavat seikat:
- Skaalautuvuusvaatimukset - Kestääkö työkalu liikennemääräsi ja datan kasvun?
- Integraatio-ominaisuudet - Kuinka helposti se yhdistyy olemassa olevaan työkaluketjuusi?
- Resurssien kulutus - Kuinka paljon ylimääräistä kuormitusta työkalu itsessään aiheuttaa?
- Tiimin asiantuntemus - Onko teillä tarvittavat taidot, jotta työkalun arvo voidaan maksimoida?
- Signaali-kohinasuhde - Pystyttekö erottamaan merkitykselliset havainnot hukkumatta datan määrään?
Yleiset käyttöönoton sudenkuopat
- Työkalujen hallitsematon lisääntyminen - Liian monien päällekkäisten ratkaisujen kertyminen
- Puutteellinen instrumentointi - Kriittisten valvontapisteiden puuttuminen
- Hälytysten aiheuttama väsymys - Liiallisten ilmoitusten tuottaminen, jolloin tiimit lopulta jättävät ne huomiotta
- Puutteellinen asiayhteys - Mittareiden yhteyden käyttäjävaikutuksiin jättäminen huomioimatta
- Datasiilot - Erillisten valvontajärjestelmien luominen niin, etteivät ne jaa tietoja keskenään
Oikean tasapainon löytäminen
Onnistuneimmissa tuotantoympäristössä testaamisen toteutuksissa saavutetaan tasapaino seuraavien asioiden välillä:
- Kattava valvonta ja hallittava monimutkaisuus
- Yksityiskohtaiset havainnot ja tietotulva
- Automaattiset vastaukset ja ihmisen tekemät päätökset
Kun otat käyttöön tuotantoympäristössä testaamiseen tarkoitettuja työkaluja, aloita pienestä ja keskity tarkasti määriteltyihin tavoitteisiin. Laajenna kattavuutta sitten vähitellen, kun tiimisi kehittää asiantuntemustaan sekä työkalujen käytössä että niiden tuottaman datan tulkinnassa.
Kuormitus, monimutkaisuus, viive
Ota testisuunnittelussa huomioon järjestelmän kuormituksen, monimutkaisuuden ja viiveen makrotason tekijät. Nämä voivat vaikuttaa pyynnön, prosessin tai tapahtuman suorittamiseen tai valmistumiseen.
Järjestelmän kuormituksen merkityksen pitäisi olla itsestään selvä. Se, miten pyyntöjä tai tapahtumia käsitellään suuren järjestelmäkuormituksen aiheuttaman rasituksen aikana, voi aiheuttaa virheitä missä tahansa tapahtumaprosessin vaiheessa.
Tämän tulisi olla oletusarvoinen osa testisuunnitteluasi. Kuten kaikki tiedämme, kuormitusta voi syntyä myös itse pyynnön seurauksena – esimerkiksi datakyselystä, joka käynnistää valtavien datamäärien käsittelyn ja siirron.
Monimutkaisuus viittaa tässä ensisijaisesti järjestelmälle esitettyjen pyyntöjen monimutkaisuuteen. Tämä monimutkaisuus voi muodostua määritettyjen ehtojen määrästä (mukaan lukien niiden poissulkemiset ja poikkeukset), pyyntöihin liittyvien tietokantojen (virtuaalisten tai muiden) määrästä tai itse järjestelmän käsittelytopologiasta.
Tässä yhteydessä käytän viivettä tarkoittamaan ajan kulumisen aiheutumista pyyntöprosessissa, vaikka tämä ei ole sanan tavanomainen merkitys. Tarkoitan tässä käyttäjän viivettä, en itse järjestelmän vastausviivettä.
Toisin sanoen, miten ominaisuus tai toiminto käyttäytyy, jos käyttäjä saapuu prosessin tiettyyn vaiheeseen ja jää sitten siihen odottamaan tekemättä mitään? Aikakatkaiseeko järjestelmä toiminnon (todennäköisesti pitäisi)? Pitäisikö sen kehottaa käyttäjää toimimaan? Pitäisikö sen pysyä kyseisessä tilassa maailman tappiin asti?
Näihin kysymyksiin voidaan vastata määrityksessä, mutta testattava tuote ei välttämättä toimi niin, minkä vuoksi ylipäätään testaamme.
Käyttäjäroolit
On selvää, että loppukäyttäjät voivat olla vuorovaikutuksessa ohjelmistojärjestelmien kanssa erilaisissa rooleissa. Sama käyttäjä voi toimia järjestelmässä eri rooleissa toimintansa mukaan.
Prosesseilla ja palveluilla voi kuitenkin myös olla erilaisia rooleja ja niihin liittyviä käyttöoikeuksia. Varmista kummassakin tapauksessa, että testien suunnittelussa ja suunnitelmassa, koskivatpa testit ominaisuuksia tai toiminnallisuuksia, otetaan huomioon kaikki mahdolliset roolitilat ja että niitä testataan.
Mitä seuraavaksi?
Etsitkö lisää vinkkejä testien suunnitteluun? Haluatko myös kehittää SaaS-kasvu- ja johtamistaitojasi?
Tilaa uutiskirjeemme ja saat uusimmat näkemykset CTO:lta ja tulevilta teknologiajohtajilta.
Autamme sinua skaalaamaan toimintaasi fiksummin ja johtamaan vahvemmin huippuasiantuntijoiden oppaiden, resurssien ja strategioiden avulla!
