Johtaminen testauksessa: testiprojektin toteuttaminen

Oletko valmis?

Gladiaattorit, on tullut aika ryhtyä työhön. Tämän artikkelin tarkoituksena on käydä läpi testausprojektin toteuttaminen. Käsittelen seuraavia aiheita:

• Testauksen klassinen puristus
• Onnistumisen ja epäonnistumisen raportointi
• Kattavuuden heikkeneminen
• Poikkeamien hallinta
• Loppuvaiheen hallinta

Oletko nyt valmis? Tässä on neljä kriittistä näkökulmaa:

• Ihmiset – onko tiimisi valmis?
• Ympäristöt – ovatko teknologiat, data, laitteet ja rajapinnat käytettävissäsi merkityksellisten testien toteuttamiseen?
• Tietämys – oletko valmistellut testisi sopivan yksityiskohtaisesti vai onko tiimisi valmis ja kykenevä tutkimaan ja testaamaan järjestelmää dynaamisesti?
• Testattava järjestelmä – onko testattava ohjelmisto tai järjestelmä todella saatavilla?

Kolme ensimmäistä näkökulmaa ovat joko hallinnassasi tai sinulla on keinot seurata, hallita ja koordinoida toimia, joilla varmistetaan ihmiset, ympäristöt ja tietämys. Testattava järjestelmä on eri asia. Jos testattava järjestelmä toimitetaan myöhässä, testauksen aloittaminen mielekkäällä tavalla ei ole mahdollista. Tämä on testauksen klassinen puristus.

Testauksen klassinen puristus

Jokainen järjestelmiä testannut on joutunut kokemaan testattavan järjestelmän myöhästyneen toimituksen. Lähes kaikilla tasoilla komponenteista kokonaisiin järjestelmiin kehittäjät kohtaavat ongelmia, ja toimitus joko viivästyy tai jää puutteelliseksi. Useimmissa tapauksissa testaukselle on määritetty tietty ajanjakso, määräaika ei siirry ja testaus joutuu puristuksiin. Tämä pakottaa tiimit valitsemaan laadun ja nopeuden välillä. Jos etsit työkaluja, jotka tarjoavat molempien parhaat puolet, tutustu parhaiden ohjelmistotestausalustojen luetteloomme.

Osittainen ja vaiheittainen toimitus

Vaikka koko järjestelmää ei voida toimittaa testattavaksi, osa toiminnallisuudesta – osittainen järjestelmä – voidaan toimittaa sillä lupauksella, että myöhemmät julkaisut sisältävät jäljellä olevan toiminnallisuuden. Julkaisun ominaisuuksien tila on kulloinkin jokin seuraavista:

• Valmis vaatimusten mukaisesti: nämä ominaisuudet ovat testattavissa – ainakin erillään.
• Puutteellinen: ominaisuuksista puuttuu toiminnallisuutta ja/tai niiden tiedetään olevan virheellisiä.
• Puuttuu: toimitus on siirretty myöhempään julkaisuun.

Saatavilla olevia ominaisuuksia voi olla mahdollista testata erillään. Ne voivat kuitenkin olla riippuvaisia muiden, vielä saatavilla olemattomien ominaisuuksien luomasta datasta, mikä voi vaikeuttaa niiden testaamista.

Ominaisuudet voivat olla saatavilla, mutta niiden tulosta ei voida varmistaa muiden, vielä saatavilla olemattomien ominaisuuksien avulla. Tällöin ennen testiä ja sen jälkeen otetun testitietokannan tarkastelu on tarpeen. On lähes varmaa, että päästä päähän -testisi, jotka edellyttävät testattavien ominaisuuksien ketjuja, ovat enimmäkseen estyneitä.

Osittaisten järjestelmien järjestelmätason testaaminen on lähes kaikilta osin vakavasti vaikeutunutta.

Testauksen puolustaminen

Tiimisi on edettävä kaikesta huolimatta. Jos järjestelmä ei ole saatavilla tai se on tiimin käytettävissä vain osittain, sinun on hallittava odotuksia ja puolustettava suunnitelmaasi. 

Testaussuunnitelmasi, olipa kyse pienestä tai suuresta kokonaisuudesta, riippuu järjestelmän saatavuudesta – tämä on oletus – joten suunnitelmasi on muututtava. Et ehkä dokumentoi muodollisia aloituskriteerejä, mutta viesti on sama:

