Ketterä testaus ja testauslähtöinen kehitys Lauri Naukkarinen
Sisältö Miten testaus menee pieleen? Miten määrityksen, kehityksen ja testauksen voi yhdistää?
Mitä testaus tuntuu yleensä projektissa tarkoittavan? Menee suunnilleen näin: Kehittäjä 1. Yksikkötestaus paikallisesti 2. Integraatiotestaus kehitysympäristössä Testaaja 3. Regressiotestaus integraatioympäristössä 4. Hyväksyntätestaus (toimitus) integraatioympäristössä Asiakas 5. Regressiotestaus 6. Hyväksyntätestaus (julkaisu)
Mikä sitten menee usein pieleen? Tavoitteet ja tarkoitus on hukassa Testataan vasta lopuksi kun kaikki “valmista”
1. Tavoitteet ja tarkoitus on hukassa Tavoitteita ei ole ymmärretty Ohjelman tarkoitusta ei ole ymmärretty “Testaaja ei tunne käyttäjää”
2. Testataan vasta lopuksi kun kaikki “valmista” Harhaluulot - Tulkitaan että testaaja “etsii virheet” - Testaus on “kilpaileva tulkinta määrityksestä”
Ratkaisu! Kehitetään testit rinnakkain määrityksen yhteydessä tai määritellään testitapausten ja esimerkkien avulla. Terminologiaa: Hyväksymistestauslähtöinen kehitys Acceptance Test Driven Development, ATDD Testauslähtöinen kehitys Test Driven Development, TDD Ominaisuuslähtöinen kehitys Behavior Driven Development, BDD
ATDD @ http://reaktor.fi/osaaminen/atdd/
Työkalu: Cucumber @ http://cukes.info/ Määrittely, testaus ja toteutus perustuvat yhteiseen ymmärrykseen Ominaisuuden sisältö määritellään testin avulla, joka automatisoidaan Työkalu: Cucumber @ http://cukes.info/
[DEMO]
Tavoitteena: yhteinen ymmärrys Automatisoitu testitapaus kertoo mitä sovelluksen täytyy tehdä. Ominaisuus on valmis kun testi menee läpi. Asiakas (tai ohjelman omistaja eli maksaja) tietää mitä hän saa. Kehittäjä tietää mitä asiakas haluaa. Testaaja tietää mitä asiakas haluaa.
Lauri.Naukkarinen@fifthelement.fi gettuget @ IRCNET http://fi.linkedin.com/pub/lauri-naukkarinen/2a/3a2/2a5