Some learned lessons from the Agile Testing Days (part 3)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics. This is part 3 of this blog.

Understand business goals and research alternatives. (Gojko Adzic (@gojkoadzic) - “Product Management using Effect Maps”)
Why is a feature really wanted by the business? This is something all members of a team should be aware of. This is because of awareness of the goal. The goal is a business goal and technology is a way to reach such a business goal. For example increasing the registered users by a million. With a mindmap technique (effect mapping) you could search for all alternatives for reaching that goal. Discuss all alternatives, draw this mindmap and get fresh ideas about this. Maybe the feature requested was not the fastest or the right way to get to the goal. Maybe an advertisement campaign could do the same for less money. Always research the alternatives and a good way is using a effect mapping.

Understand the "Why?

Some learned lessons that I could take right with me in my briefcase: Lisa Crispin(@lisacrispin) & Janet Gregory(@janetgregoryca): “Appendix A: Lessons Learned since Agile Testing Was Published”

• Try to understand the business value of a feature that is asked to be implemented (also mentioned by Gojko Adzic with effect mapping talk)
• Test automation: Needed, but maybe developers can do a better job scripting than you as a tester.
• People should be allowed to make mistakes, from mistakes you learn more than when everything went ok.
• Learn continuously in your job: opportunities enough. (also mentioned by Huib Schoots)

The next part of this posting come from some discussions and my own thoughts from a informal discussion in the evening on one of the Agile testing days. (it was called PATS)

Yes, there was beer too, and pizza later :-)

What makes a great tester is not possible to define, but you can help people learn and improve and become great testers.
What makes a great tester: Well, skills are not important, those can be learned, but it is very difficult to describe the “great tester”. When you think about it and discuss, you would almost try to describe the “greatest employee” or “the perfect human”. I’ve got more ideas about this, but that would be a different blog post. You could help employees really develop themselves (so this is also not only for testers) to create an environment where people can make mistakes. Or even set a goal for people to fail. Celebrate failures: you have learned something! (at least you would expect the latter).
Another good point is to give people the time (for example 2 or more hours a week ) to do something for themselves instead of expecting them to do that in their own time.

We still got a lot of work to do concerning risks and communication with the business about risks.
I’ve seen it myself, but mostly I get positive reactions from the business when I start to talk with them about risks, but this could be different. “We want 0% risk when we ship this.” We should ask the business for an acceptable risk level, but first I guess we should explain more about it.
Also I see a difference in perception about risks in the testing world. Are risks part of a test report and release advise or should they be used before starting testing or even developing. I would say, discuss those risks before starting developing stuff, maybe it is an idea to discuss product risks together with the effect map of Gojko Adzic. Well, this is one subject I will surely put more thoughts in.

I just liked this slide so much I had to put it in: "Where would you bite first?" (Gojko Adzic)

Anyway
I learned a lot at this great conference (and will do more the coming weeks). I met a lot of testers and (!) developers and discussed testing. At one of the presentations it was asked how many testers there were in the public. About 2/3rd of the people raised their hands. So this was also a bit of a mixed conference. So the ‘other’ group was there too :-), which made it more interesting.

Furthermore it was not a massive conference such as Eurostar, it felt like a small group of people even. (don’t know how many people attended). The ‘market’ as you see with lots of events was small (about 10 companies at the most) and relaxed. Just like the conference itself. I enjoyed it and I think I will be there next year too. Maybe I’ll see you there? Follow the Agile Testing days on Twitter.

Finally a 'thank you' for the organizers of this event
Thank you organizers (Díaz & Hilterscheid) for organizing this great event. It was good to be there. I had a nice talk with one of the organizers (José Díaz) about the conference. But also the Agile Testing Days app that was introduced for Android as well as for Apple devices. It had some flaws, but it worked good enough for me. Well, testers will be the first ones to complain of course :-)

José Diaz introducing the speakers.

Some learned lessons from the Agile Testing Days (part 2)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics.

Now to learned lessons from the sessions

