Bandymas su klaida mano galvoje (ne programinės įrangos tipo)

Dirbdamas QA, dažnai girdžiu balsą galvoje: „Ar tikrai viską patikrinote? Kartais tai yra naudingas postūmis, bet jei nepaisoma, tai pradeda tapti problema. Žemiau pakalbėsiu apie šią nemalonią vidinę klaidą ir kaip ji pasireiškia.

Šiame straipsnyje noriu pasidalinti savo mintimis ir įžvalgomis, kurias gavau tyrinėdamas šį reiškinį. Tikiuosi, kad jie jums bus naudingi, ir norėčiau išgirsti jūsų nuomonę apie tai komentaruose. Juk grįžtamasis ryšys yra vienas geriausių būdų pamatyti save iš šalies ir tobulėti.

Vidinės klaidos pranašumai: „Ar esate tikras, kad viską patikrinote?

Tai verčia jus atlikti net paprasčiausias užduotis atsargiai ir dėmesingai detalėms.

Vieną kartą, perjungęs užduotis ir jau baigęs testavimą, nusprendžiau dar kartą viską patikrinti, bet kokiu atveju. Tada ir pastebėjau nedidelę, bet esminę detalę. Užduotyje nebuvo skaičiavimo formulės, kurią turėjo atlikti nauja funkcija. Įdomu, perskaičiau ir užduoties aprašymą, ir epą ir, mano nuostabai, skaičiavimo formulė niekur nebuvo nurodyta. Taigi, kaip aš tai skaičiavau?

Gėdinga pripažinti, bet aš naudoju ir tikrinau skaičiavimus pagal kitos užduoties formulę. Nors dvi užduotys buvo susijusios, formulės turėjo veikti nepriklausomai. Suprasdamas šią klaidą, greitai paprašiau teisingų skaičiavimo taisyklių, iš naujo išbandžiau užduotį ir sužinojau, kad kūrėjas padarė tą pačią klaidą. Jie taip pat naudojo formulę iš kitos užduoties.

Ši įkyri „Little Bug“ leidžia man rasti nereikšmingų klaidų ir padaryti gaminį patikimesnį

Kai aš išnagrinėju bandymo planą, šis mažas trikdžių kelėjas pradeda svaidytis tokias mintis: „O kas, jei klientas naudos didesnį šrifto dydį arba pasenusią OS?

Dėl to aš išsamiau dokumentuoju savo testus ir dažnai į ataskaitas įtraukiu vaizdo įrašus ir ekrano kopijas

Tai nepaprastai naudinga, kai atliekami bandymai, funkcija veikia ir staiga pasirodo klaida. Kai ji identifikuojama ir ištaisyta, patikrinu savo bandymo įrašus, kad nustatyčiau, ar nepastebėjau problemos bandymo metu, ar ji buvo pristatyta vėliau gamyboje. Kartais savo ekrano kopijose ar įrašuose matau klaidą, pasislėpusią. Kai taip nutinka, išsiaiškinu, kodėl tai nepastebėjau ir kodėl nebuvo bandomojo atvejo, kad būtų galima tai užfiksuoti.

Atsižvelgdami į tą save atspindinčią pastabą, pereikime prie šio vidinio balso neigiamų pusių

Tai verčia mane labiau nerimauti, dažnai be rimtos priežasties

Tai kartais nutinka po suklydimo, tačiau taip pat pasitaiko atvejų, kai Little Bug balsas nutyla be provokacijos. Keletą kartų tai nepalikdavo manęs ramybėje net nuėjus miegoti, ir galų gale užsirašydavau sau, ką dar turėčiau patikrinti.

Tai dažnai verčia mane gaišti laiką labai sudėtingiems bandomiesiems atvejams

Tai tiesioginė pirmojo punkto pasekmė: nerimas mano galvoje gimdo keisčiausius ir košmariškiausius scenarijus. Šiuo metu jie atrodo kritiški, bet žvelgiant atgal, dažnai pasirodo, kad jie panašūs į „O kas, jei strazdas švilpia pušyje po mėnuliu?

Tai neleidžia man susikoncentruoti į kitas užduotis

Kartais net perkėlus užduotį į kitą būseną ir pradėjus ką nors naujo, mintys apie tuos bandomuosius atvejus mane persekioja ir neleidžia susikaupti naujai užduočiai. Tokiais atvejais gali būti sunku išjungti nerimą keliantį tikrintuvą-bugą.

Kaip tada galima panaudoti šią klaidą savo naudai ir kaip neleisti jai perimti?

Pirmas dalykas

