Testavimas be kokybės užtikrinimo šaltinio

Ar įmanoma atlikti pakankamą programinės įrangos testavimą tik su kūrėjais ir BA ir be kokybės užtikrinimo išteklių?

Čia yra dvi minčių mokyklos:

Vienas yra įsitikinimas, kad visos klaidos yra susijusios su kodu ir kad jei jūsų kodo testavimo aprėptis yra labai didelė, iš esmės neturėtumėte turėti jokių klaidų. Kaip bandytojai visi žinome, kad tai netiesa!


Kitas įsitikinimas, kad jūs atliekate pakankamai vieneto bandymų, taip pat atliekate integravimo, sistemos ir vartotojo priėmimo testus, kad įsitikintumėte, jog programa atitinka tikslą. Nors tai atrodo graži idėja, ji nėra praktiška, nes kūrėjai turi įsisavinti naujas funkcijas!

Abu šie įsitikinimai yra kraštutiniai.


Patikrinti savo kodą gali būti veiksminga, nes kaip kūrėjas žinote, kuri jūsų kodo dalis yra sudėtinga ir greičiausiai yra klaidinga, todėl sutelksite dėmesį į tą sritį. Be to, žinodami, kad nebėra kokybės užtikrinimo, esate priversti rašyti kokybės kodą, kaip sako vienas kūrėjas



Pirmajame darbe neturėjau kokybės užtikrinimo. Man pačiam teko įsitikinti, ar mano kodas yra pakankamai kokybiškas prieš jį išleidžiant, ir šis aspektas mane pakankamai kėlė siaubą, kad išmokau rašyti kokybės kodą (o tai iš esmės reiškia, kad jūs kruopščiai tikrinate savo kodą, darote savo kokybės užtikrinimo procesą).

Ar pakanka kūrėjo bandymų?

Manau, kad tai yra geras žingsnis, skatinantis programinės įrangos kūrėjus prisiimti atsakomybę už savo paties kodo kokybę, tačiau išbandę savo kodą, greičiausiai praleisite visas klaidų klases.

Galite būti labai efektyvus gaudydamas tokias klaidas, kokias tik galite sugalvoti, tačiau visų pirma šias klaidas visada yra lengviau užgauti. Testai, kuriuos rašote patys, niekada nepadarys prielaidų klaidoms prielaidose apie tai, ką kodas turėtų daryti, kokias įvestis jis turi tvarkyti ir pan. Norint užfiksuoti tokias konceptualias klaidas, iš tikrųjų reikia rungtynių. Negalima pradėti nuo tų pačių prielaidų rinkinio.


Darbas automatikos testuotoju reiškė, kad turėjau sutelkti dėmesį į abiejų bandymą ir kodavimą tuo pačiu metu, ir aš dažnai stengiausi! Kai kodavau testus, norėjau tik įsitikinti, kad kodas vykdomas, ir atlikti testą, manęs per daug nesijaudino, koks buvo tikrasis testas, nes mano pagrindinis dėmesys buvo skirtas kodavimui. Netrukus supratau, kad automatizuoju nenaudingus testus, kurie nesuteikė jokios vertės.

Kitas svarbus dalykas, į kurį reikia atkreipti dėmesį, yra tai, kad vieneto testavimas užfiksuoja tik programuotojo klaidas kode, vieneto testavimas neaptinka programos gedimų, o tai reiškia, kad jei turite 100% kodo aprėptį, tai nereiškia, kad programa nėra be klaidų.

Nors prieš perduodant savo kodą, visada reikia išbandyti savo kodą, tačiau taip pat svarbu, kad elgesio požiūriu jis būtų antra. Dažnai mes esame per arti kodo, kad tikrai tinkamai jį nugalėtume ir taikytume išties keistiems krašto atvejams, o geri kokybės užtikrinimo žmonės tai sugeba padaryti. Sistemos lygiu atliekant bandymus kitam vartotojų rinkiniui, pavyzdžiui, testuotojams, dažnai gali pasirodyti labai įdomių klaidų.

Be to, tai ne viskas apie funkcinį testavimą. Turime rūpintis našumo testais, saugumo testais, tinkamumo naudoti testavimais ir kt., Kurie reikalingi, jei norime išleisti aukštos kokybės programinę įrangą.


Kodėl mums vis dar reikia kokybės užtikrinimo?

Testuotojai kartais laikomi viso pristatymo vamzdyno trūkumu. Ar ne taip būtų geriau, jei viskas būtų automatizuota be jokio rankinio įsikišimo ir testuotojai, keliantys klaidas, sustabdytų leidimą?

Dalis problemų, kai bandytojai laikomi kliūtimis, kyla dėl to, kad kūrėjai neturi nuosavybės kokybės. Jei visi tikrai manė, kad yra atsakingi už produkto (ne tik kodo) kokybę, kūrėjai ir bandytojai siekia to paties tikslo.

Testuotojai gali kartu su kūrėjais rašyti geresnius testus, o kūrėjai gali padėti testuotojams rašyti automatinius čekius, taip pat mokyti testuotojus apie programos architektūrą, kad jie galėtų sukurti gerus testus, kad surastų sritis, kurios greičiausiai lūžtų atliekant sistemos bandymus.

Idealiame pasaulyje testuotojai neturėtų rasti jokių defektų, ar bent jau nereikšmingi defektai. Kai yra „kokybės užtikrinimo komanda“, kurios užduotis yra rasti defektus, kūrėjams kyla pagunda tiesiog pasikliauti testeriais, kad surastų visus trūkumus, o kūrėjai sutelkia dėmesį į kūrimą ir kodavimą.


Nors „Yahoo“ žingsnis panaikinant kokybės užtikrinimo ir testavimo skyrių skatina kūrėjus prisiimti atsakomybę už produkto kokybę, jis vis dar nėra pakankamai geras, kad užtikrintų patikimą produktą. Be to, net ir bandytojų komandoje jūs vis tiek negalite garantuoti programinės įrangos be klaidų, tačiau svarbu įsitikinti, kad į programinę įrangą žvelgiama iš įvairių požiūrių taškų ir skirtingų perspektyvų, ir tai yra tikroji to nauda ateina gera kokybės užtikrinimo funkcija (priešingai nei kokybės užtikrinimo komandai).

Testuotojai gali užtikrinti, kad kūrėjai laikosi geriausios kokybės užtikrinimo praktikos, ir padėti rengiant techninius bei verslo testus, kad būtų galima nustatyti svarbiausias klaidas prieš išleidžiant programinę įrangą.