Esittely
Hyvää iltapäivää, Habrovskin asukkaat. Ratkaisin juuri nyt testitehtävää fintech-yrityksen QA Lead -paikkaan. Ensimmäinen tehtävä, testaussuunnitelman laatiminen, jossa on täydellinen tarkistuslista ja esimerkkejä testitapauksista vedenkeittimen testaamiseen, voidaan ratkaista triviaalisti:
On vaikea kuvitella parempaa testisuunnitelmaa täydellisellä tarkistuslistalla.
Mutta toinen osa osoittautui kysymykseksi: "Onko kaikille testaajille yhteisiä ongelmia, jotka estävät heitä toimimasta tehokkaammin?"
Ensimmäisenä tuli mieleen listata kaikki enemmän tai vähemmän havaittavat ongelmat, joita törmäsin testauksen aikana, karsimaan pois pienet asiat ja tiivistämään loput. Mutta tajusin nopeasti, että induktiivinen menetelmä vastaisi kysymykseen, joka ei koske "kaikkia", vaan parhaimmillaan vain "enemmistöä" testaajista. Siksi päätin lähestyä asiaa toiselta puolelta, deduktiivisesti, ja näin tapahtui.
määritellä
Ensimmäinen asia, jonka teen yleensä, kun ratkaisen uutta ongelmaa, on yrittää ymmärtää, mistä siinä on kyse, ja tätä varten minun on ymmärrettävä sen aiheuttavien sanojen merkitys. Ymmärrettävät avainsanat ovat seuraavat:
- ongelma
- testaaja
- testaajan työ
- testaajan tehokkuutta
Käännytään Wikipediaan ja maalaisjärkeen:
(antiikin kreikan πρόβλημα) laajassa merkityksessä - monimutkainen teoreettinen tai käytännöllinen kysymys, joka vaatii tutkimista ja ratkaisemista; tieteessä - ristiriitainen tilanne, joka ilmenee vastakkaisten asenteiden muodossa minkä tahansa ilmiön, esineen, prosessin selityksessä ja vaatii riittävän teorian sen ratkaisemiseksi; elämässä ongelma muotoillaan ihmisille ymmärrettävässä muodossa: "Tiedän mitä, en tiedä miten", eli tiedetään mitä pitää saada, mutta ei tiedetä miten se tehdään. . Tulee myöhään. lat. ongelma kreikasta. πρόβλημα "heitetty eteenpäin, asetettu eteen"; sanasta προβάλλω ”heittä eteenpäin, aseta eteesi; syyttää".
Siinä ei ole paljon järkeä, itse asiassa "ongelma" = "kaikki, mikä täytyy käsitellä".
- asiantuntija (emme jaa tyyppejä, koska olemme kiinnostuneita kaikista testaajista), joka osallistuu komponentin tai järjestelmän testaamiseen, jonka tulos on:
— joukko testaukseen liittyviä toimia.
(lat. Effectivus) - saavutetun tuloksen ja käytettyjen resurssien välinen suhde (: 2015).
- seuraus toimien (tuloksen) tai tapahtumien ketjusta (sarjasta) laadullisesti tai määrällisesti ilmaistuna. Mahdollisia tuloksia ovat etu, haitta, voitto, menetys, arvo ja voitto.
Kuten "ongelmalla", sillä on vähän merkitystä: jotain, joka tuli esiin työn tuloksena.
- määrällisesti mitattavissa oleva mahdollisuus suorittaa mitä tahansa henkilön tai ihmisten toimintaa; olosuhteet, jotka mahdollistavat tiettyjen muunnosten käytön halutun tuloksen saavuttamiseksi. Testaaja on henkilö, ja elintärkeiden resurssien teorian mukaisesti jokainen henkilö omistaa neljä taloudellista omaisuutta:
käteinen (tulo) on uusiutuva luonnonvara;
energia (elämänvoima) on osittain uusiutuva luonnonvara;
aika on kiinteä ja pohjimmiltaan uusiutumaton luonnonvara;
tieto (informaatio) on uusiutuva luonnonvara, se on osa inhimillistä pääomaa, joka voi kasvaa ja tuhoutua.
Haluaisin huomauttaa, että tehokkuuden määritelmä meidän tapauksessamme ei ole täysin oikea, koska mitä enemmän tietoa käytämme, sitä pienempi tehokkuus. Siksi määrittelen tehokkuuden uudelleen "saavutettujen tulosten ja käytettyjen resurssien väliseksi suhteeksi". Silloin kaikki on oikein: tieto ei mene hukkaan työn aikana, mutta se vähentää testaajan ainoan pohjimmiltaan uusiutumattoman resurssin - hänen ajan - kustannuksia.
päätös
Etsimme siis testaajien globaaleja ongelmia, jotka heikentävät heidän työnsä tehokkuutta.
Merkittävin resurssi, joka testaajan työhön kuluu, on hänen aikansa (loput voidaan vähentää siihen tavalla tai toisella), ja jotta voimme puhua oikeasta tehokkuuslaskelmasta, tulos on myös vähennettävä aikaan. .
Tätä varten harkitse järjestelmää, jonka toimivuuden testaaja varmistaa työllään. Tällainen järjestelmä on projekti, jonka tiimiin kuuluu testaaja. Projektin elinkaari voidaan esittää karkeasti seuraavalla algoritmilla:
- Vaatimusten kanssa työskentely
- Teknisten eritelmien laatiminen
- suunnittelu
- Testaus
- Vapauta tuotantoon
- Tuki (siirry kohtaan 1)
Tässä tapauksessa koko projekti voidaan jakaa rekursiivisesti osaprojekteihin (ominaisuuksiin), joilla on sama elinkaari.
Projektin kannalta katsottuna mitä vähemmän siihen kuluu aikaa, sitä tehokkaampaa sen toteuttaminen on.
Siten päästään testerin suurimman mahdollisen tehokkuuden määritelmään projektin näkökulmasta - tämä on projektin tila, jolloin testausaika on nolla. Kaikkien testaajien yleinen ongelma on kyvyttömyys saavuttaa tätä aikaa.
Miten käsitellä sitä?
Päätelmät ovat melko ilmeisiä, ja monet ovat käyttäneet niitä pitkään:
- Kehityksen ja testauksen tulisi alkaa ja päättyä lähes samanaikaisesti (tämän tekee yleensä osasto ). Ihanteellinen vaihtoehto on, kun kaikki kehitettävä toiminnallisuus on jo valmiina automaattisten testien kattama, organisoitu regressiotestaukseen (ja mahdollisuuksien mukaan pre-commit-testaukseen jollain tavalla). .
- Mitä enemmän ominaisuuksia projektissa on (mitä monimutkaisempi se on), sitä enemmän aikaa joudutaan käyttämään tarkistamaan, ettei uusi toiminnallisuus riko vanhaa. Siksi mitä monimutkaisempi projekti on, sitä enemmän automaatiota tarvitaan .
- Joka kerta kun kaipaamme tuotannossa olevaa bugia ja käyttäjä löytää sen, joudumme viettämään lisäaikaa projektin elinkaaren läpi kohdasta 1 alkaen (Työskentely vaatimusten kanssa, tässä tapauksessa käyttäjät). Koska virheen puuttumisen syyt ovat yleensä tuntemattomia, meillä on vain yksi optimointipolku - jokainen käyttäjien löytämä bugi on sisällytettävä regressiotestiin, jotta voidaan olla varmoja, ettei se toistu.
Lähde: will.com