Olemme tulleet Leadership In Test -sarjan kahteen viimeiseen artikkeliin. Tähän mennessä olemme käsitelleet testiprojektin suunnittelua ja hallintaa alusta loppuun sekä monia siihen liittyviä työkaluja ja prosesseja.
Tässä artikkelissa haluan käsitellä yrityksen liiketoimintaprosessien varmistamista (Enterprise Business Process Assurance, EBPA) – mitä se on ja miten sitä kannattaa lähestyä. Käsittelemme seuraavia aiheita:
- Mitä yrityksen liiketoimintaprosessien varmistaminen on?
- Järjestelmien integroinnin ja testauksen ymmärtäminen
- Horisontaalinen testaus: E2E-testausmenetelmä
- Integraatioriskit ja E2E-testaus
Käsiteltävää on paljon, joten ryhdytään toimeen.
Mitä yrityksen liiketoimintaprosessien varmistaminen on?
Jokainen uusia järjestelmiä käyttöön ottava organisaatio on kohdannut ongelmia käyttäessään niitä ensimmäistä kertaa. Järjestelmät, jotka poikkeavat edes hieman olemassa olevasta infrastruktuurista ja liiketoimintaprosesseista, voivat aiheuttaa kaaosta ja olla vaikeasti korjattavia.
Iteratiiviset, ketterät ja yhteistyöhön perustuvat käytännöt auttavat, mutta koko yrityksen kattavan integroinnin haasteisiin voidaan vastata vain testauksen viimeisessä vaiheessa.
Kutsumme tätä viimeistä vaihetta nimellä Enterprise Business Process Assurance (EBPA). Onnistuminen edellyttää yhtä tai useampaa testausvaihetta, jotka osoittavat järjestelmien, liiketoimintaprosessien ja tietojen olevan integroituja ja tuottavan luvatut palvelut.
Aiheesta on vain vähän tieteellisiä artikkeleita, vaikka tämä toiminta hallitsee jokaisen laajamittaisen projektin myöhempiä vaiheita. EBPA-strategiamme pohjaksi tarkastelemme ensin lähemmin järjestelmien integroinnin ja testauksen tyyppejä, joita tulet käsittelemään.
Yritystason projekteissa monimutkaisuus kasvaa eksponentiaalisesti. Siksi yritystason tietokantojen hallintaohjelmiston valitseminen voi muuttaa laadunvarmistuksen suunnittelutyösi merkittävästi.
Järjestelmien integroinnin ja testauksen ymmärtäminen
Vertikaalinen integrointi
Teknisestä näkökulmasta integrointi tarkoittaa teknisen arkkitehtuurin eri kerrosten välistä yhteyttä. Kehittäjien integrointitestaus koostuu pääasiassa tarkistuksista, joilla varmistetaan, että käyttöliittymän kautta päivitystapahtumassa vastaanotetut tiedot tallennetaan onnistuneesti tietokantaan.
Toiseen suuntaan säilytetyt tiedot tarkistetaan, jotta ne voidaan esittää käyttöliittymässä tarkasti, kun niitä pyydetään. Teknisen arkkitehtuurin yhteyksiä ja reittejä voidaan tarkastella vertikaalisina reitteinä tai vertikaalisina integrointitesteinä.
Horisontaalinen integrointi
Loppukäyttäjät eivät näe teknistä arkkitehtuuria ja sen kaikkea monimutkaisuutta. He tarkastelevat järjestelmää joukkona toimintoja, joita eri käyttäjät käyttävät niin sanotulla käyttäjäpolulla.
Nämä polut seuraavat käyttäjien liiketoimintaprosessien reittejä ja käyttävät eri järjestelmiä ja toimintoja polun jokaisessa vaiheessa käyttöliittymän kautta.
Ketterät tiimit työskentelevät pienemmän mittakaavan tarinoiden parissa eivätkä näe laajempaa kokonaisuutta. Kehittäjät eivät yleensä pysty seuraamaan ja testaamaan pidempiä käyttäjäpolkuja, koska heillä ei ole tarvittavia ympäristöjä tai tietoja. Siksi organisaatiot luottavat yleensä laajemman mittakaavan testeihin ja testaajatiimeihin niiden validoimiseksi.
Käyttäjäpolut kattavat luonnostaan liiketoimintaprosessin ja järjestelmän ominaisuudet yhdessä. Tällä tavoin horisontaaliset testit testaavat järjestelmien ja liiketoimintaprosessin välistä integraatiota.
Vertikaalinen integraatiotestaus omaksuu teknisemmän näkökulman; horisontaalinen testaus keskittyy käyttäjän tai liiketoimintaprosessin näkökulmaan.
Seuraavaksi hyödynnämme näitä käsitteitä rakentaaksemme mallin, joka auttaa meitä ymmärtämään EBPA:ta ja suunnittelemaan sitä. Viittaamme mallissa horisontaalisiin ja vertikaalisiin integraatiomenetelmiin.
Have an account? Log In
Integraation ja testauksen malli
Integraatio on usein väärin ymmärretty käsite. Integraatioprosessi alkaa itse asiassa lähes heti koodauksen alettua. Voitaisiin sanoa, että integraatio alkaa, kun meillä on kaksi koodiriviä — toinen koodirivi on integroitava ensimmäiseen. Integraatio päättyy, kun kaikki toiminnallinen testaus päättyy käyttäjähyväksyntään.
Tarkastellaan esimerkkiä, jossa käytetään kaupallisia valmisohjelmistomoduuleja (COTS) ja toiminnanohjausjärjestelmän (ERP) moduuleja.
COTS- tai ERP-moduuleja luova ohjelmistoyritys on suorittanut yksikkö- ja toiminnallisen testauksen. Kun nämä komponentit saapuvat, niiden voidaan yleensä olettaa toimivan ja integroituvan teknisesti. Eri toimittajilta peräisin olevien integroitujen komponenttien odottamattomaan yhteistoimintaan liittyy kuitenkin aina riski.
Jos komponentteja myös mukautetaan, niiden toiminta muuttuu, mikä puolestaan todennäköisesti aiheuttaa hienovaraisia (ja toisinaan vähemmän hienovaraisia) sivuvaikutuksia muualla. Vertikaalista integraatiota tarvitaan edelleen ohjauksen ja tietojen vaihdon varmistamiseen teknologiakerroksessa sekä horisontaalista integraatiota komponenttien ja liiketoimintaprosessin välillä.
Esitämme neljä integraatiotoimintoa nelikenttämallissa, jossa on kaksi akselia. X-akselilla on testattavan järjestelmän laajuus – joko yksittäinen komponentti tai alijärjestelmä erillään tai integroidut järjestelmät liiketoimintaprosessin yhteydessä.
Mallin oikea puoli on varjostettu siniseksi, ja se edustaa EBPA:ta. Järjestelmämme testaamista muiden järjestelmien (SIT) ja liiketoimintaprosessin (BIT) yhteydessä kutsumme yrityksen liiketoimintaprosessin varmistamiseksi.
Tarkastellaan neljää nelikenttää vuorotellen.
Moduulin, ominaisuuden tai komponentin testaus
Moduuli on testattava toiminnallisesti riippumatta siitä, onko se rakennettu räätälöidysti vai onko kyseessä COTS-komponentti. Käyttäjäkokemus on aina tärkeä, ja sen on integroiduttava johonkin liiketoimintaprosessin vaiheeseen tai toimintoon.
Alijärjestelmän integraatiotestaus
Integraatio tapahtuu asteittain. Kun matalan tason komponentteja ja ominaisuuksia tulee saataville, ne integroidaan yhä suurempaan järjestelmään ja testataan, kunnes valmis, yhtenäinen järjestelmä on valmis. Kutsumme tätä alijärjestelmän integraatiotestaukseksi.
Järjestelmäintegraatiotestaus (SIT)
Mikään järjestelmä ei ole olemassa eristyksissä, joten kun järjestelmämme on valmis, meidän on integroitava se muihin järjestelmiin. Asennamme järjestelmämme ympäristöön, jossa ovat sen kanssa rajapintoja käyttävät järjestelmät, ja testaamme näiden järjestelmien toimintaa ”järjestelmien järjestelmänä” näiden rajapintojen kautta. Tavoitteemme tässä vaiheessa on käsitellä integraation teknisiä riskejä, ja kutsumme tätä järjestelmäintegraatiotestaukseksi.
Liiketoimintaintegraatiotestaus (BIT)
Integraation viimeisen vaiheen tavoitteena on varmistaa, että toteutetut järjestelmät integroituvat järjestelmien käyttäjien liiketoimintaprosesseihin ja (usein manuaalisiin) menettelyihin. Järjestelmän ulkoiset rajapinnat mukaan lukien (jos niitä ei ole jo testattu) validoimme, että yhteistyössä toimivat järjestelmät ja liiketoimintaprosessit tarjoavat yhtenäiset ja tehokkaat käyttäjäpolut sekä käsittelevät ja siirtävät tietoja oikein ja yhdenmukaisesti. Kutsumme tätä yleensä liiketoimintaintegraatiotestaukseksi.
Tämän artikkelin loppuosassa keskitymme suurelta osin mallin horisontaaliseen, EBPA:ta käsittelevään puoleen.
Aiheeseen liittyvä lukeminen: 10 PARASTA TESTIDATAN HALLINTATYÖKALUA
Horisontaalinen testaus: E2E-testausmenetelmä
Horisontaalinen integraatio perustuu eniten siihen, mitä kutsutaan usein päästä päähän -testaukseksi (E2E).
E2E-testaus on testauksen suunnittelutekniikka, jossa kutsutaan sarja toisiinsa liittyviä tapahtumia, jotka kattavat tyypillisesti useita järjestelmiä, mukaan lukien testattavana oleva järjestelmämme tai järjestelmämme. Näissä testeissä seurataan yleensä käyttäjien liiketoimintaprosessien mukaisia käyttäjäpolkuja.
Kun käytettävissä on liiketoimintaprosessin malli, prosessin läpi kulkevat polut jäljitetään, jotta voidaan luoda hyödyllinen tapahtumasarja, joka simuloi tapaa, jolla käyttäjät käyttävät järjestelmää tuotannossa.
Nämä mallit voivat olla tuttuja kaavioita, kuten vuokaavioita tai uimaratakaavioita, tai teknisempiä esityksiä, kuten UML-sekvenssi- tai yhteistyökaavioita. (UML on monien IT-organisaatioiden käyttämä yhtenäinen mallinnuskieli.)
E2E-testit käsittelevät erityisiä riskejä, joita ei voida helposti käsitellä aiemmassa alijärjestelmien testauksessa tai ympäristöissä, jotka ovat vahvasti tynkärajapintojen ja puhtaasti synteettisen datan varassa.
Horisontaalisen testauksen yhteydessä E2E-testausmenetelmää täydennetään usein erikoistuneilla ohjelmistoilla. Jos etsit huolellisesti valittua luetteloa ohjelmistoista, jotka voivat tehostaa tätä prosessia, tutustu näihin parhaiksi arvioituihin testauksenhallintaratkaisuihin
Hyväksyntä
’Sopivuuden’ käsite soveltuu komponenttien väliseen integrointiin, järjestelmien väliseen integrointiin ja järjestelmien ja liiketoimintaprosessien integrointiin.
Hyväksyntä perustuu yleensä horisontaalisten E2E-testien tuloksiin, koska liiketoiminnan sidosryhmät voivat luottaa siihen, että nämä testit osoittavat, miten uusi järjestelmä sopii heidän työskentelytapoihinsa ja tukee niitä. Horisontaaliset E2E-testit antavat heille varmuuden siitä, että toimitettu palvelu toimii.
Järjestelmien hyväksyntäprosessi riippuu yleensä ainakin osittain onnistuneesta horisontaalisesta E2E-testauksesta. Tämä johtuu siitä, että vain E2E-testit käyttävät järjestelmää realistisessa ympäristössä ja simuloivat realistista käyttäjätoimintaa.
Monissa organisaatioissa järjestelmien toiminta voidaan osoittaa vasta testauksen loppuvaiheissa, mikä antaa sidosryhmille varmuuden siitä, että järjestelmä toimii vaatimusten mukaisesti.
Jos sinua pyydetään suunnittelemaan hyväksymistesti, oletamme, että E2E-testaustekniikalla on suunnitelmassasi merkittävä rooli.
Integrointiriskit ja E2E-testaus
Kuten edellä todettiin, integrointiriskit liittyvät järjestelmien väliseen integrointiin tai järjestelmien ja liiketoimintaprosessien integrointiin.
Jotkin organisaatiot päättävät jakaa näihin kahteen riskityyppiin kohdistuvat testit järjestelmäintegraatiotestaukseen (SIT) ja liiketoimintaintegraatiotestaukseen (BIT). Usein riskit ja testit kuitenkin yhdistetään yhdeksi testausvaiheeksi, jonka nimi on E2E-testaus, hyväksymistestaus tai liiketoimintatestaus.
Riippumatta siitä, miten testaus on jäsennelty, siinä hyödynnetään laajasti edellä kuvattua E2E-testausmenetelmää. Käyttöympäristössäsi kohtaamasi riskit voivat olla muunnelmia näistä teemoista, ja sinun on ehkä mukautettava testitavoitetta ja testausmenetelmääsi sen mukaisesti.
Tässä esitettyä riskiluetteloa tulee pitää vain lähtökohtana ja muistutuksena siitä, mihin testauksessa kannattaa keskittyä. On todennäköistä, että organisaatioosi, toimialaasi tai teknologiaasi liittyy erityisiä riskejä, jotka sinun on lisättävä tähän lähtöluetteloon.
Alla olevassa taulukossa ’järjestelmillä’ tarkoitetaan integroitujen järjestelmien kokonaisuutta, johon kuuluvat kehitettävänä oleva uusi järjestelmä tai uudet järjestelmät, muut vanhat tai infrastruktuurijärjestelmät sekä ulkoiset järjestelmät, kuten pankit tai yhteistyökumppaniorganisaatiot.
| Riski | Testitavoite | Testausmenetelmä |
| Järjestelmiä ei ole integroitu (tiedonsiirto). | Osoitetaan, että järjestelmät on integroitu ja että tiedonsiirto tapahtuu oikein. | Järjestelmäintegraatiotestaus (SIT) |
| Järjestelmiä ei ole integroitu (hallinnan siirto). | Osoitetaan, että järjestelmät on integroitu (hallinnan siirto vaadittuine parametreineen tapahtuu oikein). | SIT |
| Rajapinnat vikaantuvat, kun niitä käytetään pitkään. | Osoitetaan, että rajapintoja voidaan käyttää jatkuvasti pitkän ajanjakson ajan. | SIT (Nämä tarkistukset voidaan tehdä myös osana luotettavuus- ja/tai vikasietoisuustestausta) |
| Järjestelmiä ei ole integroitu (tiedot eivät täsmää rajapintojen välillä). | Osoitetaan, että järjestelmät on integroitu (rajapinnan kautta siirrettyjä tietoja käytetään yhdenmukaisesti esimerkiksi valuutan, kielen, mittareiden, ajoitusten, tarkkuuden ja toleranssien osalta). | SIT |
| Järjestelmiä ei ole synkronoitu (tiedonsiirrot eivät käynnisty, käynnistyvät väärään aikaan tai käynnistyvät useita kertoja). | Osoitetaan, että tiedonsiirrot käynnistyvät oikein. | SIT |
| Useissa järjestelmissä olevat objektit tai entiteetit eivät täsmää järjestelmien välillä. | Osoitetaan, että liiketoimintaobjektien tilat esitetään täsmällisesti niissä järjestelmissä, jotka sisältävät objekteja koskevia tietoja. | Liiketoimintaintegraatiotestaus (BIT) |
| Järjestelmiä ei ole integroitu liiketoimintaprosessiin (toimitusketjuun). | Osoitetaan, että järjestelmät integroituvat liiketoimintaprosesseihin ja tukevat toimitusketjuprosessia. | BIT |
| Taustajärjestelmien liiketoimintaprosessit eivät tue verkko- tai mobiilikäyttöliittymiä. | Osoitetaan, että toimitusketjuprosessit ovat toimivia ja tukevat liiketoimintatavoitetta. | BIT |
| Saman henkilöstön käyttämien integroitujen järjestelmien käyttöliittymät tai toiminta ovat epäjohdonmukaisia samankaltaisissa tai toisiinsa liittyvissä tehtävissä. | Osoitetaan, että käyttäjät kokevat järjestelmien toiminnan yhdenmukaiseksi suorittaessaan samankaltaisia tai toisiinsa liittyviä tehtäviä. | BIT (Nämä tarkistukset voidaan tehdä myös käyttökokemuksen tarkistamisen aikana) |
Huomautuksia riskitaulukosta
Jotkin edellä mainituista riskeistä tarvitsevat hieman lisäselvitystä.
Tiedonsiirto-ongelmat
Usein tietoja siirretään järjestelmien välillä verkkojen kautta. Jos nämä siirrot suoritetaan eräajoina ja ne epäonnistuvat tai jos reaaliaikainen siirto epäonnistuu käyttäjän, liiketoiminnan tai jonkin muun järjestelmätapahtuman käynnistämänä, kohdetärjestelmästä puuttuu tietoja.
Virheellinen hallinnan siirto
Hallinnan siirrolla tarkoitetaan tilannetta, jossa käyttäjän toiminto tai järjestelmäprosessi siirtää käyttäjän tai prosessin järjestelmän toiseen toimintoon.
Yleensä kohteena olevasta toiminnosta voidaan valita useita vaihtoehtoja, ja käyttäjän toiminnan tai tapahtuman tietosisällön perusteella sovelluksen läpi valitaan eri reitti.
Käyttäjän näkökulmasta hänet ohjataan sovelluksessa väärään paikkaan tai järjestelmäprosessi yrittää suorittaa väärän prosessin ja menettää synkronointinsa.
Tiedot eivät täsmää
Järjestelmä saattaa jakaa esimerkiksi rahaan, omaisuuden sijaintiin tai johonkin fyysiseen määrään liittyviä tietoja, joiden on täsmättävä kaikissa järjestelmissä.
Esimerkiksi kun varastoon ostetaan ja siirretään 100 tuotetta, jotka myydään, käytetään valmistusprosesseissa, todetaan viallisiksi ja palautetaan tai romutetaan, kussakin alijärjestelmässä olevien tuotteiden määrän on täsmättävä alkuperäiseen 100 kappaleen määrään.
Muunnelma tästä ongelmasta liittyy esimerkiksi järjestelmissä käytettyihin tietoyksiköihin. Laskettujen eräkokojen tai koosteiden on oltava huomioituina, tai järjestelmien on vastattava toisiaan metristen ja brittiläisten mittayksiköiden osalta ja niin edelleen.
Järjestelmiä ei synkronoida
Edellä kuvattuun tiedonsiirto-ongelmaan liittyen siirtoja suorittavat järjestelmäprosessit on ajoitettava toimimaan oikeassa järjestyksessä, asianmukaisesti valtuutettujen prosessien tai henkilöiden käynnistäminä sekä oikea-aikaisesti ja asianmukaisen tapahtuman tai tapahtumien yhdistelmän käynnistäminä.
Jotkin eräajot on suoritettava tunneittain, päivittäin, viikoittain, kuukauden, vuosineljänneksen tai vuoden lopussa ja niin edelleen, ja niitä on valvottava. Monet toiminnalliset käyttäytymismallit riippuvat tapahtumien suhteellisesta ajoituksesta tai tietojen iästä järjestelmien välillä, joten myös nämä on tarkistettava.
Objektit eivät täsmää
Nämä riskit liittyvät objektien lukumäärien, rahan tai fyysisten mittausten sijaan hajautetuissa järjestelmissä olevien objektien tilaan. Esimerkiksi henkilöstötietueessa olevan työntekijän tilan tulisi olla yhdenmukainen kaikissa järjestelmissä, joissa tästä tieto-objektista on kopio. Samasta objektista kopioita sisältävien järjestelmien välillä tilamuutoksia jakavat prosessit on käynnistettävä ja niiden toiminta tarkistettava.
Järjestelmiä ei ole integroitu liiketoimintaan
Järjestelmien toiminnan on oltava synkronoituna käyttäjien tavoitteiden kanssa. Tyypillisiä ongelmia syntyy, kun järjestelmä näyttää puutteellisia, vanhentuneita tai virheellisiä tietoja. Tämän taustalla on yleensä se, etteivät tiedonsiirrot tai synkronoinnit toimi oikein, mutta ongelmat ilmenevät käyttöliittymän kautta.
More Articles
Taustajärjestelmien prosessit eivät tue käyttöliittymää
Tällainen ongelma ilmenee tietoja säilyttävien järjestelmien ja vuorovaikutusjärjestelmien välisenä epäjohdonmukaisuutena. Taustajärjestelmien eräajoja, joita ei suoriteta riittävän usein tai lainkaan, eivät mahdollista tietojen saatavuutta käyttöliittymän vuorovaikutusjärjestelmille. Vastaavasti vuorovaikutusjärjestelmien kautta tehdyt käyttäjätapahtumat eivät heijastu tietoja säilyttäviin järjestelmiin.
Epäjohdonmukaiset käyttöliittymät
Kun liiketoimintaa tai palvelua tarjotaan mobiili-, verkko- ja kioskipohjaisten käyttöliittymien kautta, käyttöliittymä toimii eri tavoin tai epäjohdonmukaisesti. Kaikki käyttöliittymät on voitu testata erikseen, mutta niiden toiminta poikkeaa toisistaan. Esimerkiksi käytössä voi olla erilaiset syötteiden validointisäännöt, eri tietokenttiä voidaan kerätä tai näyttää tai syötteiden järjestys voi olla erilainen.
Lopuksi
Olemme esitelleet integroinnin ja testauksen mallin, jossa koko yrityksen kattava integrointi ja liiketoimintaprosessi ovat keskeisessä asemassa. E2E-lähestymistapa on ainoa, joka edellyttää koko järjestelmän integrointia ja perustaa testit kokonaisiin käyttäjäpolkuihin. Näin sidosryhmät voivat nähdä todisteita siitä, että järjestelmät toimivat oikein realistisessa ympäristössä.
Monet organisaatiot luottavat käyttäjiin, jotka soveltavat hyväksymistesteissään jonkinlaista E2E-testausta ja suorittavat testit manuaalisesti. Kokemukseni perusteella suosittelen järjestelmällisempää, riskeihin perustuvaa lähestymistapaa, joka helpottaa suuren osan työläästä testien suorittamisesta automatisointia.
Kun organisaatiot ottavat käyttöön ketteriä ja dynaamisempia jatkuvan toimituksen kehityskäytäntöjä ja antavat ketterille tiimeille enemmän vastuuta alijärjestelmiensä testauksesta, myöhempi koko yrityksen kattava integrointi- ja hyväksymistestaus jää helposti vähälle huomiolle.
EBPA-lähestymistapa, etenkin automatisoituna, laajentaa jatkuvan integroinnin toimintamallin alijärjestelmistä koko yrityksen liiketoimintaprosessien varmistamiseen.
COTS- ja ERP-paketit mahdollistavat erittäin kyvykkäiden mutta monimutkaisten järjestelmien käyttöönoton pienemmällä kehitystyöllä, mutta integrointiin liittyvät riskit ovat yhtä merkittäviä kuin räätälöityjen ohjelmistojen kehityksessä.
Suuremmissa ympäristöissä ketterät ja jatkuvan toimituksen lähestymistavat ovat yhä suositumpia, joten monimutkaisuuden ja mittakaavan kasvaessa myös toimitusten tiheys ja niihin liittyvät riskit kasvavat.
Ratkaisu on selvä: organisaatioiden on suhtauduttava EBPA:han vakavasti. Niiden on ymmärrettävä integrointiin liittyvät riskit ja se, miten testaus tulee jäsentää niiden käsittelemiseksi. Testaajien on siirryttävä kohti nykyaikaista mallipohjaista lähestymistapaa, abstraktoitava liiketoimintaprosessinsa, järjestelmänsä ja testinsä sekä toteutettava testiautomaatio järjestelmällisesti.
Tilaa The QA Lead -uutiskirje, jotta saat ilmoituksen uusien sarjan osien julkaisusta. Nämä kirjoitukset ovat otteita Paulin testauksen johtamisen kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos osallistut kurssille, käytä eksklusiivista kuponkikoodiamme QALEADOFFER saadaksesi $60 alennusta kurssin täydestä hinnasta!
Suositeltavaa luettavaa: 10 PARASTA AVOIMEN LÄHDEKOODIN TESTINHALLINTATYÖKALUA
