Alfa-testimine on üks paljudest tarkvara testimise liikidest, mida ettevõtted ja sõltumatud arendajad saavad oma koodi kontrollimisel kasutada. Teie alfatestimise strateegia tõhusus võib olla oluline tegur programmi edukuses – seetõttu on oluline, et te teaksite täpselt, kuidas see toimib ja millist kasu see sageli annab. See on ainus viis tagada edukas rakendamine ja aitab tagada, et nii arendajad kui ka testijad saavad stabiilse ja tõhusa toote.
Alfa-testimise ja sellega seotud paljude komponentide, sealhulgas testimismeeskondade poolt selle hõlbustamiseks kasutatavate vahendite mõistmine aitab arendajatel ehitada tugevamat rakendust. Need testid võivad esmapilgul tunduda keerulised, kuid neid saab loomulikult hõlpsasti lisada mis tahes kvaliteedi tagamise lähenemisviisi. Selles artiklis vaatleme lähemalt alfatestimist ja seda, kuidas see võib aidata mis tahes kodeerimisprojekti. See hõlmab ka seda, kuidas testijad saavad liikuda sellega kaasnevate väljakutsetega ja selle protsessi tavapäraste etappidega.
Mis on tarkvara testimise ja arenduse alfa-testimine?
Alfa-testimine on vastuvõtutestimise üks vorm; see tähendab, et selle eesmärk on hinnata, kuidas programm toimib ja kas funktsionaalsus on piisavalt tugev, et rahuldada lõppkasutajad ja nende nõuded. See juhtub üsna varakult testimise ajal ja alati enne beetatestimise etappi. Paljudel juhtudel võib see alata isegi arenduse ajal; need kontrollid hõlmavad tavaliselt kahte erinevat “testimisfaasi”, millel on erinevad seadistused, töötajad ja testimise prioriteedid.
Selliste uuringute läbiviimisel on testijatel tavaliselt kontrollnimekiri probleemidest või komponentidest, mida nad peavad uurima. Nad võivad otsida tavalisi vigu ja teha põhilisi teste, et näha, kas rakenduse põhifunktsioonid töötavad nii, nagu on ette nähtud.
Kui meeskond tuvastab programmis suuremaid või väiksemaid probleeme, edastavad nad need tulemused arendajatele, kes hakkavad peagi töötama nende probleemide õigeaegse parandamise kallal.
1. Millal ja miks on vaja teha alfa-testimist?
Täpne punkt, mil ettevõte rakendab alfa-testimist, on tavaliselt erinev ja sõltub rakendusest; testid võivad alata isegi siis, kui arendajad alles rakendavad tarkvara viimaseid lihvi. Paljudel programmidel on avalik või poolavalik beetaversioon, mis on avatud väliskasutajatele. Sellistel juhtudel tehakse alfa-testimine sisemise testimise viimases etapis.
See on tavaliselt siis, kui taotlus on 60 % ulatuses valmis. Alfa-testimine on oluline, sest selle abil on võimalik tuvastada vead ja probleemid, mis mõjutavad lõppkasutaja kogemust, mõjutades programmi vastuvõttu.
2. Kui te ei pea tegema alfa-testimist.
On mõned olukorrad, kus tasub alfatestimise etapp vahele jätta, kuid seda võivad mõjutada mitmed tegurid. Näiteks võib ettevõttel olla piiratud aeg ja ressursid, mistõttu nad ei saa märkimisväärselt pikendada testitsüklit, kuigi sellel võivad olla edasised tagajärjed.
Samuti võib testimismeeskond olla täiesti kindel oma praeguses testimisprotsessis – isegi ilma ametliku alfa-testimise ajakavata võivad testijate poolt läbiviidavad kontrollid juba hõlmata iga kategooriat.
Siiski on alfa-testimine peaaegu alati seda aega ja vaeva väärt.
3. Mõningate segaduste selgitamine:
Alfa- ja beetatestimine
Kuigi neil on palju sarnasusi, on oluline teha vahet alfa- ja beetatestimise vahel.
Mis on beetatestimine?
Beeta-testimine annab tõelistele lõppkasutajatele võimaluse uurida toodet ja välja selgitada, kuidas see toimib – kusjuures beetatestijad annavad arendajatele oma kogemuste kohta rohkelt tagasisidet. See toimub täielikult reaalses keskkonnas, näidates, kuidas programm kohandab neid seadeid ja kuidas suhtleb sihtrühmaga.
Testimise käigus on oluline kasutada väliseid vaatenurki, sest ettevõtte sisesed meeskonnaliikmed ei pruugi olla võimelised avastama teatavat tüüpi probleeme või puudusi, mis on seotud ettevõtte ainulaadse arendusstiiliga.
Alfa- ja beetatestimine (erinevused ja sarnasused)
Neil kahel lähenemisviisil on mitmeid sarnasusi ja erinevusi. Alfa- ja beetatestimine võivad pakkuda kõige rohkem kasu, kui neid kasutatakse koos, sest mõlemad on kasutajate heakskiitmise testimise vormid. Iga meetodi üldeesmärk on tuvastada tarkvaras esinevad probleemid, mis võivad mõjutada kasutajaid ja nende rõõmu tarkvara kasutamisest.
Võib-olla kõige olulisem erinevus on testijad ise – kuna beetatestijad on tavaliselt lõppkasutajad või muul viisil arendajatega mitteseotud; see annab neile värske vaatenurga tarkvarale.
Teine oluline erinevus on nende testide fookus. Alfa-testid keskenduvad tavaliselt rakenduse üldisele kasutatavusele ja funktsionaalsusele, samas kui beetatestid rõhutavad rohkem stabiilsust, usaldusväärsust ja turvalisust. Nende kontrollide käigus vaadatakse, kuidas programm käitleb nii oodatud kui ka ootamatuid sisendeid, mis tähendab, et keegi, kes ei tunne tarkvara ja selle toimimist, saab anda rohkem abi.
Alfa-testimise tagasiside võimaldab arendajatel sageli programmi enne väljalaskmist muuta, samas kui beetatestide käigus avastatud vead võivad jääda ootama tulevasi versioone ja uuendusi.
Alfa testimine toimub…
– Ettevõtte sisemised arendajad, kui nad töötavad toote kallal – see võimaldab neil lahendada probleeme juba enne ametliku testimistsükli algust.
– sisemised QA testijad, kes uurivad programmi testkeskkonnas, et kontrollida, kuidas see toimib ja kuidas kasutajad reageerivad.
– Välised testijad, kes sõltuvalt rakendusest võivad teha alfa-teste, et anda tagasisidet, mis võib täpselt kajastada kasutajakogemust.
Alfa-testimise eelised
Alfa-testimise eelised on järgmised:
1. Suurem ülevaade
Alfa-testimise ehk kõige olulisem eelis on selle võime anda arendajatele ja testijatele palju suurem ülevaade rakendusest. See võimaldab neil näha, kuidas kõik kokku sobib, näiteks kas kõik tarkvara funktsioonid toimivad ootuspäraselt ja kuidas lõppkasutajad võiksid programmiga pärast selle vabastamist tegeleda.
2. Kiirem tarneaeg
Alfa-testimine võimaldab meeskonnal tuvastada vead enne väljalaskmist ja töötada ennetavate paranduste kallal, mis aitavad tagada, et kasutajad ei puutu kunagi kokku samade tõrgetega. Põhjalik ja põhjalik alfa-testimine võimaldab ettevõttel seda programmi palju varem ja suurema usaldusega selle kasutatavuse suhtes välja anda – see võib vähendada ka vajadust erakorraliste uuenduste järele.
3. Parema kvaliteediga tarkvara
Need kontrollid hõlmavad nii valge kasti kui ka musta kasti testimist, võimaldades terviklikku ülevaadet rakendusest ja viisidest, kuidas arendajad saaksid seda edu tagamiseks täiustada. Mida rohkem teste meeskond kasutab, seda rohkem vigu saab enne väljalaskmist parandada, mille tulemuseks on parem kasutajakogemus, sest kasutajad puutuvad vähemate probleemidega kokku.
4. Säästab raha
Alfa-testimine on väga kuluefektiivne kvaliteedi tagamise vorm, sest see võimaldab avastada vead juba varakult; nende parandamine hiljem võib olla kulukas. Näiteks võib see nõuda isegi täiesti uue tarkvaraversiooni loomist, mis maksab rohkem raha kui probleemi lihtne parandamine arenduse või kvaliteedi tagamise käigus.
Alfa-testimise väljakutsed
Alfa-testimise puhul peavad meeskonnad arvestama ka mitmesuguste väljakutsetega, näiteks:
1. Ei kajasta kasutajakogemust
Kuigi alfa-testijate eesmärk on jäljendada seda, kuidas kasutajad kasutavad tarkvara paljude kontrollide puhul, võivad neil siiski jääda teatavad vead märkamata, kuna nad on rakendusega tuttavad. See muudab beetatestimise veelgi olulisemaks – need kontrollid on täielikult kasutaja ainulaadsest vaatenurgast.
2. Pikk katsetsükli aeg
Need testid kiirendavad oluliselt arendustegevust, kuid nõuavad sageli suurt ajakulu, kuna on vaja põhjalikku kvaliteedi tagamist. Musta ja valge kasti meetodite kombineerimine on pikk protsess ja suurema hulga funktsioonidega programmid nõuavad tõenäoliselt ulatuslikumat kontrolli.
3. Projekti tähtajad
Samamoodi on tarkvaraprojektidel tavaliselt fikseeritud tähtajad, mida arendajad ei saa mitmel põhjusel muuta. See tähendab, et nad ei pruugi olla võimelised rakendama kõiki muudatusi enne väljalaskmist isegi pärast põhjalikku alfa-testimise strateegiat – tootes võib olla veel puudusi, kui tähtaeg möödub.
4. Ei testi kõike
Alfa-testimine keskendub peamiselt programmi üldisele funktsionaalsusele, mitte aga turvalisuse ja stabiilsusega seotud kaalutlustele, mis on seotud pigem beetatestimisega. Kuna need testimistsüklid võivad võtta aega, võib nende ulatus olla üsna piiratud; eriti suuremate tarkvaraprojektide puhul, mille testimine võtab veelgi rohkem aega.
Alfa-testide omadused
Eduka alfatestimise strateegia peamised omadused on järgmised:
1. Usaldusväärne
Meeskonna poolt läbiviidavad testid peavad andma kasulikku tagasisidet, mida nad saavad edastada arendajatele, kes saavad seejärel probleeme parandada. See tähendab ka seda, et viga peab olema korratav, kusjuures testija peab täpselt näitama, kuidas kodeerimisprobleeme reprodutseerida ja uurida.
2. Kiire
Aeg on väärtuslik ressurss igas tarkvaraprojektis – ja alfa-testimine võtab sellest tavaliselt märkimisväärse osa. Seepärast peavad alfa-testid tasakaalustama sügavust ja kiirust, kui see on võimalik, et nad kataksid kõik testjuhtumid ja iga üksiku tarkvara funktsiooni.
3. Põhjalik
Alfa-testid seavad esikohale kasutatavuse ja funktsionaalsuse; on oluline, et kvaliteedi tagamise töötajad tagaksid nende parameetrite maksimaalse (kui mitte täieliku) testide katvuse. Täielike testide läbiviimine on ainus viis tagada, et tarkvaras on olemas kõik tarkvara lühikirjelduses esitatud funktsioonid.
4. Isoleeritud
Kuigi alfa-testimine ei toimu reaalses keskkonnas, on isoleeritud testikomplektil siiski eeliseid. See võimaldab testijatel töötada programmi üksikute funktsioonidega (näiteks andmebaasiga), ilma et need muudatused mõjutaksid teisi komponente, mis säästab meeskonnale palju aega.
Alfa-testimise eesmärgid
Alfa-testimise üldised eesmärgid on järgmised:
1. Tarkvaraprobleemide lahendamine
Üks alfa-testimise peamisi eesmärke on luua parem toode, mille eest kliendid on valmis maksma või mida nad lihtsalt üldiselt kasutavad. Paljud üksikud kontrollid, mida see hõlmab, töötavad kõik selleks, et avastada probleemid või vead, millega kasutajad võivad kokku puutuda. Alfa-testimisega on meeskonnal võimalus need vead enne väljalaskmist parandada.
2. Täiendavad beetatestid
Tarkvaraarenduses töötavad alfa- ja beetatestimine kõige paremini koos ja ettevõtted saavad seda kasutada, et tagada rakenduse kõigi võimalike külgede katmine. Põhjalikud alfatestid muudavad beetatestimise lihtsamaks ja võimaldavad mõlemat tüüpi testimise suuremat katvust. See võimaldab üldisel testimisstrateegial saavutada oma täieliku potentsiaali ja annab arendajatele meelerahu.
3. Toote tõhusamaks muutmine
Kuigi alfa-testimine keskendub rakenduse vigade parandamisele, võivad nad märgata ka puudusi, mis mõjutavad kasutaja kogemust negatiivselt. See näitab ka arendajatele ja testijatele, kuhu nad peaksid oma jõupingutused tulevastes testitsüklites suunama, illustreerides kõige keerulisemaid komponente, sealhulgas neid, mille puhul on tõenäoline, et tulevikus tekib probleeme.
Täpsemalt… mida me testime alfatestimise käigus?
Siin on konkreetsed parameetrid, mida alfa-testijad kasutavad kontrollide läbiviimisel:
1. Funktsionaalsus
Alfa-testimise käigus vaadeldakse peamiselt rakenduse üldist funktsionaalsust, näiteks seda, kas funktsioonid toimivad eraldi ja koos. See võib hõlmata palju testjuhtumeid – koos võimalike vigade täieliku üksikasjadega, et tagada ulatuslik katvus, mis kinnitab tarkvara põhifunktsioone. See kattub oluliselt funktsionaalse testimisega, mis keskendub samuti sellele, et tagada programmi funktsioonide toimimine kasutajate jaoks.
2. Kasutatavus
Nende testidega vaadeldakse ka rakenduse kasutatavust. See viitab sellele, kui hästi saab kasutaja programmis navigeerida, näiteks kui intuitiivne on selle kujundus ja kui hästi see tähistab prioriteetsed funktsioonid. Nende kontrollide puhul tegutseb testija kasutajana, et näha, kuidas keegi, kes seda tarkvara ei tunne, saaks seda kasutada. Alfa-testimise abil saab näiteks kindlaks teha, kas kasutajaliides on visuaalselt liiga keeruline.
3. Tulemuslikkus
Tarkvara funktsionaalsuse kontrollimise raames kontrollitakse alfa-testide käigus ka jõudlusprobleeme, sealhulgas seda, kas programm töötab teatud seadmetes ja operatsioonisüsteemides raskesti. Testijatel on ligikaudne ettekujutus edukuse mõõdikutest, mis võimaldab neil näha, kas rakendus kasutab vastuvõetavat hulka RAM-i ja CPU-d. See võib hõlmata isegi stressi- ja koormustestimist, et kontrollida, kas programm toimib erinevates tingimustes hästi.
4. Stabiilsus
Kuigi see võib kuuluda pigem beetatestimise alla, võib see siiski olla teie alfa-testimise komplekti põhikomponent – ja aitab rakenduse funktsionaalsust veelgi enam valideerida. Need testid hõlmavad rakenduse survestamist erinevatel viisidel, et näha, kuidas see reageerib.
Kui programm näiteks jookseb kokku, tähendab see, et on tõsiseid probleeme, mis vajavad tähelepanu; igal juhul on hädavajalik, et meeskond parandaks ebastabiilse tarkvara.
Alfa-testide tüübid
Peamised alfa-testimise tüübid on järgmised:
1. Suitsu testimine
Suitsutestimine on sarnane funktsionaalsuse testimisele, rõhutades nii tarkvara kui ka selle paljude funktsioonide põhilise töövõime vajalikkust. Testijad viivad neid kontrolle läbi iga kord, kui arendajad lisavad jooksvasse build’ile uue funktsiooni kas arenduse või hilisemate uuenduste ajal. See toimub tavaliselt kiirete, minimaalsete testide kujul, mis pakuvad laiaulatuslikku katvust.
2. Korrektsuse testimine
Tervislikkuse testimine on sarnane ja kontrollib, kuidas tarkvara toimib pärast esimest veaparandusringi; mõnikord on võimalik, et see rikub kogemata teisi funktsioone. Need testid tagavad, et parandused töötavad ja ei too kaasa muid vigu.
Kui arendajate muudatused parandavad edukalt programmi probleemid, tähendab see, et see läbib tervikutesti.
3. Integratsioonitestimine
Integratsioonitestimine ühendab mitu tarkvaramoodulit ja uurib neid rühmana, näidates, kuidas rakenduse põhikomponendid omavahel koos töötavad. Oluline on kontrollida, et need koostoimed saaksid toimuda ilma stabiilsusprobleemideta. Samuti saab uurida rakenduse ühilduvust teiste programmide ja failitüüpidega ning nende integreeritavust.
4. Kasutajaliidese testimine
Kasutajaliidese testimisel vaadeldakse kasutajaliidest ja seda, kuidas see aitab kaasa kasutaja üldisele kasutuskogemusele. Näiteks peab kujundus olema pilkupüüdev ja kogu tekst peaks olema lihtsalt loetav; need võivad olla küllaltki subjektiivsed tegurid, kuid on siiski olulised kaalutlused.
Testijad peavad ka uurima, kuidas programm juhendab kasutajaid oma funktsioonide kaudu, kasutades juhendmaterjale.
5. Regressioonitestimine
Regressioonitestimine sarnaneb sanity testimisega ja teostab uuesti vanu testjuhtumeid programmi uuendatud versioonide jaoks; see võimaldab testijatel kontrollida, kas nende töö on edukas. Need kontrollid on väga üksikasjalikud ja sageli taanduvad isegi rakenduse kõige väiksemad komponendid, et näha, kas nad ikka veel toimivad; see on palju põhjalikum kui sanity testid.
Alfa-testimise protsess
Siin on samm-sammuline juhend edukate alfa-testide läbiviimiseks:
1. Planeerimine
Iga testimisstrateegia esimene samm on välja selgitada nende kontrollide ulatus ja üldine lähenemisviis, sealhulgas konkreetsed testid, mida meeskond kavatseb rakendada. See hõlmab testikava koostamist koos üksikute testjuhtumitega, mis on seotud tarkvara funktsionaalsusega.
2. Ettevalmistus
Pärast esialgset planeerimist valmistub meeskond kontrollide alustamiseks tarkvara paigaldamise ja testkeskkonna loomisega, et neid teste täiendada. Samuti võivad nad hakata koostama testiskripte, et hõlbustada automatiseerimisstrateegiat; näiteks võib hüperautomaatika muuta testimise tõhusamaks.
3. Täitmine
Kui ettevalmistused on lõpetatud, saab meeskond viia läbi alfatestid, et saada selge ettekujutus rakenduse olekust, salvestades tulemused ja mõõdikud, et hinnata, kas esineb probleeme. Sõltuvalt oma tähtaegadest võib testimismeeskonnal tekkida vajadus seada teatud kontrollid teistele eelisjärjekorda.
4. Hindamine
Pärast kontrollide lõpetamist uurib kvaliteedi tagamise meeskond neid tulemusi ja hakkab tegema järeldusi tarkvara kohta – näiteks, kas see on valmis väljalaske kuupäevaks. Selles etapis saavad nad hakata andma tagasisidet ka arendajatele, kes hakkavad ette valmistama veaparandusi.
5. Aruandlus
Testimismeeskond koostab ka ametliku aruande, mis annab põhjalikku teavet testide kohta ja selle kohta, mida tulemused näitavad, sealhulgas selle kohta, kuidas see on võrreldav oodatud tulemustega. Selles aruandes hinnatakse ka seda, kui hästi meeskond kontrolle läbi viis ja esitatakse andmed nende testide katvuse kohta.
6. Kinnitus
Pärast puuduste ja üldiste soovituste esitamist arendusmeeskonnale võivad testijad ka seda tarkvara uuesti kontrollida, et näha, kas parandused on edukad. Seejärel alustavad mõlemad meeskonnad programmi ettevalmistamist beetatestimiseks, mis on tavaliselt kvaliteedi tagamise protsessi järgmine etapp.
Alfa-testimise etapid
On kaks peamist alfa-testimise etappi:
1. Esimene etapp
Alfa-testimise esimeses etapis vastutavad tarkvarainsenerid rakenduse silumise eest ja kasutavad neid tulemusi, et paremini mõista oma tarkvara ja seda, kuidas seda veelgi paremaks muuta. Need probleemid võivad olla palju ulatuslikumad kui tulevased alfa-testid, vaadeldes pigem seda, kas rakendus jookseb käivitamisel kokku või ei installida masinatesse.
See on ainult ligikaudne läbivaatamine ja ei hõlma üksikasjalikke testjuhtumeid ega iga funktsiooni põhjalikku kontrolli – esialgne alfa-testimine aitab tagada, et programm on edasiste kontrollide jaoks sobivas seisukorras.
2. Teine etapp
Seevastu alfa-testimise teine etapp toimub sisemise kvaliteeditagamise meeskonna poolt ja see on põhjalikum, hõlmates põhjalikke testjuhtumeid, milles on kirjeldatud iga kontrolli.
Alfa-testijad viivad läbi suurema hulga teste, mille abil otsustavad, kas rakendus on valmis kas avaldamiseks või järgmiseks testimisvooruks. Nad uurivad ka tarkvara tegelikku kvaliteeti ja lisavad selle teabe oma aruandesse, andes arendajatele täielikku tagasisidet. See osa protsessist võtab tavaliselt palju kauem aega kui esialgne alfa-testimise etapp.
Alfa-testimise sisenemiskriteeriumid
Tavalised sisenemistingimused, millele need testid peavad vastama, on järgmised:
1. Üksikasjalikud nõuded
Nende testide jaoks on vaja ärinõuete spetsifikatsiooni (Business Requirements Specification, BRS) või tarkvaranõuete spetsifikatsiooni (Software Requirement Specification, SRS), milles määratakse kindlaks projekti ulatus ja nende testide lõppeesmärk. Viimane sisaldab põhjalikke andmeid tarkvara ja ettevõtte ootuste kohta; see aitab testijatel programmi paremini mõista.
2. Põhjalikud testjuhtumid
Üksikasjalikud testjuhtumid aitavad testijatel ja arendajatel mõista eelseisvaid teste ja seda, milliseid tulemusi meeskond neilt ootab. Kvaliteedi tagamise meeskond järgib neid testjuhtumeid iga kontrolli puhul, et tagada õigete testimisprotokollide rakendamine kogu protsessi igas etapis.
3. Asjatundlik testimismeeskond
Meeskonnal peab olema hea arusaam tarkvarast, et anda sobivat tagasisidet – nad peaksid ka teadma, kuidas läheneda sellele lõppkasutaja vaatenurgast. Nende kogemus rakendusega võimaldab neil kiiresti testida, ilma et nende kontrollide kvaliteet kannataks.
4. Stabiilne katsekeskkond
Testijad rajasid oma uuringute sujuvamaks muutmiseks stabiilse testimiskeskkonna, mis näitab, kuidas rakendus töötab isoleeritult ja ilma negatiivsete mõjudeta. See annab meeskonnaliikmetele selge võrdlusaluse, mis illustreerib programmi tulemuslikkust tootmiskeskkonda jäljendaval viisil.
5. Testide haldamise vahend
Paljudes testimisüksustes kasutatakse vahendit, mis suudab automaatselt logida defektid, võimaluse korral robotiseeritud protsesside automatiseerimise või muu sarnase meetodi abil. Need kolmanda osapoole rakendused võimaldavad kasutajatel ka testjuhtumeid üles laadida ja koostada, aidates neil vajadusel hõlpsasti ligi pääseda sellele teabele, et iga testi tulemusi salvestada.
6. Jälgitavuse maatriks
Jälgitavusmaatriksi rakendamine võimaldab kvaliteedi tagamise meeskonnal seostada iga rakenduse projekteerimisnõudeid vastavate testjuhtumitega. See suurendab vastutust kogu testimisprotsessis, pakkudes samal ajal täpset statistikat katvuse ja funktsioonide vaheliste seoste kohta.
Alfa-testimise lõpetamise kriteeriumid
Järgnevalt on esitatud tingimused, millele testid peavad protsessi lõpuleviimiseks vastama:
1. Alfa-katsete lõpuleviimine
Kui iga alfatest on lõpetatud ja tal on üksikasjalikud tulemused, mida meeskond saab esitada või aruande koostada, on võimalik, et enne selle testitsükli lõpetamist on veel mitu sammu jäänud. Siiski on nende testide lõpetamine sageli esimene oluline samm.
2. Täielik testjuhtumite katvus
Selleks, et kontrollida, kas testid on tegelikult täielikud, peab meeskond kontrollima oma testjuhtumeid ja vaatama, kui põhjalik on nende katvus olnud. Kui juhtumites või testijate üldises lähenemisviisis on lünki, võib olla vaja teatavaid kontrolle korrata.
3. Veenduge, et programm on täisfunktsionaalne
Kui need testid näitavad, et projekteerimisnõuete täitmiseks on vaja lisafunktsioone, peavad testijad selle parandama. Testid võivad siiski lõpptulemusena selguda, kui selgub, et rakendusel on kõik vajalikud funktsioonid, et rahuldada sidusrühmi ja kliente.
4. Aruannete kontrollitud edastamine
Lõplikud testimisaruanded näitavad tarkvara hetkeseisu ja seda, kuidas arendajad saavad seda veelgi parandada. Tagades, et aruanded jõuavad arendajateni, saab alustada järgmist kvaliteedi tagamise etappi; need aruanded on eduka väljalaskmise jaoks olulised.
5. Uuesti testimine on lõpule viidud
Alfa-testide aruanded võivad tingida vajaduse teha rakendusse täiendavaid muudatusi, mis omakorda toob kaasa rohkem alfa-testimist. Kvaliteedi tagamise meeskond peab kinnitama, et arendajate muudatused on need probleemid parandanud, ilma et need mõjutaksid seda muul viisil, mis viib parema tooteni.
6. Lõplik allkirjastamine
Mis tahes testimisprotsessi lõpetamisel vastutab kvaliteedi tagamise meeskond (eelkõige projektijuht või juht) ka kvaliteedi tagamise kinnitava dokumendi koostamise eest. Sellega teavitatakse sidusrühmi ja teisi olulisi töötajaid, et alfa-testimine on nüüdseks lõppenud.
Alfa-testide väljundite tüübid
Alfa-testimise meeskond saab nendest kontrollidest mitu väljundit, näiteks:
1. Katsetulemused
Alfa-testi abil saadakse ulatuslikke andmeid programmi ja selle hetkeseisu kohta – sealhulgas tegelikud testitulemused ja nende võrdlus kvaliteedi tagamise meeskonna oodatud tulemustega. See on üldiselt testjuhtumite kujul, mida väline testirakendus võiks automaatselt täita iga kontrolli tulemusega; spetsiifika varieerub paljude testide puhul.
2. Katseprotokollid
Need põhjalikud uuringud tekitavad tarkvara sees ka sisemisi logisid, mis annavad meeskonnaliikmele piisavalt teavet tõlgendamiseks. Näiteks võivad logid näidata märke rakenduse stressist või isegi üksikasjalikke veateateid ja hoiatusi. Need logid võivad viidata ka konkreetsetele koodiridadele – selline tagasiside on eriti kasulik arendajatele.
3. Katsearuanded
Arendajad esitavad lõpuks põhjaliku testimisaruande, milles on üksikasjalikult kirjeldatud iga kontrolli ja selle tulemust; see võib olla kõige olulisem väljund, kuna seda kasutatakse rakenduse täiustamiseks. Testiaruanded koondavad eespool nimetatud andmed loetavasse ja kergesti arusaadavasse formaati – osutades tarkvaras esinevatele probleemidele ja andes võimaluse korral ettepanekuid, kuidas arendajad võiksid neid parandada.
Ühised alfa-testimise mõõdikud
On mitmeid spetsiifilisi mõõdikuid ja väärtusi, mida testijad kasutavad alfa-testide läbiviimisel, sealhulgas:
1. Testide katvuse määr
Testide katvuse määr näitab, kui tõhusalt katavad meeskonna testjuhtumid rakenduse erinevaid funktsioone, mis näitab, kas nende kvaliteedi tagamine on piisav. Oluline on vähemalt 60%-line katvus, kuid enamik organisatsioone soovitab 70-80%, kuna täielikku katvust on raske saavutada.
2. Süsteemi kasutatavuse skaala skoor
Süsteemi kasutatavuse skaala on katse kvantifitseerida subjektiivseid kasutatavuse elemente ja kontrollida, kui keeruline on rakendus, sealhulgas seda, kui hästi see integreerib oma funktsioone. See toimub tavaliselt küsimustiku vormis, mille tulemuseks on SUS-skoor 100-st.
3. Läbiviidud katsete arv
See mõõdik annab testimismeeskonnale ülevaate tarkvara tervislikust seisundist ning selle sobivusest avalikuks väljaandmiseks või beetatestimiseks. Teadmine, kui palju kontrolle rakendus suudab läbida – arvuna, murdosa või protsendina – aitab testijatel näha, millised komponendid vajavad täiendavat toetust.
4. Maksimaalne reageerimisaeg
Alfa-testijad uurivad tavaliselt programmi reageerimisaega, mis on aeg, mis kulub rakendusel kasutaja päringu täitmiseks. Pärast nende kontrollide lõpetamist uurib meeskond maksimaalset võimalikku reageerimisaega, et teha kindlaks, kas see on kasutajate jaoks liiga pikk ooteaeg.
5. Defektide tihedus
See viitab rakenduses esinevate vigade või muude probleemide keskmisele hulgale iga üksiku mooduli kohta. Defektitiheduse määramise eesmärk on sarnane läbitud testide arvule, mis näitab, millises seisus on tarkvararakendus ja kas see on valmis avaldamiseks.
6. Katse kogukestus
Üldiselt on aeg eriti oluline mõõdik alfa-testide puhul, kuna see etapp võib võtta kauem aega kui muud kvaliteedi tagamise protsessid. Meeskonnaliikmed peavad töötama selle näitaja vähendamiseks, kui see on võimalik, et suurendada oma tõhusust ja ületada testimise kitsaskohti.
Tuvastatud vigade ja vigade tüübid
läbi alfa-testimise
Siin on peamised probleemid, mida alfa-testimine aitab tuvastada:
1. Mittetoimivad funktsioonid
Kuna alfa-testimine keskendub funktsionaalsusele, avastatakse sageli probleeme rakenduse funktsioonidega ja sellega, kuidas kasutaja saaks nendega suhelda. Kui mõni põhifunktsioon ei tööta, peaks arendusmeeskond selle võimalikult kiiresti parandama.
2. Süsteemi kokkuvarisemine
Sõltuvalt vea raskusastmest võib kogu programm ootamatu sisendi korral kokku kukkuda. Vead võivad isegi põhjustada viivitusi tarkvara väljalaskmises, kuni arendajad töötavad nende probleemide kordumise vältimiseks.
3. Kirjavigad
Programmi kasutatavuse hindamine hõlmab kujunduselementide kontrollimist, et veenduda, et kõik on lõppkasutajate jaoks rahuldav. Isegi väike trükiviga võib mõjutada nende arvamust tarkvarast, seega peavad alfa-testijad neid enne väljalaskmist kontrollima.
4. Riistvara ühildamatus
Alfa-testimisega kontrollitakse ka seda, kas rakendus ühildub kavandatud platvormidega, näiteks erinevate operatsioonisüsteemidega. Arendajad peavad tegelema ootamatute kokkusobimatuse probleemidega, et tagada, et nende rakendusi saaksid kasutada rohkem kasutajaid.
5. Mälu lekked
Ebastabiilne programm ilmneb tavaliselt varsti alfa-testimise käigus, kasutades seejuures potentsiaalselt rohkem seadme RAM-i – see aeglustab programmi tööd. Selle vea kõrvaldamine aitab rakendusel muutuda tulevaste kasutajate jaoks palju stabiilsemaks.
6. Ebakorrektne andmebaasi indekseerimine
Tarkvara andmebaasis võib esineda mitmeid probleeme, näiteks ummikseisud ja indeksite tõrked – viimane tähendab, et tarkvara ei saa kasutaja taotlusi täita. See aeglustab oluliselt andmebaasi tööd, suurendades maksimaalset reageerimisaega.
Näiteid alfatestide kohta
Siin on kolm näidet erinevate rakenduste alfa-testimise kohta:
1. Kliendisuhete haldamise tarkvara
CRM-tarkvara sisaldab põhjalikku teavet klientide ja äripartnerite kohta, mida see tavaliselt talletab andmebaasis. Alfa-testijad saavad seda kontrollida, et tagada, et see annab õigeid andmeid ka suure koormuse korral ja piisava reageerimisaja juures.
Testijad kontrollivad ka seda, kuidas see rakendus reageerib uute kirjete loomisele ja isegi kustutamisele.
2. E-kaubanduse pood
Veebilehed ja veebirakendused vajavad samuti märkimisväärset alfa-testimist. Selle stsenaariumi puhul vaatavad kvaliteedi tagamise meeskonnaliikmed veebilehte põhjalikult läbi ja veenduvad, et kõik funktsioonid – kuni maksmiseni välja – toimivad.
Kui kogu protsessi jooksul esineb suuremaid või isegi väiksemaid vigu, võivad kasutajad oma ostukorvist loobuda; seetõttu on oluline, et testijad teavitaksid arendajaid nendest probleemidest.
3. Videomäng
Videomängud on veel üks tarkvara vorm, mis nõuab pikka alfa-testimist. Sisemine kvaliteedikontrolli personal mängib iga taseme korduvalt läbi, sooritades oodatud ja ootamatuid tegevusi, et testida, kuidas rakendus reageerib.
Näiteks ei pruugi tehisintellekti tegelased oma keskkonnas liikuda, tekstuurid ei pruugi korralikult kuvada ja mäng võib kokku kukkuda, kui kasutate mittetoetavat graafikakaarti.
Manuaalsed või automaatsed alfatestid?
Automatiseerimine on sageli kasulik lähenemine alfa-testide läbiviimisel, sest see säästab meeskonnale nii aega kui ka raha. See strateegia piirab inimlike vigade esinemist, tagades järjepidevuse ja täpsuse igas testis. Automatiseerimise suurenenud kiirus parandab ka üldist katvust, võimaldades testijatel kontrollida rohkem funktsioone.
Ettevõtted võivad rakendada robotiseeritud protsesside automatiseerimist, et suurendada kasu; see kasutab intelligentseid tarkvararoboteid, et suurendada testide kohandamise taset.
Siiski on mõned olukorrad, kus manuaalne testimine on sobivam; alfa-testid hõlmavad tavaliselt subjektiivsete kasutatavusprobleemide uurimist, mida enamik automatiseerimismeetodeid ei saa arvesse võtta. Mõned rakendused kasutavad arvutinägemist, et simuleerida inimese vaatenurka ja hinnata mitmeid disainiprobleeme sarnaselt lõppkasutajale.
Paljudel juhtudel võib automatiseerimise tõhusus sõltuda meeskonna valitud kolmanda osapoole testimisprogrammi eriomadustest.
Parimad praktikad alfa-testimiseks
Mõned parimad tavad, mida alfa-testijad peaksid järgima, on järgmised:
1. Testija tugevuste kohandamine
Rühmajuhid peaksid määrama konkreetsed kontrollid vastavalt testijate individuaalsetele oskustele. See aitab tagada, et näiteks need, kes on kasutatavuse testimisega paremini kursis, teostavad neid uuringuid. Sellise lähenemise abil võivad organisatsioonid parandada oma alfa-testimise protsesse, kuna kogenud testijad suudavad tuvastada veelgi rohkem programmi mõjutavaid probleeme.
2. Automaatika rakendamine targalt
Tarkvara testimise automatiseerimine pakub palju selgeid eeliseid, sõltumata selle konkreetsest vormist, ja võib tõhusalt muuta alfa-testimise etapi. Siiski peavad ettevõtted seda arukalt kasutama, sest mõned kontrollid nõuavad inimperspektiivi. Meeskond peab uurima omaenda teste, et otsustada, milliste testide puhul oleks kasu automatiseerimisest või käsitsi testimisest.
3. Jälgitavusmaatriksi koostamine
Alfa-testijad lisavad sageli oma testimisstrateegiasse jälgitavusmaatriksi, et uurida erinevate kontrollide vahelisi seoseid ja seoseid. See hõlmab ka praegust arengut – ja ulatuslikku dokumentatsiooni meeskonna üldise lähenemisviisi kohta kvaliteedi tagamisele. Jälgimismaatriksi abil saavad testijad keskenduda ka avastatud vigadele.
4. Erinevate riistvaramudelite kasutamine
Isegi ühes ja samas operatsioonisüsteemis võivad eri tüüpi riistvara ja süsteemiarhitektuurid programmiga konflikti sattuda. See võib põhjustada krahhi ja muid tõsiseid probleeme, mis võivad piirata tarkvara kasutajaskonda. Rakenduse testimine erinevatel masinatel ja seadmetel aitab esile tuua ühilduvusprobleeme, mis võimaldab arendajatel need enne väljalaskmist lahendada.
5. Sisekontrolli läbiviimine
On oluline, et ettevõtted veenduksid, et nende tarkvara alfa-testimise protsessid on töökindlad ja suudavad hõlpsasti katta iga uuritava programmi põhifunktsioone. Seetõttu peavad testimismeeskonnad pühenduma oma lähenemisviisi pidevale täiustamisele – ehk siis panema rõhku suurele testide katvusele, et vältida lünki oma strateegias.
.
Mida on vaja alfatestimise alustamiseks?
Siin on peamised eeldused, mida alfa-testijad peavad täitma enne kontrollide alustamist:
1. Asjatundlikud testijad
Alfa-testimine esineb erinevat tüüpi tarkvaraarenduses – ja erinevad programmid nõuavad üldiselt mitmesuguseid eritellimusel põhinevaid kontrolle. On väga oluline, et ettevõtetel oleks kvaliteedi tagamise meeskonnad, kes tunnevad alfatestide peamisi põhimõtteid ja suudavad kiiresti kontrollida rakendusi, et tagada kõrge katvus. Kuigi uued testijad võivad QA-protsessile siiski palju pakkuda, parandavad kvalifitseeritud töötajad tavaliselt meeskonna lähenemisviisi veelgi.
2. Terviklik planeerimine
Planeerimine on iga eduka alfatestimise strateegia keskmes, aidates meeskonnal planeerida aega ja vahendeid rakenduse kontrollimiseks. Samuti peaks arendajatel olema piisavalt aega, et paljud probleemid enne väljalaskmist lahendada. Üksikasjalikud testjuhtumid on eriti olulised, sest need aitavad illustreerida konkreetseid kontrolle, mida meeskond kasutab, ja seda, kui hästi nad suudavad rahuldada tüüpilisi lõppkasutaja nõudeid.
3. Automaatika tarkvara
Kui ettevõte soovib oma alfatestimises rakendada automatiseerimist, võimaldab kolmanda osapoole rakendus neil teha rohkem teste vähemal ajal. Kuigi rakendusi on kindlasti võimalik testida ka ilma selle tarkvarata, on see sageli hädavajalik, et tagada tähtaegselt suur testide katvus.
Saadaval on nii tasuta kui ka tasulisi võimalusi – ja mõlemal on oma unikaalsed funktsioonid, mis aitavad neid kasutada tarkvara testimise laias spektris.
4. Stabiilne katsekeskkond
Turvaline ja stabiilne testimiskeskkond võimaldab meeskonnaliikmetel tarkvara põhjalikult uurida, eemal igasugusest välismõjust. See sarnaneb suuresti reaalse lõppkasutaja keskkonnaga, kuid toimib hoopis liivakastina, nii et testijad ja arendajad saavad simuleerida realistlikke juhtumeid. Testkeskkonnad võimaldavad meeskonnal muuta tarkvara, ilma et see mõjutaks live-versiooni – see on veelgi kasulikum rakenduse uuenduste kontrollimisel.
7 viga ja lõksu alfatestide rakendamisel
Peamised vead, mida alfatestijad peaksid vältima, on järgmised:
1. Kehv ajakava
Alfa-testimise aeg sõltub tavaliselt sellest, kui keeruline on tarkvara, ja on oluline, et kvaliteedi tagamise meeskond planeeriks seda. Ilma hea ajakavaga ei pruugi testijad enne selle etapi lõppu kõiki uuringuid läbi viia.
2. Kohanemisvõime puudumine
Testijad peaksid valmistuma võimaluseks, et tarkvara vajab tõsiseid muudatusi, et rahuldada kasutajaid – nad peavad olema paindlikud igas testis. Näiteks kui meeskond avastab, et nende testjuhtumid on ebapiisavad, peavad nad seda uuendama ja uuesti läbi viima.
3. Ebapiisav katvus
Alfa-testimine seab esikohale kasutatavuse ja funktsionaalsuse; see tähendab, et testjuhtumid peavad täielikult hõlmama rakenduse neid osi. Kui meeskond ei suuda kõiki rakenduse funktsioone enne ettevõtte tähtaega või avaldamiskuupäeva piisavalt põhjalikult testida, võivad neil jääda tähelepanuta tõsised tarkvaraprobleemid.
4. Ebakorrektne automatiseerimine
Kui kvaliteedi tagamise meeskond rakendab valesti kolmanda osapoole automatiseerimistarkvara, mõjutab see oluliselt teste ja nende kehtivust. Liigne tuginemine automatiseerimisele võib viia selleni, et nad ei märka tõsiseid disaini- ja kasutatavusprobleeme – ainult teatud automatiseerimisprogrammid suudavad arvestada inimese vaatenurka.
5. Beeta-testimine puudub
Kuigi alfa-testimine on eriti põhjalik, ei testita selle käigus kõiki tarkvara aspekte; laiaulatuslikuma katvuse tagamiseks on sageli vaja teha beetatestimine. Beeta-testide lisamine meeskonna strateegiasse näitab neile ka seda, kuidas üldsus tõenäoliselt nende tarkvaraga tegeleks.
6. Regressioonitestide tähelepanuta jätmine
Regressioonitestid on mõne funktsiooni alfa-testimisel väga olulised; see kehtib eriti siis, kui neid võrreldakse eelmiste iteratsioonidega. Ilma nende kontrollideta on testijad vähem võimelised mõistma uute vigade põhjuseid ja seega ei saa nad anda usaldusväärset tagasisidet, kuidas neid parandada.
7. Ühildumatute andmete kasutamine
Mock andmed on kriitilise tähtsusega kogu alfa testide ajal, eriti kui kontrollitakse, kas andmebaas töötab – paljud testimismeeskonnad täidavad seda ilma, et see peegeldaks kasutaja sisendeid. Ainult realistlikud andmekogumid, mis võtavad arvesse praktilisi stsenaariume, võimaldavad usaldusväärselt testida rakenduse sisemisi toiminguid.
5 parimat alfatestimise tööriista
Siin on viis kõige tõhusamat tasuta või tasulist alfa-testimise vahendit:
1. ZAPTEST Free & Enterprise versioonid
Nii ZAPTESTi Free kui ka Enterprise versioonid pakuvad tohutuid testimisvõimalusi – see hõlmab täielikku korpuse automatiseerimist veebi-, töölaua- ja mobiiliplatvormide jaoks. ZAPTEST kasutab ka hüperautomaatikat, mis võimaldab organisatsioonidel arukalt optimeerida oma alfa-testimise strateegiat kogu selle protsessi jooksul.
Veelgi suurema kasu saamiseks rakendab see programm arvutinägemist, dokumentide teisendamist ja pilveseadmete majutamist. Kui ZAPTEST on teie organisatsiooni käsutuses, on võimalik saada investeeringu tasuvus kuni 10-kordne.
2. LambdaTest
LambdaTest on pilvepõhine lahendus, mille eesmärk on kiirendada arendustegevust ilma kärpimata – see võimaldab testijatel uurida rakenduse funktsionaalsust erinevates operatsioonisüsteemides ja brauserites.
See testimisprogramm kasutab peamiselt Seleniumi skripte ja seab esikohale brauseri testimise, mis võib piirata selle funktsionaalsust kasutajate jaoks, kuid see on võimeline ka Androidi ja iOSi rakendusi hoolikalt kontrollima. Kasutajad teatavad aga ka, et tarkvara on oma niši jaoks kallis ja pakub piiratud automatiseerimisvõimalusi.
3. BrowserStack
Teine võimalus, mis tugineb suuresti pilveteenustele, BrowserStack sisaldab reaalset seadmekataloogi, mis aitab kasutajatel teha alfa-teste üle 3000 erineva masina. Sellel on ka põhjalikud logid, mis võivad lihtsustada defektide logimise ja vigade parandamise protsesse.
See rakendus aitab jällegi peamiselt veebi- ja mobiilirakenduste puhul, kuigi selle pakutav ulatus on väga kasulik. BrowserStacki õppimiskõver on samuti üsna järsk, mis muudab selle algajatele ebapraktiliseks.
4. Tricentis Testim
Tricentisel on eraldi testide automatiseerimise ja testihalduse platvormid laiema katvuse tagamiseks – mõlemad variandid suudavad pakkuda läbivat testimist erinevate seadmete ja süsteemide vahel. Tänu tehisintellektiga automatiseerimisele on Testim tõhus rakendus, mis kasutab täielikku Agile-ühilduvust, et optimeerida alfa-testimise etappe veelgi.
Vaatamata sellele funktsionaalsusele ja intuitiivsele kasutajaliidesele ei ole võimalik teatavaid testitoiminguid tühistada ja skripti tasandil on vähe ligipääsetavuse aruandlusfunktsioone.
5. TestRail
TestRaili platvorm töötab täielikult brauseris, mis lisab mugavust, muutes selle paremini kohandatavaks vastavalt testimismeeskonna praegustele nõuetele. Integreeritud ülesannete nimekirjad lihtsustavad tööde määramist ja rakendus võimaldab juhtidel ka täpselt prognoosida eelseisvat töökoormust.
Lisaks sellele aitab tarkvara aruandlus meeskonnal tuvastada probleeme testikavadega. Suuremate testikomplektide puhul on see funktsioon aga tavaliselt aeganõudev ja platvorm ise võib mõnikord olla aeglane.
Alfa-testimise kontrollnimekiri, näpunäited ja nipid
Järgnevalt on toodud täiendavad nõuanded, mida iga meeskond peaks alfa-testimise ajal meeles pidama:
1. Testida erinevaid süsteeme
Sõltumata sellest, millise platvormi jaoks on tarkvararakendus mõeldud, võib olla mitmeid süsteeme ja seadmeid, mida lõppkasutajad saavad sellele juurdepääsu. See tähendab, et testijad peavad uurima programmi ühilduvust paljude masinate vahel, et tagada võimalikult lai kasutajaskond.
2. Seadke komponendid targalt tähtsuse järjekorda
Teatud komponendid või funktsioonid võivad vajada rohkem tähelepanu kui teised. Näiteks võivad nad suhelda teiste funktsioonidega ja anda märkimisväärse panuse rakenduse üldkoormusse. Meeskonnad peavad leidma tasakaalu laiuse ja sügavuse vahel, mis siiski mõistab programmi põhikomponentide keerukust.
3. Määratlege testimise eesmärgid
Isegi kogenud kvaliteedi tagamise meeskond peab keskenduma selgelt oma eesmärgile, et tagada edukas testimise komplekt. See annab testijatele struktuuri ja prioriteedid, mis aitavad neid iga kontrolli käigus suunata. Põhjalik dokumentatsioon on üks võimalus tagada, et meeskond teab, millist lähenemisviisi võtta.
4. Kaaluge hoolikalt automatiseerimist
Kuigi ajajuhtimine on alfa-testimise ajal esmatähtis, ei saa meeskond automatiseerimistarkvara valimisega kiirustada. Nad peavad enne otsuse tegemist uurima kõiki olemasolevaid võimalusi – sealhulgas nii tasuta kui ka tasulisi rakendusi -, sest igal platvormil on erinevad funktsioonid, mis aitavad meeskonda ainulaadsel viisil.
5. Soodustada suhtlemist
Alfa-testimine on tundlik protsess, mis nõuab täielikku koostööd testijate ja arendajate vahel, eriti kui esimene leiab tarkvaraprobleemi. Meeskonnajuhid peavad töötama selle nimel, et vältida teabesilosid, ja peaksid välja töötama kõikehõlmavad aruandlusstrateegiad, et testijatel oleks lihtsam teavitada arendajaid kõikidest vigadest.
6. Säilitada lõppkasutaja perspektiivi
Kuigi beetatestimine keskendub rohkem kasutajakogemusele, peaks alfa-testimine seda siiski iga kontrolli puhul silmas pidama. Võib esineda tõsiseid kasutatavusprobleeme, mida liigne tuginemine automatiseerimisele ja valge kasti testimisele ei suuda lahendada – paljud neist kontrollidest peavad arvestama kasutajaga.
Kokkuvõte
Ettevõtte alfatestimise strateegia edu sõltub suuresti sellest, kuidas nad seda rakendavad – näiteks sellest, kuidas meeskond läheneb automatiseerimisele. Alfa testid peaksid moodustama olulise osa ettevõtte kvaliteedi tagamise protsessist, kuna see on kõige tõhusam viis rakenduse suuremaid ja väiksemaid probleeme tuvastada.
Kolmanda osapoole testimistarkvara võib optimeerida alfa-testimist veelgi nii kiiruse kui ka katvuse osas. ZAPTEST on eriti kasulik testimisplatvorm, mis pakub kasutajatele palju nii oma tasuta kui ka ettevõtte versioonis, pakkudes uuenduslikke funktsioone, millest saab kasu iga testimismeeskond.
