Hei kaikki! Nimeni on Yulia ja olen testaaja. Viime vuonna kerroin sinulle bagodelnya - Yrityksessämme järjestettävä tapahtuma virhekannan siivoamiseksi. Tämä on täysin varteenotettava vaihtoehto vähentää sitä merkittävästi (10 prosentista 50 prosenttiin eri ryhmissä) vain yhdessä päivässä.

Tänään haluan kertoa teille kevään Bagodelny-formaatistamme - BUgHunting (BUH). Tällä kertaa emme korjanneet vanhoja bugeja, vaan etsimme uusia ja ehdotimme ideoita ominaisuuksille. Leikkauksen alla on paljon yksityiskohtia tällaisten tapahtumien järjestämisestä, tuloksistamme ja osallistujien palautteesta.

Harkittuamme ja kirjoitettuamme säännöt, lähetimme yritys Slackin kaikille kanaville kutsun, joka ei sisältänyt rajoituksia:

Tämän seurauksena noin 30 henkilöä ilmoittautui - sekä kehittäjiä että ei-teknisiä asiantuntijoita. Varasimme tapahtumaan koko työpäivän, varusimme suuren kokoushuoneen ja järjestimme lounaat toimiston ruokalassa.

Miksi?

Vaikuttaa siltä, ​​​​että jokainen joukkue testaa toimivuuttaan. Käyttäjät ilmoittavat meille virheistä. Miksi edes järjestää tällainen tapahtuma?

Meillä oli useita maaleja.

1. Esittele kaverit lähempänä aiheeseen liittyviä projekteja/tuotteita.
   Nyt yrityksessämme kaikki työskentelevät erillisissä ryhmissä - yksiköissä. Nämä ovat projektitiimejä, jotka työskentelevät oman osansa toiminnallisuuden parissa, eivätkä ole aina täysin tietoisia muiden projektien tapahtumista.
2. Esittele vain kollegasi toisilleen.
   Moskovan toimistossamme työskentelee lähes 800 työntekijää, eivätkä kaikki kollegat tunne toisiaan silmästä.
3. Paranna kehittäjien kykyä löytää vikoja tuotteistaan.
   Edistämme nyt ketterää testausta ja koulutamme kaverit tähän suuntaan.
4. Ota testaukseen enemmän kuin vain tekniset asiantuntijat.
   Teknisen osaston lisäksi meillä on monia kollegoita muilta erikoisaloilta, jotka halusivat puhua enemmän testauksesta, siitä, kuinka virheestä ilmoitetaan oikein, jotta saamme vähemmän viestejä, kuten "Ahhh... mikään ei toimi."
5. Ja tietysti löytää hankalia ja ilmeisiä vikoja.
   Halusin auttaa tiimejä testaamaan uusia ominaisuuksia ja antaa heille mahdollisuuden tarkastella toteutettuja toimintoja eri näkökulmasta.

Реализация

Päivämme koostui useista lohkoista:

• tiedotustilaisuus;
• lyhyt luento testauksesta, jossa käsiteltiin vain pääkohtia (testauksen tavoitteet ja periaatteet jne.);
• osio "hyvien tapojen säännöistä" kun esittelet vikoja (täällä periaatteet on kuvattu hyvin);
• neljä testausistuntoa projekteille, joissa on korkean tason kuvatut skenaariot; ennen jokaista istuntoa pidettiin lyhyt johdantoluento projektista ja ryhmiin jakamisesta;
• lyhyt kysely tapahtumasta;
• yhteenveto.

(Emme unohtaneet myöskään istuntojen ja lounaan välisiä taukoja).

Perussääntöjä