Alkutason kriteerit ovat suunnitteluoletuksia – jos nämä kriteerit eivät täyty, suunnitteluoletuksesi ovat vääriä ja suunnitelmaa on mukautettava.

Olitpa sitten odottamassa järjestelmän toimittamista tai sinulla olisi käytössäsi osittainen järjestelmä, hyödyllinen tekeminen loppuu melko nopeasti. Silloin joudut vaikeaan keskusteluun tuoteomistajan tai projektipäällikön kanssa. Jos valmistumisen määräaika ei muutu, joudut testaamaan vähemmän. Joitakin ominaisuuksia voidaan testata suppeammin tai jättää kokonaan testauksen ulkopuolelle.

Esihenkilö saattaa uskoa, että voit kuroa ajan myöhemmin kiinni, mutta käytännössä tämä on harvoin mahdollista.

Myöhäisten tai osittaisten toimitusten vuoksi menetettyä testausaikaa ei voida korvata ‘työskentelemällä ahkerammin’.

Miksi testaus viivästyy? Mahdollisia syitä on monia, mutta ne noudattavat yleensä jotakin seuraavista kaavoista:

• Ympäristöjä ei voida määrittää ajoissa. Työ aloitettiin myöhään, ihmiset olivat liian kiireisiä tai heillä ei ollut pätevyyttä mielekkään testiympäristön luomiseen. Käytettävissä oleva ympäristö on osittainen, väärin määritetty tai keskeneräinen.
• Toimitus viivästyy, koska työn laajuus arvioitiin liian pieneksi.
• Toimitus viivästyy, koska ohjelmistossa on paljon virheitä ja sitä on vaikea testata ja korjata.
• Toimitus viivästyy, koska kehitystiimiltä puuttuu heidän käyttämissään teknologioissa tai liiketoiminta-alueella tarvittavia taitoja, kokemusta tai osaamista.
• Toimitus viivästyy, koska kehitys aloitettiin myöhään.
• Toimitus viivästyy, koska vaatimukset muuttuvat jatkuvasti.

Edellä olevasta luettelosta on jätetty pois luonnonvoimien aiheuttamat tapahtumat ja muut projektiryhmän vaikutusmahdollisuuksien ulkopuolella olevat ulkoiset tekijät. Jos projektipäällikkö vaatii, ettei testauksen määräaika muutu ja että myös testauksen laajuus pysyy ennallaan, edessäsi on merkittävä haaste. Kaikissa edellä mainituissa tapauksissa myöhäisen toimituksen syyt puoltavat laajempaa testausta, eivät suppeampaa.

Jos kehitystyön laajuus on arvioitu liian pieneksi, myös testauksen laajuus on todennäköisesti arvioitu liian pieneksi. Jos ohjelmistossa on paljon virheitä, testaus kestää kauemmin. Jos kehittäjiltä puuttuu taitoja, ohjelmisto on todennäköisesti heikkolaatuinen ja sen testaaminen kestää kauemmin. Jos kehittäjät aloittivat myöhään (miksi?) eikä laajuus muutu, miksi testausta pitäisi vähentää? Jos vaatimukset muuttuvat, suunnitelmasi ovat todennäköisesti joka tapauksessa vääriä – huonon suunnitelman noudattaminen vaikeuttaa väistämättä elämää.

Kuinka moni toimituksen viivästymisen yleisistä syistä viittaa siihen, että testausta tarvitaan vähemmän? Ei yksikään. Puolusta suunnitelmaasi.

Onnistumisista ja epäonnistumisista raportoiminen

Useimmat testaajat tietävät, että tehokas testaus edellyttää uteliaisuutta, sinnikkyyttä ja ongelmien vainua. Ensisijainen motivaatio on saada aikaan virheitä ja kerätä riittävästi näyttöä, jotta virheet voidaan jäljittää vikoihin, jotka voidaan sitten korjata. 

Vaikka vikojen löytäminen (ja korjaaminen) on hyväksi tuotteen laadulle, vikojen ilmoittaminen tuntuu usein siltä kuin välittäisit huonoja uutisia jollekulle. Kyseessä voi olla kehittäjä, joka on tehnyt jossakin virheen ja joutuu korjaamaan sen, tai saatat raportoida sidosryhmille, ettei jokin kriittinen toiminnallisuus toimi oikein ja että järjestelmän toimitus viivästyy.

