Testiautomaatioammattilainen tuntee yleisimmät käytössä olevat testiautomaatiotyökalut sekä ymmärtää teknologiaa ja yleisimpiä käytettävissä olevia tekniikoita, scriptejä, framewörkkejä, kieliä, käyttöjärjestelmiä ja muita yleisiä ohjelmistokehityksen työkaluja. Testiautomaatioammattilainen käyttää keräämäänsä työkalupakkia ja hallitsee valitsemansa työkalut monipuolisesti ja tehokkaasti. Testiautomaatioammattilainen osaa valita oikeat työkalut oikeaan työhön. Osa testiautomaatiokehittäjän työnkuvaa on myös seurata alan kehitystä ja uusimpia työkaluja, esim. vierailemalla eri testausalan konferensseissa.

Olen kerännyt tähän alle listan yleisiä testiautomaatiotyökalujaa eri kategorioissa:

Funktionaalinen testaus -työkalut:

• Robot Framework (http://robotframework.org/)
• Cucumber (https://cucumber.io/)
• SoapUI (https://www.soapui.org/)
• FitNesse (http://docs.fitnesse.org/FrontPage)
• Serenity BDD (http://www.thucydides.info/#/)
• Gauge (https://gauge.org/)
• Sahi (http://sahipro.com/)
• Mocha (https://mochajs.org/)
• Lettuce (http://lettuce.it/index.html)
• Junit.org (https://junit.org/junit5/)
• Behave (https://pypi.python.org/pypi/behave)

Visuaalinen testaus -työkalut:

• Sikuli (http://www.sikuli.org/)
• fmbt (https://01.org/fmbt)
• Applitools Eyes (https://applitools.com/)
• Galen Framework (http://galenframework.com/)

Defect management -työkalut:

• Jira (https://www.atlassian.com/jira)
• TestRail (http://www.gurock.com/testrail/)
• Microfocus Quality Center (https://software.microfocus.com/en-us/home)
• Trello (https://trello.com/)
• Manuscript (https://www.manuscript.com/)
• Taskworld (https://taskworld.com/)

Continuous Integration -työkalut:

• Jenkins (https://jenkins.io/)
• Travis CI (https://travis-ci.org/)
• Hudson CI (http://hudson-ci.org/)
• TeamCity (https://www.jetbrains.com/teamcity/)

DevOps-työkalut:

• Ansible (https://www.ansible.com/)
• Docker (https://www.docker.com/)
• Kubernetes (https://kubernetes.io/)
• Artifactory (https://jfrog.com/artifactory/)

Viestintä-työkalut:

• Slack (https://www.slack.com)
• HipChat (https://www.hipchat.com/)
• Stride (https://www.stride.com/)
• Skype (https://www.skype.com/fi/)
• Teams (https://products.office.com/en-us/microsoft-teams/)
• Yammer (https://www.yammer.com)
• IRC (esim. putty: https://www.putty.org/)

Yritän päivittää listaa parhaani mukaan. Tämä on versio 0.1.0. Jos keksit jonkun työkalun, joka mielestäsi kuuluisi listalle, laita kommentti tähän postaukseen.

Lista päivitetty 26.05.2018

Testrail (Kuinka ylläpitää ja organisoida testejä?)

Ammattimainen testaus järjestelmällistä, toistettavaa ja jäljitettävää. Käytännössä tämä tarkoittaa sitä, että testitapaukset dokumentoidaan selkeästi ja ymmärrettävästi yhteen paikkaan, josta niihin päästään helposti käsiksi. Testien dokumentaatio elää kuitenkin koko ajan uusien ohjelmistoversioiden myötä ja testicaset vanhentuvat nopeasti. Testicaseja onkin jatkuvasti päivitettävä vastaamaan uuden ohjelmistoversion vaatimuksia ja niiden ylläpito käy testaajalle nopeasti työlääksi, mikäli dokumentointiprosessi on tehty liian monimutkaiseksi.

Tähän tarpeeseen vastaa TestRail, joka on testicasejen hallintaan tarkoitettu ohjelmisto. Testrailissa voi nopeasti kirjoittaa testitapausten kuvauksia, asettaa niille automaattisesti tunnistettavan id:n (#00001), asettaa kategorian (unit test, system test, acceptance test) ja vakavuuden (low, medium, high) ja tyypin (esim. manuaalinen tai automatisoitu) ja tilan (valmis, kesken, päivitettävä). Testicaset jaotellaan test suitejen mukaan loogisiin kokonaisuuksiin (test suiteihin), joista ne on helppo löytää. Testicaseja voi myös tarkastella testin suorittamisen onnistumisen mukaan katsomalla testirunien tuloksia. TestRailissa on integraatiomahdollisuudet muihin yleisimpiin testaus- tai hallinnointiohjelmistoihin, kuten Jiraan, jos haluaa esimerkiksi määrätä tietyt testicaset tai testeistä löydetyt bugit tietylle henkilölle ratkaistavaksi.

Testitapaukset kuvataan jaettuna selkeisiin askeleisin, joiden pitää olla täysin eksplisiittisiä, eli vain yhdellä tavalla ymmärrettävissä. Kuvausten kielen pitäisikin olla mahdollisimman yksityiskohtaista ja kuvata asioita niin tarkkaan, että erehtymisen vaaraa ei ole. Jos askeleiden kuvaukset ovat liian korkealla abstraktiotasolla, kuten esimerkiksi "Täytä kyselylomake ja siirry seuraavalle sivulle", ne ovat liian epätarkkoja. Alemman tason kuvaus, kuten "Valitse 'Kotimaa'-nimisestä vetovalikosta valinta 'Finland' ja klikkaa 'Seuraava'-painiketta", on eksaktimpi ja vähentää väärinymmärrysten määrää.

TestRail on hyödyllinen testitapausten organisointiin ja dokumentointiin. Jotta sen käytöstä saataisiin kaikki mahdollinen hyöty, pitäisi testitapauksia ylläpitää ja päivittää aktiivisesti. Vaarana on, että testitapausten kuvaukset TestRailissa happanevat (go sour), samalla kun testiautomaation testitapaukset elävät omaa elämäänsä. Tällä hetkellä erilaiset CI-ratkaisut, kuten esimerkiksi automaattisten testitapausten tilan tarkastaminen suoraan Jenkinsistä ja testiautomaation lähentyessä luonnollista kieltä, testitapausten ja ajojen kirjaamisen ulkopuoliseen järjestelmään voi kyseenalaistaa. Erittäin ketterien tiimien ei välttämättä kannata laittaa resursseja siihen, vaan hyödyntää testausprosessissa syntyvää metadataa testitapausten ylläpitoon.

TestRailin kotisivut:
http://www.gurock.com/testrail/