erityyppisiä Estimointitekniikoita Ohjelmistotestauksessa
Ohjelmistotestin estimointi on olennainen hallintatoimi, jota käytetään määritettäessä likimääräistä aikataulua, joka tarvitaan minkä tahansa prosessin aloittamiseen ja päättämiseen kontrolloidussa ympäristössä.
projektisuunnittelun kannalta on ratkaisevan tärkeää, ettei aikarajoja, budjetteja ja käytettävissä olevia resursseja ylitetä. Yksi hyödyllisimmistä tehtävistä täällä on, tarkistaa resursseja ottaen huomioon vaivaa on käytettävä testi.
Utorin insinöörit hyödyntävät usein erityyppisiä estimointitekniikoita ohjelmistotestauksen aikana. Asiakkaamme ovat vahvistaneet nämä menetelmät tehokkaiksi. Siksi, käymme ne läpi, ja paljastaa niiden erityisiä etuja ja haittoja niin, että olet tietoinen siitä, miten parhaiten toteuttaa ne.
mikä on ohjelmistojen testauksen estimointi?
Ohjelmistotestin estimointi on prosessi, jossa mitataan ja hallitaan kestoa ja toimia, joita tarvitaan täydellisen testin suorittamiseen ohjelmistolla.
aikaa ja vaivaa on huomattavan helppo laskea pienimuotoisia tehtäviä varten. Mutta isompiin projekteihin. tehokkaita strategioita on oltava, jotta virheitä ei tehdä. Jos näitä hankkeita aliarvioidaan tai yliarvioidaan, niiden testausresurssit ovat joko riittämättömiä tai niitä käytetään kokonaan väärin.
Miten Tiimit Arvioivat Ohjelmistojen Testausresursseja?
ennen testin alkua on kaksi erittäin ratkaisevaa epävarmuustekijää, joista kaikki riippuu ja jotka täytyy selvittää testaajan ja asiakkaan välillä. Näitä ovat;
- mikä on koko menettelyn arvioitu kokonaiskesto?
- mikä on arvioitu menettelyn kokonaiskustannus rahana ja resursseina?
mitä on arvioitu?
aika, resurssit, kustannukset ja inhimilliset taidot määritetään tyypillisesti testauksen estimoinnin yhteydessä.
aika
ryhmäponnistuksen tehoa arvioidaan yleensä sen mukaan, pystyykö se suorittamaan tehtävän määrätyssä ajassa, määräaikaan mennessä tai ennen sitä.
kun hankevastaavat ovat tarkistaneet kunkin hankkeen jaksolta vaaditun vakiokeston, he kehittävät keinon pitää kunkin hankkeen aikataulut ajan tasalla.
hän varmistaa, että kaikki toimitetaan ajallaan. Tästä syystä ajan arviointi on yksi olennainen tekijä rakentaa kunniakas maine asiakkaiden keskuudessa ja ottaa hyvä määrä uskollisia asiakkaita.
resurssit
ennen kuin mitään hanketta voidaan aloittaa, on pakko tarkistaa käytettävissä olevat resurssit, ne, jotka pitäisi ottaa mukaan, ja suositellut korvaavat aineet, jos joitakin ei ole helposti saatavilla. Tarkistamatta tätä, on todennäköistä, että hankkeet eivät ole valmiita ennen määräaikaa.
kustannukset
koeprosessiin valmistauduttaessa arvioidut määrärahat on otettava kaikilta osin huomioon (sekä rahoitukselliset että muut).
kokonaiskustannukset on otettava huomioon mahdollisten kustannusten huomioimiseksi ja sen varmistamiseksi, että projekti pysyy asiakkaan määrittämässä budjetissa, ja työstettävä sitä, jos se ei riitä.
mainitut kentät ovat kaikki toisiinsa liittyviä ja toisistaan riippuvaisia. Sen kesto riippuu myös käytettävissä olevista välineistä ja talousarviosta.
ajan kuluessa ohjelmistotestien estimointiin liittyvä menettely on tehty eri prosesseilla, käyttäen erilaisia menetelmiä ja työkaluja, jotka ovat edenneet ajan myötä samasta syystä.
näiden tekniikoiden integrointi ja työskentely on helpottanut myös keskiarvoistamista.
ohjelmistotestauksen Estimointitekniikat
estimointimenetelmiä on yleisesti monia, mutta tarkastelemme vain muutamia suosittuja tämän artikkelin joukosta.
program evaluation and review technique (Pert)
tässä tekniikassa tehtävät on jaoteltu kolmeen alaluokkaan, jotta saadaan selville paremmin toteutukseen kuluva aika;
optimistinen skenaario; tässä tapauksessa hankkeen kesto -, rahamäärä-ja resurssikustannusten oletetaan olevan korkeimmillaan optimaalisella tasollaan. Tämä tarkoittaa sitä, että QA-tiimin yksittäiset jäsenet tekevät työtä parhaimmillaan kollektiivisesti, pitävät kiinni ajasta, ilman paineita, arvaamattomia käänteitä tai tarvetta palata tehtyyn työhön ja silti tehdä myös hienoa työtä.
todennäköisin skenaario-M; tässä kaikki asiat otetaan huomioon; kun otetaan huomioon tuttu työskenaario ja otetaan huomioon negatiiviset ja positiiviset mahdollisuudet, arvioidaan, miten se todennäköisimmin tapahtuu.
pessimistinen skenaario-P; tässä tarkastellaan negatiivisinta skenaariota, joka voisi olla. Keskiarvon laskeminen perustuu olettamukseen, että koko testin jokaisessa vaiheessa on epäilemättä käsiteltävä negatiivista tulosta.
Pert: n prosentit
- tätä tekniikkaa käyttäen tiimi työskentelee arviolla, joka tarkistaa kaikki mahdolliset kuolemantapaukset ja palkkiot kaikilla rintamilla.
- joukkueet voivat päätyä melko lähelle todellisuutta.
- se valmistelee organisaatiot kaikkiin mahdollisiin rakentamiskokeen tuloksiin, kun ne laskevat jokaisen kuviteltavissa olevan skenaarion ja valmistautuvat tarvittaessa riittävästi hillitsemään sitä.
Pert
- kun kyseessä on suurempi testiprojektien kokonaisuus, tämän estimaatin käyttäminen vie paljon enemmän aikaa.
- on suuri todennäköisyys, että epätarkkoja laskelmia tapahtuu.
- tässä käytetyt arvot eivät ole koskaan vakio ja niihin voi tulla monia virheitä, koska kyse on loppujen lopuksi vain estimoinnista.
User Case Point (UCP)
aina kun joku tai jokin käyttää kyseistä sovellusta ja kommunikoi sen kanssa, olio tunnistetaan toimijaksi. Mainittu kokonaisuus on dokumentoitu pääasiassa muokkaamattomissa Käyttötapauspainoissa, jotka vaikuttavat prosessin kapasiteettiin.
kaikki välinen viestintä turvaa kaikkien osallistumisen osakkeenomistajista LAADUNVARMISTUSTIIMIIN eri jaksojen ja määriteltyjen tavoitteiden kautta.
yli kymmenen eri tekijää vaikuttaa siihen, kuinka monimutkainen projektin teknisyys on, ja noin kahdeksan tekijää verottaa sitä monimutkaisesti ympäristön kannalta. Tämä on yhtäpitävä Gustav Karnerin havaintojen kanssa.
tämä arviointimenetelmä perustuu siihen, että lasketaan useita variantteja niin sanotuista toimijoista, käyttäjän tapauspainoista ja pisteistä, jotka vaikuttavat prosessiin, teknisyyteen ja muihin tekijöihin.
tämän prosessin aloittamiseksi niiden on ensin ristiintarkistettava omat koukeronsa ja vaikutettava prosessiin. Tämän jälkeen lasketaan vielä keskiarvoja soveltamalla niiden laskukaavoja.
hankkeen suuruuden tarkistamisen jälkeen osallistujat määrittelevät, kuinka paljon aikaa tarvitaan ennen kuin prosessi saadaan kokonaisuudessaan päätökseen. Kaksi merkittävää keinoa tämän estämiseksi ovat;
käyttäen Karnerin menetelmää ja ottaen huomioon, että jokainen testitapaus kuluttaa 20 työtuntia.
käyttäen joka tapauksessa yrityksen ennätysaikaa hankkeen loppuun saattamiseen tilastollisten keskiarvojen laskemiseksi ja nykyisen projektin keston arvaamiseksi.
UCP = Mukautumaton UCP x tekninen monimutkaisuus tekijä x ympäristöön vaikuttava tekijä.
YKP: n plussat
- jos sinun täytyy työskennellä etukäteen ja suunnitella hyvissä ajoin, tämä arviointimenetelmä on todennäköisesti parempi, koska se tehdään alkuvaiheessa ja se auttaa budjettikokojen karsimisessa ja hyväksymisessä.
- joidenkin erityisten johtamisvälineiden avulla arvioiden automaattinen laskeminen on mahdollista, mikä säästää paljon aikaa arviointiryhmälle ja helpottaa työtä.
Cons of UCP:
- jos projektin vaatimuksia ei ole annettu käyttäjän Case-pisteissä, tämä tekee mahdottomaksi käyttää tätä tekniikkaa, ja LAADUNVARMISTUSTIIMIN on hankittava eri menetelmä.
- kun UCP: t annetaan, eivätkä ne ole riittävän tarkkoja tai eksplisiittisiä, se todennäköisesti päättyy negatiivisesti estimaatteihin, jotka ovat kaukana todellisista, koska tämä menetelmä ei riipu vain tapauspisteiden antamisesta vaan selkeiden tapauspisteiden antamisesta.
Työnjakorakenne (WBS)
tässä estimointitekniikka tehdään jakamalla primääriprosessi eri alaluokkiin. Kunkin vaiheen keskimääräisen keston ennakoiva laskenta alkaa vähitellen karkealla työllä erän yksinkertaisemmista, minkä jälkeen valmistuu sekä vaikeusasteella että oikeellisuustasolla.
valitse alkutehtävän jälkeen korkein mahdollinen saavuttamasi arvo ja laske ne yhteen ja saat lopullisen arvon arvioimalla kunkin tehtävän vaatiman vaivan ja ajan.
WBS: n plussat
- tämän menetelmän ilmeinen etu on se, että se helpottaa jokaisen minuutin ja välttämättömän yksityiskohdan havaitsemista ja jakaa työn pienempiin bitteihin. Tämä tarkoittaa, että työ on tehty
- se on aina perusteellinen ja läpinäkyvä, koska johtopäätökset on taulukoitu samaan tarkoitukseen ja helpompi seurata.
Cons of WBS:
- tämä luonne vaatii yleensä mielen hieromista ja tiimin jäsenten ja sidosryhmien hyödyntämistä ulkoisesta kokemuksestaan.
- eritelmien ja asiakastarpeiden muutokset voivat johtaa vanhentumiseen ja siihen, että tiimi joutuu tutkimaan asiaa ja arvioimaan sen kokonaan uudelleen.
Delphi-menetelmä
Delphi-menetelmä on melko suosittu testausryhmien keskuudessa maailmanlaajuisesti. Vapaaehtoisilta osallistujilta saatuja tietoja kootaan yhteen ja tutkitaan tarkasti useita, eikä missään tietyssä järjestyksessä päädytä yhteisesti sovittuun lopputulokseen.
jokainen tutkimusvaihe tuo uutta tai parannettua tietoa, mikä vain lisää lopullisten tulosten tarkentumista ansaittua luottamusta.
yleensä työryhmä koostuu enintään kymmenestä henkilöstä, jotka kokoontuvat keskustelemaan projektin kriittisistä piirteistä ja kertomaan mielipiteensä hankkeen mahdollisesta kestosta.
tämän jälkeen joukkue kokoontuu uudelleen, ja tällä kertaa mielipiteet ensitreffeiltä jaetaan. Tämä antaa jäsenille toisen näkökulman hankkeeseen. Näkemykset eivät kuitenkaan ole merkittyjä ehdottajilleen.
kun tiimin jäsenet ovat käyneet tämän vaiheen läpi, he käyvät toisen yksimielisen keskustelun, ja mielipiteiden kokoaminen tuo uuden näkökulman huomioon.
tämä jatkuu, kunnes kaikki ovat samaa mieltä. Vaikka tavallinen tapa tehdä Delphi menetelmä, tämä muoto voidaan viritetty sen tarpeisiin ja valmiuksia.
Delphin ammattilaiset
- koska täällä ei tarvita ainutkertaisia kaavoja tai varusteita, se on kaikista joukkueista helpoin läpäistävä, tarvitaan vain asiakkaan vaatimukset ja hyvä mennä.
- arvio on melko lähellä tarkkuutta, sillä kokous-ja ideanjakoprosessissa otetaan huomioon monia ammatillisia näkökulmia.
Delfoi
- niin helppoa kuin se saattaakin olla läpikäyminen, se voi viedä paljon tuottavaa aikaa, koska useimmiten ei.
- on haastavaa keksiä yksi kattava arvio ensimmäisen kokouserän jälkeen ja jakaa mielipiteitä, joten yleensä siihen tarvitaan muutama.
- vaikka on kuluttanut niin paljon aikaa, tuloksia ei voi kierrättää. Joten jokainen projekti ajetaan, prosessi aloitetaan uudelleen uusien vaatimusten kanssa.
Yhteenvetona
tässä blogikirjoituksessa tarkasteltiin neljää eri estimointitekniikkaa ohjelmistotestauksessa ja sitä, kuinka vaikuttavia ne ovat kohtuullisen testausbudjetin suunnittelussa.
onnistuneiden arvioiden jälkeen, osaatko sanoa varmasti oikean lähestymistavan projektien ulkoistamiseen LAADUNVARMISTUSYRITYKSILLE?
tässä artikkeli siitä, miten valita paras lähestymistapa laadunvarmistuksen ulkoistamiseen.
kerro meille, mitä näistä testauksen estimointitaktiikoista olisit toteuttamassa, ja mikä oli näkemyksesi?