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.

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

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

Lista testiautomaatiotyökaluista

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ä.

Mobiilitestien pyörittäminen laitelabrassa (Kannattaako laitelabran rakentaminen?)

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:

• rakentaa oman laitelabransa 
• käyttää pilvipalvelun laitelabraa

Kummassakin vaihtoehdossa on sekä hyviä että huonoja puolia. Käydään nyt läpi laitelabran rakentaminen ja seuraavassa kirjoituksessa pilvipalvelun käyttö (TestObject).

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/

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/