Voitot:
- Kyky muuntaa hajahavainnot raportiksi, joka sisältää selkeän otsikon, deterministiset lisääntymisvaiheet, odotetut/todelliset tulokset ja todisteet tekoälyn tuella
- Kyky asettaa tekoälylle sääntö "käyttää vain antamaani tietoa, älä sovi" ja taata uusittavuus omalla ohjauksellaan
- Kyky erottaa vakavuus (tekninen vaikutus) ja prioriteetti (liiketoiminnan kiireellisyys) ja antaa lopullinen nimike liiketoimintakontekstilla
Testaajan löytämä vika on arvokas vain, jos se korjataan; Sen korjaaminen riippuu suurelta osin virheraportin laadusta – tietueesta, joka dokumentoi vian siten, että kehittäjä voi ymmärtää, toistaa ja korjata sen. Huonosti kirjoitettu virheraportti ("kirjautuminen ei toimi") pysäyttää kehittäjän tuntikausia, johtaa edestakaisin kirjeenvaihtoon ja usein sulkeutuu, koska "ei voi toistaa". Hyvä raportti sisältää selkeät vaiheet, odotetut ja todelliset tulokset, kontekstitiedot ja todisteet. Tekoäly (AI) on erittäin hyvä muuttamaan hajallaan olevat havainnot ammattimaiseksi, jäsennellyksi raportiksi. Mutta keskeinen varoitus pätee myös tässä: AI ei voi keksiä askelia, joita et näe; osaa täyttää puuttuvat tiedot "järkevän näköisillä", mutta epätarkoilla arvauksilla. Sinun tehtäväsi on varmistaa, että raportin jokainen rivi perustuu siihen, mitä todella havaitsit.
Hyvän vikaraportin anatomia
Tehokas raportti sisältää seuraavat osat:
- Otsikko: Lyhyt, täsmällinen, haettavissa. Ei "On virhe"; "Kassa-painiketta ei voi napsauttaa, kun ostoskorissa on yli 10 tuotetta (Chrome)".
- Toistamisvaiheet: Numeroitu, jäljitettävissä tyhjästä, deterministinen. Kehittäjän pitäisi pystyä näkemään virhe näiden vaiheiden jälkeen.
- Odotettu tulos: Mitä hyväksymiskriteerien mukaan olisi pitänyt tapahtua.
- Todellinen tulos: Mitä tapahtui (virheilmoitus, näyttö, toiminta).
- Ympäristö: Selain/laite, versio, ympäristö (testi/live), käyttäjän rooli, tiedot.
- Todisteet: Kuvakaappaus, video, loki, virhejäljitys (pinojäljitys).
- Vakavuus ja prioriteetti: Yksityiskohtaiset tiedot alla.
Vinkki: Ennen kuin lähetät raportin, kysy "jos annan nämä vaiheet jollekin muulle, voiko hän nähdä virheen ilman apuani?" kysyä. Jos vastaus on "ei", raportti on epätäydellinen. Tekoäly voi tehdä raportista kauniin, mutta vain sinä voit taata toistettavuuden.
Väkivalta ja prioriteetti: kaksi sekavaa käsitettä
Vakavuus on virheen tekninen vaikutus: kaatuuko järjestelmä, katoaako tietoja vai onko kyseessä kirjoitusvirhe? Prioriteetti on se, kuinka nopeasti se on korjattava; kyse on vaikutuksesta liiketoimintaan. Nämä kaksi eivät aina mene samaan suuntaan: yrityksen nimen väärinkirjoitus etusivulla on vähäistä, mutta tärkeysjärjestystä (maine). Harvinaisissa reunatapauksissa romahdus voi olla erittäin vakava, mutta matala prioriteetti. AI auttaa sinua tekemään tämän eron, kun annat havainnon; mutta lopullisen nimikkeen annat sinä, joka tunnet liiketoimintakontekstin.
väkivaltaa
esimerkki
etusijalla
esimerkki
Kriittinen (estäjä)
Maksua ei voi suorittaa loppuun
Kiireellinen (P1)
Tulojen menetys livenä
Korkea (pääaine)
Raportti antaa väärän summan
Korkea (P2)
Pakollinen tulevaan julkaisuun
Keskikokoinen (alaikäinen)
Harvinainen reunatapausvirhe
Keskitaso (P3)
Suunnitellussa sprintissä
Matala (triviaali)
Painikkeiden kohdistus on pois päältä
Matala (P4)
Kun on mahdollisuus
Heikko kehote / Vahva kehote
Heikko: "Ilmoita tästä virheestä: maksu ei toimi."
Vahva: "Käännä alla olevat havaintoni normaaliin virheraporttimuotoon: otsikko, toistovaiheet (numeroitu), odotettu tulos, todellinen tulos, ympäristö, vakavuus ja suositus (perusteltu). Käytä vain antamiani tietoja; täytä puuttuvat kentät, merkitse 'TIEDOT PUUTUU: ...'. Havainnot: Chrome 120, testiympäristö, 12 kohtaa, kun autoa ei paineta, mitään ei tapahdu. ei ole toimintovirhe konsolissa, 11 tuotteen kanssa ei ole ongelmaa."
Tehokas kehote; määrää muodon, "sovitussäännön" ja puuttuvien tietojen merkitsemisen. Tällä tavalla raportti on sekä tarkka että rehellinen.
Kaksoisvirheiden havaitseminen
Suurissa ryhmissä sama virhe raportoidaan yhä uudelleen ja uudelleen. Tekoäly voi verrata uutta raporttiasi olemassa oleviin avoimiin virheisiin ja ilmoittaa mahdollisista kaksoiskappaleista – tämä pitää virheenseurantajärjestelmäsi (Jira, Azure DevOps, GitHub Issues) puhtaana. Mutta varokaa: kahdella virheellä, jotka näyttävät samalta pinnalta, voivat olla erilaiset syyt; Vertaa molempien raporttien tuotantovaiheita ja ympäristöä ennen kuin suljet tekoälyn "kaksoiskappaleen" ehdotuksen. Vahingossa suljetusta "kaksoiskappaleesta" itse asiassa puuttuu erillinen virhe.
Virhejäljestä perimmäiseen syyyn: tekoälyn kyky lukea lokeja
Virheraportin teknisin osa on usein virheen jäljitys (pinojäljitys – erittely siitä, mikä koodirivi ja mikä kutsuketju laukaisi virheen). Pitkät ja monimutkaiset tukit voivat väsyttää jopa kehittäjää. Tekoäly lukee satojen rivien lokia ja tiivistää sekunneissa kriittisimmät rivit, mahdollisen perussyyhypoteesin ja koodipisteen, jossa virhe laukaistiin. Tämä sekä lyhentää raporttia että antaa kehittäjälle suoran lähtökohdan.
Muista kuitenkin kaksi rajaa. Ensinnäkin tekoälyn antama perimmäinen syy on hypoteesi, ei todiste; Kehittäjä ei saa yrittää korjata tätä tarkistamatta sitä. Toiseksi lokit sisältävät usein henkilötietoja (sähköposti, käyttäjätunnus, istuntotunnus); Peitä nämä alueet ennen puun asettamista ajoneuvoon. Hyvä käytäntö on ensin pyytää tekoälyä sanomaan "luettelo kentät, jotka täytyy peittää tässä lokissa" ja analysoida sitten puhdistettu loki.
Vinkki: Sen sijaan, että liität koko lokin raporttiin, sisällytä kriittisimmät 3–5 riviä, joista tekoäly tekee yhteenvedon, ja linkin koko lokiin. Näin raportti pysyy luettavana ja tietoja tarvitseva kehittäjä pääsee koko lokiin.
Neljä kopioitavaa mallia
1) Havainnosta raporttiin:
Tehtäväsi: vanhempi QA. Käännä seuraavat raakahavainnot tavalliseksi virheraportiksi: Otsikko / Toistovaiheet (numeroitu) / Odotettu / Todellinen / Ympäristö / Todistushuomautus / Vakavuus + Prioriteetti (perusteltu). SÄÄNTÖ: käytä vain antamiani tietoja; merkitse puuttuva kenttä "PUITTUVAT TIEDOT:..." Havainnot: [raaka muistiinpano]
2) Toistettavuuden valvonta:
Lue tämä virheraportti sellaisen kehittäjän näkökulmasta, joka ei ole koskaan nähnyt vikaa. Seuraa ohjeita ja merkitse paikat, joissa se ei tuota vikaa: epäselvä vaihe, puuttuva edellytys, puuttuvat testitiedot, ohitettu tila. Kerro minulle, mitä tietoja minun pitäisi lisätä kustakin aukosta. Raportti: [liitä raportti]
3) Vakavuus/prioriteettineuvoja:
Kuvailen seuraavan virheen: [virhe + liiketoimintakonteksti]. Anna ehdotukset ja perustelut erikseen vakavuuden (tekninen vaikutus) ja prioriteetin (liiketoiminnan kiireellisyys) osalta. Selitä, miksi nämä kaksi voivat olla erilaisia. Minä teen lopullisen päätöksen.
4) Lokin/virheen jäljitysyhteenveto:
Tutki alla olevaa virhejäljitystä/lokia. Anna minulle yhteenveto (1) perussyyhypoteesista, (2) todennäköisestä koodipisteestä, jossa virhe tapahtui, (3) kolmesta kriittisimmästä rivistä lisättäväksi raporttiin. Peitä, jos henkilötietoja on olemassa.Loki: [liitä loki]
kolme minilaukkua
Tapaus 1 – vapautuminen "en voinut tuottaa". Yhdessä tiimissä 30 % bugeista suljettiin "ei voi lisääntyä". "Toistettavuuden tarkistus" -malli on lisätty raporttiprosessiin; Ennen jokaisen raportin lähettämistä tekoäly merkitsi puuttuvat vaiheet ja edellytykset. Kolme kuukautta myöhemmin "ei voinut tuottaa" -prosentti putosi 30 prosentista 8 prosenttiin. Erona oli, että vaiheet olivat tarkkoja alusta alkaen.
Tapaus 2 – Väärennettyjen askelmien vaara. Testaaja pyysi tekoälyä kirjoittamaan raportin, jossa oli epätäydellisiä havaintoja; Tekoäly lisäsi vaiheen, jota ei koskaan tapahtunut, kuten "käyttäjä ottaa ilmoitukset käyttöön asetussivulta". Kun kehittäjä seurasi tätä vaihetta, hän ei löytänyt virhettä ja menetti aikaa. Tiimi otti käyttöön "käytä vain antamiani tietoja, älä keksi niitä" -säännön; Tehdyt vaiheet poistetaan.
Tapaus 3 – Vakavuus/prioriteettiero. Yrityksen sloganissa oli kirjoitusvirhe kotisivulla. Testauslaite antaisi tämän "matalaksi"; Tekoälykonsultti muistutti, että tekninen väkivalta on vähäistä, mutta liiketoiminnan prioriteetti on korkea (maineelementti, jonka jokainen vierailija saa). Virhe korjattiin samana päivänä "korkean prioriteetin" tagilla.
Yleisiä virheitä
- Epämääräinen otsikko. Hakemattomat, syrjimättömät otsikot, kuten "Ei toimi".
- Puuttuvat / ohitetut vaiheet. Älä kirjoita sitä, mikä on ilmeistä asiayhteydessäsi; kehittäjän epäonnistuminen tuotannossa.
- Anna tekoälyn keksiä. Puuttuvien tietojen täyttäminen "kohtuullisen arvion" avulla; vääriä askeleita.
- Ei kirjoita odotettua tulosta. Sanotaan "väärin", mutta ei määritellä mikä on oikein.
- Sekava väkivalta ja prioriteetti. Luulisi nämä kaksi yhdeksi etiketiksi; Liiketoiminnan vaikutusten arviointi väärin.
- Arkaluonteisia tietoja todisteissa. Oikeiden henkilökohtaisten tietojen jakaminen kuvakaappauksissa/lokeissa peittämättä niitä.
Yhteenvetona
Virheraportin arvo on, että kehittäjä voi toistaa ja korjata vian ilman apuasi. Tekoäly on erittäin hyvä muuttamaan hajahavainnot ammattimaiseksi, jäsennellyksi raportiksi; Se järjestää otsikon, vaiheet, odotetun/todellisen tuloksen, ympäristön ja todisteet ja tarjoaa neuvoja vakavuuden ja tärkeysasteen erosta. Mutta tekoäly voi korvata puuttuvat tiedot; Noudata "käytä vain antamiani tietoja, merkitse puuttuvat" -sääntöä ja takaa toistettavuus itse. Peitä henkilötiedot todisteeksi.
Sovellustehtävä
Ota äskettäin löytämäsi bugi ja muuta raakahavaintosi raportiksi käyttämällä "havainnosta raporttiin" -mallia ("sovitus"-säännön kanssa). Suorita sitten "toistettavuuden tarkistus" ja täytä merkityt aukot. Anna raportti kollegalle ja katso, voiko hän tehdä virheen ilman apuasi. Lopuksi määritä merkinnät "väkivalta/ensisijainen konsultti" kanssa ja viimeistele se oman harkintasi mukaan. Ota huomioon kaikki tiedot, joita tekoäly yrittää saada aikaan prosessissa.
tarkistuslista
- [ ] Otsikkoni on tarkka ja haettavissa.
- [ ] Toistovaiheet ovat tyhjästä, deterministisiä ja täydellisiä.
- [ ] Kirjoitin odotetut ja todelliset tulokset erikseen.
- [ ] Asetus- ja todistetiedot ovat täydelliset; Peittelin henkilötiedot.
- [ ] Asetin tekoälyyn "keksi, merkitse puuttuva" -säännön ja täytin aukot itse.
- [ ] Arvioin vakavuuden ja prioriteetin erikseen ja tein lopullisen päätöksen.