End-to-End-testauksen automatisointi

Abstract

Insinöörityössä selvitettiin, miksi ottaa End-to-End-testauksen automatisointia käyttöön projektissa. Miten siitä hyötyy, kun haluaa parantaa projektin laatua testeillä. Onko se kannattavaa ja hyödyllistä implementoida projektiin. Voiko ilman sitä pärjätä kilpailevan sovelluksen kehittämisessä.

Työn tavoite oli selvittää, miksi End-to-End-testauksen automatisointia implementoidaan projekteihin. Onko sillä positiivista vaikutusta projektin valmistukseen, auttaako se kehitystä jollain tavalla vai nopeuttaako se jotain osaa projektin kehityksessä?

Työssä käytettiin kirjoituspöytätutkimusta valmistaakseen insinöörityön. Työssä opiskeltiin End-to-End-testauksen automatisoinnin toiminnallisuuksia, asennusta ja käyttökokemuksia, jonka jälkeen verrattiin omaan henkilökohtaiseen kokemukseen.

Tulokseksi todettiin, että on oltava kehitysympäristön kanssa yhteensopiva kehikko End-to-End-testausta varten. Lisäksi End-to-End-testit ovat herkkiä antamaan virheellisiä ilmoituksia, jos sovelluksen ympäristö on epävakaa. Siitä on kuitenkin iloa muille organisaation jäsenille ja on myös kelvollinen projekti osien testaaja. On kuitenkin olemassa kevyempiä tapoja testata projektin osien toimintaa. End-to-End-testauksen automatisoinnin implementointi projektiin on melko kallista. Varsinainen asennus on helppoa, mutta pitkäaikainen käyttö on kallista. Olemassa on kaksi eri tapaa hoitaa toteutus, mutta molemmat tavat voivat olla yhtä kalliita vaihtoehtoja.

End-to-End-testausta kannattaa toteuttaa, jos organisaatiolla on siihen varoja. End-to-End-testaus kykenee tunnistamaan web-sovelluksessa virheitä sekä samalla testaa liikkuvien osien toiminnallisuutta. End-to-End-testaukseen ei kannata keskittää kaikki organisaation testausresurssit vaan pitää sen yhtenä osana jatkuvassa integraatiossa.

End-to-End-testauksen automatisointia ei ole pakko lisätä projektiin ja ilman sitä pystyy silti tekemään laadukkaan web-sovelluksen. Suositellaan kuitenkin ohjelman liikkuvien osien testausta, jonka voi suorittaa muilla testauskehikoilla.

This thesis explores why End-to-End is used in projects and how it is used to ensure the quality of a web application. Is End-to-End testing worth the time and effort it takes to be implemented in the project? Can End-to-End testing be ignored entirely for the project's development or is it necessary for every web application?

This thesis goes over why projects implement End-to-End testing and ponders on whether the testing has a positive or negative impact on a web application. This thesis is an exploratory research on End-to-End testing. It investigates its functionality, installation and other developers' user experience, and compares these with the author's personal experience in End-to-End testing.

The results of the thesis seem to indicate that one should have a compatible framework before considering the implementation of End-to-End testing. The tests themselves are not very conclusive, so the environment itself will need to be stable for there to be useful results. There are faster and more efficient ways to test web application objects. End-to-End testing is, however, useful for other members of the development team, because it allows for visualization of tests when they are running.

The big drawback for End-to-End testing is its high maintenance cost: installing a framework is straightforward and fast but maintaining tests on a continuous testing cycle becomes very expensive when hiring a developer for the creation of said End-to-End tests. It is possible to use keyword driven testing and have a non-developer performing End-to-End tests, but keywords will still need to be coded.

In conclusion, End-to-End testing is worth implementing in a project if there are sufficient funds for it to be done. It is not essential for web applications, but End-to-End testing can identify errors through user experience, and it tests whether different web application parts are functioning correctly or not. End-to-End testing needs to be carefully balanced. It is not strictly necessary for it to be in a project, yet it is still recommended that a project has some way of testing a web application's moving parts.