Archive

Posts Tagged ‘agile’

How to do UI test ?

novembre 3, 2009 Laisser un commentaire

Me again…

Well, I just wanted to speak about an issue for which I didn’t find any proper answer yet.

The matter is gui testing. Currently, at work, we do proper unit test for « framework level code ». By « framework code », I mean code being in some utilities or services projects which are put there to be reused. These tests are usually fairly easy to do, since the context is well known. Furthermore, as once as we change this code, these tests prove their value. As changes are made quite often, be it only when adding new stuff and thus refactoring, we feel like these tests are good bang for bucks.

For example, recently, we saw a bug in some on « framework code ». We wrote a failing test for it (well, I’m not 100% sure of that, but we should have had anyway ;)), fixed it and, on the go, spotted some possible improvements. We did them as well, then ran again all tests and we were pretty confident about it.

But, then, what about « project specific code » ?

Hum, what’s in it anyway ? Some « framework level code », for sure, which is already tested, and then some JPA, wicket and business related code. Testing the JPA code would basically mean testing the JPA layer, which is pointless. What about the GUI then ? Well, wicket isn’t exactly the easiest framework for it… The way its generates the ids make it hard(er) for most of the html test tools, like for example selenium. And even if, what to test actually ? Should we do some « clicks through » tests for all use cases ? All possible navigation paths ? And what about the data needed by these tests ? Using WicketTester, then we would be at pain with jquery heavy pages (well, I guess most of the selenium like frameworks are at pain in this case…). Overall, the efforts to put there are likely to be important.

So, what about the gain ? The odds that we’ll touch again these classes are quite low, way lower than framework level code. Basically, we don’t reuse these stuff. And if some functionalities/pages are fine enough, then we may even not touch them again before very long.

In the end, we have some layers which are, at the same time, harder to test and with less « return on investment ». It looks like not testing these « project specific/gui layers » is a good idea…

However, which bugs the end users, tester or product owner are likely to see the first ? The gui bugs, for sure. Worse, whereas framework layer code tends to be mostly Java, the front end relies heavily on nice stuff like CSS, html and javascript. And as if refactoring wasn’t already hard enough there, Wicket, with its string based property and compound models, makes it even harder. So in the end, this gui layer is quite error prone and highly visible to the « customers/users »… Bad isn’t it ? And don’t forget all these quirks about back button, interruption of page loading, browsers inconsistencies and many ui possibilities… Even worse !

That’s where my issue with ui test lies… This ui layer is a pain to test, and would be tested mainly for just a development, without much reuse. But, it’s an error prone layer. And it’s the most visible one… So, if, like me, you’re kind of fond of tests and bullet proof code, then you might well share my dilemma…

What to do then ? Well, for the time, I’ve no proper answer. I guess I should try to spend more time testing my ui before giving it to the outer world, even it feels awkward to do it manually. For sure, exploratory tests might help, but again they’re manual and in no way comprehensive… No clear solution here for me, unfortunately…

Any hint deeply welcome ! In fact, I guess that’s the (hidden) aim of this post : maybe someone’ll come with some magic bullet(s). After all, Christmas is coming soon, so it’s dreaming time anyway 😉

++

Étiquettes : , , , ,

Book: Scrum and Xp from the Trenches

octobre 7, 2009 Laisser un commentaire

At work, we’re currently reviewing our Agile process. So I thought it was a nice occasion to read again Scrum and Xp from the trenches, esp. since we have a paper edition of it.

Simply put, this book is why I started to be so much interested in Agile software development : the process it described is really compelling. The author hardly presents what is an Agile process (from a theoretical point of view), rather it dives immediately on how they did it. Still, he provides the different choices they faced and explains why they went for such or such solutions, all in order to accomplish the various “agile steps” which are to be done. It really enlightens the reader, helping to grasp properly what it’s all about. Furthermore, it gives ground to the author’s claim that it’s just how they did it : one gets easily that’s adaptation is the key, that Agility is not a stone graved process. This helps to consider it’s own environment with a fresh eye.

At the end of the book, I had the feeling I had a proper overview of the whole process, on how these teams worked. Added to the explanations on why they choose such solutions, it makes it all reasonable, sound and efficient. Attractive and, hosnestly, a real breakthrough compared to all these RUP, ITIL and others crappy acronyms. What else could we expect from a process ? It actually seemed like helping and being efficient ! Crazy ! The only question I had left was “when can I start ?” (which is part of the reason I moved to Thomas Daily by the way lol).

In retrospective, now that I’ve been working in a Agile shop for now 7 months, the book didn’t answer all the questions I had since. Furthermore, more theoretical books have helped me really grasp why such a process was working, that it was all about the empiric nature of each IT project. Still, when coming back to this book, it was once again compelling. Going through the experience and writing of Henrik Knibberg has helped me once again, spotting points where we didn’t get it all.

As such, I really advice this book (which comes as well as a free ebook, both having been updated since publication) for all people interested in getting Agile, how it works, what it provides or even to improve one’s own way of applying it. So don’t hesitate : read it !

++

Side note : Henrik speaks of other “from the trenches” stories in his book. I never found any, so if anyone knows some other, I’m interested !

More details on infoQ.
Review written first on codesmell.

Étiquettes : , , ,

Why is "Agile" planning better than the traditional Gantt approach ?

septembre 10, 2009 2 commentaires

Last sunday, I’ve been discussing with a friend about planning. In his company, they’re doing it the « traditional » way, with a Gantt like approach. The example was of an excel sheet containing two tasks, coding and testing, one after the other. Quite to my disappointment, I was at pain to express clearly the advantages of an « Agile » planning. So, in order to be clearer next time, here is my homework 🙂

Users care for features and nothing else !
Thinking back on this discussion, I think the key point I didn’t express at that time was, as Mary Poppendieck would put it : « These days we do not program software module by module; we program software feature by feature ». It really goes to the fundamental differences between a Gantt like planning and an « Agile » one.

When planning modules by modules, and can have buffers before/after, reorganize your plan, but basically you’re at risk of delivering nothing or something that the users don’t really care about (if you go for partial delivery). And all that, maybe, just because some corner issues (either in terms of functionality or technical) aren’t resolved.

With features planning, you put what the user wants first, meaning there is a high probability of pleasing him. Furthermore, a feature doesn’t dictate a technical scope : even if the technical aspects are not all perfect, you can still release the feature if possible/needed. The full database schema hasn’t to be known/implemented/optimized for having some functionality working…

Finally, an Agile team commits itself for a set of features. Sorting out the difficulties encountered is part of this commitment. When committing to fit to a Gantt planning, it can be done perfectly and still having nothing working or of interest for the users…

Software development tasks cannot be accomplished in isolation
On a more general scope, separating activities in software development is a risky business. What you do on the data base level has impact on the software. DBA and developers have to speak together, they don’t work in isolation. Furthermore, if during testing some feature is missing, the odds are high that both the code and the database will be affected. What do you do if you’re now in the « testing » phase of your gantt planning ? In which cell does it fit ?

Software development is full of uncertainties
Last but not least, a Gantt planning looks horribly deterministic. It looks like all is sorted out, that we know exactly where we go. But software isn’t like mass production : each project is different. What if some functionality isn’t properly described ? What about technical uncertainties ? What if priorities change ? Agile planning – and agile software development – is all about taking these uncertainties in account. The exact tasks to achieve for a functionality aren’t figured out months before working on it (as if anyone could ever do so). The iterations and daily scrum are all about, as well, resolving uncertainties when they appear and when we have the required knowledge.

As usual, all feedback welcome !

++

Étiquettes : ,
%d blogueurs aiment cette page :