Yritysarkkitehtuuri
Tiedätkö kolme testauksen ongelmakohtaa, jotka saattavat jäädä huomaamatta ammattilaisiltakin?

Testauksen tarkoituksena on löytää mahdolliset viat ja puutteet testauksen kohteena olevasta tietojärjestelmästä. Mutta mitä vikoja ja puutteita löytyy itse testauksesta? Mitä niille voisi tehdä?

Kyselykierros asiantuntijoillemme osoitti, että tarvetta testausprosessin analysoinnille ja edelleen testauksen kehittämiselle kyllä olisi.

Tässä Reflectorilaisten Top 3 -lista ongelmakohdista, jotka usein jäävät testauksessa huomaamatta:

1. End-to-End -testauksen puutteellinen tai liian myöhäinen toteuttaminen

Useinkaan tietojärjestelmä ei ole yksittäinen, erillinen tai itsenäinen järjestelmä, vaan se koostuu useista eri järjestelmistä muodostaen kokonaisuuden, jonka riippuvuudet vaikuttavat koko järjestelmän toimivuuteen tai toimimattomuuteen. Tietojärjestelmien toteuttaminen on pilkottu pieniin palasiin ja toteutustiimit keskittyvät testaamaan ja varmentamaan vain oman osionsa toimivuuden. Kuitenkin muutos yhteen järjestelmään tai sen osaan tarkoittaa, että koko tietojärjestelmä tulisi vähintään regressiotestata, jotta varmistetaan aikaisemmin kehitetyn järjestelmäkokonaisuuden toimivuus vielä muutoksen jälkeenkin.

Kuinka sitten huolehditaan, että End-to-End -testaus tulee tehtyä mahdollisimman aikaisessa vaiheessa ja riittävän kattavasti?

Kuten tietojärjestelmää, myös testausprosessia tulee ajatella kokonaisuutena, jossa lähtökohtana on koko tietojärjestelmän testaus ja sen toiminnan varmistaminen yksittäisten järjestelmän osien lisäksi. Tähän päästään varmistamalla

  • että on sovittu, kuka vastaa kokonaistestauksesta.
  • testauksen mukanaolo riittävän aikaisessa vaihessa ja riittävän kattavasti.
  • resurssien ja ajan riittävyys, mukaanlukien riittävä määrä uusintakierroksia.
  • järjestelmän eri osista vastaavien henkilöiden välinen kommunikointi.

2. Virheistä ei kerätä oppia tulevaan

Tietojärjestelmä, jossa ei ole vikoja, on mielikuvituksen tuote. Riippumatta siitä, kuinka paljon ja millä tavalla testataan, vikoja löytyy vielä tuotantojärjestelmistäkin – enemmän tai vähemmän, isompia ja pienempiä vikoja.

Kun näin käy, on virheistä syytä ottaa opiksi ja tarkastella syitä sille, miksi virhettä ei löydetty aikaisemmissa testauksen vaiheissa. Analyysin tuloksena voidaan sitten tehdä muutoksia testauksessa niin, että todennäköisyys saman tai vastaavanlaisen virheen läpipääsyyn pienenee.

Sopimalla, miten vikoja analysoidaan ja liittämällä se osaksi testausprosessia varmistutaan siitä, että sille tulee varrattua aikaa ja resursseja. Järjestelmällinen vika-analyysi mahdollistaa testauksen jatkuvan kehittämisen.

3. Tutkiva testaus jää tekemättä

Usein tietojärjestelmän uusille ominaisuuksille tehdään vaatimusmäärittely ja niiden pohjalta hyväksymiskriteerit. Niiden pohjalta testaajat tekevät testaussuunnitelmat ja testit, joilla varmistetaan hyväksymiskriteerien täyttyminen ja haluttu lopputulos.

Testaajan näkökulmasta työ näin tehtynä on rutiininomaista ja joskus jopa tylsää.

Allokoimalla aikaa siihen, että testaajat voivat vapaasti ja luovasti tutkia järjestelmää, mahdollistetaan uuden oppiminen ja työn mielekkyys. Samalla tavoitteena on parantaa testikattavuutta tutkimalla järjestelmää eri näkökulmista ja kulkemalla erilaisia polkuja.

Onko teidän yrityksenne Top 3 -ongelmakohdat jo kartoitettu ja kehityssuunnitelma tehty?

Reflector on ICT-talo, jonka ykköstehtävä on auttaa asiakkaitamme liiketoiminnan isoissa ja pienissä muutoshankkeissa. Ketterästi ja riippumattomasti.

Jaa artikkeli

Voisit pitää myös näistä:

Yritysarkkitehtuuri konsultti

Datan hyötykäytön anatomiaa

Miten dataa pitäisi hyödyntää? Mikä osa datasta on relevanttia ja mikä voidaan sivuuttaa? Miten ihmiset liittyvät datan hyödyntämiseen? Näihin kysymyksiin nykypäivän dataintensiivisessä ympäristössä

Lue lisää
Kokonaisarkkitehtuuri Reflector

Ota yhteyttä, mietitään yhdessä juuri teille parhaat ratkaisut

Täytä tiedot ja siirry lataamaan tutkimus

Kokonaisarkkitehtuuri Reflector

Get in touch!