Kukaan ei halua kertoa huonoja uutisia, ja on luonnollista tuntea haluttomuutta järkyttää muita ihmisiä, etenkin läheisiä työtovereita. Mutta sen pohtiminen, ovatko uutisesi hyviä vai huonoja, ei kuulu viestinvälittäjän huolenaiheisiin. 

Viat ovat aina jollekin huonoja uutisia, mutta testauksen tehtävänä ei ole suhtautua asioihin tällä tavoin tuomitsevasti. Testaaja on tietyssä mielessä kuin toimittaja, joka etsii totuutta. Kiplingin tarina Elefantin lapsi sisältää seuraavat säkeet:

Minulla on kuusi rehellistä palvelijaa:
    (He opettivat minulle kaiken, minkä tiesin)
Heidän nimensä ovat Mitä ja Missä ja Milloin
    Ja Miten ja Miksi ja Kuka.

Samalla tavoin kuin toimittaja kertoo uutisen, sinä kerrot tarinan siitä, mitä löysit testatessasi järjestelmää.

Totuus – uutinen – voi olla hyvä tai huono, mutta vastuullasi on yksinkertaisesti etsiä sekä ongelmia että onnistumisia parhaasi mukaan. Yrität selvittää, mitä järjestelmä tekee ja miten se sen tekee. 

Projektin aivan lopussa tavoitteena on toimittaa järjestelmä tuotantoon niin, että avoimia ongelmia on mahdollisimman vähän. Haluat kaikkien testiesi läpäisevän, mutta onnistumisen tiellä ovat testien epäonnistumiset, jotka on tutkittava ja ratkaistava. Taktinen tavoitteesi on löytää ongelmat nopeasti, mutta perimmäinen tavoitteesi on, ettei raportoitavia ongelmia olisi lainkaan. 

Raportoidaksesi testausprojektisi onnistumisesta tai epäonnistumisesta tarkasti harkitse edistyneiden testauksenhallintatyökalujen integroimista; ne tarjoavat kattavat analytiikkaominaisuudet

Sinun on toimittava pitkälti kuin tutkiva toimittaja – etsittävä tarinaa kriittisellä ja riippumattomalla mielellä. Kuten Kipling kirjoitti:

Jos voit kohdata Voiton ja Turmion ja kohdella noita kahta huijaria aivan samalla tavalla …

Silloin pidät pääsi kylmänä ja toimit hyvin projektisi ja sidosryhmiesi hyväksi.

Kattavuuden heikkeneminen

Riippumatta siitä, mikä testauksen alussa asetettu kattavuustavoite tai -tavoitteet ovat, useat tekijät yhdessä pienentävät tosiasiassa saavutettavaa kattavuutta. Heikkeneminen on sopiva termi, koska se kuvaa osuvasti suunniteltujen testien laajuuden vähittäistä kaventumista ja väistämätöntä havaintoa siitä, ettei kaikkia suunniteltuja testejä voida suorittaa käytettävissä olevan ajan kuluessa.

Kattavuuden heikkenemiselle on useita syitä jo ennen testauksen suorittamista:

• Ensinnäkin testaussuunnitelmissa yksilöidään käsiteltävät riskit ja niiden käsittelyssä käytettävä lähestymistapa. Suunnitelmissa oletetaan yleensä testaukselle tietty budjetti – joka on aina kompromissi.
• Heikot, epävakaat tai keskeneräiset järjestelmävaatimukset, suunnitelmat ja määrittelyt vaikeuttavat testien määrittelyä. Järjestelmän kattavuus kärsii määrittelyjen puutteellisista yksityiskohdista.
• Testiympäristöjen myöhäinen saatavuus tai riittämättömyys tekee tietyistä suunnitelluista testeistä epäkäytännöllisiä tai merkityksettömiä. Laajamittaisempaa integraatiotestausta voi olla mahdotonta suorittaa suunnitellusti, koska kaikkia rajapintoja tai rajapintojen vastapuolena toimivia järjestelmiä ei voida asettaa saataville.
• Suorituskykytestaus saattaa vaarantua, koska ympäristöjen mittakaava ei ole riittävä tai ne eivät vastaa tuotantoympäristöä.
• Testattavan ohjelmiston myöhäinen toimitus tarkoittaa, että määräaikojen pysyessä ennallaan testauksen piiriin kuuluvaa määrää on vähennettävä.

