Accueil > Non classé > Agile Tour in Strasbourg : session on tests and Agility

Agile Tour in Strasbourg : session on tests and Agility

The 2nd session I went to in the Agile Tour 2009 was about testing in an Agile process. This presentation was done by Frédéric Oehl, from Smartesting.

The presentation mainly consisted of 2 parts : one about tests and agility, the others about Smartesting tool for… testing. Surprising isn’t 😉

Anyway, the first part provided good insight on testing, with some surprise in it : they spoke of « Exploratory test ». What’s that ? In a few words (the wikipedia tells way more), it’s just the idea that the developers should have time to test the application without strict guideline, relying instead on their knowledge and gust feeling.

Per se, the idea isn’t new, even if I never encountered a name for it up to now. Furthermore, we speaking more of it with Frédéric, it appeared that it could be done in different ways, like : let each developer do exploratory tests on other dev. code or plan some time for the whole team to do such tests before the sprint is over, in order to bullet proof it.

For sure, exploratory testing has to be part of a bigger testing plan. Furthermore, we tend all to do such kind of tests. Yet, to put a name on it and then plan for it is quite different, and may let enough time to actually do it, which sounds nice. For sure, there are drawbacks as well, notably about inefficiency if 2 teams members do the same test every time. As usual, communication could help here 😉

Regarding Smartesting product, named Test Designer, it’s a Eclipse RCP application, using the work flow tools available there. Its main goal is to be able to describe some application work flow. In fact, it starts with some business requirements list (ordered by priority), then links them to part of some UML models describing the application’s work flow. Then, some guys have to make it happen, meaning that they have to write the tests needed by these UML models. This automation process, as they name it, is not part of the product.

I won’t say it’s revolutionary in itself, but to be able to use the same tools for both requirements gathering and functional testing sounds sensible.

They claim as well that it helps not having to redo all tests every time something change. Indeed, these functional tests are written per page (or I guess per page transition). As such, changing some part of the work flow involves only the related tests. Once again, nothing amazingly new, but this idea of slicing functional tests as well, to help maintain them, makes sense again.

In the end, as usual, one still has to provide the actual tests and then to maintain them. As such, it appears that this tool is used mainly by « big players ». These big players include some in India… yes, they sell their app there, without developing it there… fun isn’t it ?

In the end, this talk provided me with elements on my quest to find some way to do proper GUI testing, so I enjoyed this session as well 🙂

++

Publicités
Étiquettes :
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :