The playground

More information here

kokeile QA

sanan Ad-hoc merkitys on jotain, joka ei ole järjestyksessä tai ei ole järjestäytynyt tai jäsentymätön. Vastaavanlaisessa muistiossa Ad-hoc-testaus ei ole mitään muuta kuin eräänlainen mustan laatikon testaus tai käyttäytymistestaus. Ad-hoc-testaus suoritetaan noudattamatta mitään virallista prosessia, kuten vaatimusasiakirjoja, testaussuunnitelmaa, testitapauksia jne. Samoin tilapäistä testausta suoritettaessa ei ole olemassa muodollista testausprosessia, joka voitaisiin dokumentoida. Ad-hoc-testaus tehdään yleensä […]

sanan Ad-hoc merkitys on jotain, joka ei ole järjestyksessä tai ei ole järjestäytynyt tai jäsentymätön. Vastaavanlaisessa muistiossa Ad-hoc-testaus ei ole mitään muuta kuin eräänlainen mustan laatikon testaus tai käyttäytymistestaus.

Ad-hoc-testaus suoritetaan noudattamatta mitään virallista prosessia, kuten vaatimusasiakirjoja, testaussuunnitelmaa, testitapauksia jne. Samoin tilapäistä testausta suoritettaessa ei ole olemassa muodollista testausprosessia, joka voitaisiin dokumentoida.

Ad-hoc-testaus tehdään yleensä niiden ongelmien tai vikojen löytämiseksi, joita ei voida löytää virallista prosessia seuraamalla.

tämän testin suorittavilla testaajilla tulee olla erittäin hyvä ja perusteellinen tietämys tuotteesta tai sovelluksesta.

kun testaajat suorittavat ad hoc-testausta, he aikovat vain rikkoa järjestelmän seuraamatta mitään prosessia tai ilman erityistä käyttötapausta.

Ad-hoc-testauksen ominaisuudet

  1. Ad-hoc-testaus tehdään hakemuksen tai tuotteen virallisen testauksen päätyttyä.
  2. tämä testaus suoritetaan tavoitteena rikkoa sovellus ilman mitään prosessia.
  3. ad-hoc-testin suorittavilla testaajilla tulee olla perusteelliset tiedot tuotteesta.
  4. ad-hoc-testauksessa havaitut virheet paljastavat seuratun testausprosessin porsaanreiät.
  5. Ad-hoc-testaus voidaan suorittaa vain kerran, kunnes löydetään vika, joka vaatii uusintatestauksen.

milloin tilapäinen testaus voidaan tehdä?

nyt mieleesi saattaa tulla kysymys, milloin meidän pitäisi tehdä ad-hoc-testaus?

tähän vastatakseni voin sanoa, että Ad-hoc-testaus voidaan tehdä missä vaiheessa tahansa, oli se sitten projektin testauksen alku -, keskikohta-tai loppukoe. Tämä voidaan tehdä vain, kun testaajilla on täydellinen tietämys tuotteesta. Tämä testaus voidaan tehdä myös silloin, kun aika on hyvin rajallinen ja yksityiskohtainen testaus on tarpeen.

kun Ad hoc-testausta ei pitäisi tehdä?

kokenut ja taitava testaaja voi päättää, milloin ad-hoc-testausta ei tehdä. Vaikka on harvoja tapauksia, joissa ad hoc-testausta ei pitäisi tehdä:

  • Ad hoc-testausta ei tarvita, jos testitapauksessa on jo olemassa bugi. Tällaisissa tapauksissa vika on ilmoitettava ja se on testattava uudelleen, kun se on korjattu.
  • Ad-hoc-testausta ei saa tehdä, kun asiakas tai asiakas suorittaa ohjelmiston Betatestauksen.

mitkä ovat Ad-hoc-testauksen tyypit?

periaatteessa on olemassa kolmenlaisia Ad-hoc-testejä. Ne ovat:

– Buddy testing: tämäntyyppisen testauksen tekevät kehittäjä ja testaaja, jotka ovat vastuussa kyseisestä moduulitoimituksesta. Tällaisessa testauksessa kehittäjä ja testaaja istuvat yhdessä ja työskentelevät kyseisen moduulin parissa välttääkseen rakentamasta virheellisiä skenaarioita, jotka toisaalta auttavat testaajaa raportoimaan virheellisistä vioista.

-Paritestaus: tämän tyyppisessä testauksessa kaksi testaajaa työskentelee yhdessä yhdellä moduulilla. He periaatteessa jakavat testiskenaariot keskenään. Tämän tyyppisen testauksen tavoitteena on laatia mahdollisimman suuret testiskenaariot, jotta koko moduulilla olisi täydellinen testipeitto. Koko moduulin testaamisen jälkeen he voivat myös dokumentoida testiskenaarionsa ja havaintonsa.

–Apinatestaus: tämän tyyppisessä testauksessa suoritetaan joitakin satunnaistestejä, joiden tarkoituksena on murtaa järjestelmä. Tämä testaus auttaa meitä löytämään uusia vikoja, joita ei ehkä saada kiinni aikaisemmin.

Ad-hoc-testauksen edut tai hyödyt:

alla muutamia Ad-hoc-testaukseen liittyviä etuja tai etuja:

  1. Ad-hoc-testaus antaa testaajalle vapauden soveltaa omia uusia tapoja testata sovellusta, mikä auttaa heitä selvittämään enemmän vikoja kuin muodollinen testausprosessi.
  2. tämän tyyppinen testaus voidaan tehdä milloin tahansa missä tahansa ohjelmistokehityksen elinkaaressa (SDLC) noudattamatta mitään virallista prosessia.
  3. tämän tyyppinen testaus ei rajoitu vain testiryhmään, vaan sen voi tehdä myös kehittäjä kehittäessään moduuliaan, joka auttaa heitä koodaamaan paremmin.
  4. Ad-hoc-testaus osoittautuu erittäin hyödylliseksi, kun aikaa on vähemmän ja ominaisuuden perusteellinen testaus on tarpeen. Tämä auttaa toimittamaan ominaisuus laadukkaasti ja ajoissa.
  5. Ad-hoc-testaus voidaan suorittaa samanaikaisesti muiden testaustyyppien kanssa, mikä auttaa löytämään enemmän vikoja lyhyemmässä ajassa.
  6. tämän tyyppisessä testauksessa ei tarvita dokumentaatiota, joka auttaa testaajaa tekemään ominaisuuden tai sovelluksen kohdennetun testauksen pelkäämättä muodollista dokumentaatiota.

Ad hoc-testauksen haitat:

  1. koska ad-hoc-testaus tehdään ilman minkäänlaista suunnittelua ja jäsentämättömästi, niin vikojen virkistämisestä tulee joskus iso ongelma.
  2. ad-hoc-testauksen aikana toteutettuja testiskenaarioita ei dokumentoida, joten testaajan on pidettävä mielessään kaikki skenaariot, joita hän ei välttämättä pysty muistamaan tulevaisuudessa.
  3. Ad-hoc-testaus on hyvin paljon riippuvainen ammattitaitoisesta testaajasta, jolla on perusteellinen tietämys tuotteesta, sitä ei voi tehdä kukaan tiimin Uusi jäsen.

parhaat käytännöt ad-hoc-testauksen yhteydessä:

Jos ad hoc-testausta ei suoriteta asianmukaisella tavalla, se voi johtaa täydelliseen ajan ja vaivan menetykseen. Alla on muutamia vinkkejä, jotka kannattaa pitää mielessä, koska missä ja miten tätä ad-hoc-testausta sovelletaan:

  1. hyvä tietämys tuotteesta:

    testaajalla, joka aikoo suorittaa ad-hoc-testauksen, tulee olla erittäin hyvä tietämys tuotteesta. Hänen pitäisi olla hyvin tietoinen kaikista tuotteen ominaisuuksista. Tämä auttaa testaajaa virhearvioinnissa ja vikojen enimmäismäärän löytämisessä vioille alttiilta alueilta.

  2. Priorisointiominaisuus:

    kun usealle ominaisuudelle tehdään ad hoc-testaus, testaajien tulee ensin luokitella ja priorisoida ominaisuudet. Ominaisuudet, joita asiakkaat käyttävät paljon, on testattava ensin niin, että jos ominaisuudessa on jokin prioriteettivirhe, se voidaan ilmoittaa ja korjata aikaisin.

  3. karkea suunnittelu:

    vaikka ad-hoc-testauksessa ei tarvita dokumentaatiota kuten aiemmin todettiin, mutta testauksen aikana testattavien osoittimien merkitseminen muistiin auttaa testaajaa muistamaan kaikki mahdolliset testialueet. Tämä auttaa saamaan suurimman testikattavuuden lyhyemmässä ajassa.

    työkalujen käyttö:

    joskus testauksen aikana lokeista löytyy vikoja tai poikkeuksia, jotka eivät näy käyttöliittymässä tai jotka eivät estä testausta millään tavalla. Tällaiset viat voivat olla myös vakavia. Jotta saisimme kiinni tällaisia vikoja tai poikkeuksia, meidän on käytettävä työkaluja, kuten debuggereita, profiloijia tai tehtävämonitoreja.

  4. havaintojen dokumentointi:

    vaikka ad-hoc-testaus ei tue dokumentaatiota, on aina parempi kirjoittaa lyhyt huomautus testauksesta, havainnoista, poikkeamista. Jos vikoja havaitaan, on luotava asiaankuuluva testitapaus, jotta testaaja voi testata skenaarion uudelleen tulevaisuudessa.

muita suosittuja artikkeleita:

  • mitä on Regressiotestaus ohjelmistoissa?
  • mitä validointi ohjelmistotestauksessa on? tai mikä on ohjelmiston validointi?
  • Apinatestaus – esimerkkejä, eroja, työkaluja,miten tehdään, etuja, haittoja, tyyppejä
  • mitä on Komponenttitestaus?
  • mikä on Uusintakoe? Milloin käyttää sitä? Edut ja haitat

Vastaa

Sähköpostiosoitettasi ei julkaista.