Iman on kokenut laadunvarmistuksen vetäjä, joka työskentelee Québecissä Kanadassa. Hän voitti The Test Factor -palkinnon The Testing Festival 2021 -tapahtumassa, mikä on varmasti hänen uransa tähänastinen kohokohta…
Juttelimme hänen kanssaan kuullaksemme lisää voittaneesta konseptista, siitä, mikä inspiroi häntä, hänen lähestymistavastaan testaukseen sekä hänen tähänastisesta matkastaan. Uskomme, että moni asia resonoi kanssasi!
QAL
Hei Iman, tervetuloa QAL-yhteisöön. Aloitetaan alusta. Miten päädyit testauksen pariin? Olitko kehittäjä ennen testaajaksi ryhtymistä?
Iman Benlekehal
Opiskelin kehittäjäksi, joten osaan koodata, mutta en ole koskaan työskennellyt koodaajana. Opintojeni jälkeen kävin muutamissa työhaastatteluissa, ja yksi niistä koski testaajan paikkaa. Kysyin, ”okei, mitä testaus on?” Haastattelija ei oikeastaan vastannut kysymykseen yksityiskohtaisesti, vaan esitti minulle paljon kysymyksiä persoonastani — häntä kiinnosti luonteeni. Sitten hän kertoi minulle ”sinulla on työhaastattelu ING Directissä, verkkosäästöpankissa”
Kun menin haastatteluun, sama toistui. Haastattelija esitti minulle myös joitakin testausta koskevia kysymyksiä, esimerkiksi: ”Miten testaisit tämän sopimuksen tai nämä korot?” ja ”kuvittele, että meillä on tällaisia tarjouksia tämäntyyppiselle tilille, miten testaisit sen?” Ja muistan esittäneeni hänelle enemmän kysymyksiä kuin hän minulle.
Kun saavuin kotiin, ystäväni kysyi, miten haastattelu meni, ja sanoin ”no, se oli outoa. Esitin hänelle enemmän kysymyksiä kuin hän minulle, enkä osannut vastata hänen testausta koskeviin kysymyksiinsä. En siis tiedä, taisi mennä huonosti.”
Yllätyksekseni minut palkattiin, ja kysyin jatkuvasti itseltäni ”okei, mitä tämä testaus oikein on? Mitä minä tulen testaamaan?” Ensimmäinen esihenkilöni sanoi: ”Et tiedä testauksesta. Tässä on lause tai vaatimus, kirjoita testitapaus.” Sanoin hänelle ”En ole koskaan kirjoittanut testitapausta.” Hän sanoi, ”Tee se, katsotaan sitten” Joten [minä] tein sen. Ja hän sanoi, ”Selvä, osasit sen.” Sitten ajattelin ”Aivan, okei. En siis tule testaamaan painikkeita?” ”Et, sinä tulet testaamaan vaatimuksia. Ovatko ne luotettavia ja ymmärrettäviä?” Joten ajattelin ”Okei, tässä työssä saan esittää kysymyksiä?” Ja hän sanoi, ”Juuri niin.” Siitä hetkestä lähtien testaamisesta tuli intohimoni. Rakastan tätä työtä.
QAL
Eli kuvailisit testausta oikeiden kysymysten esittämiseksi?
Iman Benlekehal
Pidän siitä, että saan esittää miksi- ja miten-kysymyksiä. Ranskassa nuorena opiskelijana ei saa esittää syvällisiä miksi- ja miten-kysymyksiä, ellei ole ensin suorittanut tutkintoa, mutta olen aina halunnut ymmärtää, miksi asiat tapahtuvat. Miksi minua pyydetään tekemään jotakin? Tässä tehtävässä sain oikeuden esittää näitä kysymyksiä. Minulla oli siihen rooli, ja olin siitä todella innoissani. Erittäin innostunut. Se oli ensimmäinen asia, josta pidin.
Toinen syy on se, että pidän ihmisistä ja erilaisten ihmisten kanssa työskentelystä. Rakastan siihen liittyvää haastetta sekä sitä, että ihmiset saadaan puhumaan samaa kieltä ja tavoittelemaan samaa päämäärää. Käyttäjä haluaa yhtä asiaa, esihenkilö [joka] haluaa toista ja kehittäjä sanoo jotakin muuta. Ja sinä olet jotenkin kaiken tämän keskellä, ja sinun on saatava heidät ymmärtämään toisiaan. Juuri siitä haasteesta pidän eniten: ihmisten saamisesta ymmärtämään toisiaan.
Have an account? Log In
QAL
Eli testaus ei ole vain sitä, että tulet mukaan ohjelmiston rakentamisen lopussa, tutkit sitä ja yrität rikkoa asioita?
Iman Benlekehal
Minun mielestäni ei, se on paljon enemmän. Tuo on perusasia, yksi tehtävistä. Oletetaan, että 100 % testeistä on läpäisty. Mikä tekee näiden 100-prosenttisesti läpäistyjen testien tuloksesta käyttäjälle hyvän?
Olet tyytyväinen, koska olet kattanut 100 % vaatimuksista. Mutta mikä saa sinut ajattelemaan, että kattavuutesi vastaa todella tarvittavaa? Jos et näe käyttäjiä etkä ymmärrä miksi- ja miten-kysymyksiä, voit testata mitä tahansa, mutta tulos ei ole oikea.
QAL
Työskenteletkö siis mielelläsi läheisesti UX- ja käyttäjätutkimustiimin kanssa?
Iman Benlekehal
Pyrin työskentelemään kaikkien kanssa. Joissakin projektiryhmissä tuoteomistaja on eturintamassa ja toimii kaikkien, myös käyttäjien, puolestapuhujana. Se sopii minulle, ja työskentelen mielelläni heidän kanssaan. Haluan kuitenkin myös kuulla, mitä käyttäjät todella tarvitsevat laadun näkökulmasta, en vain toiminnallisuuden kannalta. Vaikka tuotepäälliköt kertovat minulle, keitä ihmiset ovat ja ketkä ovat sidosryhmiäsi, laajennan näkökulmaa ja esitän lisää kysymyksiä. Keitä he ovat? Tiedostavatko he, että pyytämäsi asia aiheuttaa tällaisen vaikutuksen? Tällaisia kysymyksiä. Minulle kyse ei siis ole vain testauksesta, vaan se oli vain yksi osa kokonaisuutta.
Aiheeseen liittyvää luettavaa: TESTAUKSEN JOHTAMINEN: TESTAUSTYÖKALUT
QAL
Eli ajattelet kokonaisvaltaisesti koko projektia?
Iman Benlekehal
Täsmälleen.
QAL
Selvä, ymmärsin. Eli tästä sai alkunsa Siirry ylös ja levitä -konsepti? Onnittelut muuten Test Factor -voitostasi!
Iman Benlekehal
Kiitos! Konsepti syntyi työskenneltyäni Ranskassa ja Kanadassa ja huomattuani, että riippumatta toimialasta tai mantereesta meillä on edelleen samat ongelmat. Laatu ja testaus pidetään ainoastaan projektitason asioina. Ja kuten kerroin, laajennan rajoja ja haastan sidosryhmiä, koska jos pidämme ne samalla tasolla yrittämässä ratkaista tai testata kaikkea, mitä täällä annetaan, tiedän kokemukseni perusteella, että käyttäjien kanssa tulee lopulta ongelmia. Meille tulee budjettiongelmia ja muita ongelmia.
Eräänä päivänä sanoin: ”Selvä, lakatkaa ajattelemasta siirtymistä oikealle ja lakatkaa ajattelemasta siirtymistä vasemmalle. Ensinnäkin teidän on mentävä ylöspäin ja saatava hierarkia, ylin johto, vakuuttuneeksi siitä, mitä laatu on. Mitä laadunvarmistus on, mikä tavoitteemme on? Miten se etenee? Miten se toimii? Kyse ei ole vain testauksesta. Ja kun sanomme, että laatu on kaikkien vastuulla, minun näkökulmastani se alkaa heistä. He ovat ensisijaisesti vastuussa kaiken laadusta ja testauksesta.
Siksi tämä ajatus syntyi, tai ainakin nimi syntyi, koska kaikki tietävät, että tästä lähtien meidän on vakuutettava ylin johto ja saatava se jotenkin mukaan. Minulle se on ennakkoedellytys. Se ei ole keskellä. Se on ensimmäinen asia, joka meidän on tehtävä, ennen kuin mietimme, mihin voimme sijoittaa parhaat testausalueet.
Ja sitten levittäminen, koska ei riitä, että menemme vain vakuuttamaan hierarkian, ylimmän johdon tai toimitusjohtajat. Heidän kanssaan on työskenneltävä, jotta laatu voidaan levittää kaikkialle yritykseen ja jotta syntyy laatukulttuuri ja laatuajattelutapa. Jos projekti epäonnistuu tai siinä ilmenee valtava virhe – esimerkiksi sosiaalisissa verkostoissa – sen parissa työskennelleet tiimit eivät jää sinne. Kukaan ei muista sitä henkilöä, joka työskenteli epäonnistuneen projektin parissa, eikä sitä, mikä virheen aiheutti. Ihmisille jää mieleen yrityksen nimi. Siksi kyse on paljon tärkeämmästä asiasta kuin vain siitä, että projekti ja tiimit ovat vastuussa laadusta: kaikki ovat vastuussa.
QAL
Eli sanot, että haluat tulla mukaan muuttamaan koko yrityskulttuuria ja yrityksen ajattelutapaa?
Iman Benlekehal
Täsmälleen. Testaus on vain yksi toimenpide. Se on vain laadun viimeinen osa. Laadun varmistamiseksi on laadittava strategia ja mietittävä, mitä kriteerejä tässä projektissa on korostettava käyttäjien kanssa. Jos käyttäjä esimerkiksi tarvitsee hyvää suorituskykyä, tarvitsemme tämän suorituskyvyn testaamiseen työkalun, ja sattumalta tämä työkalu on erittäin, erittäin kallis. Eikä sille esimerkiksi ollut budjetoitu rahaa, siihen ei ollut varattu lainkaan budjettia. Jälleen asia tulee siis vastaan liian myöhään.
Joten kyllä, meidän on testattava aikaisemmin, mutta meidän on oltava mukana aikaisemmin ja ymmärrettävä laatu sekä laatukriteerit – niitä on ISO 25010 -standardin myötä mielestäni nykyään kymmenen. Käyttäjien on ilmaistava tarpeensa kaikkien näiden kriteerien osalta, ja ylimmän johdon on ymmärrettävä, miksi nämä kriteerit ovat erittäin tärkeitä.
Kun tämä on tehty ja ymmärrämme kaikki riskit, voimme testata. TDD ja kaikki nämä asiat ovat hienoja, ja ne ovat erittäin tärkeitä. En sano, etteivätkö ne ratkaisisi mitään ongelmia, mutta monet ongelmat voidaan ratkaista jo ennen testausta.
QAL
Eli tämä tapahtuu ennen testausstrategiaa ja mallintamista?
More Articles
Iman Benlekehal
Kyllä. Joissakin projekteissa projektipäällikkö on iloinen siitä, että olen mukana hänen tiimissään. He sanovat: ”Selvä, meillä on Iman, hän hoitaa testausstrategian.” Minä sanon: ”Selvä, hienoa. Voitko ottaa meidät mukaan keskusteluun asiakkaan kanssa, jotta voimme esitellä hänelle strategian?”Ja yleensä se sopii heille. He vaikuttavat ymmärtävän ajatuksen ja antavat minun puhua asiakkaan kanssa. Se on täydellistä. Seuraavalla viikolla hän kuitenkin sanoo: ”Selvä, arvioimme budjettisi.” Minä sanon: ”Kuka arvioi laadunvarmistuksen tarvitsemat toimintabudjetit?
He eivät ymmärrä, ettei kyse ole vain teoriasta, jonka mukaan meidän on oltava mukana kaikissa osa-alueissa. Heidän on vaikea muuttaa ajattelutapaansa ja ymmärtää, ettei testaus ja laatu ole vain prosenttiosuus kehittäjien työstä. Luulen, että he käyttävät 40 prosenttia arvioista. Ei ole vielä muodostunut tavaksi hakea laadunvarmistuksen asiantuntijoita mukaan ja sanoa: ”Selvä, tässä on projekti, vaikka laadunvarmistus ei ole mukana. Mitä mieltä olet?”
Ja kokemuksemme avulla voimme tuoda esiin, mitä asiakas todella halusi. Rakastan rivien välistä lukemista ja sanomista: ”Selvä, hän sanoi näin, mutta todellisuudessa se tarkoittaa tätä, tätä ja tätä. Kysy häneltä asiaa, niin näet.” Tämän laadun asiantuntijat tai kokeneet ihmiset, jotka ovat työskennelleet monilla eri toimialoilla, voivat tuoda esiin. On tärkeää auttaa jopa ylintä johtoa ymmärtämään tämä – samoin projektijohtoa.
QAL
Selvä, ymmärretty! Odotan innolla, että näen, miten projekti kehittyy Jonathonin toimiessa uutena mentorinasi. Kiitos ajastasi. Vielä yksi kysymys: onko sinulla neuvoja ihmisille, jotka ovat vasta aloittamassa uraansa testauksen parissa, esimerkiksi siitä, miten heidän kannattaisi lähestyä rooliaan, kehittymistään tai jotakin muuta?
Iman Benlekehal
Jatka kysymysten esittämistä äläkä pelkää, kun ihmiset sanovat sinulle ”ei, sinun osuutesi, sinun roolisi on siellä lopussa.” Ei. QA-testaajilla on valtavan tärkeä rooli. He eivät vain testaa tai suorita, vaan heidän on autettava ihmisiä ymmärtämään toisiaan ja varmistettava, että puhumme samaa kieltä ja tavoittelemme samaa päämäärää. Seuraavien kymmenen vuoden aikana teknologiat kehittyvät, ja ihmisiä tarvitaan vähemmän varsinaiseen testaamiseen, mutta testausfilosofia säilyy ja sitä tarvitaan edelleen erittäin paljon.
Jatka oppimista ja tutustu tähän podcastiin: AUTONOMISEN AUTOMAATION SUKUPOLVI JA MILTÄ SE NÄYTTÄÄ (BERTOLD KOLICS MABLISTA)
