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

Miksi Record and Replay -työkaluja ei kannata käyttää testiautomaatiossa?

Record and Replay -termillä (suom. "Tallenna ja toista") viitataan testiautomaatiotyökaluihin, joiden avulla voidaan tallentaa käskysarjoja ja toistaa nämä käskysarjat koneellisesti. R&R-työkaluilla testaaja käynnistää tallennuksen, suorittaa haluamansa käskyt (testit) testattavaan ohjelmistoon ja lopettaa tallennuksen, jonka jälkeen hänellä on valmiiksi automatisoitu testicase kyseiseen testiin. Tunnettuja työkaluja ovat esim. Selenium IDE, Appium Studio, Screenster ja CloudQA.

Wau, kuulostavatpa R&R-työkalut hienoilta ja käteviltä! Testiautomaatiokehittäjille ei siis liene enää tarvetta, jos manuaalitestaajakin pystyy automatisoimaan testit, vain tallentamalla testisuorituksen, eikö niin? Ikävä kyllä on.

R&R-työkalujen ongelma on se, että niiden tuottamat automaatiotestit ovat hauraita ja helposti särkyviä. R&R-työkalujen yleinen käyttökohde on web-pohjaisten ohjelmistojen UI-testien automatisointi. Tällöin R&R-työkalut tallentavat käskysarjat käyttäen hyväksi HTML-sivun lokaattoreita, kuten id, class tai xpath. Nämä lokaattorit kuitenkin muuttuvat usein päivitysten myötä ja tällöin testitkin lakkaavat toimimasta. Varsinkin, jos lokaattori on sivurakenteesta automaattisesti generoitu xpath-polku. ID- ja class-lokaattorit tuppaavat säilyttämään relevanssinsa pidempään, koska niitä ei muokata yhtä usein. Xpath on myös tehokas työkalu, mutta sen hyödyntäminen vaatii useimmiten erilaisten akseleiden (axis) käyttämistä.

Record and Replay -työkaluista voi olla hyötyä, mikäli testaajat eivät ole teknisesti päteviä, testattava
järjestelmä pysyy muuttumattomana tai automatisoitavien testien määrä on valtaisa. Nauhoitetut testit ovat nyt myös sidottu työkalun tarjoajan ekosysteemiin, mistä voi olla vaikeaa saada niitä ulos, mikäli käytetty työkalu joskus vaihtuu. Käytännössä osaava testiautomaatiokehittäjä onkin yleensä parempi sijoitus, sillä järjestelmät päivittyvät usein, testitapaukset muuttuvat, työkalut vaihtuvat ja jonkun pitää ymmärtää järjestelmän testauksen tekniset rajoitteet ja mahdollisuudet ja se, mitä testauksesta kannattaa automatisoida.
Ikävä kyllä.