Testauksen suorittamisen aikaiselle kattavuuden heikkenemiselle on myös useita syitä:

• Jos testattavan ohjelmiston laatu on testausvaiheen alkaessa heikko, testien suorittaminen voi olla erityisen turhauttavaa. Perustavanlaatuisimmat testit saattavat epäonnistua, ja havaitut virheet voivat olla niin olennaisia, että niiden korjaamiseen tarvitaan enemmän aikaa kuin kukaan osasi odottaa. Jos testaus keskeytetään ohjelmiston liian heikon laadun vuoksi, aikataulu viivästyy. Jos määräaika ei siirry, joidenkin testien laajuutta rajataan.
• Jos virheitä ilmenee odotettua enemmän, korjaus- ja uudelleentestauskierros vie itsessään enemmän aikaa, ja aika loppuu ennen kuin kaikki testit ehditään suorittaa.
• Kun aika loppuu ja päätös julkaisusta tehdään, kaikkia testejä ei ole suoritettu loppuun. Joko joitakin testejä ei koskaan päästy suorittamaan suunnitelman mukaisesti tai jotkin jäljellä olevat virheet estävät epäonnistuneiden testien loppuun saattamisen. Kun käyttöönoton päivämäärä ei siirry, kyseessä on edellä mainittu testauksen klassinen puristus.

Testauksen kattavuuden heikkenemisen käsitteleminen on yksi testaajien haasteista kaikissa projekteissa. Asiat etenevät harvoin sujuvasti, ja testaukseen (ja kattavuuteen) käytettävissä olevan ajan vähentäminen on yleensä ainoa vaihtoehto projektin pitämiseksi aikataulussa.

Testauksen määrän vähentäminen ei ole väärin; väärin on vain vähentää testausta mielivaltaisesti. Kun siis tehdään päätöksiä siitä, mitkä testit karsitaan, on arvioitava vaikutus testitavoitteisiin ja käsiteltäviin riskeihin. Saatat joutua käymään läpi joitakin hankalia keskusteluja sidosryhmien kanssa.

Jos vaikutus on merkittävä, saatat joutua järjestämään kokouksen niiden kanssa, jotka pyytävät karsintoja (yleensä projektinhallinnan edustajat), sekä niiden kanssa, joiden etuihin karsinnat saattavat vaikuttaa (sidosryhmät). Tehtäväsi on kuvata tilanne suoritettujen testien, testatun järjestelmän tämänhetkisen tunnetun tilan, epäonnistuvien ja/tai etenemisen estävien testien sekä jäljellä olevan testauksen määrän osalta.

Suunnitelmasi ja mallisi kuvaavat testauksen alkuperäisen laajuuden ja ovat ratkaisevan tärkeitä, jotta sidosryhmät ja johto ymmärtävät puutteet ja jäljellä olevat riskit sekä voivat päättää, jatketaanko testausta vai lopetetaanko se.

Poikkeamien hallinta

Kun projekti siirtyy järjestelmätestauksen ja hyväksymistestauksen vaiheisiin, sitä ohjaavat suurelta osin testauksen suorittamisen aikana ilmenevät poikkeamat. Poikkeamat käynnistävät projektin jäljellä olevia toimia, ja poikkeamatilastot voivat toisinaan antaa hyvän kuvan projektin tilanteesta. Kun poikkeamia luokitellaan, on ajateltava etukäteen, miten näitä tietoja myöhemmin käytetään.

Poikkeama on testauksen aikana tapahtuva suunnittelematon tapahtuma, jolla voi olla vaikutusta testauksen onnistuneeseen loppuunsaattamiseen, hyväksymispäätökseen tai tarpeeseen ryhtyä johonkin muuhun toimenpiteeseen.

Käytämme näistä suunnittelemattomista tapahtumista neutraalia termiä – poikkeama. Näistä tapahtumista käytetään kuitenkin usein myös muita termejä; jotkin niistä ovat neutraalimpia kuin toiset. 

Epäonnistuvista testeistä saatetaan käyttää nimityksiä havainnot, poikkeamat tai ongelmat – neutraaleja termejä, jotka eivät oleta syytä. Joskus käytetään kuitenkin termejä ongelmat, bugit, viat tai virheet – mikä olettaa järjestelmän olevan viallinen. Tämä saattaa kuitenkin olla ennenaikainen johtopäätös, ja nämä nimitykset voivat johtaa harhaan.

