Testaaminen on järjestelmäkehityksen elintärkeä osa. Järjestelmien jatkuva mo- nimutkaistuminen ja erityisesti graafisten käyttöliittymien lisääntyminen johtaa siihen, että laadunvarmistuksen merkitys kasvaa edelleen ja lisäksi siitä tulee entistä haastavampaa ja kalliimpaa. Keskimäärin yli puolet ohjelmistokehitys- projektien kokonaiskustannuksista syntyy testauksesta. Testauksen automa- tisoinnilla pyritään pienentämään testauksesta aiheutuvia kustannuksia ja sa- malla tehostamaan testauksen toimintaa.
Aina ei ole kuitenkaan järkevää automatisoida testausta. On voitava pe- rustella, milloin testaamisen automatisointi on kannattavaa. Regressiotestauk- sen yhteydessä näin usein on, sillä testausta suoritetaan useita kertoja käyttäen samoja testitapauksia. Regressiotestauksen tarkoitus on varmistaa, että ohjel- misto toimii muutosten jälkeen oikein. Sen vuoksi regressiotestausta tulisi suo- rittaa mahdollisimman usein, mielellään jokaisen muutoksen ja
̈lkeen. Manuaa- lisesti työmäärä on kuitenkin niin iso, että sen suorittaminen ei ole järkevää au- tomatisoimatta.
Tässä pro gradu -tutkielmassa luodaan kirjallisuuteen perustuva katsaus ja selvitetään, millaisia malleja, viitekehyksiä ja tekniikoita on esitetty graafisten käyttöliittymien regressiotestauksen automatisointiin. Tarkemmin esitellään viitekehyksistä Daily Automated Regression Tester (DART) ja automatisointi- työkaluista Selenium IDE, jotka valittiin myös esimerkkiprojektimme graafisten käyttöliittymien regressiotestauksen automatisointiin.
Tutkielman empiirisessä osuudessa raportoidaan tämä kokeellinen tutki- mus, jossa luotiin malli, jota pilotoitiin esimerkkiprojektimme. Koska organisaa- tiomme on testauksen automatisoinnin saralla testauksen kypsyysmallin alim- malla tasolla, emme voineet käyttää DARTia suoraan, vaan siitä piti luoda or- ganisaatiollemme sopiva malli. Tätä mallia hyväksi käyttäen saimme automati- soitua esimerkkiprojektimme graafisen käyttöliittymän regressiotestauksen. Testauksen kohteena tässä pilotissa oli suuremman järjestelmän yksi osa: pika- linkkisovellus. Tutkimuksen perusteella voitiin vetää johtopäätös, että graafis- ten käyttöliittymien automaattinen regressiotestaus on mahdollista ottaa orga- nisaatiossamme käyttöön melko pienin ponnistuksin mutta jatkotutkimus on kuitenkin vielä tarpeellista maksimaalisen hyödyn saamiseksi.
...
Testing is an essential part of the system development process. The continuous evolution of the systems and especially the increasing number of graphical user interfaces emphasize the importance of quality assurance. It also becomes more expensive and more challenging. On the average testing generates more than 50 per cent of the total expenses of a system development project. Automating test- ing processes is a means to lower the expenses and simultaneously enhance the effectivity of testing.
It is not always reasonable to automate the testing. It must be justified when test automation is worthwhile. Usually this is the case with regression testing because the same test cases are executed several times. The purpose of regression testing is to prove that the software works as intended after there has been a modification in the code. Therefore regression tests should be executed as often as possible, preferably after every modification. However, running tests manually is very labori
ous so it is not reasonable to do so without automation.
In this Master’s Thesis, using a literature review, I examine what kind of models, frameworks and techniques there are to support automating regression testing of graphical user interfaces. I discuss especially Daily Automated Regres- sion Tester (DART) and Selenium IDE which were adopted for piloting the auto- mated regression testing of graphical user interfaces in our sample project.
In the empirical section of the study I report this pilot project. Because our or- ganization is on the lowest level of the Testing Maturity Model we could not adopt the DART framework as such but we needed to modify it to create a version suita- ble for our project. Using this model we were able to automate the regression test- ing of the graphical user interface in our sample project. The application under test was part of a bigger system: an application used to create quick links in the system. Based on the results of the study it is clear that it is possible to adopt automated regression testing of graphical user interfaces in our organization with quite little effort. However, regardless of the results I cannot declare that this study is enough to adopt the automation process organization-wide but more investigation is need- ed. However the results suggest that more investigation is worthwhile.
...
