Itsenäisesti hallinnoituvat ohjelmistotiimit käyttävät nykyään laajempaa valikoimaa työkaluja kuin koskaan aiemmin. Tyypillisessä ohjelmistotiimissä voi olla käytössä kaksikymmentä tai jopa kolmekymmentä työkalua. Tässä artikkelissa käsittelemme seuraavia aiheita, jotta sinun olisi helpompi suunnistaa tässä kokonaisuudessa:
- Testauksen työkalut
- Työkaluarkkitehtuuri
- Testauksen hallinta
- Testauksen suunnittelu
- Suljetun vai avoimen lähdekoodin työkalu?
- Työkalun valintaharjoitus
Aloitetaan tarkastelemalla tärkeimpiä testaamiseen käyttämiäsi työkalutyyppejä.
Testauksen työkalut
Testaukseen liittyvät työkalut on kätevää jakaa kolmeen tyyppiin:
- Yhteistyötyökalut: nämä tukevat ideoiden ja vaatimusten kirjaamista, tiimin sisäistä viestintää sekä jonkinasteista integraatiota automatisoituihin prosesseihin ja toisinaan myös botteihin.
- Testaustyökalut: laaja valikoima työkaluja, jotka tukevat testidatan hallintaa, testauksen suunnittelua, yksikkötestauskehyksiä, toiminnallisten testien suorittamista, suorituskyky- ja kuormitustestausta, staattista testausta, testausprosessin hallintaa, testitapauksia sekä testien kirjaamista ja raportointia.
- DevOps- tai infrastruktuurin hallintatyökalut: nämä työkalut tukevat ympäristöjen ja alustojen hallintaa, käyttöönottoa infrastruktuurina koodin ja konttiteknologioiden avulla sekä tuotantolokien kirjaamista, valvontaa ja analytiikkaa.
The Tools Knowledge Base on verkkopohjainen työkalurekisteri, joka eroaa useimmista verkkorekistereistä siinä, että sen kattavuus ulottuu yhteistyö-, testaus- ja DevOps-työkaluihin. Näillä kolmella alueella on yli 1 700 työkalua. Työkalujen verkkosivut on indeksoitu, ja niistä voi tehdä hakuja.
Sivusto kokoaa ja indeksoi myös yli 300 bloggaajaa, ja yli 52 000 blogia on indeksoitu ja haettavissa. Olemme koonneet URL-osoitteet tärkeimpiin työkaluluokkiin sekä näiden luokkien blogihakujen pikahakuihin.
Yhteistyötä, testausta ja DevOpsia tukevia työkaluja on yli 1 700.
Palaamme testauksen hallintaan vaikuttaviin ja sitä tukeviin tärkeimpiin kysymyksiin myöhemmin tässä artikkelissa.
Have an account? Log In
Työkaluarkkitehtuuri
Alla olevassa kuvassa olemme tunnistaneet useimmat nykyaikaiset ohjelmistotiimit käyttämät työkalutyypit. Olemme erotelleet työkalut, joita yleensä käytetään kehitys-, testaus- ja tuotantoympäristöissä.
Näiden työkalujen perustana ovat infrastruktuurityökalut , jotka tarjoavat ympäristöjen isännöintiin tarvittavat alustat, virtuaalikoneet ja kontit, sekä automaattisia käyttöönottoja suorittavat työkalut. Käyttöönottojen ja julkaisujen hallintaan käytettäviä työkaluja kutsutaan julkaisujen ja putkien orkestrointityökaluiksi. Tiimin sisäistä viestintää sekä viestintää monien automatisoitujen prosessien kanssa hallitaan yhteistyö- tai ChatOps-työkaluilla.
Vaikka siirtyminen DevOpsiin edistää jatkuvaa kehitystä tukevien työkalujen kehittämistä ja käyttöönottoa, lähes kaikki nämä työkalut ovat hyödyllisiä mille tahansa ohjelmistokehitys- tai operointitiimille.
Sinun ei tarvitse edustaa DevOps-kulttuuria käyttääksesi ”DevOps”-työkaluja.
Testauksen hallinta
Testinhallintatyökalut ovat välttämättömiä kaikissa laajoissa projekteissa. Ketterissä projekteissa käytetään yleensä tapahtumienhallintatyökalua ja testien osalta luotetaan jossain määrin käyttäjätarinoiden ja skenaarioiden käyttöön keskeisten esimerkkien, ellei kaikkien testien, seuraamisessa. Testinhallintatyökalujen laajuus vaihtelee hyvin yksinkertaisista ratkaisuista, kuten Microsoft Excelistä, kattaviin sovelluksen elinkaaren hallinnan (ALM) tuotteisiin.
Yleisesti ottaen testinhallintatyökalujen käyttöalueet kattavat useita osa-alueita:
Testikattavuusmalli: Useimmissa testinhallintatyökaluissa voidaan määrittää joukko vaatimuksia, joihin testitapaukset ja/tai testien tarkistukset yhdistetään. Nämä vaatimukset voivat joskus olla hierarkkisia asiakirjan sisällysluettelon tapaan. Yhä useammin voidaan tallentaa myös muita malleja, kuten käyttötapauksia tai liiketoimintaprosessien työnkulkuja. Testisuunnitelman ja testien suorittamisen kattavuusraportit ovat yleensä saatavilla.
Testitapausten hallinta: Testitapauksia ja niiden sisältöä voidaan hallita testien dokumentoidun rekisterin ylläpitämiseksi. Testitapausten sisältö voidaan valmistella ennen testausta tai kirjata suoritettujen testien perusteella. Testitapaukset voivat olla vapaamuotoista tekstiä tai jäsenneltyjä vaiheiksi, joilla on odotetut tulokset. Asiakirjojen ja kuvien tuominen testien tai vaiheiden yhteyteen on yleistä.
Testien suorittamisen suunnittelu: Testit voidaan järjestää hierarkiaksi tai merkitä tunnisteilla dynaamisemman rakenteen luomiseksi. Testiryhmän jäsenille voidaan määrittää testejä. Testien suunniteltuja kestoja voidaan käyttää synkronoidun aikataulun julkaisemiseen koko ryhmän suoritettavista testeistä. Testien osajoukkoja voidaan valita vaatimusten kattavuuden saavuttamiseksi, valittujen ominaisuuksien testaamiseksi ja regressiotestijoukkojen suorittamiseksi uudelleen. Suoritettaviksi voidaan valita myös testit, jotka on kirjattu suorittamattomiksi, estyneiksi, epäonnistuneiksi tai joilla on jokin muu tila.
Testien suorittaminen ja kirjaaminen: Kun ryhmä suorittaa testejä, testien tila kirjataan. Kaikista suoritetuista testeistä kirjataan testaaja sekä päivämäärä, kellonaika ja kesto. Hyväksytyille testeille voidaan määrittää yksinkertainen hyväksytty-tila. Epäonnistuneisiin, estyneisiin tai poikkeaviin testituloksiin voidaan liittää näyttökuvia ja testituloksia sekä määrittää tapahtumaraportti. Monet työkalut tarjoavat liittymiä testien suorittamiseen tarkoitettuihin työkaluihin, jotka hallitsevat testejä ja suorittavat niitä, kirjaavat tuloksia ja jopa luovat tapahtumaraporttien luonnoksia.
Tapahtumienhallinta: Testien epäonnistumiset kirjataan suorituslokiin. Ne edellyttävät yleensä lisätutkimuksia, virheenkorjausta ja korjaamista silloin, kun epäonnistuminen johtui ohjelmistovirheestä. Lisätutkimuksia edellyttävät epäonnistumiset kirjataan yleensä tapahtumina, havaintoina tai virheraportteina. Tapahtumaraportteihin voidaan tallentaa suuri määrä tukitietoja. Tapahtumille määritetään yleensä tyyppi, testattava kohde, prioriteetti ja vakavuus. Jotkin yritykset kirjaavat valtavan määrän tietoa ja yhdistävät sen kehittyneeseen tapahtumienhallintaprosessiin.
Raportointi: Kaikista edellä mainituista ominaisuuksista voidaan laatia raportteja ja analyyseja tarpeen mukaan. Raporttien valikoima vaihtelee suunnitellusta ja toteutuneesta testikattavuudesta tapahtumaraporttien tilaan, jolla seurataan avoinna olevia tutkimuksia, korjaustöitä ja uudelleentestausta, sekä eri epäonnistumistyyppien korjaamiseen kuluvan ajan analyyseihin ominaisuuden, vakavuuden ja kiireellisyyden mukaan ja niin edelleen.
Maailman suosituin testinhallintatyökalu on edelleen Microsoft Excel.
Testisuunnittelu
Testisuunnittelu perustuu malleihin. Järjestelmä- ja hyväksymistestaajien tapauksessa tyypillisiä malleja ovat vaatimusasiakirjat, käyttötapaukset, vuokaaviot tai uimaratakaaviot. Myös teknisemmät mallit, kuten tilamallit, yhteistyökaaviot, sekvenssikaaviot ja muut vastaavat, tarjoavat vankan perustan testisuunnittelulle.
Monissa projekteissa malleja käytetään vaatimusten tai korkean tason suunnitelmien tallentamiseen. Kun ne ovat testaajien saatavilla, niitä voidaan käyttää kattavuuskohteiden poimimiseen jäljittämällä polkuja suoraan mallista. Jos tällaisia malleja ei ole saatavilla, testiryhmän kannattaa usein tallentaa esimerkiksi prosessien vuokaavioita tai uimaratakaavioita. Ne auttavat testaajia käymään merkityksellisempiä keskusteluja sidosryhmien kanssa erityisesti kattavuusmenetelmästä keskusteltaessa.
Omistettujen ratkaisujen alueella on syntymässä työkaluja, joiden avulla esimerkiksi vuokaavioita voidaan tallentaa ja käyttää testitapausten luomiseen jäljittämällä polkuja jonkin kattavuustavoitteen mukaisesti, kuten kaikki linkit, kaikki prosessit, kaikki päätösten lopputulokset, kaikki parit tai kaikki polut. Nämä työkalut voidaan yhdistää testidatan hallinta- ja generointityökaluihin testidatayhdistelmien luomiseksi manuaalisia tai automatisoituja testejä varten.
On myös työkaluja, joiden avulla mallintaminen voidaan tehdä testien suorittamiseen tarkoitetuissa työkaluissa. Esimerkiksi näiden työkalujen avulla testisuunnittelija voi tallentaa kaikki verkkosivun kentät, luoda linkkejä kenttien yhdistämiseksi ja luoda sivulle navigointimallin – kaiken tämän graafisessa muodossa.
Mallia käytetään sitten navigointipolkujen luomiseen ja sellaisen testikokonaisuuden muodostamiseen, joka täyttää tietyt kattavuuskriteerit – aivan kuten edellä mainituissa mallinnustyökaluissa. Nämä suoritusympäristöt voivat luoda automatisoituja testipolkuja valittujen kriteerien avulla tai tuottaa niitä satunnaisesti. Ne voivat myös raportoida näiden mallien mukaisen kattavuuden.
Tämä on tällä hetkellä dynaaminen alue – seuraa mallinnustyökaluja, jotka tukevat testisuunnittelua ja testien generointia, sekä suoritusympäristöjä, jotka tukevat testattavan järjestelmän mallintamista, automatisoitua testipolkujen valintaa ja raportointia.
More Articles
Omistettu vai avoimen lähdekoodin ratkaisu?
Viimeisten kahdenkymmenen vuoden aikana ilmaisten ja avoimen lähdekoodin ohjelmistojen (FOSS) käyttö erityisesti infrastruktuurin ylläpitämiseen on ollut laajaa. Microsoftin käyttöjärjestelmälisenssien ja niihin liittyvien verkkopalvelinohjelmistojen käyttökustannukset sekä yleinen näkemys siitä, että Linux/Unix on luotettavampi ja turvallisempi kuin Windows, tarkoittavat, että Linux/Unix on monissa ympäristöissä palvelinten ensisijainen käyttöjärjestelmä.
Vaikka artikkelissa käsitellään avoimen lähdekoodin ja omistusoikeudellisten työkalujen hyviä ja huonoja puolia, jos etsit erityisesti Jiran kanssa hyvin integroituvia ratkaisuja, kattava oppaamme aiheesta Jira-kohtaiset testinhallintatyökalut voi auttaa sinua tekemään perustellun päätöksen.
Alla olevat kaksi taulukkoa (päivitetään päivittäin w3techs.com-sivustolla) esittävät käyttöjärjestelmien ja verkkopalvelintuotteiden suhteellisen suosion. Noin 85 % sivustoista käyttää tunnetuimpia avoimen lähdekoodin verkkopalvelintuotteita, Apachea ja Nginxiä.
Näiden FOSS-infrastruktuurituotteiden suosio osoittaa, että avoimen lähdekoodin tuotteet voivat olla vähintään yhtä luotettavia kuin omistusoikeudelliset tuotteet tai jopa luotettavampia.
Ohjelmistotiimille, joka tarvitsee kaksikymmentä tai kolmekymmentä ohjelmistotyökalua toimintansa tueksi, on saatavilla luotettavia ja toimivia FOSS- ja omistusoikeudellisia työkaluja jokaiseen tehtävään. Miten valitset omistusoikeudellisen ja FOSS-tuotteen välillä?
Alla oleva taulukko tiivistää joitakin seikkoja, joita saatat pohtia valitessasi työkalutyyppiä.
| Omistusoikeudellinen | FOSS | |
| Saatavuus | Työkaluja on saatavilla kaikille osa-alueille. | Jotkin osa-alueet, erityisesti kehitys- ja infrastruktuurityökalut, ovat paremmin tuettuja kuin toiset. |
| Hankintakustannus | Usein kallis, erityisesti ”yritystuotteet”. | Ilmainen tai yhteisökäyttöön tarkoitettu lisenssi ilman kustannuksia. Yritys- tai isännöidyille versioille voi olla saatavilla kaupallisia lisenssejä. |
| Dokumentaatio | Yleensä erittäin hyvä. | Vaihtelee. Joskus erinomainen, joskus olematon ja kaikkea siltä väliltä. Ohjelmoijat kirjoittavat sen usein ohjelmoijille, joten se on vähemmän käyttökelpoinen kuin kaupallisten tuotteiden dokumentaatio. |
| Tekninen tuki | Erittäin hyvä, mutta maksullinen. | Vaihtelee. Jotkin työkalujen kehittäjät tarjoavat erinomaista tukea ja jopa lisäävät ominaisuuksia pyynnöstä. Monilla työkaluilla on verkkofoorumeita – mutta keskustelu voi olla hyvin teknistä. Muiden työkalujen tuki on heikkoa. |
| Luotettavuus/laatu | Yleensä erittäin hyvä. | Vaihtelee. Tuotteet, joilla on paljon käyttäjiä, kieli- ja alueversioita sekä suuret tukitiimit, ovat yleensä erinomaisia. Yksittäisten henkilöiden kirjoittamat työkalut, joilla on vähän osallistujia ja käyttäjiä, voivat olla epävakaita. |
| Ominaisuuksien monipuolisuus | Ominaisuudet noudattavat yleensä julkaistuja tuotesuunnitelmia ja ovat tavallisesti kattavia. | Tuotteet kehittyvät yleensä käyttäjien tarpeiden ja osallistujatiimin koon perusteella. Osallistujat lisäävät yleensä tarvitsemiaan ominaisuuksia esimerkiksi asiakaskyselyiden sijaan. |
| Julkaisu-/korjaustiheys | Suurten versioiden julkaisemisen väli on yleensä kuukausia ja joskus vuosia. Korjausversioita julkaistaan säännöllisesti. Varoitukset ja julkaisutiedotteet ovat yleensä erittäin hyviä. | Vaihtelee. Suurten infrastruktuurituotteiden pääversiot julkaistaan kuten omistusoikeudellisissa tuotteissa. Pienemmät ja vähemmän suositut tuotteet julkaistaan yleensä useammin. Varoituksia annetaan vähän tai ei lainkaan, julkaisutiedotteet ovat heikkoja ja taaksepäin yhteensopivuus saattaa ajoittain kadota. |
FOSS-tuotteet voivat olla edullisempia hankkia, mutta muut kustannukset ja vastuut voivat olla merkittäviä. Ratkaiseva tekijä näiden kahden välillä on yleensä yhdistelmä kulttuuriasi, riskinottohaluasi ja teknistä kyvykkyyttäsi.
Kun ostat omistusoikeudellisia tuotteita ja tukisopimuksia, yhteensopimattomuuteen (muiden tuotteiden kanssa), luotettavuuteen, helppokäyttöisyyteen ja tarkkaavaiseen tekniseen tukeen liittyvät riskit ovat yleensä pieniä, vaikka kustannukset voivatkin olla korkeat.
FOSS-tuotteiden kanssa sinun on yleensä tehtävä paljon perusteellisempaa tutkimusta ennen kuin sitoudut käyttämään jotakin niistä. Eihän käytettävissäsi ole myyjää, jonka kanssa keskustella, ja dokumentaatio voi olla informatiivisen sijaan lähinnä toiminnallista. Kokeilujakson käyttöönotto on tietenkin helppoa ja voit ottaa käyttöön niin monta työkalua kuin haluat, mutta sinun on tutkittava perusteellisemmin työkalun ominaisuudet.
Heikompi käytettävyys ja yhteensopimattomuus nykyisten työkalujesi kanssa voivat aiheuttaa ongelmia, joten saatat joutua kirjoittamaan rajapintaohjelmistoja tai laajennuksia sekä raportointi- tai tietojen tuonti- ja vientiapuohjelmia.
Lisäksi sinun on koulutettava itsesi ja tiimisi, jotta pääsette ajan tasalle, ja yleensä huolehdittava ohjelmiston tuesta itse. Tiimisi tuntee kuitenkin työkalun toiminnan perusteellisemmin ja pystyy suurelta osin tukemaan itse itseään.
FOSS-työkalu voisi auttaa sinua hankkimaan kokemusta uudenlaisesta työkalutyypistä pienin kustannuksin. Tämän kokemuksen ansiosta sinulla olisi paremmat valmiudet valita pitkällä aikavälillä suljetun lähdekoodin työkalu.
Työkalun valintaharjoitus
Jos etsit testienhallintatyökalua tukemaan nykyistä tai tuttua äskettäistä projektiasi ja sovellustasi, laadi yllä olevassa testienhallintatyökaluja käsittelevässä keskustelussa mainittujen ominaisuusalueiden perusteella luettelo 15–20 ominaisuudesta, jotka ovat joko:
- Pakollisia
- Toivottavia
Luettelo voi sisältää toiminnallisia ominaisuuksia, integraatioita, helppokäyttöisyyteen keskittymisen, tuen, suuren käyttäjäkunnan tai verkkokeskustelupalstat ja usein kysytyt kysymykset. Jos sinulla on jo työkalu käytössä, älä valitse sitä.
Etsi vaatimustesi tekstin avulla Työkalujen tietokanta -tietokannasta kolme työkalua (mukaan lukien suljetun lähdekoodin tuote ja FOSS-tuote), jotka vaikuttavat vastaavan vaatimuksiasi. Luo työkalujen ominaisuuskuvausten perusteella kolmen tuotteen ominaisuusvertailutaulukko. Lisää neljäs sarake tosiasiassa käyttämällesi työkalulle vertailua varten.
- Miten työkalut vertautuvat toisiinsa ominaisuuksien osalta?
- Mitä ominaisuuksia FOSS-työkaluista puuttuu suljetun lähdekoodin työkaluihin verrattuna?
- Kuinka monta työkalua on olemassa, jotka täyttävät vaatimuksesi suurin piirtein?
- Kuinka kauan uskot tarvitsevasi käyttää aikaa työkalujen tutkimiseen, jotta voisit laatia esimerkiksi kolmen työkalun esivalintalistan?
Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uusia osia julkaistaan. Nämä kirjoitukset ovat otteita Paulin Testauksen johtamisen kurssilta — suosittelemme sitä lämpimästi kaikille, jotka haluavat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos päätät osallistua, käytä ainutlaatuista kuponkikoodiamme QALEADOFFER saadaksesi 60 dollaria alennusta kurssin täydestä hinnasta!
Opi muiden testaajien kokemuksista kuuntelemalla podcastejamme tai tutustumalla blogeihimme. Tässä on yksi, josta uskomme sinun oppivan paljon: MITEN TESTAUSTAIDOT TEKIVÄT MINUSTA PAREMMAN AUTOMAATIOKEHITTÄJÄN