We are getting more and more inventive with tools that help us testing. (Geoff Bache & Emily Bache (@emilybache): “Specification by Example using GUI tests – how could that work?”)
There are ways for automation of tests for which you do not have to program and you don’t need the software under test. You can still prepare automation for the new features. By discussing the specifications with examples beforehand you can prepare an automated tool up-front. When the software is ready, the testcases will be there and preparing the tests is a quick and simple job. This is one example of inventive ways to do automation. If you are interested in more details, please check out this site: http://texttest.carmen.se/index.php?page=main

A way to deal with the information overflow and too much to learn. (Rob Lambert (@Rob_Lambert): “Do agile teams have wider awareness fields?”)
We can learn everything we think there is to know and still have a lot to learn. Because we really can’t learn everything. There is a lot of information out there and we will have to filter that information to our own needs. We will have to make choices. A good way to do that could be by making a diagram for yourself of things you know, you can influence and things you don’t know yet (and can’t do). Furthermore you could use a kind of “fish diagram” to plan the things you want to learn.

Slide from the presentation (Rob Lambert)

Rob Lambert's slides can be found here

Don’t think in ‘we’ and ‘them’. I will be aware of this kind of things from now (I hope) (Linda Rising: “Who do You Trust? Beware of Your Brain”)
Automatically, if we speak of the other group such as: Them developers, them designers, them project managers, you will influence yourself, you brain, so that working together with ‘them’ could get difficult. At least you will have automatically build a kind of wall between you and them. For the group you are in and working together within a specific named group (testers for example), this could be a positive thing. But closing out other groups (unaware you are doing that, we all do that) could cause problems and rivalry. Organizations and groups within organizations should be aware of a common goal what binds all people together. The video is not out (yet?), but you can find another good talk from Linda here.

There is always room to improve. (Huib Schoots (@huibschoots) - “So you think you can test?”)
I guess I think I’m a great tester, I am testing now for about 15 years. But what does that mean really? Did I do the same trick over and over again during the 15 years of testing? Because then the experience will be only 1 year of experience… Repeated 15 times. I don’t think I fall in this category, but there are so many ways to improve yourself as a tester and improve your skills. If I check the list that Huib Schoots showed us I can see I’m still missing out on some wonderful experiences. But where to find the time? Someone from the audience said that for a professional would use 20% of his private time for his job. At least I do that, I guess more than that. But there is always room to improve. You can find a blog posting about this from Huib here.

Another lesson here: Being passionate is contagious. That one I had learned already.

Next posting later this week.

Follow me on Twitter to get updated or add yourself to my Newsletter.
You could also check out my Testevents website! (There is a testevents newsletter too there)

Did you miss the Agile Testing Days and you live in The Netherlands, please check this out on the 6th of December VX company does a summary for you.

Some learned lessons from the Agile testing days (part 1)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics. I cannot describe everything, but I tried to write a personal note of these days. What did I learn during these days?
So this list is only a part of all the things I’ve learned, but they give some ideas that you maybe could use too.

Port in the Centre of Potsdam City

I’ve been present on the first three days of this four day testevent. This posting in three parts is about the 2nd and 3rd day. The first day I visited the workshop of Michael Bolton: “Critical thinking skills for testers”, which gave me even more to think about. But that workshop is not mentioned below.

In general
Some topics returned a few times which I would like to point out:

• What is a good tester? Do you think you have enough experience to say that for yourself?
• How can you help other testers to improve their testing skills? Making mistakes and learning by doing that is one way.
• The IT world changes a lot at this moment and so is testing. Agile is taking over and is maybe a first step towards a different way of developing software. Testers should keep up with all these new trends, because there are a lot of challenges coming our way!
• Don’t think in groups like: “we testers”, “you developers”. We are all developers and we have the same goal as the organization we’re in. We should know the business goals (why) of the organization when we work on a project.
• The standard way of presenting, bullets with text on Powerpoint is on his way back. I’ve seen Prezi, mindmaps and presentations consisting only out of bad drawn, but effective pictures. Michael Bolton also did an experiment with his presentation I understand. I did not see it myself alas.

Presentation via a mindmap (Stevan Zivanovic)

Next posting later this week.

Follow me on Twitter to get updated or add yourself to my Newsletter.
You could also check out my Testevents website! (There is a testevents newsletter too there)

Did you miss the Agile Testing Days and you live in The Netherlands, please check this out on the 6th of December VX company does a summary for you.