Suosittelemme, että varaat termit bugi, vika ja virhe niiden diagnoosin tuloksille, jotka koskevat testattavan järjestelmän rakentamisen aikana ilmenneitä epäonnistumisia ja jotka yleensä aiheuttavat kehitystiimille uudelleentyötä.

Poikkeamat ilmenevät kahdella tavalla:

1. Järjestelmän vika: järjestelmä ei toimi testissä odotetulla tavalla, eli se toimii jollakin tavalla virheellisesti tai näyttää siltä, ettei se täytä jotakin vaatimusta.
2. Testauksen tai testien keskeytyminen tai vaarantuminen: jokin tapahtuma vaikuttaa testaajien mahdollisuuksiin suorittaa tehtävänsä, kuten testiympäristön, tietojen, rajapintojen, tukevien integroitujen järjestelmien tai palvelujen menetys tai vikaantuminen tai jokin muu ulkoinen vaikutus.

Järjestelmän vika

Nämä poikkeamat ovat usein kaikkein suorimmin huolta aiheuttavia, koska ne heikentävät luottamusta järjestelmän laatuun. 

Testauksen keskeytyminen ja testien vaarantuminen

Jotkin organisaatiot eivät pidä näitä tapahtumia poikkeamina lainkaan – keskeytykset kuuluvat projektien loppuvaiheen arkeen. Vaarantuneista testeistä, joissa ympäristö tai testausjärjestely on virheellinen, saatetaan syyttää testaustiimiä (järjestelyn tekemisestä tai ainakin siitä, ettei järjestelyä tarkistettu ennen testausta).

Molemmissa tapauksissa testauksen eteneminen kärsii, ja jos johdat prosessia, olet vastuussa viivästysten selittämisestä. Tästä syystä sinun tulee joko kirjata nämä tapahtumat poikkeamiksi tai pyytää tiimiä pitämään testauslokia ja kirjaamaan ympäristön käyttökatkot, kokoonpano-ongelmat tai testaukseen sopivien ohjelmistoversioiden puuttuminen. Jos et tee niin, sinun on vaikea perustella etenemisen viivästyksiä, ja se voi antaa sinusta ja tiimistä huonon kuvan.

Kirjataanko poikkeamat vai ei?

Ketteryys- ja jatkuvan toimituksen lähestymistapojen yleistyminen on haastanut perinteisen näkemyksen poikkeamien hallinnasta. Vaiheistetuissa projekteissa poikkeamia käsitellään kehittäjille tarkoitettuina mahdollisina työpaketteina, jotka hyväksytään vakavuuden ja/tai kiireellisyyden perusteella. 

Noudatettavana on muodollinen, usein byrokraattinen prosessi, jossa kehitys- tai muu tiimi tarkastaa, priorisoi ja käsittelee poikkeamat. Käytössä voidaan käyttää kehittyneitä poikkeamien hallintatyökaluja.

Pienemmissä ketterissä tiimeissä testaajan ja kehittäjän välinen yhteistyö on tiivistä. Koko tiimi saattaa kokoontua päivittäin keskustelemaan suuremmista poikkeamista, mutta useimmiten virheet havaitaan, diagnosoidaan, korjataan ja testataan uudelleen epämuodollisesti ilman tarvetta kirjata poikkeamaa tai ottaa mukaan muita tiimin jäseniä tai organisaation ulkopuolisia liiketoiminta- tai IT-henkilöitä. Vakavammista virheistä voidaan keskustella ja ne voidaan sisällyttää käyttäjätarinan työhön tai koota erillisiin virheenkorjausiteraatioihin tai -sprintteihin.

Käsittelimme dokumentaation tarkoitusta ja tarvetta aiemmassa artikkelissa. Sama keskustelu soveltuu myös poikkeamiin. Tiimin on pohdittava, tarvitaanko poikkeamien hallintatyökalua ja -prosessia ja onko siitä hyötyä tiimille ja/tai edellyttävätkö tiimin ulkopuoliset henkilöt sitä.

Suuremmilla tiimeillä on yleensä kolme syytä tukeutua prosesseihin ja työkaluihin poikkeamien hallinnassa: 

