Robot Framework is an open-source generic test automation framework, developed by the Robot Framework Foundation (www.robotframework.org). RIDE is an integrated development environment developed for creating and managing Robot Framework test scripts. This guide shows how to install Robot Framework and RIDE and some of the most popular libraries, such as SeleniumLibrary and Chrome Webdriver tool for programmatic control of the Chrome browser.
This guide uses Windows Powershell, which can be found when using Windows search 'powershell'. This guide was made with Python 3.7.0. on Windows 10.
1. Robot Framework
# If you want to use a virtual environment for the installation, activate it first:
(devenv) PS C:\Users\tvirtane\Documents\devenv> .\Scripts\activate
# Install Robot Framework with pip:
pip install robotframework
# Verify the correct version of the installation:
(devenv) PS C:\Users\tvirtane\Documents\devenv> robot --version
Robot Framework 3.0.4 (Python 3.7.0 on win32)
2. RIDE
# Download Python 3 compatible version of RIDE from GitHub:
https://github.com/HelioGuilherme66
# Unzip .zip file to your /devenv/ folder
# Install wxPython (a requirement for RIDE):
pip install -U wxPython
# Install RIDE;
python3 setup.py install
# Click the created icon or start it from folder 'devenv' with command:
(devenv) PS C:\Users\tvirtane\Documents\devenv> ./Scripts/ride.py
3. SeleniumLibrary
# Install SeleniumLibrary for Robot Framework:
pip install robotframework-seleniumlibrary
4. Chrome WebDriver
# Download the newest Chrome WebDriver 2.42 from:
http://chromedriver.chromium.org/downloads
# Unzip the chromedriver_win32.zip and move the 'chromedriver.exe' file to a folder:
C:\Python3\Scripts\
# Add this Chromedriver filepath to your PATH environment variable:
C:\Python3\Scripts\chromedriver.exe
# Guide for changing environment variables can be found here:
https://testaataiitke.blogspot.com/2018/10/python-3-installation-guide.html
Last updated 10.10.2018
Robot Framework and RIDE installation guide
Robot Framework ja RIDE asennusohje
Robot Framework on avoin testiautomaatiotyökalu, jota kehittää Robot Framework Foundation (www.robotframework.org). RIDE on Robot Frameworkin käyttöön kehitetty integroitu kehitysympäristö (Robot Integrated Development Environment), joka helpottaa testiskriptien kirjoittamista ja hallintaa. Tämän ohjeen tarkoituksena on asentaa Robot Framework, siihen RIDE kehitysmpäristö ja yleisimpiä kirjastoja, kuten SeleniumLibrary ja Chrome WebDriver -työkalun selaimen ohjelmalliseen hallintaan.
Tässä ohjeessa käytetään perinteisen komentorivin (command promptin, cmd) sijaan uudempaa Windows Powershellia, joka sisältää UNIX-tyyliset komentokäskyt, kuten listaa, ls. Eli avaa Powershell kirjoittamalla 'powershell' Windowsin hakuun ja paina Enter.
Ohje on tehty Python 3 käyttäen Windows 10 -käyttöjärjestelmää.
1. Robot Framework
# Mikäli haluat asentaa Robot Frameworkin virtuaaliympäristöön, aktivoi se ensin komenolla
(devenv) PS C:\Users\tvirtane\Documents\devenv> .\Scripts\activate
# Asenna Robot Framework käyttäen pip-työkalua komennolla:
pip install robotframework
# Tarkista asennettu versio (huomaa käytössä oleva virtuaaliympäristö):
(devenv) PS C:\Users\tvirtane\Documents\devenv> robot --version
Robot Framework 3.0.4 (Python 3.7.0 on win32)
2. RIDE
# Lataa Python 3:lle forkattu versio RIDEsta GitHubista:
https://github.com/HelioGuilherme66
# Unzippaa .zip-paketti /devenv/-kansioon.
# Asenna wxPython
pip install -U wxPython
# Asenna RIDE
python3 setup.py install
# Käynnistä kuvakkeesta tai 'devenv'-kansiosta komennolla:
(devenv) PS C:\Users\tvirtane\Documents\devenv> ./Scripts/ride.py
3. SeleniumLibrary
# Asenna SeleniumLibrary for Robot Framework kirjasto komennolla:
pip install robotframework-seleniumlibrary
4. Chrome WebDriver
# Lataa uusin Chrome WebDriver 2.42 osoitteesta:
http://chromedriver.chromium.org/downloads
# Pura lataamasi chromedriver_win32.zip ja siirrä 'chromedriver.exe'-tiedosto kansioon:
C:\Python3\Scripts\
# Lisää tämä polku Windowsin PATH-ympäristömuuttujaan:
C:\Python3\Scripts\chromedriver.exe
# Ohjeet ympäristömuuttujien asettamiseen löytävät täältä:
https://testaataiitke.blogspot.com/2018/10/python-3-asennusohje.html
Päivitetty 10.10.2018
Tässä ohjeessa käytetään perinteisen komentorivin (command promptin, cmd) sijaan uudempaa Windows Powershellia, joka sisältää UNIX-tyyliset komentokäskyt, kuten listaa, ls. Eli avaa Powershell kirjoittamalla 'powershell' Windowsin hakuun ja paina Enter.
Ohje on tehty Python 3 käyttäen Windows 10 -käyttöjärjestelmää.
1. Robot Framework
# Mikäli haluat asentaa Robot Frameworkin virtuaaliympäristöön, aktivoi se ensin komenolla
(devenv) PS C:\Users\tvirtane\Documents\devenv> .\Scripts\activate
# Asenna Robot Framework käyttäen pip-työkalua komennolla:
pip install robotframework
# Tarkista asennettu versio (huomaa käytössä oleva virtuaaliympäristö):
(devenv) PS C:\Users\tvirtane\Documents\devenv> robot --version
Robot Framework 3.0.4 (Python 3.7.0 on win32)
2. RIDE
# Lataa Python 3:lle forkattu versio RIDEsta GitHubista:
https://github.com/HelioGuilherme66
# Unzippaa .zip-paketti /devenv/-kansioon.
# Asenna wxPython
pip install -U wxPython
# Asenna RIDE
python3 setup.py install
# Käynnistä kuvakkeesta tai 'devenv'-kansiosta komennolla:
(devenv) PS C:\Users\tvirtane\Documents\devenv> ./Scripts/ride.py
3. SeleniumLibrary
# Asenna SeleniumLibrary for Robot Framework kirjasto komennolla:
pip install robotframework-seleniumlibrary
4. Chrome WebDriver
# Lataa uusin Chrome WebDriver 2.42 osoitteesta:
http://chromedriver.chromium.org/downloads
# Pura lataamasi chromedriver_win32.zip ja siirrä 'chromedriver.exe'-tiedosto kansioon:
C:\Python3\Scripts\
# Lisää tämä polku Windowsin PATH-ympäristömuuttujaan:
C:\Python3\Scripts\chromedriver.exe
# Ohjeet ympäristömuuttujien asettamiseen löytävät täältä:
https://testaataiitke.blogspot.com/2018/10/python-3-asennusohje.html
Päivitetty 10.10.2018
Python Virtualenv installation guide
Virtualenv is a tool for Python that allows the easy creation of virtual python environments. We can have multiple different Python environments with different Python modules.
For the installation, we will use pip, a packet management tool that was installed with Python 3.
Instead of the traditional command prompt (cmd), we will use the newer Windows Powershell, that contains more UNIX-like commands, like ls. This is a personal preference, of course. So, let's start by writing 'powershell' to the Windows search and press Enter.
Now we are ready to start installing virtualenv!
1. Go to your folder of choice, for example:
cd C:\Users\myname\Documents\
2. Install virtualenv with command:
pip install virtualenv
3. Create a new virtual environment named 'devenv' with command:
virtualenv devenv
Now, you should have a folder named 'devenv' that has local copies of Python tools.
4. Lastly, you have activate the virtual environment in Powershell., by being in the folder /devenv/ and writing the command:
./Scripts/activate
You can see that the virtualenv is activated, when the name of the environment in shown in braces () before the command line, for example:
(devenv) PS C:\Users\myname\Documents
Last updated 10.10.2018
For the installation, we will use pip, a packet management tool that was installed with Python 3.
Instead of the traditional command prompt (cmd), we will use the newer Windows Powershell, that contains more UNIX-like commands, like ls. This is a personal preference, of course. So, let's start by writing 'powershell' to the Windows search and press Enter.
And this is what it looks like:
Now we are ready to start installing virtualenv!
1. Go to your folder of choice, for example:
cd C:\Users\myname\Documents\
2. Install virtualenv with command:
pip install virtualenv
3. Create a new virtual environment named 'devenv' with command:
virtualenv devenv
Now, you should have a folder named 'devenv' that has local copies of Python tools.
4. Lastly, you have activate the virtual environment in Powershell., by being in the folder /devenv/ and writing the command:
./Scripts/activate
You can see that the virtualenv is activated, when the name of the environment in shown in braces () before the command line, for example:
(devenv) PS C:\Users\myname\Documents
Last updated 10.10.2018
Python Virtualenv asennusohje
Virtualenv on Pythonille tehty työkalu, jolla voi helposti ja luoda virtuaalisia pythonympäristöjä. Tällöin meillä voi olla samanaikaisesti useita eri projekteja, joissa jokaisessa on omat kirjastot ja riippuvuudet.
Virtualenv ei ole kriittinen, mutta se helpottaa erilaisten ympäristöjen hallintaa. Esimerkiksi, jos asennat Robot Frameworkin suoraan ilman virtualenvia, niin se menee automaattisesti Python asennuksen oletuskansioon, eli esim. C:\Python3\. Jos taas olet virtuaaliympäristön sisällä ja asennat Robot Frameworkin , menee asennus kyseisen virtuaaliympäristön Python asennuskansioon.
Virtualenvin asennukseen käytettään pip-työkalua, joka asentui Python 3:en mukana.
Käytetään perinteisen komentorivin (command promptin, cmd) sijaan uudempaa Windows Powershellia, joka sisältää UNIX-tyyliset komentokäskyt, kuten ls. Eli avaa Powershell kirjoittamalla 'powershell' Windowsin hakuun ja paina Enter.
Nyt voimme aloittaa virtualenvin asennuksen haluttuun kansioon,
esim.: C:\Users\myname\Documents\
1. Mene haluttuun kansioon komennolla cd (sanoista change directory):
cd C:\Users\myname\Documents\
2. Installoi virtualenv Pythonille komennolla:
pip install virtualenv
3. Luo uusi virtuaaliympäristö nimeltä 'devenv' komennolla:
virtualenv devenv
Nyt devenv-kansiossa on omat paikalliset versiot Pythonin tarvittavista utility-työkaluista.
4. Aktivoi virtuaaliympäristö Powershellissä, olemalla kansiossa /devenv/ ja kirjoittamalla komento:
./Scripts/activate
Komentorivin alussa pitäisi nyt lukea suluissa (devenv) PS C:\Users\myname\Documents,
joka kertoo, että virtuaaliympäristö on käynnissä. Kaikki komennot, jotka nyt suoritetaan, suoritetaan kyseisen virtuaaliympäristön Python-kirjastoja käyttäen.
Päivitetty 10.10.2018
Virtualenv ei ole kriittinen, mutta se helpottaa erilaisten ympäristöjen hallintaa. Esimerkiksi, jos asennat Robot Frameworkin suoraan ilman virtualenvia, niin se menee automaattisesti Python asennuksen oletuskansioon, eli esim. C:\Python3\. Jos taas olet virtuaaliympäristön sisällä ja asennat Robot Frameworkin , menee asennus kyseisen virtuaaliympäristön Python asennuskansioon.
Virtualenvin asennukseen käytettään pip-työkalua, joka asentui Python 3:en mukana.
Käytetään perinteisen komentorivin (command promptin, cmd) sijaan uudempaa Windows Powershellia, joka sisältää UNIX-tyyliset komentokäskyt, kuten ls. Eli avaa Powershell kirjoittamalla 'powershell' Windowsin hakuun ja paina Enter.
Ja tältä se näyttää:
Nyt voimme aloittaa virtualenvin asennuksen haluttuun kansioon,
esim.: C:\Users\myname\Documents\
1. Mene haluttuun kansioon komennolla cd (sanoista change directory):
cd C:\Users\myname\Documents\
2. Installoi virtualenv Pythonille komennolla:
pip install virtualenv
3. Luo uusi virtuaaliympäristö nimeltä 'devenv' komennolla:
virtualenv devenv
Nyt devenv-kansiossa on omat paikalliset versiot Pythonin tarvittavista utility-työkaluista.
4. Aktivoi virtuaaliympäristö Powershellissä, olemalla kansiossa /devenv/ ja kirjoittamalla komento:
./Scripts/activate
Komentorivin alussa pitäisi nyt lukea suluissa (devenv) PS C:\Users\myname\Documents,
joka kertoo, että virtuaaliympäristö on käynnissä. Kaikki komennot, jotka nyt suoritetaan, suoritetaan kyseisen virtuaaliympäristön Python-kirjastoja käyttäen.
Päivitetty 10.10.2018
Python 3 installation guide
1. Navigate to: https://www.python.org/downloads/ and download the newest version of Python 3.7.0. for your operating system. This guide uses Windows 10.
2. Start installation by clicking the python-3.7.0.exe
Here you can add Python to your Windows Environment variable PATH by clicking the lower option "Add Python 3.7 to PATH". Click "Customize installation".
Next!
Default installation folder is C:\Python3. Click Install!
And after a short wait, Python 3.7.0. has been installed succesfully.
4. And we can verify the succesfull installation by searching for "cmd" and opening the "Command Prompt" by hitting Enter.
Now we can write a commad to the command prompt: python --version
and python gracefully answers with version 3.7.0.
If the command produces an error, it means that the Python installation path has not been added to the Windows PATH environment variable and that's why the command prompt can't find it.
But we can fix this by simply adding it to the PATH!
5. Setting Windows 10 Environment variables
The most important environment variable is PATH, which the command prompt uses to find paths to installed programs. Python has its own internal path variable named PYTHONPATH, that is used as the default directory for findgin Python libraries and modules.
Open the Environment variables by writing "environment variables" to search and press Enter.
Click on Environment Variables.
Choose the PATH variable and doubleclick it.
Click NEW button and add two new lines:
C:\Python3
C:\Python3\Scripts
Click OK and confirm changes. Now, when you open the command prompt (Step 4) and try the command again, it should print the correct version number.
(Extra tip for maintaining both Python 2.7 and Python 3.7 installations)
6. If you have both Python 2.7 and Python 3.7 installed and you want to use both of them through the command prompt, rename one the python.exe files. In the example picture below, I renamed my Python 3 installation's .exe file to "python3.exe". Now I can write "python3 --version", when I want to use Python 3 and write "python --version", when I want to use the old Python 2.7.
Last updated 10.10.2018
2. Start installation by clicking the python-3.7.0.exe
And after a short wait, Python 3.7.0. has been installed succesfully.
4. And we can verify the succesfull installation by searching for "cmd" and opening the "Command Prompt" by hitting Enter.
Now we can write a commad to the command prompt: python --version
and python gracefully answers with version 3.7.0.
If the command produces an error, it means that the Python installation path has not been added to the Windows PATH environment variable and that's why the command prompt can't find it.
But we can fix this by simply adding it to the PATH!
5. Setting Windows 10 Environment variables
The most important environment variable is PATH, which the command prompt uses to find paths to installed programs. Python has its own internal path variable named PYTHONPATH, that is used as the default directory for findgin Python libraries and modules.
Open the Environment variables by writing "environment variables" to search and press Enter.
C:\Python3
C:\Python3\Scripts
Click OK and confirm changes. Now, when you open the command prompt (Step 4) and try the command again, it should print the correct version number.
(Extra tip for maintaining both Python 2.7 and Python 3.7 installations)
6. If you have both Python 2.7 and Python 3.7 installed and you want to use both of them through the command prompt, rename one the python.exe files. In the example picture below, I renamed my Python 3 installation's .exe file to "python3.exe". Now I can write "python3 --version", when I want to use Python 3 and write "python --version", when I want to use the old Python 2.7.
Last updated 10.10.2018
Python 3 asennusohje
1. Lataa asennustiedosto
Mene osoitteeseen: https://www.python.org/downloads/ ja lataa Pythonin uusin asennustiedosto 3.7.1. omalle käyttöjärjestelmällesi. Tämä ohje on tehty käyttäen Windows 10 -käyttöjärjestelmää.
2. Käynnistä asennus
Käynnistä tiedoston python-3.7.1.exe asennus.
Tässä vaiheessa voit lisätä Pythonin Windowsin ympäristömuuttujiin valitsemalla rastin alempaan vaihtoehtoon "Add Python 3.7. to PATH". Ympäristömuuttujien asettaminen käydään vielä läpi tämän ohjeen lopussa. Valitse "Customize installation".
Next!
Asennuskansioksi sopii C:\Python3. Meillä voi olla asennettuna samaan aikaan Python 2.7 kansioon C:\Python27 ja kumpikin elää sovussa keskenään. Install!
Ja Python 3.7.1. on asennettu onnistuneesti!
3. Varmista asennuksen onnistuminen
Ja tämän voimme todeta avaamalla komentorivin kirjoittamalla "cmd" Windowsin hakuun ja valitsemalla "Command Prompt" tai vain painamalla Enter.
# Nyt voimme kirjoittaa komentoriville komennon:
python --version
ja Python vastaa onnistuneesti versionumerolla 3.7.1.
(kuvassa tehty vanhemmalla versiolla)
Mikäli komento tuottaa virheen, se tarkoittaa, että Python -asennuksen polkua ei ole lisätty Windowsin PATH-muuttujaan, eikä komentorivi siksi löydä komentoa.
Mutta tämä voidaan korjata lisäämällä asennuspolku ympäristömuuttujaan!
4. Windowsin ympäristömuuttujien asettaminen
Tämä on tärkeä taito oppia, sillä ympäristömuuttujia pitää muokata ja lisätä jatkossakin. Tärkein tietää näistä on PATH, minkä kautta esimerkiksi komentokehote löytää asennuspolut. Pythonilla on oma sisäinen ympäristömuuttuja PYTHONPATH, joka on Python-kirjastojen oletushakupolku.
Avaa ympäristömuuttujat kirjoittamalla hakuun "environment variables" ja paina Enter.
Valitse valikosta Environment Variables.
Valitse PATH muttuja ja tuplaklikkaa sitä (tai valitse se ja paina Edit).
# Lisää kaksi uutta riviä New-napista ja lisää siihen:
C:\Python3
C:\Python3\Scripts
Klikkaa Ok ja varmista muutokset. Nyt kun avaat komentorivin (Kohta 3) ja kokeilet komentoa uudestaan, versionumeron pitäisi tulostua oikein.
5. LISÄVINKKI: Python 2.7 ja Python 3.7 rinnakkain
Mikäli sinulla on asennettuna koneellasi sekä Python 2.7. ja Python 3.7. ja haluat käyttää molempia komentoriviltä, kannattaa toinen python.exe-tiedostoista nimetä uudelleen.
Alla olevassa esimerkissä nimesin Python 3 asennuksen .exe tiedoston "python3.exe". Nyt voin kirjoittaa komentoriville "python3 --version", kun haluan käyttää Python 3.7.0 ja pelkkä "python --version", kun haluan käyttää vanhaa Python 2.7.
Päivitetty 10.10.2018
Mene osoitteeseen: https://www.python.org/downloads/ ja lataa Pythonin uusin asennustiedosto 3.7.1. omalle käyttöjärjestelmällesi. Tämä ohje on tehty käyttäen Windows 10 -käyttöjärjestelmää.
2. Käynnistä asennus
Käynnistä tiedoston python-3.7.1.exe asennus.
Ja Python 3.7.1. on asennettu onnistuneesti!
3. Varmista asennuksen onnistuminen
Ja tämän voimme todeta avaamalla komentorivin kirjoittamalla "cmd" Windowsin hakuun ja valitsemalla "Command Prompt" tai vain painamalla Enter.
# Nyt voimme kirjoittaa komentoriville komennon:
python --version
ja Python vastaa onnistuneesti versionumerolla 3.7.1.
(kuvassa tehty vanhemmalla versiolla)
Mikäli komento tuottaa virheen, se tarkoittaa, että Python -asennuksen polkua ei ole lisätty Windowsin PATH-muuttujaan, eikä komentorivi siksi löydä komentoa.
Mutta tämä voidaan korjata lisäämällä asennuspolku ympäristömuuttujaan!
4. Windowsin ympäristömuuttujien asettaminen
Tämä on tärkeä taito oppia, sillä ympäristömuuttujia pitää muokata ja lisätä jatkossakin. Tärkein tietää näistä on PATH, minkä kautta esimerkiksi komentokehote löytää asennuspolut. Pythonilla on oma sisäinen ympäristömuuttuja PYTHONPATH, joka on Python-kirjastojen oletushakupolku.
Avaa ympäristömuuttujat kirjoittamalla hakuun "environment variables" ja paina Enter.
# Lisää kaksi uutta riviä New-napista ja lisää siihen:C:\Python3
C:\Python3\Scripts
Klikkaa Ok ja varmista muutokset. Nyt kun avaat komentorivin (Kohta 3) ja kokeilet komentoa uudestaan, versionumeron pitäisi tulostua oikein.
5. LISÄVINKKI: Python 2.7 ja Python 3.7 rinnakkain
Mikäli sinulla on asennettuna koneellasi sekä Python 2.7. ja Python 3.7. ja haluat käyttää molempia komentoriviltä, kannattaa toinen python.exe-tiedostoista nimetä uudelleen.
Alla olevassa esimerkissä nimesin Python 3 asennuksen .exe tiedoston "python3.exe". Nyt voin kirjoittaa komentoriville "python3 --version", kun haluan käyttää Python 3.7.0 ja pelkkä "python --version", kun haluan käyttää vanhaa Python 2.7.
Päivitetty 10.10.2018
lauantai 26. toukokuuta 2018
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:
Lista päivitetty 26.05.2018
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)
- Sikuli (http://www.sikuli.org/)
- fmbt (https://01.org/fmbt)
- Applitools Eyes (https://applitools.com/)
- Galen Framework (http://galenframework.com/)
- 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/)
- Jenkins (https://jenkins.io/)
- Travis CI (https://travis-ci.org/)
- Hudson CI (http://hudson-ci.org/)
- TeamCity (https://www.jetbrains.com/teamcity/)
- Ansible (https://www.ansible.com/)
- Docker (https://www.docker.com/)
- Kubernetes (https://kubernetes.io/)
- Artifactory (https://jfrog.com/artifactory/)
- 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/)
Lista päivitetty 26.05.2018
torstai 5. huhtikuuta 2018
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ä.
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ä.
maanantai 27. maaliskuuta 2017
Nykypäivänä suuri osa uusista sovelluksista on appeja, joita käytetään älylaitteilla, kuten kännyköillä ja tableteilla, perinteisten pöytätietokoneiden sijaan.
Tämä asettaa omat vaatimuksensa testaukselle, sillä testattavien laite- ja käyttöjärjestelmäparien määrä lähestyy erityisesti Googlen Android-ekosysteemissä ääretöntä. Applen iOS-ekosysteemi on laitelukumäärältään helpommin hallittavissa, mutta siinäkin on omat niksinsä, miten laitteilla saadaa testit pyörimään sujuvasti. Windows-phonet voidaan jättää testaamatta (kirjoittajan mielipide, joka voidaan perustella laitteiden käytön vähäisyydellä). Miten siis saadaan testattua sama mobiilisovellus mahdollisimman monella eri laitteella luotettavasti, nopeasti ja vielä mahdollisimman edullisesti?
Testausorganisaatio on siis ison valinnan edessä. Testausorganisaatio voi joko:
Laitelabra on tila, jossa mobiililaitteet puksuttavat testejä läpi. Laitteet sijaitsevat tavanomaisesti siististi riveissä ja niiden takaa kulkee suuri piuhaviidakko, joka yhdistää ne sisäverkkoon ja syöttää niille sähköä. Laitteista vastaava työntekijä asentaa säännöllisin väliajoin uusimpia mobiililaitteita räkkiin ja korjaa tai asentaa uudelleen kaatuneet laitteet. Erilaiset ohjelmistopäivitykset, kuten vaikka uusi Android-käyttöjärjestelmän versio, saattavat rikkoa kännykän yhteensopivuuden ja tiputtaa sen testiympäristöstä.
Labran ylläpitotyön määrä on suuri. Uusimpien laitteiden hankintaan käytettävä rahamäärä on suuri. Etuina on täysi varmuus testauksen oikeellisuudesta ja erilaisten tavanomaisuudesta poikkeavien testitapausten toteuttaminen. Testilabra on strateginen resurssi, jota voidaan hyödyntää myös organisaation muissa sisäisissä testeissä.
Laitelabran rakentaminen on strateginen resurssi, jonka pystyttämistä pitäisi miettiä liiketoiminnan näkökulmasta. Labran rakentaminen ja ylläpito vaatii paljon resursseja, joten sen tuottama lisäarvo pitää pystyä liiketaloudellisesti perustelemaan suhteessa pilvipalvelun käyttöön. Pitää kysyä, mitä lisäarvoa oman laitelabran rakentaminen tuo testaukseen ja jos tuo, onko se lisäarvo riittävää - uskaltaisin sanoa, että pienten organisaatioiden on kannattavampaa ainakin aloittaa pilvipalvelun kokeilemisella ja vasta sitten siirtyä oman laitelabran suunnittelemiseen.
Lähteet:
TestObject, kotisivut: https://testobject.com/
Tämä asettaa omat vaatimuksensa testaukselle, sillä testattavien laite- ja käyttöjärjestelmäparien määrä lähestyy erityisesti Googlen Android-ekosysteemissä ääretöntä. Applen iOS-ekosysteemi on laitelukumäärältään helpommin hallittavissa, mutta siinäkin on omat niksinsä, miten laitteilla saadaa testit pyörimään sujuvasti. Windows-phonet voidaan jättää testaamatta (kirjoittajan mielipide, joka voidaan perustella laitteiden käytön vähäisyydellä). Miten siis saadaan testattua sama mobiilisovellus mahdollisimman monella eri laitteella luotettavasti, nopeasti ja vielä mahdollisimman edullisesti?
Testausorganisaatio on siis ison valinnan edessä. Testausorganisaatio voi joko:
- rakentaa oman laitelabransa
- käyttää pilvipalvelun laitelabraa
Laitelabra on tila, jossa mobiililaitteet puksuttavat testejä läpi. Laitteet sijaitsevat tavanomaisesti siististi riveissä ja niiden takaa kulkee suuri piuhaviidakko, joka yhdistää ne sisäverkkoon ja syöttää niille sähköä. Laitteista vastaava työntekijä asentaa säännöllisin väliajoin uusimpia mobiililaitteita räkkiin ja korjaa tai asentaa uudelleen kaatuneet laitteet. Erilaiset ohjelmistopäivitykset, kuten vaikka uusi Android-käyttöjärjestelmän versio, saattavat rikkoa kännykän yhteensopivuuden ja tiputtaa sen testiympäristöstä.
Labran ylläpitotyön määrä on suuri. Uusimpien laitteiden hankintaan käytettävä rahamäärä on suuri. Etuina on täysi varmuus testauksen oikeellisuudesta ja erilaisten tavanomaisuudesta poikkeavien testitapausten toteuttaminen. Testilabra on strateginen resurssi, jota voidaan hyödyntää myös organisaation muissa sisäisissä testeissä.
Laitelabran rakentaminen on strateginen resurssi, jonka pystyttämistä pitäisi miettiä liiketoiminnan näkökulmasta. Labran rakentaminen ja ylläpito vaatii paljon resursseja, joten sen tuottama lisäarvo pitää pystyä liiketaloudellisesti perustelemaan suhteessa pilvipalvelun käyttöön. Pitää kysyä, mitä lisäarvoa oman laitelabran rakentaminen tuo testaukseen ja jos tuo, onko se lisäarvo riittävää - uskaltaisin sanoa, että pienten organisaatioiden on kannattavampaa ainakin aloittaa pilvipalvelun kokeilemisella ja vasta sitten siirtyä oman laitelabran suunnittelemiseen.
Lähteet:
TestObject, kotisivut: https://testobject.com/
torstai 16. maaliskuuta 2017
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/
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/
perjantai 10. helmikuuta 2017
Tässä kirjoituksessa tarkastellaan esimerkkiä bugista, joka pysäytti Microsoftin Zune-mediasoittimet.
Oli joulukuun 31. päivä. Se päivä oli vuoden 366 päivä, karkausvuonna 2008. Ihmiset kävelivät iloisina kaupunkien kaduilla kuunnellen nappikuulokkeistaan Coldplayn Viva la Vidaa. Kunnes, tuona päivänä kaikki Microsoftin ensimmäisen sukupolven Zune-mediasoittimet sammuivat, eivätkä koskaan enää heränneet.
Bugi johtui yhden ainoan numeron erosta loopissa, joka käsitteli vain 365 päivää. Sen seurauksena looppi ei koskaan pysähtynyt ja Zune jäätyi. Koodi näytti tältä:
Koodin ideana on ottaa päivien määrä kellosta ja laskea vuosi. Mitä koodissa oikeasti tapahtuu on se, että kun vuodessa on 366 päivää, ohjelma jää ikuiseen while-silmukkaan, eikä koskaan riko sitä. Ja koska tämä koodinpätkä oli Zunen käynnistysskriptissä, Zune jäätyi joka käynnistyksellä.
Lähde:
James A. Whitaker, "Exploratory Software Testing: Tips, Tricks, Tours and Techniques to Guide Test Design". (2009). Pearson Education. p. 256.
Oli joulukuun 31. päivä. Se päivä oli vuoden 366 päivä, karkausvuonna 2008. Ihmiset kävelivät iloisina kaupunkien kaduilla kuunnellen nappikuulokkeistaan Coldplayn Viva la Vidaa. Kunnes, tuona päivänä kaikki Microsoftin ensimmäisen sukupolven Zune-mediasoittimet sammuivat, eivätkä koskaan enää heränneet.
Bugi johtui yhden ainoan numeron erosta loopissa, joka käsitteli vain 365 päivää. Sen seurauksena looppi ei koskaan pysähtynyt ja Zune jäätyi. Koodi näytti tältä:
// Tarkista karkausvuosiyear = ORIGINYEAR; /* = 1980 */while (days > 365){ if (IsLeapYear(year)) { if (days > 366) { days -= 365; year += 1; } } else { days -= 365 year += 1; }} Koodin ideana on ottaa päivien määrä kellosta ja laskea vuosi. Mitä koodissa oikeasti tapahtuu on se, että kun vuodessa on 366 päivää, ohjelma jää ikuiseen while-silmukkaan, eikä koskaan riko sitä. Ja koska tämä koodinpätkä oli Zunen käynnistysskriptissä, Zune jäätyi joka käynnistyksellä.
Lähde:
James A. Whitaker, "Exploratory Software Testing: Tips, Tricks, Tours and Techniques to Guide Test Design". (2009). Pearson Education. p. 256.
torstai 9. helmikuuta 2017
Sanapari Ad hoc tulee latinan kielestä ja se tarkoittaa "for this" - tätä varten. Sanaparia käytetään yleisesti etuliitteenä tapauksissa, joissa pitää nopeasti keksiä ratkaisu jotain tiettyä, usein yllättäen esiintynyttä, tapausta varten. Sama pätee myös Ad hoc -testauksessa.
Määritelmänsä mukaisesti Ad hoc -testaus on siis epäformaali prosessi, joka tehdään ilman suunnittelua tai dokumentointia. Sitä käytetään tyypillisesti, kun formaali, strukturoitu testaus on päättynyt, mutta järjestelmästä on silti löytynyt jokin bugi ja siitä pitäisi päästä nopeasti eroon ennen tuotantoon vientiä. Tällöin vian syy pitää löytää nopeasti, eikä testisuunnitteluun jää aikaa.
ISTQB Exam Certificationin (2016) artikkeli nostaa esiin viisi parasta käytäntöä (best practices) Ad hoc -testauksessa:
Kuitenkin Ad hoc -testausta pitäisi tehdä mahdollisimman vähän, sillä sen liiallinen käyttö kertoo strukturoimattomasta ja toimimattomasta testausprosessista, joka itsessään antaa syytä huoleen testauksen laadusta. Ammattimaisen ohjelmistotestauksen pitäisi olla aina formaalia, strukturoitua ja jäljitettävää. Siksi Ad hoc -testausta pitäisikin käyttää mahdollisimman vähän, tapauskohtaisesti, ad hoc.
Lähteet:
Ad hoc -testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ad_hoc_testing
"What is Ad hoc testing? Types, advantages and disadvantages". ISTQB Exam Certification, Saatavilla: http://istqbexamcertification.com/what-is-ad-hoc-testing/
Määritelmänsä mukaisesti Ad hoc -testaus on siis epäformaali prosessi, joka tehdään ilman suunnittelua tai dokumentointia. Sitä käytetään tyypillisesti, kun formaali, strukturoitu testaus on päättynyt, mutta järjestelmästä on silti löytynyt jokin bugi ja siitä pitäisi päästä nopeasti eroon ennen tuotantoon vientiä. Tällöin vian syy pitää löytää nopeasti, eikä testisuunnitteluun jää aikaa.
ISTQB Exam Certificationin (2016) artikkeli nostaa esiin viisi parasta käytäntöä (best practices) Ad hoc -testauksessa:
- Testaajalla on syvä tuntemus testattavasta järjestelmästä
- Testaus priorisoidaan koskemaan järjestelmän tärkeimpiä osia
- Voidaan tehdä kevyt, karkea testaussuunnitelma
- Testaaja hyödyntää työkaluja järjestelmän tehokkaassa tutkimisessa
- Havainnot dokumentoidaan, vaikka prosessia ei dokumentoitasi
Kuitenkin Ad hoc -testausta pitäisi tehdä mahdollisimman vähän, sillä sen liiallinen käyttö kertoo strukturoimattomasta ja toimimattomasta testausprosessista, joka itsessään antaa syytä huoleen testauksen laadusta. Ammattimaisen ohjelmistotestauksen pitäisi olla aina formaalia, strukturoitua ja jäljitettävää. Siksi Ad hoc -testausta pitäisikin käyttää mahdollisimman vähän, tapauskohtaisesti, ad hoc.
Lähteet:
Ad hoc -testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ad_hoc_testing
"What is Ad hoc testing? Types, advantages and disadvantages". ISTQB Exam Certification, Saatavilla: http://istqbexamcertification.com/what-is-ad-hoc-testing/
tiistai 7. helmikuuta 2017
Edellinen kirjoitukseni käsitteli Applitools Eyes -työkalua visuaalisen testauksen automatisointiin, mutta työkaluja siihen löytyy enemmänkin. Galen Framework on avoin ja vapaasti käytettävä framework, joka on kehitetty erityisesti web-sivujen layout-testien automatisointiin. Galenin lähdekoodi löytyy Githubista. Kattava dokumentaatio Galenin syntaksista löytyy Frameworkin kotisivulta.
Toisin kuin Applitoolsissa, missä testaus perustuu kahden erilaisen kuvatiedoston vertailuun, Galen Frameworkin ideana on kirjoittaa web-sivun layoutille vaatimukset (spesifikaatio, .gspec-tiedosto), jota vasten web-sivu ajetaan ja Framework ilmoittaa html-raporttina, läpäisikö vai reputtiko ulkoasu määritetyt vaatimukset. Galenin vaatimukset kirjoitetaan sen omalla kuvailevalla syntaksilla, mutta myös Javaa tai Javascriptia on mahdollista käyttää. Merkkauskieli on yksinkertaista ja helposti luettavaa, joten alkuunpääsy on suhteellisen helppoa.
Alla on esimerkki kuvitteellisesta Galen-spesifikaatiosta web-sivun "Koti" ja "Yhteystiedot" menu-buttonien ulkoasujen tarkistukseen:
Aluksi siis määritellään web-sivun elementit niiden id:n, classin tai xpathin mukaan. Kun elementit on alustettu, voidaan niille asettaa erilaisia niiden ulkomuotoon liittyviä vaatimuksia. Edellisessä koodinpätkässä Koti-nappulalle asetetaan vaatimukseksi, että sen korkeus ja leveys ovat 64 pikseliä, nappulan teksti on "Koti" ja se on horisontaalisesti linjassa viereisen nappulan kanssa. Jos jokin näistä ei pidä suorituksen aikana paikkaansa, testi epäonnistuu.
Yksi Galen Frameworkin hyvistä puolista on mahdollisuus ajaa nopeasti ja helposti samoja vaatimusmäärittelyjä (.gspec-tiedostoja) eri selaimilla ja resoluutioilla. Sama testi voidaan ajaa yhdellä komennolla Firefoxilla, Chromella tai Internet Explorerilla ja samalla voidaan asettaa eri ajettavat resoluutiot. Näin esimerkiksi mobiilikäyttöön suunniteltu resoluutio voidaan tarkastaa samalla komennolla (tämän hyvin toimiminen voi tosin vaatia hyvin suunniteltua vaatimusmäärittelyä).
Mihin siis Galen Framework soveltuu erityisen hyvin ja mihin taas ei? Galen Framework on varteenotettava työkalu layout-testauksen automatisoinnille. Sen hyvinä puolina ovat ehdottomasti sen avoimuus ja ilmaisuus, sekä vaatimusmäärittelyn tarkkuuden. Tämä vaatimusmäärittelyiden tarkka kirjaaminen on tosin myös työlästä, eikä Galenia siksi kannata yrittää käyttää joka tilanteessa. Galenin testit ovat kuitenkin suhteellisen nopeita suorittaa, sillä raskaita kuvanvertailu-operaatioita ei suoriteta. Vain hullu (ruot. galen, galet, galna) jättäisi Galenin kokeilematta.
Lähteet:
Galen Framework, saatavilla: http://galenframework.com/
Galen Framework GitHubissa: https://github.com/galenframework/galen
Galen Frameworkin dokumentaatio ja syntaksi: http://galenframework.com/docs/all/
Toisin kuin Applitoolsissa, missä testaus perustuu kahden erilaisen kuvatiedoston vertailuun, Galen Frameworkin ideana on kirjoittaa web-sivun layoutille vaatimukset (spesifikaatio, .gspec-tiedosto), jota vasten web-sivu ajetaan ja Framework ilmoittaa html-raporttina, läpäisikö vai reputtiko ulkoasu määritetyt vaatimukset. Galenin vaatimukset kirjoitetaan sen omalla kuvailevalla syntaksilla, mutta myös Javaa tai Javascriptia on mahdollista käyttää. Merkkauskieli on yksinkertaista ja helposti luettavaa, joten alkuunpääsy on suhteellisen helppoa.
Alla on esimerkki kuvitteellisesta Galen-spesifikaatiosta web-sivun "Koti" ja "Yhteystiedot" menu-buttonien ulkoasujen tarkistukseen:
// Alusta layout-elementit objekteiksi@objects menu_home id home_btn menu_contact id contact_btn
// Aloita sektio (html-raporttia varten)= Menu Section =// Varsinaiset määrittelyt menu_home: visible height 64px width 64px text is "Koti" aligned horizontally right menu_contact
menu_contact: visible height 32px width 32px text is "Yhteystiedot" aligned horizontally left menu_home Yksi Galen Frameworkin hyvistä puolista on mahdollisuus ajaa nopeasti ja helposti samoja vaatimusmäärittelyjä (.gspec-tiedostoja) eri selaimilla ja resoluutioilla. Sama testi voidaan ajaa yhdellä komennolla Firefoxilla, Chromella tai Internet Explorerilla ja samalla voidaan asettaa eri ajettavat resoluutiot. Näin esimerkiksi mobiilikäyttöön suunniteltu resoluutio voidaan tarkastaa samalla komennolla (tämän hyvin toimiminen voi tosin vaatia hyvin suunniteltua vaatimusmäärittelyä).
Mihin siis Galen Framework soveltuu erityisen hyvin ja mihin taas ei? Galen Framework on varteenotettava työkalu layout-testauksen automatisoinnille. Sen hyvinä puolina ovat ehdottomasti sen avoimuus ja ilmaisuus, sekä vaatimusmäärittelyn tarkkuuden. Tämä vaatimusmäärittelyiden tarkka kirjaaminen on tosin myös työlästä, eikä Galenia siksi kannata yrittää käyttää joka tilanteessa. Galenin testit ovat kuitenkin suhteellisen nopeita suorittaa, sillä raskaita kuvanvertailu-operaatioita ei suoriteta. Vain hullu (ruot. galen, galet, galna) jättäisi Galenin kokeilematta.
Lähteet:
Galen Framework, saatavilla: http://galenframework.com/
Galen Framework GitHubissa: https://github.com/galenframework/galen
Galen Frameworkin dokumentaatio ja syntaksi: http://galenframework.com/docs/all/
torstai 26. tammikuuta 2017
Usein testiautomaatiossa keskitytään funktionaaliseen testaukseen. Testiautomaatio-caset rakennetaan suorittamaan ohjelman vaatimusten mukaista toiminnallisuutta. Tärkeintähän on, että ohjelma toimii niin kuin pitääkin ja jos toiminallisuus on kunnossa, niin ohjelma on valmis tuotantoon, eikö niin? Vai onko sittenkään? Minkä näkökulman jätämme testaamatta? Sen, miltä ohjelma näyttää visuaalisesti.
Visuaalisen testauksen tarkoitus on löytää bugit, jotka syntyvät UI-komponentteja päivittäessä. Visuaalinen testaus vie manuaalisesti paljon aikaa ja sen onnistuminen riippuu testaajan silmän tarkkuudesta. Gregory Goldshteyn (2016) listaa artikkelissaan neljä kohtaa, jotka muodostavat hänen visuaalisen testauksen checklistinsa. Nämä neljä kohtaa ovat:
- Varmista, että jokainen UI-komponentti on oikean kokoinen, muotoinen, värinen ja oikeassa paikassa
- Varmista, etteivät UI-komponentit ole päällekkäin tai peitä toisiaan
- Varmista, ettei ruutukoon muutos riko UI-komponentteja (esim. tabletit, kännykät, pöytäkone)
- Varmista, että kaikki kuvat näkyvät oikein
Miten voimme hyödyntää testiautomaatiota web-sivun visuaalisessa testaamisessa? Applitools Eyes (https://applitools.com/) on visuaalisen testauksen automatisointiin tarkoitettu työkalu, jota käytetään web-sovelluksena. Sovelluksen saa toimimaan esim. Chromeen ladattavana Applitools Eyes Express -lisäosana (https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh). Web-käyttöliittymä on yksinkertainen ja helppokäyttöinen, kuten myös lisäosan käyttäminenkin. Lisäosan toiminnolla voi ottaa kuvan aukiolevasta web-sivusta baselineksi, ja toisella kerralla otettua kuvaa verrataan baselineen. Kuvien erot näytetään vierekkäin, erot korostettuina. Jos kuvissa on eroja (eli uusi versio web-sivusta ei vastaa alkuperäistä), testi näyttää punaista ja epäonnistuu. Testicaseihin voi asettaa erilaisia suoja-alueita, esim. dynaamisesti vaihtuvaa sisältöä, kuten mainoksia, varten. Erojen huomaamisen tasoa voi säätää tiukasta löyhään tai sen voi asettaa tutkimaan vain sivun layoutin säilymistä.
Vaikka Applitools Eyes tuntuukin helpottavan visuaalisen testauksen työurakkaa, testicasejen suunnittelu (eli ensimmäiset ajot määritelmän asettamiseksi) vievät aikaa ja niitä pitää päivittää usein. Applitools on kuitenkin hyvä huomaamaan ne pienetkin erot tai virheet, mitkä helposti menevät ihmisiltä ohi. Sen käytön voidaan katsoa vähentävän graafisten virheiden määrää sovelluksen tulevaisuudessa. No, katsotaan. Kauneus on katsojan silmässä.
Lähteet:
Applitools Eyes, Saatavilla: https://applitools.com/
Applitools Eyes Express -lisä Google Chromeen, Saatavilla: https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh
"Review of Visual vs. Functional Testing with Applitools", Gregory Goldshteyn, 12.01.2016. Saatavilla: https://www.linkedin.com/pulse/review-visual-vs-functional-testing-applitools-gregory-goldshteyn
Robot-AppEyes, Robot Framework moduuli Applitoolsille, Saatavilla: http://navinet.github.io/Robot-AppEyes/
Visuaalisen testauksen tarkoitus on löytää bugit, jotka syntyvät UI-komponentteja päivittäessä. Visuaalinen testaus vie manuaalisesti paljon aikaa ja sen onnistuminen riippuu testaajan silmän tarkkuudesta. Gregory Goldshteyn (2016) listaa artikkelissaan neljä kohtaa, jotka muodostavat hänen visuaalisen testauksen checklistinsa. Nämä neljä kohtaa ovat:
- Varmista, että jokainen UI-komponentti on oikean kokoinen, muotoinen, värinen ja oikeassa paikassa
- Varmista, etteivät UI-komponentit ole päällekkäin tai peitä toisiaan
- Varmista, ettei ruutukoon muutos riko UI-komponentteja (esim. tabletit, kännykät, pöytäkone)
- Varmista, että kaikki kuvat näkyvät oikein
Miten voimme hyödyntää testiautomaatiota web-sivun visuaalisessa testaamisessa? Applitools Eyes (https://applitools.com/) on visuaalisen testauksen automatisointiin tarkoitettu työkalu, jota käytetään web-sovelluksena. Sovelluksen saa toimimaan esim. Chromeen ladattavana Applitools Eyes Express -lisäosana (https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh). Web-käyttöliittymä on yksinkertainen ja helppokäyttöinen, kuten myös lisäosan käyttäminenkin. Lisäosan toiminnolla voi ottaa kuvan aukiolevasta web-sivusta baselineksi, ja toisella kerralla otettua kuvaa verrataan baselineen. Kuvien erot näytetään vierekkäin, erot korostettuina. Jos kuvissa on eroja (eli uusi versio web-sivusta ei vastaa alkuperäistä), testi näyttää punaista ja epäonnistuu. Testicaseihin voi asettaa erilaisia suoja-alueita, esim. dynaamisesti vaihtuvaa sisältöä, kuten mainoksia, varten. Erojen huomaamisen tasoa voi säätää tiukasta löyhään tai sen voi asettaa tutkimaan vain sivun layoutin säilymistä.
Vaikka Applitools Eyes tuntuukin helpottavan visuaalisen testauksen työurakkaa, testicasejen suunnittelu (eli ensimmäiset ajot määritelmän asettamiseksi) vievät aikaa ja niitä pitää päivittää usein. Applitools on kuitenkin hyvä huomaamaan ne pienetkin erot tai virheet, mitkä helposti menevät ihmisiltä ohi. Sen käytön voidaan katsoa vähentävän graafisten virheiden määrää sovelluksen tulevaisuudessa. No, katsotaan. Kauneus on katsojan silmässä.
Lähteet:
Applitools Eyes, Saatavilla: https://applitools.com/
Applitools Eyes Express -lisä Google Chromeen, Saatavilla: https://chrome.google.com/webstore/detail/applitools-eyes-express/ofhaaccocoghamklkjfliehhdhmibdbh
"Review of Visual vs. Functional Testing with Applitools", Gregory Goldshteyn, 12.01.2016. Saatavilla: https://www.linkedin.com/pulse/review-visual-vs-functional-testing-applitools-gregory-goldshteyn
Robot-AppEyes, Robot Framework moduuli Applitoolsille, Saatavilla: http://navinet.github.io/Robot-AppEyes/
torstai 19. tammikuuta 2017
Smoke testing, joka tunnetaan myös nimillä confidence testing, sanity testing, build verification test (BVT) ja build acceptance test, tarkoittaa ohjelmiston valmistavaa testausta ennen julkaisua, jonka tarkoituksena on varmistua siitä, että ohjelmiston tärkeimmät ominaisuudet toimivat. Smoke-testaus suunnitellaan siten, että testicaset kattavat järjestelmän tai sen moduulin kriittisimmän toiminnallisuuden. Mutta mikä on se syy, miksi smoke-testausta tehdään?
Nykyaikaisten ohjelmistojen arkkitehtuuri perustuu yksittäisiin moduuleihin, jotka toteuttavat tietyn toiminallisuuden ja siihen, että moduulit viestivät ja toimivat keskenään yhteen. Useiden eri moduulien muodostamat kokonaisuudet ovat usein hyvin monimutkaisia, jolloin vain harvalla on kokonaiskuva järjestelmän täydellisestä toiminnasta ja siitä, miten yksittäisten moduulien toiminta vaikuttaa koko järjestelmään. Usein esimerkiksi alimman tason moduulin toteutus on hämärretty, eikä ohjelmistokehittäjää edes kiinnosta, miten sen sisäinen logiikka on toteutettu, kunhan moduulin tuottama output-data on oikeanlaista muiden moduulien käyttöön.
Tässä kuitenkin piilee inhimillisen virheen mahdollisuus. Nykyaikainen ketterä, agile, ohjelmistokehitys on nimensä mukaisesti nopeatahtista ja yksittäisiä moduuleja päivitetään tai muutetaan päivittäin. Koska nämä moduulit ovat tiivisti yhteydessä muihin moduuleihin, pienikin, harmittomalta vaikuttanut muutos yhden moduulin toiminnassa voi rikkoa koko järjestelmän yhteistoiminnan, odottamattomasti.
Tämän takia päivittäistä kääntämistä (daily build) ja sen automatisoitua smoke-testausta pidetään yhtenä ohjelmistokehityksen "hyvistä käytännöistä", best practices. Päivittäisellä automatisoidulla smoke-testauksella saadaan kiinni kaikki ne odottamattomat bugit, jotka syntyivät kehittäjän eilen tekemästä muutoksesta. Bugit havaitaan siten ajoissa ja toimiva ohjelmistoversio voidaan palauttaa ennen kuin epätoimivaa ohjelmistoversiota ehditään kehittää pidemmälle. Testaajina tiedämme, että tämä tarkoittaa mahdollisesti suuria säästöjä niin ajassa, rahassa kuin miestyövuosissakin.
Smoke-testauksella voidaan siis saada nopea vastaus ohjelmiston yleisen tason toimivuudesta. Sen tehtävänä, kuten testauksella yleisestikin, on luoda luottamusta ohjelmiston laatuun. Smoke-testauksella voimme olla varma, että meidän jokapäiväinen buildimme toimii huomennakin.
Lähde:
Smoke testing (software), Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Smoke_testing_(software)
Nykyaikaisten ohjelmistojen arkkitehtuuri perustuu yksittäisiin moduuleihin, jotka toteuttavat tietyn toiminallisuuden ja siihen, että moduulit viestivät ja toimivat keskenään yhteen. Useiden eri moduulien muodostamat kokonaisuudet ovat usein hyvin monimutkaisia, jolloin vain harvalla on kokonaiskuva järjestelmän täydellisestä toiminnasta ja siitä, miten yksittäisten moduulien toiminta vaikuttaa koko järjestelmään. Usein esimerkiksi alimman tason moduulin toteutus on hämärretty, eikä ohjelmistokehittäjää edes kiinnosta, miten sen sisäinen logiikka on toteutettu, kunhan moduulin tuottama output-data on oikeanlaista muiden moduulien käyttöön.
Tässä kuitenkin piilee inhimillisen virheen mahdollisuus. Nykyaikainen ketterä, agile, ohjelmistokehitys on nimensä mukaisesti nopeatahtista ja yksittäisiä moduuleja päivitetään tai muutetaan päivittäin. Koska nämä moduulit ovat tiivisti yhteydessä muihin moduuleihin, pienikin, harmittomalta vaikuttanut muutos yhden moduulin toiminnassa voi rikkoa koko järjestelmän yhteistoiminnan, odottamattomasti.
Tämän takia päivittäistä kääntämistä (daily build) ja sen automatisoitua smoke-testausta pidetään yhtenä ohjelmistokehityksen "hyvistä käytännöistä", best practices. Päivittäisellä automatisoidulla smoke-testauksella saadaan kiinni kaikki ne odottamattomat bugit, jotka syntyivät kehittäjän eilen tekemästä muutoksesta. Bugit havaitaan siten ajoissa ja toimiva ohjelmistoversio voidaan palauttaa ennen kuin epätoimivaa ohjelmistoversiota ehditään kehittää pidemmälle. Testaajina tiedämme, että tämä tarkoittaa mahdollisesti suuria säästöjä niin ajassa, rahassa kuin miestyövuosissakin.
Smoke-testauksella voidaan siis saada nopea vastaus ohjelmiston yleisen tason toimivuudesta. Sen tehtävänä, kuten testauksella yleisestikin, on luoda luottamusta ohjelmiston laatuun. Smoke-testauksella voimme olla varma, että meidän jokapäiväinen buildimme toimii huomennakin.
Lähde:
Smoke testing (software), Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Smoke_testing_(software)
maanantai 9. tammikuuta 2017
Jos apinalle antaisi tietokoneohjelman testattavaksi, miten apina suorittaisi tehtävän? Lopputuloksena olisi todennäköisesti jono satunnaisia näppäinpainalluksia ja hajonnut tietokoneen näppäimistö. Oliko apinasta siis mitään hyötyä vai ei?
Apinatestauksella (Monkey testing) tarkoitetaan testausta, jossa järjestelmälle annetaan satunnaisia syötteitä ja tutkitaan, miten järjestelmä selviytyy niiden käsittelystä. Usein juuri virheelliset syötteet, joiden käsittelyyn kehittäjät eivät ole osanneet varautua, johtavat järjestelmän vika- tai virhetilanteisiin. Apinatestaus onkin tärkeä työkalu järjestelmän häiriökestävyyden arvioinnissa (robustness). Satunnainen syöte voi myös tuoda uusia out-of-the-box ideoita järjestelmän koettelemiseen ja sillä tavoin antaa uusia keinoja löytää järjestelmän rikkovia bugeja.
On olemassa myös termi fuzz testing (sumea testaus), joka usein esiintyy apinatestauksen yhteydessä. Osa määrittelee termien eroksi sen, että apinatestaus viittaa nimenomaan satunnaisiin toimiin (random actions), kun taas sumea testaus viittaa syötetyn datan satunnaisuuteen (random input data). Toisin sanoen, sumeaa testausta on esimerkiksi se, että syöttää ohjelmalle Excel-taulukon, jonka dataa on muokattu tai rikottu määritelmien vastaiseksi. Apinatestauksen esimerkki voisi puolestaan olla ohjelman käyttäminen painamalla satunnaisesti jokaista käytettävissä olevaa nappia.
Apinat voidaan jakaa älykkäisiin (smart) ja tyhmiin (dumb). Sama pätee myös apinatestauksessa.
Älykkäillä apinoilla on suppea idea järjestelmän toiminnasta, älykkäät apinat tietävät oman paikkansa ja kykynsä ja järjestelmän kyvyt, älykkäät apinat ovat fokusoituneet järjestelmän rikkomiseen ja osaavat raportoida niistä. Tyhmät apinat eivät tiedä mitään järjestelmän toiminnasta, tyhmät apinat eivät osaa syöttää oikeanlaista syötettä, tyhmät apinat eivät tiedä omia tai järjestelmän kykyjä, eivätkä ne toimi suunnitelmallisesti.
Testaamisen ei pitäisi olla päämäärätöntä näppäimistön hakkaamista, mutta silti siitä näyttää aina silloin tällöin olevan hyötyä. Arvelisin kuitenkin, että koulutettu testaaja tulee silti halvemmaksi kuin lennättää simpanssi Espooseen ja opettaa sille koodaamista. Banaanejakaan ei tarvitse ostaa.
Lähteet:
Monkey Testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Monkey_testing
Apinatestauksella (Monkey testing) tarkoitetaan testausta, jossa järjestelmälle annetaan satunnaisia syötteitä ja tutkitaan, miten järjestelmä selviytyy niiden käsittelystä. Usein juuri virheelliset syötteet, joiden käsittelyyn kehittäjät eivät ole osanneet varautua, johtavat järjestelmän vika- tai virhetilanteisiin. Apinatestaus onkin tärkeä työkalu järjestelmän häiriökestävyyden arvioinnissa (robustness). Satunnainen syöte voi myös tuoda uusia out-of-the-box ideoita järjestelmän koettelemiseen ja sillä tavoin antaa uusia keinoja löytää järjestelmän rikkovia bugeja.
On olemassa myös termi fuzz testing (sumea testaus), joka usein esiintyy apinatestauksen yhteydessä. Osa määrittelee termien eroksi sen, että apinatestaus viittaa nimenomaan satunnaisiin toimiin (random actions), kun taas sumea testaus viittaa syötetyn datan satunnaisuuteen (random input data). Toisin sanoen, sumeaa testausta on esimerkiksi se, että syöttää ohjelmalle Excel-taulukon, jonka dataa on muokattu tai rikottu määritelmien vastaiseksi. Apinatestauksen esimerkki voisi puolestaan olla ohjelman käyttäminen painamalla satunnaisesti jokaista käytettävissä olevaa nappia.
Apinat voidaan jakaa älykkäisiin (smart) ja tyhmiin (dumb). Sama pätee myös apinatestauksessa.
Älykkäillä apinoilla on suppea idea järjestelmän toiminnasta, älykkäät apinat tietävät oman paikkansa ja kykynsä ja järjestelmän kyvyt, älykkäät apinat ovat fokusoituneet järjestelmän rikkomiseen ja osaavat raportoida niistä. Tyhmät apinat eivät tiedä mitään järjestelmän toiminnasta, tyhmät apinat eivät osaa syöttää oikeanlaista syötettä, tyhmät apinat eivät tiedä omia tai järjestelmän kykyjä, eivätkä ne toimi suunnitelmallisesti.
Testaamisen ei pitäisi olla päämäärätöntä näppäimistön hakkaamista, mutta silti siitä näyttää aina silloin tällöin olevan hyötyä. Arvelisin kuitenkin, että koulutettu testaaja tulee silti halvemmaksi kuin lennättää simpanssi Espooseen ja opettaa sille koodaamista. Banaanejakaan ei tarvitse ostaa.
Lähteet:
Monkey Testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Monkey_testing
torstai 29. joulukuuta 2016
Mitä tarkoitetaan mustalla tai valkoisella laatikolla testauksessa? Aloitetaan laatikoiden määritelmillä.
Musta laatikko (Black-box) on järjestelmä, jonka sisäinen toimintalogiikka on tuntematon. Pystymme havaitsemaan järjestelmään liitetyt sisääntulot (input) ja siitä lähtevät ulostulot (output), muttemme tiedä, miten ulostuloa on tässä välissä muokattu. Usein pystymme päättelemään sisään- ja ulostulon eroista, mitä muutoksia järjestelmä tekee sisääntuloon, muttemme voi varmuudella sanoa, miten tai millä logiikalla ne on toteutettu.
Valkoinen laatikko (White-box) on järjestelmä, jonka sisäinen toimintalogiikka on tunnettu. Meillä on tietoa järjestelmän toteutuksen teknisistä yksityiskohdista ja sen logiikkaa kuvaava tekninen dokumentaatio. Logiikkakuvauksen avulla tiedämme täsmälleen, miten tai millä logiikalla järjestelmä muokkaa sisääntuloa.
Entä näiden laatikoiden testaus? Mitä black-box & white-box testing tarkoittavat käytännössä ja mitä eroja niillä on?
White-box testauksessa (tunnetaan myös nimellä Structure-based testing) järjestelmän sisäisestä rakenteesta johdetaan dynaamisesti testicaset, kun taas black-box testauksessa meillä on käytössä vain tiettyjä, järjestelmän ulkoisiin ominaisuuksiin nojaavia, spesifejä testejä. White-box testaus on siis testaajan kannalta monta kertaa mukavampaa ja tehokkaampaa, koska tiedämme, miten järjestelmä toimii, eikä sitä tarvitse arvuutella. Black-box testauksessa olemme täysin omillamme, eikä meillä ole mitään varmuutta siitä, että käyttämämme testit suorittavat kaiken ohjelmakoodin - vaikka maailman osaavin testausammattilaisten tiimi black-box testaisi mitä tahansa järjestelmää, on silti hyvin mahdollista, että peräti 70 prosenttia kaikesta koodista ei suoritettaisi kertaakaan! (Mitchell & Black, 2015)
Boris Beizer kirjoittaa kirjassaan Software Testing Techniques (ITC Press, 1990) yleisiä sääntöjä liittyen ohjelmakoodin suoritukseen ja bugien todennäköisyyteen:
1. Testaamatta jätetty koodinpätkä jättää järjestelmään bugeja. Bugien määrää voidaan arvioida kaavalla: testaamaton koodi * bugien todennäköisyys
2. Ohjelman yleisimpien suoritusteiden (pathien) testaus, varsinkin yksikkötestitasolla, ei ole niin tärkeää kuin harvinaisten suoritusteiden, koska järjestelmän toiminta kokonaisuudessaan testataan vielä myöhemmin järjestelmätasolla.
3. Logiikkavirheet tai logiikan sumeus (fuzzy thinking) ovat kääntäen verrannollisia pathin suorittamisen todennäköisyyteen.
4. Ohjelmoijat eivät useinkaan osaa arvioida ohjelman käyttämien pathien suoritustodennäköisyytttä - vain analyysi kertoo, mitä patheja suoritetaan todennäköisimmin.
5. Koodisegmenttien tärkeyden arviointi on subjektiivista ja voi johtaa virheisiin. Ohjelmoija voi olla niin ylpeä kauniista koodistaan tai tekemästään monimutkaisesta algoritmista, että testaa sen monta kertaa, mutta jättää testaamatta yksinkertaisen for-loopin, koska ajattelee "Mikä noin yksinkertaisessa lauseessa voi mennä pieleen?".
Listassa on ainakin muutama hyvä syy, miksi testaajan on tärkeää tietää suoritetun koodin määrä ja miksi järjestelmiä pitäisi aina testata white-box testauksella - testaus on siis sitä helpompaa, mitä enemmän tietää ohjelman suorittamista reiteistä tai koodin määrästä. Mustat laatikot kannattaa suosiolla jättää lentokoneisiin.
Lähteet:
Mitchell, Jamie L. & Black, Rex. "Advanced Software Testing, Vol. 3. Second Edition". (2015). p. 24-26. Rocky Nook.
Beizer, Boris. "Software Testing Techniques". (1990). ITC Press.
Musta laatikko (Black-box) on järjestelmä, jonka sisäinen toimintalogiikka on tuntematon. Pystymme havaitsemaan järjestelmään liitetyt sisääntulot (input) ja siitä lähtevät ulostulot (output), muttemme tiedä, miten ulostuloa on tässä välissä muokattu. Usein pystymme päättelemään sisään- ja ulostulon eroista, mitä muutoksia järjestelmä tekee sisääntuloon, muttemme voi varmuudella sanoa, miten tai millä logiikalla ne on toteutettu.
Valkoinen laatikko (White-box) on järjestelmä, jonka sisäinen toimintalogiikka on tunnettu. Meillä on tietoa järjestelmän toteutuksen teknisistä yksityiskohdista ja sen logiikkaa kuvaava tekninen dokumentaatio. Logiikkakuvauksen avulla tiedämme täsmälleen, miten tai millä logiikalla järjestelmä muokkaa sisääntuloa.
Entä näiden laatikoiden testaus? Mitä black-box & white-box testing tarkoittavat käytännössä ja mitä eroja niillä on?
White-box testauksessa (tunnetaan myös nimellä Structure-based testing) järjestelmän sisäisestä rakenteesta johdetaan dynaamisesti testicaset, kun taas black-box testauksessa meillä on käytössä vain tiettyjä, järjestelmän ulkoisiin ominaisuuksiin nojaavia, spesifejä testejä. White-box testaus on siis testaajan kannalta monta kertaa mukavampaa ja tehokkaampaa, koska tiedämme, miten järjestelmä toimii, eikä sitä tarvitse arvuutella. Black-box testauksessa olemme täysin omillamme, eikä meillä ole mitään varmuutta siitä, että käyttämämme testit suorittavat kaiken ohjelmakoodin - vaikka maailman osaavin testausammattilaisten tiimi black-box testaisi mitä tahansa järjestelmää, on silti hyvin mahdollista, että peräti 70 prosenttia kaikesta koodista ei suoritettaisi kertaakaan! (Mitchell & Black, 2015)
Boris Beizer kirjoittaa kirjassaan Software Testing Techniques (ITC Press, 1990) yleisiä sääntöjä liittyen ohjelmakoodin suoritukseen ja bugien todennäköisyyteen:
1. Testaamatta jätetty koodinpätkä jättää järjestelmään bugeja. Bugien määrää voidaan arvioida kaavalla: testaamaton koodi * bugien todennäköisyys
2. Ohjelman yleisimpien suoritusteiden (pathien) testaus, varsinkin yksikkötestitasolla, ei ole niin tärkeää kuin harvinaisten suoritusteiden, koska järjestelmän toiminta kokonaisuudessaan testataan vielä myöhemmin järjestelmätasolla.
3. Logiikkavirheet tai logiikan sumeus (fuzzy thinking) ovat kääntäen verrannollisia pathin suorittamisen todennäköisyyteen.
4. Ohjelmoijat eivät useinkaan osaa arvioida ohjelman käyttämien pathien suoritustodennäköisyytttä - vain analyysi kertoo, mitä patheja suoritetaan todennäköisimmin.
5. Koodisegmenttien tärkeyden arviointi on subjektiivista ja voi johtaa virheisiin. Ohjelmoija voi olla niin ylpeä kauniista koodistaan tai tekemästään monimutkaisesta algoritmista, että testaa sen monta kertaa, mutta jättää testaamatta yksinkertaisen for-loopin, koska ajattelee "Mikä noin yksinkertaisessa lauseessa voi mennä pieleen?".
Listassa on ainakin muutama hyvä syy, miksi testaajan on tärkeää tietää suoritetun koodin määrä ja miksi järjestelmiä pitäisi aina testata white-box testauksella - testaus on siis sitä helpompaa, mitä enemmän tietää ohjelman suorittamista reiteistä tai koodin määrästä. Mustat laatikot kannattaa suosiolla jättää lentokoneisiin.
Lähteet:
Mitchell, Jamie L. & Black, Rex. "Advanced Software Testing, Vol. 3. Second Edition". (2015). p. 24-26. Rocky Nook.
Beizer, Boris. "Software Testing Techniques". (1990). ITC Press.
Paljonko bugit maksavat?
Paljonko virheet koodissa voivat pahimmillaan maksaa? Tämähän on se syy, miksi testataan - jotta vältyttäisiin katastrofeilta ja miljoonien eurojen vahingonkorvauksilta. Tiedämme, että määrittelyvaiheessa löydetyn bugin hinta on keskimäärin 100€, laatutestausvaiheessa 1500€ ja tuotannossa 10 000 euroa (Leon, 2015). Toisten arvioiden mukaan hintaluokka kasvaa aina tason noustessa yhdellä nollalla. Joka tapauksessa kallista. Ja aina silloin tällöin epätodennäköisiltäkin vaikuttaneet riskit voivat realisoitua ja pahin tapahtua.
Tähän alas olen kerännyt muutaman esimerkin projekteista, joissa testaus on pettänyt ja kaikki on mennyt pahimman laatuisesti pieleen:
- Ariana 5 avaruusraketti:
Ariane 5:n ensimmäinen testilento 4.6.1996 päättyi näyttävään räjähdykseen 37 sekuntia lähtönsä jälkeen, koska sitä ohjanneessa ohjelmistossa oli bugi - tyyppimuunnos 64-bittisestä liukuluvusta (floating point number)16-bittiseksi etumerkilliseksi kokonaisluvuksi (signed integer) aiheutti virheen, koska liukuluku oli liian suuri esitettäväksi 16-bittisenä etumerkillisenä kokonaislukuna.
BUGIN HINTA: Raketin lähdön hinnaksi oli arvioitu 165 - 220 miljoonaa dollaria (Wikipedia, 2016)
- Toyotan takaisinveto:
Elokuussa 2009 neljää matkustajaa kuljettanut Toyota Lexus ES350 alkoi yllättäen kiihdyttää yli 160 km/h nopeuteen, kunnes ajoi ulos tieltä, tappaen matkustajat. Toyotan mukaan autossa oli ohjelmistovirhe, joka aiheutti lagia auton lukituksenestojärjestelmässä. Toyota päätyi vetämään maailmanlaajuisesti takaisin yli 9 miljoonaa autoa vuonna 2010.
BUGIN HINTA: Takaisinvedot, vahingonkorvausvelvoitteet ja markkinointikulujen arvioidaan maksaneen Toyotalle jopa 3 miljardia dollaria. (Leon, 2015)
-Knight Capital:
Vuonna 2012 pörssivälitysyhtiö Knight Capital otti käyttöön uuden osakkeiden välitysohjelmansa. Valitettavasti ohjelman osto- ja myyntialgoritmi toimi hieman kehnosti, se nimittäin osti osakkeita pyydetyllä hinnalla, mutta myi ne välittömästi 15 prosenttia halvemmalla.
BUGIN HINTA: Vääriä välityksiä tapahtui 40 kertaa sekunnissa, 2400 kertaa minuutissa ja ne polttivat rahaa Knight Capitalilta lähes 440 miljoonaa dollaria. (Gang, 2016)
Tästä voi ottaa vain opiksi. Testaa tai itke.
Lähteet:
Ariane 5, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ariane_5
Janet Leon, "The True Cost of a Software Bug: Part One". 28.02.2015. Celerity. Saatavilla: http://blog.celerity.com/the-true-cost-of-a-software-bug
Gang, T. Penn State University. Saatavilla: http://www.cse.psu.edu/~gxt29/bug/softwarebug.html
Tähän alas olen kerännyt muutaman esimerkin projekteista, joissa testaus on pettänyt ja kaikki on mennyt pahimman laatuisesti pieleen:
- Ariana 5 avaruusraketti:
Ariane 5:n ensimmäinen testilento 4.6.1996 päättyi näyttävään räjähdykseen 37 sekuntia lähtönsä jälkeen, koska sitä ohjanneessa ohjelmistossa oli bugi - tyyppimuunnos 64-bittisestä liukuluvusta (floating point number)16-bittiseksi etumerkilliseksi kokonaisluvuksi (signed integer) aiheutti virheen, koska liukuluku oli liian suuri esitettäväksi 16-bittisenä etumerkillisenä kokonaislukuna.
BUGIN HINTA: Raketin lähdön hinnaksi oli arvioitu 165 - 220 miljoonaa dollaria (Wikipedia, 2016)
- Toyotan takaisinveto:
Elokuussa 2009 neljää matkustajaa kuljettanut Toyota Lexus ES350 alkoi yllättäen kiihdyttää yli 160 km/h nopeuteen, kunnes ajoi ulos tieltä, tappaen matkustajat. Toyotan mukaan autossa oli ohjelmistovirhe, joka aiheutti lagia auton lukituksenestojärjestelmässä. Toyota päätyi vetämään maailmanlaajuisesti takaisin yli 9 miljoonaa autoa vuonna 2010.
BUGIN HINTA: Takaisinvedot, vahingonkorvausvelvoitteet ja markkinointikulujen arvioidaan maksaneen Toyotalle jopa 3 miljardia dollaria. (Leon, 2015)
-Knight Capital:
Vuonna 2012 pörssivälitysyhtiö Knight Capital otti käyttöön uuden osakkeiden välitysohjelmansa. Valitettavasti ohjelman osto- ja myyntialgoritmi toimi hieman kehnosti, se nimittäin osti osakkeita pyydetyllä hinnalla, mutta myi ne välittömästi 15 prosenttia halvemmalla.
BUGIN HINTA: Vääriä välityksiä tapahtui 40 kertaa sekunnissa, 2400 kertaa minuutissa ja ne polttivat rahaa Knight Capitalilta lähes 440 miljoonaa dollaria. (Gang, 2016)
Tästä voi ottaa vain opiksi. Testaa tai itke.
Lähteet:
Ariane 5, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ariane_5
Janet Leon, "The True Cost of a Software Bug: Part One". 28.02.2015. Celerity. Saatavilla: http://blog.celerity.com/the-true-cost-of-a-software-bug
Gang, T. Penn State University. Saatavilla: http://www.cse.psu.edu/~gxt29/bug/softwarebug.html
tiistai 27. joulukuuta 2016
Mitä ominaisuuksia ohjelmistotestaaminen vaatii testaajalta? Mitä ominaisuuksia vaaditaan hyvältä testaajalta? Voidaanko luetella lista ominaisuuksia, jotka testaajan tulisi täyttää ollakseen alansa ammattilainen? Entä tulevaisuudessa?
Jan Mellemanin kirjoituksen "What type of human will still be a tester in 2025?" (Neil's Quest for Quality, 2014) mukaan tulevaisuuden testaaja on puhdasverinen, pur sang, ammattilainen, jonka osaaminen perustuu tietoon (knowledge), taitoihin(skills) ja kokemukseen (experience). Hänen mielestään testiammattilaisen pitää seurata alansa kehitystä, uusimpia työkaluja ja innovaatioita ja oikeasti haluta käyttää niitä jokapäiväisessä testauksessa. Testausammattilaisen pitää kehittää persoonansa emotionaalisia puolia, jotta hänestä tulee tiimipelaaja, joka ymmärtää missä bisneksen arvo (value) ja edut (benefits) majailevat. Testausmmattilainen on se ihmislinkki, joka yhdistää eri osastot ja järjestelmät toisiinsa ja valvoo niiden laatua. Testausmmattilainen kuuntelee asiakkaan toiveet, muuttaa ne vaatimusmäärittelyiksi ja rakentaa siltoja ohjelmisto-arkkitehdin ja kehittäjien välille.
Aika moneen pitäisi testaajan siis taipua.
Voisiko tuon edellisen kappaleen tiivistää listaksi hyvän testaajan ominaisuuksia? Kokeillaan:
Aika moneen pitäisi testaajan siis taipua.
Voisiko tuon edellisen kappaleen tiivistää listaksi hyvän testaajan ominaisuuksia? Kokeillaan:
Luova, utelias, analyyttinen, hyvä kuuntelija, proaktiivinen, nopea oppija, tekninen suuntautunut, asiakassuuntautunut, organisointi- ja priorisointikyvykäs, laatusuuntautunut, määrätietoinen ja peräksiantamaton. Tällaisia ominaisuuksia ISTQB koe -harjoitussivusto (ISTQB Exam Certification) listaa hyvälle testaajalle.
Okei, lista näyttää jo vähän selkeämmältä. Mutta mitä nuo ominaisuudet tarkoittavat käytännössä? Mitä taitoja ohjelmistotestaajalta vaaditaan käytännön työelämässä? Tmap Nextin (2006, Chapter 16 Test Roles) Testaajien roolit -luvun määritelmän mukaan Test Team Leaderin vaatimuksena on, että testaaja on laajalti tietoinen TMap life cycle -mallista sekä primaarisista testiaktiviteeteista, hänellä on erikoisosaamista testauksen arvioinnissa ja testisuunnittelutekniikoissa, hän osaa käyttää testityökaluja, hänellä on yleiset tiedot ja taidot informaatiotekniikassa, hänellä on tietoa järjestelmien kehityksestä ja kyvykkyys määrittää testauksen laajuus, johtamistaitoja, kokemusta projektisuunnittelusta ja -johtamisesta ja kyvykkyys valmentaa muita.
Mutta hyväksi testaajaksi ei pääse (pelkästään) lukemalla kirjoja. Hyväksi testaajaksi kasvaminen on pitkä ja vaikea prosessi. Jonkin tietyn kyvyn (lähes) täydellinen oppiminen vie ihmiseltä aikaa keskimäärin n. 10 000 tuntia, tai toisin sanoen, 10 vuotta jokapäiväistä parin tunnin harjoittelua. Eli helppoa tietä hyväksi testaajaksi ei ole. Ainoa, mikä siihen auttaa on testaus. Ja testaus. Ja testaus. Enää 9 000 tuntia jäljellä...
Lähteet:
Neil's Quest for Quality - A TMap HD Story (Alder Boersma & Erik Vooijs, 2014). "What type of human will still be a tester in 2025?". Jan Mellema. pp. 224 - 225. Sogeti.
ISTQB Exam Certification, istqexamcertification.com. (2016). Saatavilla: http://istqbexamcertification.com/software-tester/
TMap Next: for result-driven testing (2006). Chapter 16 Test Roles, s. 726. Sogeti Nederland B. V.
Neil's Quest for Quality - A TMap HD Story (Alder Boersma & Erik Vooijs, 2014). "What type of human will still be a tester in 2025?". Jan Mellema. pp. 224 - 225. Sogeti.
ISTQB Exam Certification, istqexamcertification.com. (2016). Saatavilla: http://istqbexamcertification.com/software-tester/
TMap Next: for result-driven testing (2006). Chapter 16 Test Roles, s. 726. Sogeti Nederland B. V.
Tilaa:
Blogitekstit (Atom)