Archive for the ‘Testing’ Category



This year I will tour Europe with my new workshop: Behavior Driven Development for Rich Internet Applications using JavaScript.

Who is this workshop for?

JavaScript developers.  This is a workshop for those developers who already have some experience with TDD and JavaScript. I will not explain what an automated test is, I expect attendees to be familiar with the notion of test-first development. However, you don't have to be a TDD expert to join the workshop. Some experience with test doubles (mock, stubs...) will help, although we will review them in their JavaScript version.
Attendees must be familiar with dynamic languages and must have a good JavaScript knowledge. Although a deep knowledge of the JavaScript language is not required, it is important to be used to the language, at least practicing code katas. I have prepared these exercises to make sure we all can expect a certain level of JavaScript knowledge. I help with any doubts on those exercises.
Important: Aim of this workshop is to teach developers how to develop rich client applications, not a website with some JavaScript on it. Mobile apps based on JavaScript fall into this category.

Workshop contents

BDD is a full stack methodology. In this other post you can read how I am implementing BDD for RIAs. We will develop several user stories from the ground up, starting from the specification workshop and ending with working software.  This is the table of contents:

  • Communication: some advise for effective communication and productivity.
  • Specification workshop: requirements and business value.
  • Agile JavaScript infrastructure: everything we need to get started.
  • Cucumber and its many flavors: examples with cucumber.js and SpecFlow
  • Event oriented programming.
  • Testing techniques with JavaScript and test doubles.
  • Most common design patterns: ports and adapters, passive view, observer, factory, singleton.
  • Architecture: those other things that don't emerge from the design but have to be thought upfront.

Everything is practical. Attendees work in pairs, rotating every now and then to be able to pair up with at least four people. Pair programming is explained in the workshop and I am facilitating and helping pairs all the time. We stop after each exercise to add some theoretical notes and recaps.

Why JavaScript?

I used to think that JavaScript was something terrible,  even worse than PHP 🙂 But it is no longer like that (PHP has also improved!). The JavaScript platform is so powerful these days. It's quite mature and evolving very fast. Mainly because browsers are improving a lot. Even our good friend IE, is negotiation a truce with developers in its latest versions.

Desktop applications were so powerful back in the 90's regarding the user experience and the programming techniques. The web as it came in the 2000 decade, was a step back in terms of tooling and user experience but it was a huge advantage in terms of deployment. Now we can leverage everything that has been effective in the past 20 years: rich user experience,  powerful programming techniques and tools, agile testing, and high market potential (web and mobile). JavaScript platform means to me the JavaScript language and also CoffeeScript and any other language which compiles into JavaScript.

Is BDD different for JavaScript?

Not really from the high level. However, rich client applications are now easier to test than ever. What in traditional web development are integration tests, now can be turned into unit tests, making maintenance much more efficient. The actual instances of the objects in our application are directly accessible in our tests, there is not need to hit the application through the GUI to run end to end tests.
The amount of glue code or automation code can be reduced or even removed in some cases. It is worth understanding the differences to take advantage of rich client side development.

Should you attend this workshop?

This is a career investment. If you don't expect to practice any learned lesson from the workshop, better you save your money. On the other hand, if you come to the workshop willing to learn, ask and practice, this workshop will save you a lot of time, effort and mistakes.  Every time I invest my money in training I try to calculate the ROI somehow and have a clear reason as to why am I doing that investment.

In this workshop you will understand the best practices that took me years (and pain) to learn. You will be ready to apply them in your upcoming projects. It is impossible for you to master all the techniques after a single day but you will get a solid foundation to start from and knowledge to avoid critical mistakes.

Is there any sample application developed this way?

Yes there is! 🙂 Check it out for free at LiveTeamApp.com, my latest and coolest application for team productivity.

The bonus

When you enroll on the workshop you also get homework and homework help. You can send me any questions you have, anytime. You also get access to a mailing list where you can get new exercises, news, and more. Because I don't just want attendees for the workshop, I want people to learn so I'll help you keep on learning.