1. Sen varmistamiseksi, etteivät poikkeamat unohdu
2. Sen varmistamiseksi, että sidosryhmät ja projektinjohto tarkastelevat vakavia ongelmia 
3. Projektin aikana ja sen jälkeen mahdollisesti arvokkaiden mittareiden keräämiseksi.

Kiireellisyyden erottaminen vakavuudesta

Riippumatta siitä, minkä poikkeamien hallintaprosessin otat käyttöön, suosittelemme määrittämään kaikille poikkeamille sekä prioriteetti- että vakavuuskoodin.

• Prioriteetti määritetään testauksen näkökulmasta, ja se vaikuttaa siihen, milloin poikkeama ratkaistaan. Testaajan tulee päättää, onko poikkeaman prioriteetti korkea vai matala (tai jokin sallituista väliasteista). Prioriteetti ilmaisee, kuinka kiireellinen vika on testaajien näkökulmasta, ja perustuu testauksen epäonnistumisen vaikutukseen muuhun testaukseen.
• Vakavuus määritetään käyttäjän näkökulmasta, ja se ilmaisee (yleensä) virheen hyväksyttävyyden tai hyväksymättömyyden. Loppukäyttäjien tai heidän esihenkilöidensä tulee määrittää vakavuus tai (tehokkaammin) tarvittaessa korvata testaajien alkuperäinen arvio. Vakavuus kuvastaa virheen vaikutusta liiketoimintaan, jos sitä ei korjata ennen toimitusta. Tyypillisesti vakava virhe tekee järjestelmästä käyttökelvottoman. Jos virheen vakavuus on matala, sen voidaan katsoa olevan liian vähäpätöinen korjattavaksi ennen tuotantokäyttöönottoa, mutta se voidaan korjata myöhemmässä julkaisussa.

Jos poikkeama pysäyttää testauksen ja testaus on kriittisellä polulla, koko projekti pysähtyy.

Korkean prioriteetin poikkeama pysäyttää kaiken testauksen ja yleensä myös projektin.

Poikkeamien luokittelujärjestelmissä on tärkeää muistaa, ettei jokainen kiireellinen poikkeama ole vakava eikä jokainen vakava poikkeama ole kiireellinen.

Loppuvaiheen hallinta

Kutsumme testausprosessimme viimeisiä vaiheita loppuvaiheeksi, koska testaustoimintojen hallinta näinä viimeisinä, mahdollisesti kiihkeinä ja stressaavina päivinä edellyttää erilaista kurinalaisuutta kuin testauksen suunnittelun aikaisempi, näennäisesti paljon rennompi ajanjakso.

Muista, että testauksen tarkoituksena on toimittaa sidosryhmille tietoa päätöksenteon mahdollistamiseksi – hyväksyä, korjata, hylätä, jatkaa projektia tai luopua siitä kokonaan. 

Jos sinulla on yhteinen käsitys testauksessa käytettävistä malleista, on paljon helpompaa selittää, mikä ”toimii” (mallin kannalta) ja missä asiat eivät toimi sekä mitä riskejä näihin toimimattomuuksiin liittyy. Sidosryhmät käyttävät näitä tietoja päätöstensä tekemiseen – sinun ohjauksessasi.

Yksi riskiperusteisen testauksen omaksumisen hyödyistä on se, että kun testausta supistetaan projektin loppuvaiheessa, käytämme jäännösriskiä perusteluna testauksen jatkamiselle tai jopa testauksen lisäämiselle. 

Kun johto vaatii testauksen supistamista, testaajien tulisi yksinkertaisesti tuoda esiin riskit, joista tingitään. Tämä on paljon helpompaa, kun varhainen riskinarviointi on tehty, sitä on käytetty testitoimintojen ohjaamiseen ja sitä on seurattu koko projektin ajan. Kun johto on jatkuvasti tietoinen jäännösriskeistä, on epätodennäköisempää, että se ylipäätään pyrkii supistamaan testausta.

Siinä kaikki, hyvät ystävät – onnea testaukseen!

Tilaa QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uusia osia julkaistaan. Nämä kirjoitukset ovat otteita Paulin Leadership In Test -kurssista, jota suosittelemme lämpimästi, jos haluat perehtyä syvällisemmin tähän ja muihin aiheisiin. Jos päätät tehdä niin, käytä eksklusiivista kuponkikoodiamme QALEADOFFER ja säästä 60 dollaria kurssin täydestä hinnasta!