• Ilmoittautuminen tapahtumiin on henkilökohtainen, joka ratkaisee ongelman, jossa koko tiimi tyhjenee hitaudesta, jos yksi henkilö päättää olla lähtemättä.
• Osallistujat vaihtavat joukkuetta joka istunnossa. Näin osallistujat voivat tulla ja mennä milloin tahansa, ja voit myös tavata useampia ihmisiä.
• komennot kaksi henkilöä ennen jokaista istuntoa muodostuvat satunnaisesti, tämä tekee siitä dynaamisemman ja nopeamman.
• Esitetyistä bugeista sinut palkitaan pistettä (3-10) kriittisyydestä riippuen.
• Kaksoiskappaleista ei anneta pisteitä.
• Joukkueen jäsenen tulee ilmoittaa virheet kaikkien sisäisten standardien mukaisesti.
• Ominaisuuspyynnöt luodaan erillisessä tehtävässä ja osallistuvat erilliseen nimitykseen.
• Tarkastusryhmä valvoo kaikkien sääntöjen noudattamista.

Muut tiedot

• Aluksi halusin tehdä "edenneen" testaustapahtuman, mutta... Melko paljon tyyppejä muista kuin tuotetiimeistä ilmoittautui (SMM, lakimiehet, PR), meidän piti yksinkertaistaa sisältöä huomattavasti ja poistaa monimutkaiset/profiilitapaukset.
• Johtuen Jiran yksiköiden työstä eri projekteissa, kulkumme mukaan, loimme erityisesti erillisen projektin, johon laitoimme mallin bugien esittelyyn.
• Pisteiden laskemiseen aiottiin käyttää webhookien kautta päivitettyä tulostaulukkoa, mutta jotain meni pieleen ja lasku jouduttiin lopulta tekemään manuaalisesti.

Kaikki törmäävät ongelmiin tapahtumien järjestämisessä, ja helpottaakseni tilannettasi kuvailen ongelmiamme, joita voit välttää.

Yksi kaiuttimista sairastui yhtäkkiä ja joutui etsimään uuden.
Olin hurjan onnekas, että löysin korvaajan samasta joukkueesta klo 9). Mutta on parempi olla luottamatta onneen ja olla varaa. Tai ole valmis antamaan tarvittava raportti itse.

Meillä ei ollut aikaa ottaa toimintoja käyttöön, meidän piti vaihtaa lohkot.
Jotta vältetään koko lohkon heittäminen pois, on parempi tehdä varasuunnitelma.

Jotkut testikäyttäjät putosivat, meidän piti nopeasti luoda uusia.
Tarkista testikäyttäjät etukäteen tai pysty tekemään ne nopeasti.

Melkein yksikään kaveri, jolle muotoa yksinkertaistettiin, ei tullut.
Ketään ei tarvitse raahata väkisin. Nöyryytä itsesi.
On mahdollisuus määrätä tiukasti tapahtuman muoto: "amatööri"/"edennyt", tai valmistaa kaksi vaihtoehtoa kerralla ja päättää jälkikäteen kumpi järjestetään.

Hyödyllisiä organisointipisteitä:

• varaa kokous etukäteen;
• järjestä pöydät, älä unohda jatkojohtoja ja ylijännitesuojaa (kannettavien tietokoneiden/puhelimien lataus ei välttämättä riitä koko päiväksi);
• automatisoida pisteytysprosessi;
• laatia rankingtaulukot;
• tehdä paperimonisteita testikäyttäjien kirjautumisilla ja salasanoilla, ohjeet Jiran kanssa työskentelyyn, komentosarjat;
• Muista lähettää muistutuksia viikkoa ennen tapahtumaa ja ilmoittaa myös, mitä sinun tulee ottaa mukaasi (kannettava tietokone/laitteet);
• kerro kollegoillesi tapahtumasta demossa, lounaalla, kahvikupin ääressä;
• sovi devovien kanssa, ettet päivitä tai julkaise mitään tänä päivänä;
• valmistaa kaiuttimet;
• neuvotella ominaisuuksien omistajien kanssa ja kirjoittaa lisää skenaarioita testausta varten;
• tilata herkkuja (keksejä/karkkeja) välipaloiksi;
• muista kertoa meille tapahtuman tuloksista.

Tulokset

Koko päivän aikana kaverit onnistuivat testaamaan 4 projektia ja luomaan 192 bugia (134 niistä ainutlaatuista) ja 7 ongelmaa ominaisuuspyyntöjen kanssa. Tietysti projektin omistajat tiesivät jo joistakin näistä virheistä. Mutta oli myös odottamattomia löytöjä.

