This is a Test Management Tutorial for Software Testing. Se sisältää testauksen Hallintavaiheet, Työkalut ja testauksen hallinnan Vs organisaatiorakenne:
testauksen hallinta on prosessi, jossa hallitaan kaikkia testiin liittyviä toimintoja, dokumentteja ja muuta siihen liittyvää työtä. Organisaatiorakenteilla tarkoitetaan tietyissä projekteissa työskentelevien ryhmien tai työntekijöiden hierarkiaa.
vaikuttaako organisaatiorakenne testauksen hallintaan?
jos vastauksesi on ei, katsotaan miksi? Jos kyllä, katsotaan, miten se vaikuttaa. Löytääksemme näiden kahden välisen suhteen meidän on ymmärrettävä nämä aiheet selkeästi ja tutkittava sitten Testijohtamisen ja organisaatiorakenteen välistä suhdetta.
Johdatus testauksen hallintaan
testauksen hallinta tarkoittaa tietyn projektin koko ohjelmistotestausprosessin hallintaa. Testauksen hallintaprosessia sovelletaan koko ohjelmistokehityksen elinkaareen. Siksi ihanteellista on, että heti kun ohjelmistokehitysprosessi alkaa, myös testauksen hallintaprosessi pitäisi aloittaa.
Testipäälliköllä oli seuraavat tehtävät-
- Testipäällikön tulee varmistaa näiden työtuotteiden johdonmukaisuus ja laatu.
- työskentele Testianalyytikon ja teknisen Testianalyytikon kanssa sopivan mallin valitsemiseksi ja räätälöimiseksi.
- työskentele Test Analyst ja Technical Test Analyst kanssa luodakseen standardit näille tuotteille, kuten yksityiskohtaiset tasot.
- käy työn tuotteet läpi soveltuvia tekniikoita käyttäen.
testauksen Hallintakomponentit
testauksen hallinta on jaettu 5 osaan paremman ymmärryksen saavuttamiseksi:
- Testidokumentaatio
- testin estimointi
- Testimittarit
- testin edistymisen mittaaminen
- testauksen elinkaaren seuranta
#1) Testidokumentaatio
alla on lueteltu kolme erilaista Testidokumentaatiota:
- Testipolitiikka
- Testistrategia
- yleinen Testisuunnitelma
#1) Testauspolitiikka:
- tiivistää arvon, jonka organisaatio saa testauksesta.
- määrittelee testauskäytännöt.
- kuvaa, miten testauksen tehokkuutta arvioidaan.
- kuvaa Testiprosessia.
- miten organisaatio aikoo parantaa Testiprosessia?
#2) testausstrategia:
- kuvataan Yleiset testausmenetelmät, joita käytetään projekti-ja Tuoteriskien hallintaan.
- Analyyttiset Strategiat: Kuten Riskiperusteinen Testaus.
- Mallipohjainen Strategia: Kuten toimintaprofiili, jossa testiryhmä kehittää mallin, joka perustuu todellisiin ja hyväksyttyihin ympäristö -, syöttö-ja olosuhteisiin.
- Menetelmästrategia: laatuominaisuudet, joissa testiryhmä käyttää testiolosuhteiden sarjaa, tarkistuslistaa tai yleistettyjen loogisten testien kokoelmaa.
- Process or Standard-Compliant techniques: seuraa prosessin joukkoa, kuten SCRUM/Agile.
- reaktiiviset strategiat: käyttäen vikaan perustuvia hyökkäyksiä, kuten EKSPLORATIIVISTA testausta.
- Neuvoa-Antava Strategia: Kuten käyttäjän ohjaama testaus, jossa testiryhmä luottaa yhden tai useamman sidosryhmän panokseen testiolosuhteiden määrittämisessä, kuten ulkoistettu Yhteensopivuustestaus.
- kuvaa myös:
- Integrointimenettelyt
- testaustekniikat
- testauksen riippumattomuus
- pakolliset ja vapaaehtoiset standardit
- testiympäristö
- Työkalut
- ohjelmistotuotteiden uudelleenkäytettävyys
- uusintatestaus ja regressio.
#3) Päätestisuunnitelma:
- se kattaa kaikki tarvittavat testaustehtävät.
- siinä käsitellään sitä, miten testaus toteuttaa Testistrategiaa ja-politiikkaa.
- jos jotain ei ole kuvattu, Testisuunnitelmassa on kuvattava syy ja lieventämissuunnitelma.
- testaussuunnitelman sisältö on:
- testattavat kohteet
- testattavat laatuominaisuudet.
- aikataulu
- Toteutussykli
- Toteutussykli
- puutteelliset muuttujat
- testikohteet
- Poistumiskriteerit
- hankkeen riskit
- testaustoimien yleinen hallinnointi,
- roolit ja vastuut
- panos ja tuotos
#2) testin estimointi
Yleiset pisteet:
- on johdon toiminta
- se perustuu kokemukseen.
- se sisältää tarkan ja yksityiskohtaisen luettelon kustannuksista, resursseista, tehtävistä ja ihmisistä.
- arviointi on toimitettava johdolle perusteluineen.
- lopullinen arvio kuvaa organisaation ja hankkeen tavoitteiden parasta mahdollista tasapainoa.
- arvio perustuu tuolloin saatavilla olleisiin tietoihin, se laadittiin.
- jotta arviot pysyisivät täsmällisinä, ne olisi päivitettävä vastaamaan uusia ja muuttuneita tietoja.
testin estimointiin vaikuttavat tekijät:
- vaadittu laatutaso
- järjestelmän koko
- Historiatiedot
- Prosessitekijät, kuten strategia, kehitys ja elinkaari
- Materiaalitekijät, kuten testiympäristö, Automaatio, Työkalut ja tiedot
- Henkilötekijä
- prosessin monimutkaisuus
- koulutus ja kt(tiedon siirto)
- uusien työkalujen ja teknologian, prosessin tai tekniikoiden omaksuminen ja kehittäminen.
- vaatimus tarkemmasta Testieritelmästä.
- komponenttien saapumisen ajoitus
- testitulokset.
arvauksia:
- Työnjakorakenne
- tiimin Estimointisessio
- testaajan ja kehittäjän suhde
- Organisaatiohistoria
- Funktiopisteanalyysi, LOC.
testin estimointia selitetään tarkemmin myöhemmin opetusohjelmassa.
#3) Testimittarit
- mitä mitataan, katsotaan tehdyksi?
- mikä ei mittaa, onko helppo jäädä huomiotta?
- on määriteltävä rajallinen joukko hyödyllisiä mittareita.
- pitäisi määritellä vain ne mittarit, joiden tulkinnasta kaikki ovat yhtä mieltä.
- mittareiden raportointi ja yhdistäminen tulisi automatisoida.
- isännöitsijän tulee validoida tiedot metrijärjestelmänä.
hankkeen metriikka: % hyväksytyistä, hylätyistä jne.
Tuotemetri:
- Tuotteen ominaisuudet
- deficit Density
Process Metric: Measures capability of testing like % of the deficit.
ihmiset: yksilön kyvyt.
Testin Etenemismittari:
- testiolosuhteiden/ – tapausten lukumäärä, suunniteltu vs toteutettu.
- kokonaisvika luokiteltu Vakavuusasteen, prioriteetin, nykytilan ja vaikutusten mukaan.
- vaadittujen, hyväksyttyjen, koottujen ja testattujen muutosten määrä.
- suunniteltu vs toteutuneet kustannukset.
- suunniteltu vs todellinen kesto
- suunniteltu vs todellinen testauksen virstanpylväs.
- Tuotteen Laaturiskitilanne
- % testiponnistuksen, kustannusten tai ajan menetys.
#4) testauksen edistymisen mittaus
Tuoteriskit:
- % katetut riskit.
- % epäonnistumisriskistä
- % yksilön tunnistamasta riskistä.
viat:
- todettujen vikojen lukumäärä vs. ilmoitettujen vikojen lukumäärä.
- vikojen keskimääräinen saapumisaika
- yksittäisten testattavien kohteiden viat.
- RCA: n toteaminen(Perussyyanalyysi)
- vika on Testijulkaisuissa.
- vika vaiheessa
- tärkeys ja vakavuus
- raportti hylätään vs kaksoiskappale
- aika, joka on kulunut
- vanhojen vikojen korjaamisesta aiheutuneiden uusien vikojen määrä.
testi:
- testitulosten kokonaismäärä
- Regressiotestien kokonaismäärä.
kattavuus:
- vaatimuksen ja suunnittelun kattavuus
- riskien kattavuus
- Ympäristöasetusten kattavuus
- koodin kattavuus
#5) mittarit, joilla seurataan testauksen elinkaarta
Monitoritestisuunnitelma
- riskin ja vaatimuksen määrä
- vian löytyminen
- suunnitelma vs todelliset ponnistelut.
Monitor Test Design
- suunnittelun aikana havaittujen vikojen määrä.
Monitor Test Analysis
- tilojen lukumäärä
- virheiden määrä analyysissä
Monitor Test Implementation
- % ympäristön konfiguraatio
- % testitapauksesta automatisoitu.
monitorin suoritus
- % hyväksytyistä, epäonnistuneista, ajamattomista, estetyistä testitapauksista
- % käsitellyistä Testitapauksista
- suunnitellut vs toteutuneet viat ratkaistu
- % suunnitelmasta vs toteutunut kattavuus
näytön sulkeminen
- % hyväksytyistä testitapauksista ail
- % testitapauksista, jotka tarkastettiin uudelleenkäytettävään luokkaan
- % automatisoiduista Testitapauksista.
- korjattujen/korjaamattomien vikojen lukumäärä.
- % testituloksesta
alla käsitelty testin seuranta-ja valvontavaihe selittää tarkemmin tätä aihetta.
testauksen Hallintavaiheet
testauksen hallintaprosessin aikana on otettava huomioon seuraavat seikat. Toisin sanoen seuraavat ovat testauksen hallintaprosessin eri vaiheet:
- riskianalyysi
- testin estimointi
- testin suunnittelu
- Testiorganisaatio
- testien seuranta ja valvonta
- asioiden hallinta
- testausseloste
voit huomaa, että neljä ensimmäistä vaihetta ovat enemmän suunnittelua ja loput kolme toteutusta. Näin ollen voimme jakaa koko testauksen hallintaprosessin kahteen osaan eli suunnitteluun ja toteutukseen.
Tutkitaanpa yksityiskohtaisesti eri Testinhallintavaiheita.
#1) riskianalyysi
tässä vaiheessa selvitetään riskitekijät ja mahdolliset ratkaisut. Jos riskianalyysi tehdään perusteellisesti, voimme välttää tulevat epäonnistumiset tai ainakin jonkinlainen ratkaisu saattaa olla saatavilla.
riski on jotain, mitä voi tapahtua tai ei. Mutta jos se tapahtuu, mikä on sen vaikutus? Se voi vaikuttaa pahasti ohjelmistojen laatuun, yrityksen maineeseen ja paljon muuta.
riskitekijät on selvitettävä tämän huonon vaikutuksen välttämiseksi. Riskitekijöiden selvittämiseksi on tehtävä riskianalyysi. Riskejä on kahdenlaisia, ts. Projekti-ja Tuoteriskit. Projektiriskit ovat työprosessiin liittyviä riskejä ja Tuoteriskit kehitettyyn tuotteeseen liittyviä riskejä.
#2) testin estimointi
testin estimointi tarkoittaa kunkin testiaktiivisuuden/ – vaiheen vaatiman ajan ennustamista. Koska tämä on arvio, se ei voi olla tarkka. Paremman testiarvion saamiseksi voimme tutkia yrityksemme aiempia projekteja tai kuulla tiimimme jäseniä, jotka ovat vastuussa kyseisestä työstä tai testivaiheesta.
#3) Testisuunnittelu
itse Testisuunnittelu on pitkä prosessi. Se sisältää testitavoitteiden määrittelyn, testin laajuuden, testistrategian, aikataulutuksen, resurssit, viestinnän lähestymistavan jne. Vaatimusten olisi oltava hyvin selkeitä testitavoitteiden ja-laajuuden määrittelemiseksi. Testisuunnitelma on tarkoitettu testaajille, käyttäjille ja projektiryhmän jäsenille.
testaussuunnitelmassa kuvataan testauksen rooli projektissa. Testisuunnitelma sisältää myös roolit ja vastuut, luettelon ominaisuuksista, joita testataan ja joita ei testata, testausympäristön, luettelon työkaluista ja oletuksista, jos sellaisia on.
#4) Testiorganisaatio
testauksen suunnitteluvaiheessa olemme suunnitelleet kaikki mahdolliset asiat testauksesta.
siksi tarvitsemme osaavia tiimiläisiä toteuttamaan tätä suunnitelmaa tai tekemään siitä onnistuneen. Testiorganisaatiossa on kyse täydellisen testitiimin rakentamisesta onnistuneeseen projektiin.
#5) testauksen seuranta ja valvonta
testauksen ollessa kesken tai testaajien suorittaessa testaussuunnitelmaa kaikkien näiden töiden edistymistä on seurattava. Pitäisi seurata kaikkea tätä testaustyötä. Jos testiseuranta tehdään, niin testitiimi ja testipäällikkö saavat palautetta testauksen etenemisestä?
tämän palautteen avulla testipäällikkö voi ohjata tiimin jäseniä parantamaan testaustyön laatua. Testiseurannan avulla projektiryhmä saa näkyvyyttä testituloksista. Auttaa myös tietää testin kattavuus.
isoissa projekteissa testiseuranta tehdään automatisoidulla työkalulla, sillä tiedonkeruu helpottuu. Pienissä projekteissa yksi henkilö kerää kaikki testauksen etenemiseen liittyvät tiedot tai dokumentit. Testauksen etenemistietojen keräämiseen Voimme käyttää apuna IEEE 829-testilokimallia. Kyse oli testien seurannasta.
katsotaanpa, mitä Testiohjaus on? Projektityö ei aina mene niin kuin olemme suunnitelleet. Suunnitelman ja varsinaisen työn välillä saattaa olla eroja. Minimoidaksemme tai poistaaksemme nämä erot, meidän on tehtävä joitakin muutoksia ja siten ohjaamme testityötä.
#6) Issues Management
Issues voi olla mikä tahansa ohjelmistokehitys-ja testausprosessin aikana ilmenevä ongelma. Se voi olla pienin syy, jonka vuoksi emme pysty kehittämään/toimittamaan laadukasta tuotetta. Jotkut asiat ovat tulppa, eli ratkaisematta tätä kysymystä emme voi jatkaa jatkoprosessia.
Issue management on kyse siitä, miten käsittelemme näitä asioita/ongelmia. Voimme kutsua sitä myös tapahtumien hallinnaksi. Ongelmien hallinta edellyttää ongelmien ratkaisuprosessin parempaa suunnittelua. Parempi ongelmien hallinta riippuu testauspäällikön taidoista ja kokemuksesta.
miten nämä ongelmat ilmenevät?
ongelman puhkeamiseen voi olla useita syitä. Osa asioista liittyy strategiaan ja osa määrittelyyn, henkilöstöhallintoon, aikatauluihin jne.
Strategiakysymykset:
esimerkit:
- hankkeelta loppuvat varat.
- Projektiviestintä oli heikkoa.
- projektinhallintaprosessi ei ole mainittujen standardien mukainen.
Määritelmäasiat: vaatimuksiin liittyvät asiat.
esimerkkejä: epäselvät vaatimukset. Epäselvien vaatimusten vuoksi voidaan ottaa käyttöön paljon asioita.
aikatauluongelmat: tämä on yleisin ongelmakohde. Työntekijät joutuvat kamppailemaan aikarajan täyttämiseksi.
henkilöstöasiat:
esimerkit:
- joukkueesta puuttuu taitoa.
- väärä työntekijän kartoitus työhön.
asioita voi olla paljon enemmänkin, emmekä voi mainita niistä kaikkia tässä. Näin ongelmanhallinta on kirjaamista, seurantaa ja ongelmien ratkaisemista.
#7) Testiraportti
Testiraportti auttaa tunnistamaan testin kattavuuden, kehitetyn tuotteen laadun ja vaaditut prosessiparannukset. Voimme päättää, kuinka paljon testausta tarvitaan.”
jos testausta tehdään riittävästi, voimme toimittaa tämän testiraportin sidosryhmille tai asiakkaille. Jotta he myös tutustuvat tuotteen laatuun ja saavat käsityksen siitä, kuinka paljon tuotetta testataan.
testauksen hallintatyökalut
testauksen hallinta monimutkaistuu, kun etenemme ohjelmistokehitysprosessissamme ja se on yksi tärkeimmistä syistä, joiden vuoksi testauksen hallintatyökaluja on nykyään saatavilla niin paljon.
nämä työkalut auttavat testauksen hallintaprosessin neljässä viimeisessä vaiheessa (Testiorganisaatio, testauksen seuranta & valvonta, asioiden hallinta ja Testiraportti). Koska nämä työkalut auttavat testauksen hallinnan tärkeissä vaiheissa, ne on otettava ensimmäisenä huomioon hankkeessa.
alla listatut ovat suosituimmat Testinhallintatyökalut:
- qTest
- Praktiest
- Zephyr
- Koekollabi
- Jiran Testiflo
- XQual
- Xray – Huipputestin hallinta
- testrail
- qacoverage
- Jiran (RTM) vaatimukset ja testauksen hallinta
- Spiratest by Inflectra
- Kualitee
- Aqua
- Testipad
- Junoone
=> Klikkaa tästä saadaksesi tarkempia arvioita TOP Test Management Tools
Organizational Structures
Let ’ s see the different organizational structures.
organisaatiorakenteille voi olla tiettyjä sääntöjä tai ideaalisia rakenteita, mutta siitä huolimatta jokaisella organisaatiolla voi olla rakenteensa. Organisaatiorakenteita on niin paljon, ja jokaisella on omat etunsa ja haittansa.
tässä käsitellään joitakin niistä.
ensiksi näemme yksinkertaisimman organisaatiorakenteen, jota käytetään pienissä hankkeissa.
tässä rakenteessa sekä testaajat että ohjelmoijat raportoivat Kehityspäällikölle.
- kehityspäälliköllä on hyvä kontrolli projektitoimintaan.
- testaus-ja kehitystiimien välisen kommunikaatiokuilun mahdollisuus vähenee.
- myös kokouksissa on hyvä päättää kehityspäällikön määräajoista, sillä hänellä on täysi tietämys testaus-ja kehitystyöstä.
- tiimityöskentely on tehokasta, koska kerrokset ovat vähissä.
tämän rakenteen haittoja ovat:
- koska testauspäällikköä ei ole, on mahdollista, että testausta pidetään projektin loppuvaiheessa.
- on toinenkin mahdollisuus, että testauksen merkitys hankkeelle vähenee. Sitä voidaan pitää hankkeen myöhäisenä aikana.
yleensä pienissä organisaatioissa pienissä projekteissa käy niin, että kehitystiimi vie enemmän aikaa kuin on mainittu ja testitiimi joutuu kärsimään eli testiryhmän on testattava tuote määräaikaan mennessä, jolloin testiryhmä saa vähemmän aikaa testata tuotetta.
tässä rakenteessa kehityspäällikön on pidettävä mielessä, että hänen tavoitteenaan ei ole vain saattaa projekti loppuun, vaan kehittää laadukkaita ohjelmistoja.
toiseksi yleisimmin käytetty organisaatiorakenne:
tämä on yleisin organisaatiorakenne. Tässä rakenteessa testaajat raportoivat Testauspäälliköille ja Kehittäjät Kehityspäällikölle. Sekä Testipäällikkö että kehityspäällikkö raportoivat projektipäällikölle.
Testipäällikkö vastaa kaikesta testiin liittyvästä toiminnasta ja kehityspäällikön vastuulla on saada ohjelmisto kehittymään. Projektipäällikkö ohjaa sekä testaus-että kehittämistoimintaa.
edut:
- toisin kuin edellinen rakenne, tässä rakenteessa on eri johtajat testaus ja kehittäminen, joten molemmat voivat keskittyä työhönsä. He pysyvät omistautuneina työlleen ja heille tulee vähemmän häiriötekijöitä.
- tässä rakenteessa testaustoimintaa ei voida laiminlyödä tai sitä ei voida pitää hankkeen myöhäisenä aikana. Tämä tarkoittaa, että sekä testaus että kehittäminen saavat yhtä suuren merkityksen.
- kriittisten päätösten teossa testiryhmä on riippumaton.
haitat:
- on mahdollista, että kommunikaatiokuilu johtuu useita tasoja.
Testijohtaminen Vs organisaatiorakenteet
organisaatiorakenteet vaikuttavat suoraan testin johtamiseen. Eri organisaatiorakenteilla on erilainen vaikutus testauksen hallintaan, joten testauksen hallinta vaihtelee Testauspäällikön taidon ja kokemuksen sekä testauspäällikön aseman mukaan organisaatiorakenteessa.
tässä on nähty kaksi organisaatiorakennetta. Ensimmäisessä rakenteessa kehityspäällikkö ja testauspäällikkö ovat sama henkilö, joten se vaikuttaa testauksen hallintaan. Kehityspäällikön tavoitteena on ohjelmistojen kehittäminen, ja sitä tehdessään hän joutuu katsomaan myös testaustyötä.
näin hän saattoi toisinaan esittää puolueellisia mielipiteitä. Hän voi vain unohtaa asian ja mennä eteenpäin. Näin se voi vaikuttaa testauksen hallintaan. Riippumaton testijohtaja pystyy tarjoamaan enemmän oikeudenmukaisuutta ja testien hallinta on parempi riippumattomien testijohtajien kanssa.
johtopäätös
olemme nähneet molemmat aiheet eli testijohtamisen ja organisaatiorakenteet erikseen ja näiden kahden välisen suhteen ohella. Voimme päätellä, että organisaatiorakenteet vaikuttavat testauksen hallintaan.
vertailtaessa molempia edellä mainittuja rakenteita, toisessa rakenteessa testinhallinta hoidetaan ensimmäistä paremmin. Syynä tähän saattaa olla vannoutunut testipäällikkö.
organisaatiorakenteet vaihtelevat organisaatiosta toiseen. Vaikka testinhallintaan on olemassa jokin määritelty prosessi (tai tiimit saattavat käyttää testinhallintatyökaluja), testauksen hallinta vaihtelee erilaisten organisaatiorakenteiden, testipäälliköiden, testipäällikön taitojen ja kokemuksen vuoksi.