Johdatus ohjelmistotestajatyöhön
Mikä on ensimmäinen asia, joka mielessäsi ajatellessasi ohjelmistotestaustehtävää? Ei koodaava teos? Tai ammatti, joka on erittäin helppo, koska se antaa sinulle mahdollisuuden löytää virheitä muissa töissä (virheiden löytäminen, kun muissa on helpoin tehtävä meille kaikille)? Tai luuletko sitä ammattina, joka käsittelee tuotteen oikeellisuuden tarkistamista? Kaikki nämä ajatukset ovat paikkansapitäviä ja ovat ohjelmistotestaustyön päivittäisiä toimia. Ohjelmistojen testaaminen ei kuitenkaan rajoitu vain näihin toimintoihin.
Hakemuksen ymmärtäminen
Sovellus voi olla mistä tahansa verkkotunnuksesta - terveydenhuolto, vakuutus, rahoitus jne. Sovellusalueen oppiminen on erittäin tärkeää kaikille ohjelmistotöille, jotta avataan ovet ajattelua eri näkökulmista ja erilaisista käyttäjän näkökulmista testattaessa sovellusta. Tästä on aina odotettavissa selkeiden ja ei niin ilmeisten sovelluspolkujen paljastaminen ja validointi. Perusteellisen tietämyksen saaminen sovelluksesta auttaa validoimaan tuotetta tehokkaasti samalla, kun testaaja voi tulla hyödyksi projektille, jossa häntä pidetään yhtenä tuotteen käyttäytymistä koskevista ensisijaisista tietolähteistä.
Vaikka verkkotunnuksen ja toiminnallisuuden oppiminen on jatkuva prosessi, muille tärkeille tekijöille on testitietojen tuntemus.
Testausprosessi
Testausprosessi voi vaihdella yrityksestä toiseen tai jopa projektista toiseen. Nykyään meillä on erilaisia ohjelmistokehitysmalleja, kuten V-malli, prototyyppimalli tai kokonaan erilainen menetelmä, kuten ketterä lähestymistapa ohjelmistokehitykseen. Kehitysmallin muutoksen myötä myös noudatettava testaustapa vaihtelee. V-mallissa työskentelemällä on hyvin määritellyt prosessit, kun taas ketterässä metodologiassa työskentelyn odotetaan testaavan jatkuvasti muuttuvissa olosuhteissa.
Työ ei ole vielä sujuvaa, kun sinulla on hyväksyttävä verkkotunnuksen tuntemus ja testausprosessin ymmärtäminen. Seuraava haaste, joka elämän mukana tulee, on erilaisten työkalujen oppiminen.
Työkalut
Työkalut tarkoittavat testinhallintatyökaluja, vikojen kirjaustyökaluja, tietokannanhallintatyökaluja ja niin edelleen.
Erilaisten viankeruuohjelmistojen ominaisuuksien ja työkalujen, joidenkin avoimen lähdekoodin ja joidenkin lisensoitujen kanssa on aina etuna tuntea useampi kuin yksi työkalu. Se auttaa sitä helposti siirtämään projekteja tai ryhmiä seuraamaan erilaisia työkaluja. Alueella, prosessilla ja työkaluilla on riittävä tietämys. Ohjelmistojen testaajan työssä on enemmän elämää, mikä tekee hänen työpäivästään haastavan ja jännittävän. Tiimien välinen yhteistyö on yksi tärkeä tekijä minkä tahansa projektin onnistumisessa ja tehokkaan yhteistyön kannalta viestinnällä on erittäin tärkeä rooli.
Suositellut kurssit
- Suorita täydellinen J2EE-kurssi
- Online R-ohjelmoinnin koulutus
- Siirry ohjelmointikurssille
- Verkkosertifiointikoulutus Haskell-ohjelmassa
viestintä
Viestinnällä on erittäin tärkeä merkitys ohjelmistolle, jolle se on ominaista, koska ohjelmistokehityksen alkuvaiheista lähtien testausryhmän jäsenet ovat mukana (parhaana käytäntönä) keskusteluissa vaatimuksista, kyselyyn yritysanalyytikoille mahdollisten kysymysten tai puutteiden suhteen. Tehokkaalla viestintätaidolla varustettu ohjaaja voi kommunikoida riskit tehokkaasti, kommunikoida tehokkaasti kehitysryhmän kanssa ja kommunikoida tehokkaasti testituloksissa ja testausraporteissa.
Ohjelmistojen testaajan toimintojen suunnittelu
Kuten nimestä voi päätellä, testisuunnittelu on vaihe, jossa valmistelu testaukseen tehdään. Testerin valmisteluun sisältyy erityyppisiä toimia, joita tster tekee sovelluksen tehokkaaseen soveltamiseen. Tämä auttaa sovelluksen validointia ja sovelluksen virheiden paljastumista tehokkaasti. Suunnittelun aloittamiseksi testataan vaatimukset ymmärtää odotukset.
1. Vaatimukset
Testausryhmälle voidaan antaa vaatimuksia kehysten, kuvakäsikirjojen ja excel-lomakkeiden muodossa. Kaikkien näiden asiakirjojen tarkoituksena on esitellä asiakkaan vaatimukset tehokkaasti ja helposti ymmärrettävällä tavalla. Rautalangan asiakirja ei ole muuta kuin asiakirja, joka voi olla PowerPoint-esityksen muodossa, joka kuvaa asiakkaan vaatimuksia. Samoilla linjoilla kuvakäsikirjoitukset kuvaavat yleensä näytöiden vaaditun ulkoasun / suunnittelun. Nykyään markkinoilla on saatavana erilaisia työkaluja, joita voidaan käyttää tarvittavien asiakirjojen valmisteluun. Tarvittavien asiakirjojen luominen on ensisijaisesti yritysanalyytikon vastuulla. Maun odotetaan ymmärtävän vaatimukset perusteellisesti. Jotta sekä kokeilijat että kehittäjät ymmärtäisivät vaatimukset oikein, liike-elämän analyytikot pitävät foorumin avoinna kaikille, jotta he voivat ottaa esiin ja saada kyselyihin vastauksia jokaisesta vaatimuksesta. Alusta avoimien kysymysten ja kyselyjen keskustelemiseksi ja kommunikoimiseksi vaihtelee projektikohtaisesti. Se voi olla sähköpostiketju tai neuvottelupuhelu tai jopa ylläpidetty jaettu asemavarasto, joka pitää ajan tasalla kaikki avoimet kysymykset ja niiden vastaukset, kuten liike-elämän analyytikko tarjoaa.
Selkeä viestintä ja viestinnän tietueilla on erittäin tärkeä rooli todistamisessa. Pieni oletus vaatimuksesta voi joskus johtaa merkittäviin virheisiin tuotteessa. Ohjelmistojen testaajalle suositellaan jokaisessa vaiheessa ominaisuuksia viestinnän pitämiseksi puhtaana. Ohjelmistojen testaaja Työviestintä voi tapahtua yritysanalyytikkojen kanssa tai jopa tiimin sisällä. Selkeä viestintä auttaa pitämään oletukset poissa suunnittelun ja toteutuksen aikana. Samanaikaisesti on suositeltavaa olla viestintätietue (mieluiten sähköpostikommunikaatio). Kirjallisen tiedonannon pitäminen vaatimusten kyselyistä auttaa testin suorittamisen myöhemmissä vaiheissa, joissa toiminnallisuutta ei ehkä ole kehitetty, kuten tallennetussa viestinnässä vahvistetaan.
2. Skenaario
Kun vaatimukset on ymmärretty, testaaja alkaa dokumentoida skenaarioita testiskenaario-asiakirjassa. Skenaario, kuten nimestä voi päätellä, on toimivuusvirta, jota käyttäjä seuraa tehtävän suorittamiseksi.
Esimerkkejä skenaarioista -
- Käyttäjän pitäisi voida kirjautua sisään onnistuneesti.
- Käyttäjän pitäisi voida varata liput järjestelmään.
- Käyttäjän pitäisi voida peruuttaa liput järjestelmässä.
- Käyttäjän pitäisi voida nähdä / päivittää profiilin yksityiskohdat.
Nämä ovat loogisia tehtäviä, jotka käyttäjä suorittaa järjestelmässä. Nämä ryhmitellyt loogiset tehtävät auttavat ikääntymään muistamaan kaikki mahdolliset skenaariot, jotka käyttäjän odotetaan suorittavan. Nämä skenaariot dokumentoidaan yleensä Excel-arkeissa tai joskus käyttämällä joitain työkaluja. Sananlaskija menee poimimaan kaikki tällaiset skenaariot vaatimusasiakirjoista. Tällaisia skenaarioita sisältävää asiakirjaa kutsutaan testiskenaario-asiakirjaksi (tai jonnekin korkean tason asiakirjaasiakirjaksi). Tämä asiakirja toimii syöttöasiakirjana testitapausten laatimiseen.
3. Asia
Tämä on yksityiskohtaisempi versio Software Tester -työn skenaariosta, jossa skenaario on jaoteltu yksityiskohtaisempiin vaiheisiin, jotka käyttäjä tosiasiallisesti suorittaa käyttäessään sovellusta. Edellä mainittuihin skenaarioihin perustuva yksinkertainen esimerkki on:
Skenaario - Käyttäjän pitäisi voida kirjautua sisään onnistuneesti.
Testitapaukset:
- Varmista, että käyttäjä pystyy syöttämään oikean käyttäjänimen.
- Varmista, että käyttäjä pystyy syöttämään salasanan.
- Vahvista napsauttamalla sisäänkirjautumispainiketta oikean käyttäjänimen ja salasanan syöttämisen jälkeen, käyttäjä pystyy kirjautumaan sisään.
Tällainen luettelo näistä tapauksista voi edelleen sisältää validointitarkistuksen jokaisessa kentässä, negatiivisten skenaarioiden tarkistamisen ja niin edelleen.
Alla on esimerkkejä näistä tapauksista -
- Varmista, että käyttäjänimi, kun sitä ei syötetä, järjestelmä antaa asianmukaisen virheen.
- Varmista tämä salasana, kun sitä ei ole annettu, järjestelmä antaa asianmukaisen virheen.
- Varmista, että käyttäjänimi ja salasana, kun niitä ei syötetä, järjestelmä antaa asianmukaisen virheen.
- Tarkista, että syöttäessäsi väärän salasanan järjestelmä lähettää asianmukaisen virheviestin.
- Tarkista, että syöttämällä väärän käyttäjänimen, järjestelmä antaa asianmukaisen virheviestin.
4. Vaatimusten jäljitettävyysmatriisi (RTM)
Vaatimusten jäljitettävyysmatriisi, kuten nimestä voi päätellä, auttaa todistamaan liiketoiminnan tarjoamien vaatimusten kattavuuden tarkistamisen ja sisällyttämisen testausasiakirjoihin, kuten skenaarioihin ja testitapauksiin.
Paras käytäntö on, että tämä on erillinen asiakirja, joka osoittaa vaatimuksen numeron kartoittamisen skenaarioiden / tapausten kanssa, joissa tämä vaatimus sisältyy.
Tätä asiakirjaa ei välttämättä käytetä kaikenlaisissa hankkeissa, mutta käytettynä se auttaa vahvasti jäljittämään vaatimuksiin vastaavat korkean tason skenaariot. Se osoittaa kattavuuden ja sitä voidaan käyttää tarkistamaan ainakin yksi näistä tapauksista jokaisen vaatimuksen suhteen. RTM-asiakirjan luomista ja ylläpitämistä pidetään parhaana käytänteenä, mutta kaikenlaiset projektit (kuten ketterä) käyttävät ohjelmistoja eivät todista työdokumenttia. Kun vaatimukset muuttuvat hyvin usein, tämän asiakirjan ylläpitäminen voi kuulua. Tämän yleiskustannusten välttämiseksi ja samalla tavoin jäljittää vaatimukset, jotkut projektit sisällyttävät jäljitettävyysosan Software Tester -työtapaukseen tai sen skenaariodokumenttiin.
Tärkeä asia on saada tapa jäljittää skenaariot / tapaukset vaatimuksiin ja päinvastoin. Hyvin dokumentoidut vaatimukset tekevät Proverille näiden asiakirjojen luomisen ja ylläpidon helpomman. Moniselitteiset vaatimukset, jatkuvasti muuttuvat vaatimukset tekevät todistajien elämästä haastavamman ja voivat johtaa epäjohdonmukaisiin toimitettaviin asiakirjoihin, jotka johtavat puuttuvaan validointiin ja siten lopputuotteen virheeseen.
Testaajan toistaiseksi matka suunnitteli ja valmistautui testattavaksi. Koska sotaan valmistautuminen on osa sotaa, sama pätee myös tähän. Mitä tiiviimpiä nämä asiakirjat luodaan, sitä on entistä helpompi valvoa toiminnallisuus ja paljastaa melkein kaikki viat. Testaajan seuraavan vaiheen vaihe on Suorittaminen.
Ohjelmistojen testaus toimii
Tässä vaiheessa kaikki edellä mainitut asiakirjat otetaan käyttöön. Vaatimuksia käytettiin skenaarion luomiseen, skenaariota käytettiin sen luomiseen. tämä tapausasiakirja on tässä itsensä riittävä asiakirja sovelluksen validoinnin aloittamiseksi. Prover aloittaa sovelluksen validoinnin suorittamalla vaiheet tästä tapausasiakirjasta. Useita näitä tapauksia voidaan käyttää yhden skenaarion validointiin tai jopa yksi testitapaus voi vastata yhtä testiskenaariota. Kaikki riippuu skenaarioiden monimutkaisuudesta tai joskus testitiimissä noudatetusta standardista. Siksi yksi testitapausdokumentti voi sisältää 20-50 testitapausta tai siinä voi olla 100-120 testitapausta. Nämä numerot ovat vain selventäviä tarkoituksia varten, ne voivat vaihdella villinä projektikohtaisesti. Tämän vaiheen tulos on testivirheet. Tässä vaiheessa esiintyvien voimassa olevien vikojen määrä antaa hyvän kuvan sovelluksen vakaudesta, testauksen laadusta, rakennuslaadusta ja monista sellaisista tekijöistä, jotka vaikuttavat suoraan tuotteeseen. Tämä vaihe on tärkein vaihe, kun testaaja menestyy kattamaan kaikki testitapaukset (validoi melkein kaikki vaadittavat käyttäjäpolut) ja nostamaan samalla mahdollisimman monta kelvollista virhettä. Kaikki yritykselle vaaditut valmistelut, viestintätaidot ja kyselyt tulevat toimimaan tässä testausvaiheessa.
Ohjelmistovirheiden testaaja toimii
Suoritettaessa tätä tapausta mikä tahansa käyttäytyminen, joka ei ole yhtä suuri kuin odotettu tulos, nostetaan virheeksi. Jokaisessa testitapauksessa on kuvaus, odotettu tulos ja sarake todellisesta tuloksesta. Vaikka suunnittelutoimisto Software Tester Work -asiakirja sisältää kuvauksen ja odotetut tulokset sekä tyhjän sarakkeen todellisista tuloksista. Suorittaessaan testitapauksia testaajan on tarkoitus täyttää todellinen tulossarake. Samaan aikaan, jos todellinen ei ole yhtä suuri kuin odotettu tulos, vika kirjataan. Vian kirjaaminen ei tarkoita vain kehittäjälle ilmoittamista ongelmasta. Se on jälleen muodollinen prosessi, joka yleensä tehdään työkalun avulla. Tällä hetkellä markkinoilla on erilaisia työkaluja, osa avoimesta lähdekoodista ja osa lisensoiduista. Kaikilla vikojen kirjaustyökalulla on seuraavat kentät -
- Projektin / julkaisun nimi
- Vikayhteenveto
- Vian yksityiskohtainen kuvaus
- Vian vakavuus
- Vian prioriteetti
- Vaihe havaittiin
- Määritetty
- Liitteet
Kuten näemme, kaikkien näiden kenttien tarkoituksena on saada muodolliset prosessiviisaat yksityiskohdat löydetystä aiheesta. Tämä auttaa kehittäjiä toistamaan puutteen ympäristössä ja korjaamaan sen. Alla on lyhyt kuvaus kaikista näistä kentistä -
- Projektin / julkaisun nimi - sen julkaisun nimi, josta vika löytyi, projektilla on yleensä useita julkaisuja ja samalla projektilla voi olla useita aliprojekteja. Tämä kenttä auttaa nostamaan tietyn julkaisun aiheen.
- Vikayhteenveto - Lyhyt yhden linjan kuvaus löydetystä vikasta.
- Vian yksityiskohtainen kuvaus - Tämä on vian yksityiskohtainen kuvaus, sen tulisi sisältää yksityiskohtia, kuten ympäristö, jossa vika löydettiin, ja käytettyjä testitietoja, todelliset tulokset odottivat tulosta ja kaikki lisätiedot, jotka lisäävät arvokkaampaa tietoa sidosryhmille ymmärtää vika. vika.
- Vian vakavuus - Se tarkoittaa, kuinka vakava vika on. Yleensä sillä on arvot, jotka ovat samanlaisia kuin kriittinen, korkea, keskitaso, matala tai numeeriset arvot, kuten 4, 3, 2, 1.
- Vian prioriteetti - Se tarkoittaa, kuinka kiireellisesti vian korjaaminen on tärkeää.
- Vian havaitsemisvaihe - Koska vikaa voidaan kirjata monissa vaiheissa, yksikkötestaus, SIT (järjestelmäintegraatiotestaus), UAT (käyttäjän hyväksymistestaus) tai jopa tuotantovaihe.
- Määritetty - Kehittäjän tai kehitysjohdon nimi.
- Liitteet - Tämä antoi testaajalle mahdollisuuden liittää tilannekuva ruudusta, johon ongelma ilmeni.
Testien suorittaminen ja virheiden kirjaaminen on vaihe, jossa testaajalle voi kohdata monia haasteita. Jotkut heistä kommunikoivat tehokkaasti kehittäjien kanssa. Voisimmeko väittää, että onko vian kirjaaminen kaikilla tarvittavilla tiedoilla riittämätöntä, jotta kehittäjät ymmärtävät vian?
Se on, ja joissakin tapauksissa se vaatii lisätietoja / keskustelua kehittäjien kanssa. On tapauksia, joissa testaaja kohtaa odottamattoman käytöksen, josta hän ei ehkä ole varma, onko kyse viasta. Näihin olosuhteisiin kohtaavat yleensä vankkurit, jotka ovat uusia joukkueessa, joilla on rajallinen verkkotunnuksen tuntemus tai joilla on epäselvyys vaatimuksista. Testaajaa ei tässä syytä syyttää, jos määräajat ovat tiukat ja vaatimukset muuttuvat jatkuvasti. Useimmissa tapauksissa vanhempi oppii verkkotunnuksesta suunnitellessaan ja toteuttaessaan testitapauksia. Kuten voimme nähdä, testaajan polku ei ole niin helppoa kuin se havaitaan. Se vaatii jatkuvasti oppimisasennetta, hyvää kommunikaatiotaitoa, hyvää yhteistyötaitoa ja innokkuutta sopeutua olosuhteisiin, joissa käytetyissä aloissa, työkaluissa, prosesseissa tapahtuu muutoksia. Vaikka puhuimme manuaalisten testaajien matkasta, kokonaisprosessi koskee myös automaatio-testaajia. Toisaalta automatisoinnilla on merkittäviä muutoksia prosessissa, koska testauksen ja suunnittelun laajuus, toteutus vaihtelevat huomattavasti.
Kun otetaan huomioon sananlaskijan matka, kuten edellä käsiteltiin, voimme silti sanoa, että ohjelmistojen testaajaominaisuuksien työ on helpompaa kuin kehittäjän?
Voidaan sanoa, että sen lisäksi, että verrataan testaajan / kehittäjän roolia, on hyödyllisempää käydä keskustelu siitä, kuinka kahden yhteistyö voi johtaa koko tuotteen merkittävään menestykseen. Joskus unohdamme, että testaajan tehtävänä on löytää sovelluksesta ongelmia eikä osoittaa kehittäjien virheitä. Kun unohdamme työn idean, se johtaa toisinaan tarpeettomaan keskusteluun. On kuitenkin havaittu, että on yhtä hyviä testaus-, kehitysryhmiä, joissa kaikki ymmärtävät, että lopullinen tarkoitus on saada sovellus toimimaan odotetusti. Toivotaan, että jokainen tarkastelee testityön positiivista puolta roolina, joka auttaa tuotteen puhdistamisessa, eikä sellaisena, joka vain löytää virheitä!
Suositellut artikkelit
Tämä on ollut opas selkeiden ja ei niin itsestään selvien sovelluspolkujen löytämiseksi ja validoimiseksi, joka on aina ohjelmiston testaajan ensisijainen odotus. Nämä ovat seuraavat ulkoinen linkki, joka liittyy ohjelmistojen testaamiseen.
- Viallinen elinkaari ohjelmistojen testauksessa
- 6 hämmästyttävintä ohjelmistotestauksen haastattelua koskevaa kysymystä
- Ura ohjelmistotestauksessa