Kaikki osallistujat saivat makeat palkinnot.

Ja voittajat ovat termossit, merkit, neulepaidat.

Mikä osoittautui mielenkiintoiseksi:

• osallistujat pitivät kovien istuntojen muotoa odottamattomana, kun aika on rajallinen ja aikaa ei voi viettää paljon ajatteluun;
• onnistui testaamaan työpöytä-, mobiiliversiota ja sovelluksia;
• katselimme useita projekteja kerralla, ei ollut aikaa kyllästyä;
• tapasin erilaisia ​​kollegoita, tarkasteltiin heidän tapojaan esitellä virheitä;
• tunsi kaiken testaajien tuskan.

Mitä voidaan parantaa:

• tee vähemmän projekteja ja pidennä istuntoaikaa 1,5 tuntiin;
• valmistele lahjat/matkamuistot paljon etukäteen (joskus hyväksyntä/maksu kestää kuukauden);
• rentoutua ja hyväksyä, että jokin ei mene suunnitelmien mukaan ja tulee ylivoimainen este.

Arviot

Anna Bystrikova, järjestelmänvalvoja: ”Almutalo on minulle erittäin opettavainen. Opin testausprosessin ja tunsin kaiken testaajien "tuskan".
Testauksen aikana tarkastat aluksi esimerkillisenä käyttäjänä pääkohdat: napsahtaako painike, meneekö se sivulle, onko ulkoasu siirtynyt pois. Mutta myöhemmin huomaat, että sinun täytyy ajatella enemmän laatikon ulkopuolella ja yrittää "rikota" sovellus. Testaajilla on vaikea työ; ei riitä, että "työntää" koko käyttöliittymää, sinun on yritettävä ajatella laatikon ulkopuolella ja olla erittäin tarkkaavainen.
Vaikutelmat olivat vain positiivisia, vaikka nytkin, jonkin aikaa tapahtuman jälkeen, näen, kuinka töitä tehdään löytämieni bugien kanssa. On hienoa olla mukana parantamassa tuotetta ^_^."

Dmitry Seleznev, etupään kehittäjä: "Testaus kilpailutilassa motivoi meitä löytämään lisää bugeja). Minusta tuntuu, että kaikkien pitäisi yrittää osallistua Baghuntingiin. Tutkivalla testauksella voit löytää ne tapaukset, joita ei ole kuvattu testisuunnitelmassa. Lisäksi ihmiset, jotka eivät tunne projektia, voivat antaa palautetta palvelun mukavuudesta."

Antonina Tatchuk, vanhempi toimittaja: "Pidin kokeilemaan itseäni testaajana. Tämä on täysin erilainen työtyyli. Yrität rikkoa järjestelmän, et ystävystyä sen kanssa. Meillä oli aina mahdollisuus kysyä kollegoilta jotain testaamisesta. Opin lisää virheiden priorisoimisesta (olen esimerkiksi tottunut etsimään kielioppivirheitä teksteistä, mutta tällaisen virheen "paino" on hyvin pieni; ja päinvastoin, jokin, mikä ei tuntunut kovin tärkeältä, päätyi kriittinen bugi, joka korjattiin välittömästi ).
Tilaisuudessa kaverit antoivat yhteenvedon testausteoriasta. Tästä oli hyötyä ei-teknisille ihmisille. Ja muutamaa päivää myöhemmin tajusin itseni ajattelevan, että kirjoitin toisen sivuston tueksi käyttämällä "mitä-missä-milloin" -kaavaa ja kuvailen yksityiskohtaisesti odotuksiani sivustolta ja todellisuudesta.

Johtopäätös

Jos haluat monipuolistaa tiimisi elämää, katso toiminnallisuutta tuoreella tavalla, järjestä mini "Syö omaa koiranruokaa", sitten voit yrittää järjestää tällaisen tapahtuman, ja sitten voimme keskustella siitä yhdessä.

Kaikkea hyvää ja vähemmän bugeja!

Lähde: will.com