You can buy your ticket now

The next edition will be in Postdam, Germany. It will be part of AgileDevPractices (March 4, 2013). Following editions will be published here (look in the right-hand sidebar). If you would like to host the workshop in your city, please contact me.
Pricing: Early Bird 750€, Regular 850€.  Buy Now

Tell me more

Do you want to know where and when is the next workshop edition? Join the mailing list. You will not receive any spam, I promise 😉


Look at me. I am so exhausted and happy at home... because I come from Agile Testing Days 2012! (Postdam, Germany).
One of the best conferences in the world for agile testers, managers and developers. It's been my first time in this event. First of all, I want to say thank you to José Díaz, Madeleine Griep, Uwe Gelfert and the whole #AgileTD team brought by Diaz & Hilterscheid. Everything has been excellent. Everything on time, precisely calculated and performed... as if they were German! 😉

Agile Testing Days Logo

My friend Iván Stepaniuk and I landed in Berlin on monday afternoon. It was easy to get to Postdam by train. The strong chocolat smell in Postdam's train station is the best welcome message  for two hungry geeks  🙂

Curiosities

At 6.30pm a bus gave us a lift from the hotel to the speaker's dinner in a nice restaurant where food was excellent and the wine was Spanish 😉 So the networking started from minute one. I didn't know any of the guys in the table and had a great time talking to them. Something I really appreciate is that we were back in the hotel at... 11pm? or maybe sooner, so there was plenty of time to sleep and get ready for the next day.

Then conference started on Tuesday at 9am but before that, Lisa Crispin facilitated an open space called "the lean coffee" starting at 7.30am for those early birds who wanted to ask questions or share experiences.  I enjoyed the time there. There was "lean coffee" also on the next two days but I was just destroyed and needed to rest.

Everyday was absolutely busy with one activity after the other and plenty of food in the hall all the time. Very handy because you don't waste time going for food, it is always available and you eat standing on your feet having the chance to talk to people. Perfect for networking and for those like me who forget what time is the lunch supposed to be.

On Wednesday night buses took everybody to the "Most Influential Agile Testing Professional Person award" dinner. A special place where again the food was spectacular and there was an awesome magician, a beautiful acrobat (this was the music, a Metallica cover), and live music. And.. the award went to Lisa Crispin! Congratulations! 😀

One thing that grab my attention is that the majority of the speakers are self-employed, independent professionals (including myself). Some of them have been working for important companies but end up working for themselves. What do you think this means? 🙂

What I have learned

As a developer I have learned that good testers are methodical and share the same passion for continuous improvement. Developers should know something about testing and testers should know something about development. But a great developer is never going to be a great tester, and a great tester is never going to be a great developer. Both roles are necessary in teams. And the job of testers should not be placed at the end of the iteration but at the beginning. Quality products can only be developed when quality has been in place since the beginning. It is not that quality can be added at the end.
Design for quality the same way you write code for testability,... quality-first development!
I have learned that good testers love their jobs.
At this point it is well-known that the majority of the defects introduced in software have to do with people and mistakes in the communication.
Apart from this general thoughts I learned something in every talk, every keynote and every chat during coffee breaks or dinners. I tweeted some of the most remarkable sentences I listened using the hashtag #agileTD.
Talking to more experienced consultants also helped me confirm that some ideas I have work for them. And some points of view make sense to others too.

Something new I will try to apply

On my current project, the product owner come up with feature requests for the team to work on, and once they go live,  it turns out that they are not really used sometimes. But we don't get the chance to discuss why should they be implemented. Some discussions end up with the product owner saying, "I know the business and this should be done".
I'll try to introduce the idea of  testing business assumptions. Design in a way that allows us to determine whether changes are really impacting the business.
I will ask ... "How will we know if this change (feature request, bugfix or behavior change) as a negative or positive impact on our users?". It is about creating business measurable software for metrics to be easy to find.
I believe these ideas come from the lean startup movement. The were expressed by Gojko Adzic based on his experiences.
Mind maps might help. Gojko proposes answering the following:

  • Why: Why do we need to introduce this change?
  • Who: Who is going to be affected by the change?
  • What: What is it?
  • How: How is going to impact the business?

