Yksi tämän päivän testaustilanteen keskeisistä väärinkäsityksistä on, että tuotannossa testaaminen edellyttää vain kolmea osaamisaluetta: prosessiosaamista, automaattisten testaustyökalujen tuntemusta ja häiriötilanteiden hallintakykyä. Nämä ovat tärkeitä, mutta silmiinpistävästi tästä luettelosta – ja rekrytoivien esihenkilöiden ajatuksista – puuttuu jotakin, jonka voisi kuvitella olevan kaikkein perustavanlaatuisinta:
Kyky suunnitella käytännöllinen testi tuotantoympäristöjä varten.
Olisi koomista, ellei se olisi niin hälyttävää, että lähes mikään organisaatio ei aseta keskeistä laadunvarmistuksen osaamista etusijalle toteuttaessaan tuotannossa testaamisen strategioita.
Suoritettiin testi sitten manuaalisesti tai automaation avulla tuotannossa olevassa järjestelmässä, sinun on ensin tiedettävä, miten suunnitellaan testi, joka tuottaa hyödynnettävää tietoa häiritsemättä käyttäjäkokemusta, eikö niin?
Olisi koomista, ellei se olisi niin hälyttävää, että lähes mikään organisaatio ei aseta testien suunnittelun osaamista etusijalle toteuttaessaan tuotannossa testaamisen strategioita. Suoritettiin testi sitten manuaalisesti kontrolloidussa ympäristössä tai automaation avulla tuotannossa olevassa järjestelmässä, sinun on ensin tiedettävä, miten suunnitellaan testi, joka tuottaa hyödynnettävää tietoa häiritsemättä käyttäjäkokemusta, eikö niin?
Testien suunnittelun 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ää, mikä tekee testistä merkityksellisen?
Koska huonosti suunniteltujen testien automatisointi tuotannossa antaa epäluotettavaa dataa nopeammin ja luo tarpeettomia riskejä? Eikä tuotannossa epäpätevällä tavalla testaamisen kutsuminen ”ketteräksi” vaikuta minusta todelliselta parannukselta, paitsi ehkä Scrum Masterin näkökulmasta.
Testien suunnittelun merkitys ja kurinalaisuus, erityisesti tuotannossa tapahtuvan testaamisen yhteydessä, ovat jo pitkään kaivanneet elvyttämistä. Pitäkää tätä minun panoksenani tähän pyrkimykseen.
Mikä on olennaista tehokkaassa tuotannossa testaamisessa?
Ensimmäinen askel tuotannossa testaamisen hallitsemiseksi on tehdä muutamia olennaisia erotteluja, jotka ovat epäilemättä jo intuitiivisesti tuttuja useimmille laadunvarmistuksen parissa työskenteleville, mutta joita harvoin esitetään järjestelmällisesti tuotannossa testaamisen yhteydessä.
Tarkastellaan näitä perustavanlaatuisia käsitteitä, jotka muuttavat lähestymistapasi tuotannossa testaamiseen.
Eksplisiittinen ja implisiittinen toiminnallisuus tuotantoympäristöissä
Aloitetaan kriittisestä erottelusta eksplisiittisen ja implisiittisen toiminnallisuuden välillä tuotannossa testattaessa.
Ensin mainittu on se, mitä useimmat meistä ajattelevat ”toiminnallisuutena”. Se viittaa Tuotteen muodollisesti määrittelemiin ominaisuuksiin ja kyvykkyyksiin, joiden muodollinen määrittely ohjaa niiden toteutusta 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, asia ei ole näin edes hyvin määriteltyjen ominaisuuksien kohdalla. Ainakin eksplisiittisen toiminnallisuuden sisältämä tarkkuus helpottaa tuotantotestien muodostaman tukirakenteen rakentamista sen ympärille (tai illuusion tällaisesta tukirakenteesta).
Implisiittinen toiminnallisuus tuotantoympäristössä on aivan eri asia.
Se koostuu käyttäjän tai ympäristön syötteisiin liittyvistä toimintatavoista ja vastauksista, joita ei ole muodollisesti määritelty tai ennakoitu. Se, ettei implisiittiselle toiminnallisuudelle tuotannossa suunnitella riittäviä testejä, on ylivoimaisesti useimpien tuotteen käyttöönoton jälkeen löydettävien kriittisten virheiden lähde (toinen lähde on riittämätön testaaminen harvinaisissa laitteisto-, ohjelmisto- ja laiteympäristöissä).
Toisin sanoen:
Implisiittisen toiminnallisuuden testaaminen tuotannossa edellyttää huomattavaa kekseliäisyyttä ja mielikuvitusta. Se on tuotannossa testaamisen strategioiden aidosti luova osa.
Implisiittisen toiminnallisuuden testaaminen tuotantoympäristöissä edellyttää tiettyä pirullista nokkeluutta, jotta siinä voi kehittyä hyväksi, eikä sitä valitettavasti voi opettaa tavanomaisten laadunvarmistusprosessien avulla.
Mikään ketterän menetelmän menetelmä tai automaattisen testaamisen viitekehys ei opeta sinulle, miten implisiittistä toiminnallisuutta testataan tehokkaasti tuotannossa, mutta asianmukainen testien suunnittelu voi kannustaa siihen.
Kuinka siis määrittelet testien suunnittelustrategian tuotantoympäristösi implisiittiselle toiminnallisuudelle? Onneksi se on mahdollista. Mutta ennen kuin siirrymme suoraan tähän kysymykseen, tarkastellaan vielä muutamia muita olennaisia erotteluja, jotka ovat kriittisiä tehokkaan tuotannossa testaamisen kannalta.
Positiivinen ja negatiivinen testaaminen
Keskeinen huomio: Tuotannossa testattaessa sekä positiivinen että negatiivinen testaaminen 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: Ominaisuuksien toimivuuden varmistaminen suunnitellulla tavalla tuotantoympäristöissä
- Negatiivinen testaus tuotannossa: Järjestelmän reagoinnin strateginen testaaminen odottamattomiin syötteisiin häiritsemättä todellisia käyttäjiä
Miksi tuotannossa testaaminen on erilaista
Vaikka nämä erot ovat käsitteellisesti selkeitä, tuotannossa testaaminen tuo mukanaan ainutlaatuisia haasteita:
- Suuremmat panokset: Reunatapaukset vaikuttavat todellisiin asiakkaisiin ja liiketoiminnan toimintaan
- Todellisen maailman monimutkaisuus: Käyttäjien toiminta noudattaa harvoin ennustettavia kaavoja
- Liiketoiminnan jatkuvuus: Testaus ei saa häiritä normaalia toimintaa
Määrittelyä pidemmälle
Määrittelyt tarjoavat harvoin kaikkea, mitä tuotannossa tehokkaaseen testaamiseen tarvitaan:
Liiallinen riippuvuus määrittelystä – 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äärittelyistä.
Tämä havainnollistaa sitä, mitä kutsun "empiiriseksi harhaluuloksi": odotetaan jonkin asian kertovan nimenomaisesti, mitä pitää tehdä, ennen kuin se voidaan ymmärtää.
Onnistunut tuotantoympäristöjen testisuunnittelu edellyttää:
- Toiminnallisuuden parametrien asianmukaista määrittelyä
- Loogista ajattelua siitä, mikä on mahdollista
- Sekä käyttäjien että ympäristön välisten 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 ja loi kappaleita, joissa oli kaksi erilaista riviväliä.
Nykyajan vastineita tuotannossa testattaessa:
- Odottamattomat käyttäjäoikeuksien yhdistelmät pilvisovelluksissa
- Ennalta arvaamattomat API-pyyntöjen järjestykset mikropalveluarkkitehtuureissa
- Samanaikaisuuskilpailut suuren samanaikaisuuden ympäristöissä
Tarkastellaan nyt kolmea keskeistä parametria, jotka terävöittävät tuotantotestausmenetelmääsi:
1. Ominaisuuksien käyttöalan testaaminen
Määritelmä: Sen tunnistaminen, miten käyttäjät saattavat ottaa ominaisuuksia käyttöön yhteyksissä tai tavoilla, joita ei suunnitteluvaiheessa 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, huomioi nämä rajat:
Muista: Ominaisuuden validointi tuotannossa ei tarkoita vain sen varmistamista, että se toimii suunnitellusti, vaan myös sen tarkistamista, ettei sitä voida käyttää tarkoittamattomilla tavoilla, jotka saattaisivat vaikuttaa järjestelmän vakauteen tai turvallisuuteen.
Have an account? Log In
2. Työnkulun keskeytysten testaaminen aktiivisissa järjestelmissä
Varoitus: Tämä lähestymistapa edellyttää, että testaat jo määriteltyjä työnkulkuja tuotannossa. Jos näin ei ole, käsittele nämä perusasiat ensin!
"Onnellista polkua" pidemmälle
Kun testaat tuotannossa, tutki näitä kriittisiä työnkulun häiriöitä:
✅ Keskeytyneet työnkulut: Prosessi käynnistyy mutta ei koskaan valmistu
✅ Peruutetut toiminnot: Käyttäjä peruuttaa toiminnon nimenomaisesti kesken prosessin
✅ Uudelleen käynnistetyt prosessit: Käyttäjä yrittää samaa toimintoa useita kertoja
✅ Taaksepäin siirtyminen: Käyttäjä palaa aiempiin vaiheisiin eri syötteillä
Tuotantotestauksen toteutusvinkkejä
Käytä ominaisuuslippujen kaltaisia tekniikoita hallitaksesi turvallisesti näiden testien näkyvyyttä tuotantoympäristöissä.
Sovellukset todellisessa maailmassa
Asiantuntijan vinkki: Näitä tilanteita kuvataan harvoin määrittelyissä, mutta ne edustavat todellista käyttäytymistä tuotannossa.
3. Järjestyksellisyys tuotantotestauksessa
Haaste: Tuotantojärjestelmissä, joissa suoritetaan useita samanaikaisia prosesseja, toimintojen järjestys voi johtaa odottamattomiin virheisiin, joita on vaikea toistaa testiympäristöissä.
Kaksi kriittistä suoritusjärjestyksen mallia
Edeltävät myötävaikuttavat olosuhteet
Näytä kuva
- Määritelmä: Tapahtumat, joiden on tapahduttava ennen epäonnistuvaa prosessia
- Ominaisuudet: Saattaa ilmetä vasta tiettyjen järjestysten jälkeen, joiden luonnollinen tapahtuminen kestää päiviä
- Esimerkki tuotannossa: Käyttäjän käyttöoikeuksia muokataan → välimuisti vanhenee → tiettyä ohjelmointirajapintaa kutsutaan
Seuraavat myötävaikuttavat olosuhteet
- Määritelmä: Virheet, jotka tulevat ilmeisiksi vasta myöhempien vuorovaikutusten kautta
- Ilmeneminen: Virhe pysyy piilossa myöhempään toimintoon asti
- Esimerkki tuotannossa: Tietojen korruptoituminen tapahtuu huomaamatta, kunnes raportti luodaan
Miksi tämä on niin haastavaa?
Tuotannossa tehtävien suoritusjärjestystestien laajuuden määrittäminen edellyttää:
- Järjestelmän vuorovaikutusten perusteellista tuntemusta
- Monimutkaisten prosessien tilasiirtymien mallintamista
- Sekä tarkoitettujen että tahattomien tilayhdistelmien ymmärtämistä
"Kuten yhden kappaleen kaksi riviväliarvoa, nämä odottamattomat tilat voivat aiheuttaa tuotantoympäristöissä suurta tuhoa."
Keskeiset työkalut tuotannossa tehtäviin suoritusjärjestystesteihin
- Kaaostekniikkaa hallittujen virheiden tarkoitukselliseen käyttöönottoon
- Havainnointityökaluja tilamuutosten seuraamiseen järjestelmien välillä
- Hajautettua jäljitystä pyyntöjen kulkureittien seuraamiseen mikropalveluissa
Yhteenveto: Suoritusjärjestykseen liittyvät ongelmat ovat yksi merkittävimmistä vakavien virheiden lähteistä nykyaikaisissa tuotantojärjestelmissä. Aseta tämä osa-alue etusijalle testausstrategiassasi.
Lopputulos
Ominaisuusliput muuttavat tuotannossa testaamisen riskialttiista käytännöstä hallituksi ja dataohjautuvaksi prosessiksi. Irrottamalla käyttöönoton julkaisusta ja tarjoamalla välittömän palautusmahdollisuuden ne luovat turvaverkon, jonka ansiosta tiimit voivat validoida ohjelmiston todellisissa olosuhteissa vaarantamatta käyttökokemusta tai järjestelmän vakautta.
Ominaisuuksienhallinta-alustat tuotantotestauksessa
Ominaisuuksienhallinta-alustat ovat muuttaneet tuotannossa testaamisen riskialttiista hankkeesta hallituksi ja järjestelmälliseksi prosessiksi. Silti monet organisaatiot eivät hyödynnä näitä työkaluja tehokkaasti osana testien suunnittelustrategiaansa.
Riskienhallinnan kehitys tuotannossa
Perinteiset lähestymistavat tuotannossa testaamiseen perustuivat kaksijakoisiin päätöksiin – ominaisuus oli joko käytössä kaikilla tai ei kenelläkään. Ominaisuuksienhallinta-alustat muuttavat tämän toimintamallin perusteellisesti:
- Yksityiskohtainen hallinta: Testaa ominaisuuksia tietyillä käyttäjäsegmenteillä kaikkien käyttäjien kattavien tai kokonaan käytöstä poistettujen käyttöönottojen sijaan
- 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 vähitellen reaaliaikaisten suorituskykytietojen perusteella
Yksinkertaisia ominaisuuslippuja pidemmälle
Vaikka perusmuotoinen ominaisuusliputus on ollut käytössä vuosia, nykyaikaiset ominaisuuksienhallinta-alustat tarjoavat keskeisiä toimintoja, jotka muuttavat tuotantotestausta:
Kun ominaisuuksienhallinta-alustat integroidaan asianmukaisesti testien suunnittelustrategiaan, ne mahdollistavat:
- Kohdennetun riskien rajoittamisen – Rajoita uusien ominaisuuksien näkyvyyttä tietyille käyttäjäsegmenteille
- Vahvistamisen oikeilla käyttäjillä – Testaa todellisilla käyttäjillä synteettisten testitietojen sijaan
- Välittömän korjaamisen – Ratkaise ongelmat ilman hätäjulkaisuja tai palautuksia
Integrointi havainnointityökaluihin
Ominaisuuksienhallinta-alustojen todellinen voima tulee esiin, kun ne integroidaan havainnointi- ja valvontajärjestelmiin:
Perinteinen lähestymistapa:
- Havaitse ongelmat täyden käyttöönoton jälkeen
- Testitulosten manuaalinen varmistaminen
- Välikohtauksen jälkeinen analyysi
Ominaisuuksien hallinnan integrointi:
- Yhdistä ominaisuuden aktivointi järjestelmän mittareihin
- Automaattinen suorituskyvyn valvonta ominaisuuslipun mukaan
- Reaaliaikainen näkemys ominaisuuksien vaikutuksista
Todellinen vaikutus: tuotannossa tapahtuvan testauksen muuttaminen
Ominaisuuksien hallinta-alustoja käyttöön ottavat organisaatiot raportoivat merkittävistä hyödyistä:
- Välikohtausten vakavuuden vähentyminen: "Voimme testata ominaisuuksia tuotannossa hyvissä ajoin ennen markkinointijulkaisua. Jos ominaisuus aiheuttaa ongelmia julkaisupäivänä, voimme yksinkertaisesti kytkeä sen pois päältä tappokytkimellä – palautuksia ei tarvita." — Chris Guidry, tekniikasta vastaava johtaja, O'Reilly Media.
- Julkaisusyklien nopeutuminen: IBM:n, TrueCarin ja muiden johtavien yritysten tiimit hyödyntävät ominaisuuksien hallintaa tuotannossa testaamiseen ja saavat näin julkaisuja, joita ne kuvailevat "turvallisiksi ja seremonioitta toteutettaviksi".
- Testikattavuuden paraneminen: Ominaisuusliput paljastavat reunatapauksia, joita on mahdotonta simuloida kontrolloiduissa ympäristöissä.
Käytännön toteutus testisuunnittelussa
Jotta voit sisällyttää ominaisuuksien hallinta-alustat tehokkaasti testisuunnittelustrategiaasi:
- Suunnittele varmennuspisteet, jotka vastaavat ominaisuuslippujen siirtymiä
- Luo varaskenaariot jokaiselle ominaisuuslipulla hallittavalle komponentille
- Määritä suorituskykykynnykset, jotka käynnistävät ominaisuuden automaattisen käytöstäpoiston
- Määritä segmenttikohtaiset testitapaukset käyttäytymisen validoimiseksi eri käyttäjäryhmissä
- Dokumentoi lippujen riippuvuudet ketjuuntuvien häiriöiden estämiseksi
Ominaisuuksien hallinta-alustat eivät korvaa harkittua testisuunnittelua – ne vahvistavat sitä. Tuotannossa tapahtuvan testauksen laatu riippuu edelleen olennaisesti siitä, kuinka hyvin testisi on suunniteltu.
Yleiset vältettävät sudenkuopat
Vankasta ominaisuuksien hallinnasta huolimatta useita haasteita on edelleen:
- Lippuvelka - Hylätyt tai unohdetut liput, jotka synnyttävät teknistä velkaa
- Riittämätön valvonta - Lipun tilan ja järjestelmän suorituskyvyn välisen yhteyden huomiotta jättäminen
- Liiallinen itsevarmuus - Tuotantoa edeltävän testauksen ennenaikainen vähentäminen
- Lippujen keskinäiset riippuvuudet - Monimutkaisten ja vaikeasti vianmäärityksen mahdollistavien suhteiden luominen
Yhteenveto
Ominaisuuksien hallinta-alustat tarjoavat tehokkaita ominaisuuksia tuotannossa tapahtuvaan testaamiseen, mutta ne on integroitava harkitusti osaksi yleistä testisuunnittelustrategiaa. Eniten hyötyvät organisaatiot eivät vain ota näitä työkaluja käyttöön, vaan miettivät perusteellisesti uudelleen, miten testisuunnittelu toimii ominaisuuslippuihin perustuvassa ympäristössä.
Kun ominaisuuksien hallinta toteutetaan asianmukaisesti osana kattavaa testisuunnittelua, 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 tapahtuvan testauksen perustan, laajempi työkaluekosysteemi tuo mukanaan omat toteutuksen haasteensa. Oikeiden työkalujen valinta ja määritys 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 yksityiskohtaisia suorituskykytietoja koko sovelluspinoon liittyen.
Haasteet: Edellyttää usein merkittävää instrumentointia ja voi tuottaa liikaa dataa, joka kuormittaa pienempiä tiimejä. - Lokienhallintajärjestelmät
Hyödyt: Välttämättömiä virheenkorjauksessa ja rikosteknisessä analyysissä tuotannossa tapahtuvan testauksen aikana.
Haasteet: Voivat tuottaa valtavia datamääriä 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 kriittistä uusia ominaisuuksia tuotannossa testattaessa:
- Hälytysten koontialustat
Edut: Kokoavat ilmoitukset useista valvontajärjestelmistä.
Haasteet: Erinomaisia häiriötilanteiden hallintaan, mutta voivat olla häiritseviä, jos niitä ei määritetä huolellisesti hälytysväsymyksen välttämiseksi. - Häiriötilanteiden hallintajärjestelmät
Edut: Tehostavat viestintää tuotantohäiriöiden aikana.
Haasteet: Tehokas käyttö edellyttää tarkasti määriteltyjä toimintaohjeita ja integrointipisteitä; voivat aiheuttaa ylimääräistä työtä yksinkertaisissa käyttöönotoissa.
More Articles
Käyttöönotossa huomioitavaa
Kun tuotannossa testaamiseen tarkoitettuja työkaluja otetaan käyttöön, tiimien tulisi arvioida seuraavat asiat:
- Skaalautuvuusvaatimukset – Käsitteleekö työkalu liikennemääräsi ja datan kasvun?
- Integrointimahdollisuudet – Kuinka helposti se yhdistyy olemassa olevaan työkaluketjuusi?
- Resurssien kulutus – Kuinka paljon ylimääräistä kuormaa työkalu itsessään aiheuttaa?
- Tiimin asiantuntemus – Onko teillä tarvittavat taidot työkalun hyödyn maksimoimiseksi?
- Signaali-kohinasuhde – Pystyttekö saamaan merkityksellisiä havaintoja hukkumatta dataan?
Yleiset käyttöönoton sudenkuopat
- Työkalujen paisuminen – Liian monien päällekkäisten ratkaisujen kertyminen
- Puutteellinen instrumentointi – Kriittisten valvontapisteiden puuttuminen
- Hälytysväsymys – Liiallisten ilmoitusten tuottaminen, jolloin tiimit lopulta jättävät ne huomiotta
- Riittämätön konteksti – Mittareiden yhteyden käyttäjävaikutuksiin jättäminen selvittämättä
- Datasilot – Erillisten valvontajärjestelmien luominen niin, etteivät ne jaa tietoja keskenään
Oikean tasapainon löytäminen
Menestyksekkäimmissä tuotannossa testaamisen toteutuksissa saavutetaan tasapaino seuraavien asioiden välillä:
- Kattava valvonta ja hallittava monimutkaisuus
- Yksityiskohtaiset havainnot ja tietotulva
- Automatisoidut vastaukset ja ihmisen tekemät päätökset
Kun otat testityökaluja käyttöön tuotantoympäristöissä, aloita pienestä ja keskity tarkasti määriteltyihin tavoitteisiin. Laajenna kattavuutta vähitellen, kun tiimisi kehittää asiantuntemustaan sekä työkaluissa että niiden tuottaman datan tulkinnassa.
Kuormitus, monimutkaisuus, viive
Huomioi järjestelmän kuormituksen, monimutkaisuuden ja viiveen makrotason tekijät testisuunnittelussasi. Nämä voivat vaikuttaa pyynnön, prosessin tai tapahtuman suorittamiseen tai loppuun saattamiseen.
Järjestelmän kuormituksen merkityksen pitäisi olla ilmeinen. Pyyntöjen tai tapahtumien käsittely suuren järjestelmän kuormitustestin aikana voi epäonnistua (missä tahansa tapahtumaprosessin vaiheessa).
Tämän tulisi olla testisuunnittelusi oletusarvoinen osa. Kuten kaikki tiedämme, kuormitus voi syntyä myös itse pyynnön seurauksena – esimerkiksi datakyselystä, joka käynnistää valtavien datamäärien käsittelyn ja siirron.
Monimutkaisuudella tarkoitetaan tässä ensisijaisesti järjestelmälle esitettyjen pyyntöjen monimutkaisuutta. Monimutkaisuus voi koostua määritettyjen ehtojen määrästä (sekä niiden poissulkemisista ja poikkeuksista), pyyntöihin liittyvien tietokantojen (virtuaalisten tai muiden) määrästä tai itse järjestelmän käsittelytopologiasta.
Tässä yhteydessä käytän termiä viive kuvaamaan pyyntöprosessiin syntyviä aikakatkoja, mikä ei ole sanan tavanomainen merkitys. Tarkoitan tässä käyttäjän viivettä, en itse järjestelmän vastausviivettä.
Toisin sanoen, miten ominaisuus tai toiminnallisuus käyttäytyy, jos käyttäjä siirtyy prosessin tiettyyn vaiheeseen ja jää sitten siihen odottamaan tekemättä mitään? Aikakatkaiseeko järjestelmä toiminnon (sen luultavasti pitäisi)? Pitäisikö sen kehottaa käyttäjää? Pitäisikö sen pysyä kyseisessä tilassa aikojen loppuun asti?
Näihin kysymyksiin voidaan antaa vastaukset määrittelyssä, mutta testattava tuote ei välttämättä toimi niin, minkä vuoksi testaamme alun perin.
Käyttäjäroolit
Tietysti loppukäyttäjät voivat olla vuorovaikutuksessa ohjelmistojärjestelmien kanssa eri rooleissa. Sama käyttäjä voi toimia järjestelmän kanssa eri rooleissa toimiensa mukaan.
Myös prosesseilla ja palveluilla voi kuitenkin olla erilaisia rooleja ja niihin liittyviä käyttöoikeuksia. Varmista kummassakin tapauksessa, että testisuunnittelussasi ja -suunnitelmassasi, olipa kyse ominaisuuksista tai toiminnallisuuksista, otetaan huomioon ja testataan kaikki mahdolliset roolitilat.
Mitä seuraavaksi?
Etsitkö lisää vinkkejä testien suunnitteluun? Haluatko myös vauhdittaa SaaS-kasvua ja johtamistaitojasi?
Tilaa uutiskirjeemme saadaksesi uusimmat näkemykset teknologiajohtajilta ja tulevilta teknologiajohtajilta.
Autamme sinua skaalaamaan älykkäämmin ja johtamaan vahvemmin huippuasiantuntijoiden oppaiden, resurssien ja strategioiden avulla!