tai man šovė į galvą, kai rašiau apie minusus – ir tai, ką kartoju kaip mantrą – yra štai koks: išsamus testavimas yra mitas. Klaidų visada bus.

Kad ir koks kruopštus bebūtumėte, neįmanoma numatyti visų veiksmų ir scenarijų derinių, o tai reiškia, kad negalite užfiksuoti kiekvienos klaidos anksčiau, nei tai padarys jūsų vartotojai.

Ypač nuolat besikeičiančiame pasaulyje.

Tai yra kažkas, ką jūs tiesiog turite priimti ir judėti toliau.

Su tuo susitaikyti man padėjo pagrindinių gamybos klaidų – ką kai kurie žmonės vadina postmortems – priežasčių analizė. Tai yra tada, kai kalbatės su visais dalyvaujančiaisiais, kad išsiaiškintumėte, kaip įvyko klaida ir ką galėtume padaryti, kad ji nepasikartotų.

Ir sužinojau, kad dažniausiai rimtus defektus lėmė paprasti apsirikimai: kartais netikrindavo bandomieji atvejai su tuščiomis reikšmėmis, todėl tam tikri produktai parduotuvėje nerodomi; kitais atvejais lokalizacija buvo praleista, todėl ekrano pavadinimas buvo tuščias.

Tačiau dangus nenukrito. Darbas tęsėsi ir mes visi daugiau dėmesio skyrėme vietoms, kuriose anksčiau buvome paslydę.

Antras dalykas

Nutildydavau įkyrų Checker-Bug taikydamas testavimo metodus: sprendimų lenteles ir būsenų perėjimo diagramas.

Tai padeda vizualizuoti programos logiką ir gauti aiškesnį galimų bandomųjų atvejų vaizdą, o tai reiškia, kad galite būti labiau tikri, kad jų nepastebėsite.

Jei jums reikia atnaujinimo, sprendimų lentelė yra lentelė, kurioje įvedame sąlygas ir taisykles į stulpelius ir eilutes. Nurodę visų sąlygų ir taisyklių parinktis, užpildome laukiamą rezultatą.

Būsenos perėjimo diagrama naudojama, kai turime objektą su skirtingomis būsenomis, o objektas keičia savo būseną pagal tam tikras sąlygas. Tai ne visada tinka, bet buvo labai naudinga, kai dirbau kuriant apskaitos paslaugą; tų diagramų objektai buvo tokie, kaip ataskaitos, programos ar skaitmeniniai parašai.

trečia,

vaistas nuo tos įkyrios vidinės klaidos mane iš tikrųjų rado vieną. Paaiškėjo, kad tai buvo bandymų atvejų tarpusavio peržiūra ir bendravimas po suklydimų.

Paprasta, gal net akivaizdu, bet tai veikia kaip žavesys.

Ir ketvirtas

būdas nuraminti mano smegenis buvo įvertinti efektyvumą ir riziką. Kai vidinė klaida pradėjo šnibždėti man į ausį: „Patikrinkite dar keletą bandymų atvejų“, prisiminiau savo komandos vadovą ir užduodavau tris klausimus:

• Kiek tai užtruks?
• Kokia bus nauda?
• Kokia tikimybė, kad tai atskleis ką nors svarbaus?

Taip, kartais prasminga testuoti keliose OS versijose su skirtingais kalbos nustatymais, tamsiomis ir šviesiomis temomis, padidintu šrifto dydžiu ir pan., tačiau dažniausiai šios patikros yra nereikalingos.

Įsivaizduokite, kad atlikdami tokius testus radote klaidą: koks jos prioritetas? Dėl konkrečių atkūrimo veiksmų net avarijai gali būti suteiktas nedidelis prioritetas.

Kiek laiko užtruks šie patikrinimai? Nuo penkių iki dešimties minučių – tai nėra didelis dalykas, bet net ir tiek laiko ne visada yra. Per tą laiką galėtumėte perskaityti vidutinio dydžio užduoties aprašymą.

Baigimas (tikiuosi)

Kaip ir bet kuris įrankis, jūsų nervinga vidinė klaida gali būti palaima arba prakeiksmas. Norint išmokti ką nors efektyviai naudoti, dažnai prireikia patirties ir laiko. Ir tikiuosi, kad šis straipsnis padės greičiau sutramdyti vidinį kritiką, sutaupyti nervų ir sustiprinti pasitikėjimą savimi.

Tiesiog noriu suteikti jums šiek tiek paramos ir galbūt užuot kovoję, kol būsite išsekę, rasite būdą, kaip dirbti su šiuo mažu žvėreliu ir padaryti jį savo sąjungininku.