Šiuolaikinis testavimas - kokybės užtikrinimo vaidmens raida

Programinės įrangos kūrimas vystėsi nuo krioklio, „Agile“ ir dabar „DevOps“ laikų. Natūralu, kad testavimas kaip disciplina taip pat parodė keletą pagrindinių pokyčių, kad pritaikytų naujus darbo ir programinės įrangos pristatymo būdus.

Tačiau vis dar yra didžiulis nesusipratimas ir neteisingas suvokimas apie testuotojų vaidmenį ir viso kokybės užtikrinimą.

Šiame įraše apžvelgsime, kaip vystėsi testavimas, ypač per pastarąjį dešimtmetį, ir ką QA specialistai turi padaryti, kad liktų priekyje.


Testavimas gali būti tik įdomesnis!

Nors programinės įrangos testavimo veikla pasikeitė, kad prisitaikytų prie naujų darbo būdų, vis tiek matau daug senamadiškų požiūrių į testavimą ir kokybės užtikrinimo vaidmenį.


Nudžiugina tai, kad IT pramonėje vis dar yra daugybė žmonių, kurie mano, kad kokybės užtikrinimas ar testuotojai yra svarbiausia. Testuotojai dažnai laikomi tiesiog funkcionaliais testuotojais, kurie testuoja tik tada, kai kūrėjai baigia dirbti su funkcija. „Kokybės užtikrinimas“ suvokiamas kaip bandymas, klaidų radimas ir pranešimas apie jas bei žalios šviesos suteikimas išleidimui.

Dar labiau jaudina tai, kad šis kokybės užtikrinimo vaidmens suvokimas yra pats svarbiausias tarp pačių testuotojų ir kokybės užtikrinimo specialistų.



Tradicinis programinės įrangos testavimas

Istoriškai, bandant būtų vadovaujamasi paskutiniame krioklio projekto etape, jis būtų tvirtai laikomas projekto gyvavimo ciklo dešinėje. Apibrėžę išankstinį reikalavimo apibrėžimą, testuotojai, pasibaigus kūrimo etapui, paėmė kūrėjų komandos estafetę ir dažnai, rankiniu būdu, dažniausiai per nutylėtas komandas ir MVĮ grupes vykdė ilgus, išsamius testavimo scenarijus.

Testų atvejai buvo kruopščiai suplanuoti iš anksto, scenarijus vykdė specialistai, aptiko defektus ir pranešė apie juos, bandymų ciklai buvo vykdomi ir pakartotinai atliekami, kol bus pasiekti iš anksto nustatyti kokybės lygiai.


Visų pirma, kūrėjai ir testuotojai visada buvo aiškiai atskirti, o pareigos ar veikla nesutapo. Iš tiesų, per atskirą, atskirą testavimo etapą, veikla buvo sutelkta vien į funkcinį programinės įrangos patvirtinimą, kurio pagrindinis tikslas buvo rasti ir pranešti apie trūkumus.



QA judrumo amžiuje

Pasirodžius judrioms metodikoms ir darbo būdams, kūrimo ir testavimo veikla buvo sujungta tiek, kad programinės įrangos testavimas nebebuvo atskiras etapas. Vietoj to, testavimas tapo netiesiogine veikla programuojant programinę įrangą.

Kai kuriais atvejais būtų sunku įžvelgti skirtumą tarp „testuotojo“ ir „kūrėjo“, nes kiekvienas turėtų galimybę sklandžiai vykdyti vienas kito veiklą.

„Kokybė“ nustojo tapti vienintele testuotojų atsakomybe ir tapo bendra visų, dalyvaujančių kuriant ir pristatant gaminį, atsakomybe.


Kartu su šia raida bandymo atsakomybė buvo perkelta į kairę nuo kūrimo, iš esmės kepimo kokybę nuo pat pradžių.

Dėmesys buvo nukreiptas nuo pastatytos programinės įrangos defektų paieškos prie to, kad defektai nepatektų į programinę įrangą.

Turėdamas bendrą tikslą užtikrinti, kad produktas ar funkcija būtų funkcionalus ir atitiktų reikalavimus, bet taip pat atitiktų paskirtį ir užtikrintų aukštą vartotojų pasitenkinimą.

Susijęs:


Testuotojų įsitraukimas į istorijos tobulinimą, tarpusavio kodų peržiūras, vienetų testavimą ir tokias praktikas kaip TDD, BDD ir nuolatinis testavimas užtikrino, kad testavimas ir kokybė buvo priešakyje ir buvo įtrauktas į kūrimą.

Nors „Agile“ nuėjo ilgą kelią, kad sujungtų kūrimo ir testavimo veiklą bei praktiką, operacijų komanda vis tiek buvo nutildyta. Du darbo srautai („Dev & Ops“) dažnai nežinojo apie vienas kito veiklą.

Jei gamyboje kas nors suklysta, tyrimas užtruktų ilgai. Kūrėjai neturėjo supratimo apie jų taikymo našumą gamyboje ilgainiui; abiejų komandų bendradarbiavimas nebuvo skaidrus ar aiškus.



Sveiki atvykę į „DevOps“

„DevOps“ reiškia kūrimo ir valdymo komandų bendradarbiavimą kuriant, pristatant, prižiūrint ir palaikant. Tai reiškia nuolatinę išteklių, procesų ir paties produkto sąjungą.


„DevOps“ įgalina nuolatinio integravimo ir vertės perdavimo galutiniam vartotojui metodus.

„DevOps“ judėjimas paskatino naują testavimo perspektyvą ir sukūrė naujas galimybes patiems testuotojams.

Šioje naujoje eroje bandytojai turi būti suderinti tiek su kūrimu, tiek su operacijomis.