More information can be read in his latest book, Impact Mapping.

Niels Malotaux said that about 55% of the defects are in the requirements, not in the code. Someone in the room remarked that it is the 70%. So we need to work more in the iteration planning. The aim of testing is to prevent defects, not to find them.

Regarding the team, I will read this book on The Five Dysfunctions of a Team.

I will also read Lisa's & Janet's book, which is something I should have done time ago!

Some refletions on the state of the industry

Pretty much every keynote talked about the past. Nothing we are doing now is new, many things come from the 50's (some of them even before) and later decades. So it's important to leverage what we learned in the past avoiding the same mistakes again and again.  I would summarize the current status of the agile software movement in the first sentence of the manifesto: Individuals and interactions over processes and tools.
Although some attendees expected more technical talks with tools on them, the majority of speakers talked about teams, self-coaching, collaboration,  communication and design principles.

The Test Lab!

I told Lisa Crispin about my new application, LiveTeamApp. But I made the mistake of not telling her it was still a "beta" version and she tweeted about it faster than light. That encouraged me to just tell everyone about the application 🙂 Thanks Lisa!


Left to right: Ivan Stepaniuk, James Lyndsay, Carlos Ble, Bart Knaack

After lunch I visited @theTestLab. where I met James Lyndsay and Bart Knaack. Professional testers and great guys. Bart and James spent the whole day in the test lab, just for the sake of serving others. To help and teach people about testing. They didn't attend to keynotes or talks, they just focused on helping people. To me, that says a lot about them. I am happy to have met them. I proposed LiveTeamApp as an additional testing exercise for the lab and they gently accepted the proposal:

Exploratory testing session for LiveTeamapp

The intrepid testers found about 10 usability issues and 2 minor bugs. Big applause for them: Christian KliebeHuib Schoots, Simon Morley, Thomas, and my friend Ivan. Does anybody know Thomas' surname?  I would like to link to his blog or twitter!

 

 

LiveTeamApp might be available for upcoming test labs run by @theTestLab. And is available online for any team that want to use it 🙂

 

Our talk on BDD applied to Javascript solutions

Daniel Maslyn rocks!

Daniel Maslyn is just the best chair you can have as a speaker.  Thank you Daniel!
I have to say that being the chair is not easy. I've also been the chair for some talks and... I don't think I did very well (sorry speakers).

I am quite satisfied with our talk. We worked hard on the preparation, we were able to communicate what we meant, and people said it was understandable. So mission complete, thank you attendees! And thank you Ivan for accepting my co-speaker proposal, you talked very well in my opinion.
The slides will be available for download soon. The AgileTestingDays team will send the download details to all conference attendees.
I plan to write a book (this time in English with some help) on the subject, and I think we will be talking about this in more conferences (always updating the contents).  If you find the subject interesting and your English is better than mine (easy!) you can collaborate with me in the revision, just contact me please 🙂

Looking forward for next year's conference

I highly recommend the Agile Testing Days conference. All the talks I attend to were very well prepared. Speakers presented clearly and the keynotes where fantastic.
It is a great opportunity to meet professionals with different roles and even to find a job. This year Nokia was looking for developers to hire and the information could be found at their exhibitor in the hall. So much value from a single conference.
Hope to see you there next year!

 

Why is it not running my tests?

So you tell TestDriven.Net (the rocket) or Resharper to run all your tests from Visual Studio but suddenly some of them do not run. What is going on?

Easy: one or more of your tests are throwing StackOverflowException or maybe other fatal error the system is not able to recover from. Infinite recursion causes this.
TestDriven.Net might print this in the output window: "An existing connection was forcibly closed by the remote host"

To find out which one, run all the tests with Resharper and see which one is "aborted". Then add a break point and debug it. The debugger will tell you exactly where is the problem for you to fix it.

Happy testing! 🙂

 

  • Newer Entries →