Testavimo sritis nebėra tik gaminio, bet ir infrastruktūros, kurioje galiausiai atliekamas produktas, testavimas.

Nuolatinė integracija (CI) ir nuolatinis pristatymas (CD) tapo de facto programinės įrangos kūrimo ir pristatymo standartu, todėl dabar daug bandymų skiriama CI / CD vamzdynui, aplinkai ir infrastruktūrai užtikrinti.

Tai stuburas, palaikantis vystymąsi ir gimdymą.

Jei šių bandymų nepaisoma, aplinka gali būti nenuosekli, švaistyti daug pastangų tiriant pakartotines infrastruktūros problemas ir galiausiai sukelti didelę riziką plėtrai ir greitą pristatymą.



Šiuolaikinis testavimas - kokybės skatinamas vystymasis

Nors daug nuveikta siekiant įtvirtinti kokybę kiekviename kūrimo etape ir dėl to testavimo sritis yra daug platesnė, aš vis tiek manau, kad kokybės užtikrinimo institucijos didžiąją laiko dalį praleidžia ieškodamos funkcinių problemų ir daugiausia dėmesio skirdamos programinės įrangos patikrinimui.

Dauguma kokybės užtikrinimo priemonių nesuvokia savo vaidmens svarbos ir poveikio, kurį jie gali turėti vystymuisi ir įgyvendinimui.

Nepaisant didelių vystymosi praktikos pokyčių per pastaruosius dešimt metų, manau, kad testuotojai vis dar senoviškai žiūri į savo vaidmenį ir todėl yra įsitvirtinę senojoje testavimo eroje.

Testavimas kaip profesija ir testuotojo vaidmuo kurį laiką buvo ugnis, kai atsirado „automatizuotas testavimas“. Ir iš tiesų, daugelis pramonės specialistų vis dar mano, kad testuotojo vaidmuo yra tiesiog išbandyti kūrėjų kuriamą programą, kurią visas galima automatizuoti.

Jei kūrėjams labiau tinka ir yra nuovokiau rašyti kodą, reikalingą automatiniam testavimui, tai ko apskritai reikia bandytojui komandoje?

Atėjo laikas pakeisti tą suvokimą. Turime pripažinti „testavimo“ ir „kokybės užtikrinimo“ vertės ir įgūdžių skirtumą, nes tais atvejais, kai testavimas yra funkcinis programinės įrangos patikrinimas ir patvirtinimas, kokybės užtikrinimas nėra viena veikla. Kokybė yra procesų, įskaitant bandymus, ir geriausios praktikos rinkinys, užtikrinantis, kad vartotojams pristatomas kokybiškas produktas.

Turime siekti kokybės tobulinimo ir į kokybės užtikrinimo profesiją žiūrėti kaip į pagrindinę ir pagrindinę programinės įrangos kūrimo ir pristatymo funkciją, taigi Šiuolaikinis testavimas .

Kokybė jau yra pagrindinis kūrimo komponentas nuo pradžios iki pabaigos, dirbant visame procese. Nors, kalbant paprastai, sakoma, kad pristatymo komandoje visi yra atsakingi už kokybiško produkto pristatymą, aš tvirtai tikiu, kad kokybės užtikrinimo užduotis yra užtikrinti, kad komanda laikytųsi kokybės praktikos.



Kas yra šiuolaikinis kokybės užtikrinimas

Kai bandomoji profesija dažnai buvo vertinama kaip galimybė patekti į plėtrą, projektų valdymą ar kitas - dažniausiai pelningesnes - disciplinas, naujasis kokybės užtikrinimas yra aukštos kvalifikacijos vaidmuo, reikalaujantis visapusiškų žinių apie vystymosi praktiką.

Tam reikia plačiai suprasti kodavimo praktikos iššūkius, įvertinti diegimo metodus ir aplinką, našumo ir saugumo standartus, metodus ir iššūkius.

Tai yra „T“ formos vaidmuo, kai išteklius gali ne tik pritaikyti savo gilias žinias ir patirtį, kad įgyvendintų savo pagrindines užduotis, bet ir pritaikyti platesnes kontekstines žinias architektūros ir plėtros srityje.

Bet kurio projekto centre sėdintis šiuolaikinis kokybės užtikrinimas turėtų gerai suprasti architektūrą, našumą, saugumą ir debesų pasiūlą, būti techniškai pagrįstas ir turėti troškulį mokytis naujų technologijų, kad išliktų žaidime.

Pastaba:Kita sritis, kuri greitai tampa labai populiari ir būtina atliekant duomenų kokybės testavimą, bandant didelius duomenis, duomenų ežerus ir duomenų saugyklas.

Atėjo laikas pakeisti QA vaidmens suvokimą ir tai, ką testuotojai daro. Tai turi prasidėti patys bandytojai. Pradinis taškas yra gilus rūpinimasis kokybe.

Testuotojai yra ne tik tam, kad atliktų funkcinius bandymus ir praneštų apie klaidas. Kokybės užtikrinimo vaidmuo yra daug didesnis. Mes esame suplanuoti projektą užtikrinti kokybės praktiką .

Nuodugniai išbandydami programą, turime turėti pakankamai žinių apie visą sistemos veikimą, o ne tik žiūrėti į programą kaip į juodą langelį.

Norėdami turėti tokių artimų žinių, turime nuolat mokytis ir neatsilikti nuo naujų technologijų bei darbo būdų. Svarbiausia, kad kokybės užtikrinimas turėtų būti pritaikytas.

Kai kokybės užtikrinimo specialistai supranta savo projekto tikslą ir pradeda manyti, kad jų vaidmuo yra pagrindinis programinės įrangos kūrimo ir pristatymo elementas, kai mes laikomės šiuolaikinių testavimo principų, tik tada galime pakeisti kitų suvokimą.