From Nothing to Something

A couple of times I have tried to start on a new project and discover that there is NO test ware at all, and hardly any documentation about how the system works, and I think I have found a way to get a bit of both. In the last project I arrived one month into a three month release (SCRUM based, running sprints with deliveries for each 3 weeks - but not into production) where they wanted to extend an already existing system - and that system had neither test ware nor system documentation. At the same time I only had a few days a week in the project and only two months all in all, so I needed to focus my energy on actually getting stuff done - getting as much test done as I could in the limited time I had with as little overhead as possible.

So here is what I did:

From what little documentation I found I tried to create a breakdown of the system, something like this:

E.g. Microsoft Outlook

• Mail
• Send
• Receive
• Archive
• ...
• Calendar
• Create appointment
• Send appointment
• Modify appointment
• Reoccurence
• ...
• Tasks
• Contacts

You get the picture :-)

From here I start exploring - actually often I start exploring at the top level, I just find what main areas there are, and take it from there.
As I explore every area I take notes, what functionality can I access from there, can I identify flows?
So I build up my "test tree"as I go along, I learn about the system, I identify new areas to explore and take a lot of notes.
I try to limit each "session" to maybe 1½ or 2 hours and then I take a break and start documenting! Yep you heard right, I actually try to keep track of what I have done and what I have learned, I can reuse the knowledge and I can give it to whoever will come after me in this project - I actually like structure!
In the last project we were using HP QC, that was the company standard and there were no excuse for not doing so. So I found a practical way to use it. The top level areas were folders and each of the sub-areas were then test cases. I didn't write steps (of course :-)) but I wrote the charter - the purpose of the test case.
Now I had an overview of the system - now I took another tool in my toolbox - my test design techniques. And yes I LOVE test design techniques and I love the fact that I have received formal training in it (and I am both ISTQB and TMap certified by the way) - I take all the training and knowledge I can get and use it to enhance my toolbox.
An example; I had this dialogue with 4 fields, some with drop down and one with data entry - I used my skills in data combination testing (Classification trees) combined with pairwise and identified all the variations I would need to address if I should say that I had covered ALL alternatives... and then I used it as inspiration. And by the way I attached the classification tree to the test case for others to use in the future.
After a while I had talked to the users, gotten an idea about some of the flows in the system - so I sat down and made a proces flow diagram and discussed with them whehter I had understodd their system right - and then used that as inspiration for a charter with focus on primary workflow.
When I started to test formal releases I of course created a test plan in QC and added all the relevant charters to that - so I could give a status on progress anytime, and had an overview of my test and the defects I had found.

So a little story from my little corner of "the real world" (hmm I will never be able to use that term again after #agileTD) about how to combine some of the "classic testing skills" with exploratory test - and the demands for documentation. Nothing big an fancy... just practical use :-)

Agile Testing Days - Day 4

Hmmm the list of stuff to take a look at is getting longer by the hour for me.

I was truely inspired by Ola Ellnestam's keynote this morning. I LOVED the fact that his presentation was a serie of handmade drawings in black and white that totally supported his story. I was slightly disturbed by his unicorn though ;-)

The focus on fast feedback is crucial to make agile work - and the illustration of the different feedback cycles he described makes sense, going from the very code near feedback of XDD, over acceptance test to release and last but not least the feedback of the end users. How do we improve our way of working so that we get the cycles shortened as much as possible. The suggestion is to start from the inside out - how can we improve the feedback cycle on the XDD level?

Also the approach with building a small application first, get feedback and then iterate and let it grow after the needs of the business. All to often we are still struggling with something that can borderline water-scrum-fall - that all the thinking about what is needed is done right from day number one - and that no one really questions "do we really need ALL this". We just start cutting it in small nice pieces (user stories), prioritizes them and starts building it from an end of.

The concept of SLACK is something I hardly ever see practiced in the agile projects I have participated in. We sprint like something with very big teaths are right behind us, always focusing on the next sprint the next delivery. Lloyd Roden illustrated this perfectly and got the message through - we need a break, just like athlets we need to restitue in order to get better, in order to perform. Maybe we can do a bit ourself to? maybe we can speak up and say "I need a break" or "wouldn't it be great if we took some time to look at X, this might actually help us perform better in the future".

Combining the role of requirement engineer and test engineer was up for discussion in the presentation from Jan Jaap. I don't know whether it will be possible to do this in every project, but I really like the thoughts about testers for REAL being involved from the beginning, helping ensuring that what we say we are building is really what the business asked for. Whehter that is by taking the role as TE-Tester or it is by taking the battle to get involved for real in the definition of user stories.  But I know that several of my collegues back home would love the combined role.

Scott Barber kept us very much awake during the keynote - following the evolution of software - and I really liked the fact that he did not "do" agile, he "is" agile. I think that experience shows that agile for many is a state of mind, a way of living - it is not something we sit down and read a book to learn to be. Of course a lot practical stuff can be learned but the basic or rather fundamental stuff is something you have within you - it is who you are.

My Agile testing days 2012 ended with a presentaiton by Huid Schoots, and a fine finale it was :-) Some good stuff was e.g. Learn by getting together; learn from each other – being a context driven tester is not something you do from 9 to 5. And be carefull with templates, they can limit your thinking. Especially loved the quote "There is no more fun than making mistakes. That way I learn something".

I actually think this has been one of the best conferences I have been at ever! The fact that the theme of the conference is "limited" to agile testing compared with many of the big conferences where "testing" is the theme made the discussions in the breaks so much more engaging - we all focused on how to learn about testing in an agile context, about improving the way we work in that context - LOVED IT.

Think I will try to discuss some of the stuff from the conference in the coming blog posts - need to dive in, dig deeper.

Agile Testing Days - Day 3

Uhh so much new stuff, so much inspiration - today I think I'll take another approach than "just" listing the sessions I have been attending and in stead think a bit more om what I got with me home from Day 3 at the Agile Testing Days 2012.

Be an Inspirational Speaker

I attended the first and the last keynote (missed the one in the middle, needed to go out and see daylight :-)), and you cannot see and hear people like Jurgen Appelo and Gojko Adzic without being inspired. And inspired in two different ways actually;

1. I want to improve the way I do presentations - I want to be better at using visual effects (other than unicorns) and to use humor as a weapon to keep people awake. Tell the story in a way that visualizes your points and make them understandable to someone who doesn't know what is going on in your head :-). And more than anything believe in what you are presenting - when you do that you will "burn through" and get your message out there. I don't think I would be able to make a great presentation if it was about something that I wasn't passionate about.
2. New things to try out (of course!). Listen and read and observe, steal (I actually don't think it is stealing - more borrowing) what you can use and tweak it to fit into your context. Oh yes I used my favorite buzzword - CONTEXT.

Key Learnings - day 3

• The only person you can reliably influence and change is you
• You get more out of what you focus on - so focus on positive stuff
• Track happiness to measure improvements
• Many of our traditional testing (and test management) skills still applies - we just have to tweak them so that they match the agile world we now excist in.
• If there are rules and regulations about how you track and document stuff - have a discussions with the ones who "audit" and find the most effecient way of doing it. Eg. ways to extract comments from code to create reports automatically rather than writing the stuff in Word.
• Maslow's hierarchy of needs - now for test and quality
• Focus on what business need you are going to satisfy with your code rather than focusing on requirements in a traditional sense.

When I come home again after day 4 I need to compile a list of books and articles to read - so much new stuff that inspires me right now.

Agile Testing Days - Day 2

Tuesday was the first day with the "normal conference" and my program looked like this:

1. Keynote "Disciplined Agile Delivery: the foundation for scaling agile" with Scott W. Ambler
2. Testing distributed projects with Hartwig Schwier
3. The many flavours and toppings of exploratory testing with... me
4. Keynote "myths about the Agile teting, De-bunked" with Janet Gregory and Lisa Crispin
5. An informal session with Gojko Adzic on impact mapping
6. developers Exploratory Testing - raising the bare with Sigge Birgisson
7. Keynote "self coaching" with Lasse Koskela

To be totally honest I can't tell you much about the first keynote, I ended up following twitter and the battle between unicorns and the real world (sorry.... Looooong story)

The presentation from Hartwig Schwier gave a good overview of many of the challenges you have when working with agile in a distributed project - maybe not so much new and lifechanging, but still a good presentation that collected the challenges we have when going agile in a distributed team when it comes to communication, timedifference, culture and technology. (and by the way, a good and structured presentation and a good illustrations to get to the point).

Number three I will leave to others to comment - I think it went okay, there was full house and great discussions and questions afterwards.

Number 4 - the keynote by Lisa Crispin and Janet Gregory was great. In an hour the two grand ladies of agile testing managed to de-bunk many of the myths about agile testing. Things like:

1. testing is dead
2. ATDD/SBE tests only confirm behavior
3. Testers must be able to program
4. Testers must be able to program
5. Agile teams always deliver software faster

It was an engaged and fun keynote where they managed to kill these myths one at the time - well done.

Originally I had planned to go to an open space, but Gojko Adzic invited to an informal session where he would introduce the concept about impact mapping. Now this was an informal session - no presentation and stuff like that - but intersting conversations, and I LIKE IMPACT MAPPING - I need to learn more. The main thing is to move the focus from the what that business requires (e.g. what feature) to figuring out what VALUE it is they are trying to bring to the business, and then maybe find a shorter road to fulfil their need. Yet another book for the list of books I need to buy :-)

Picture shows Gojko while drawing a unicorn - actually it changed to a unipig during the talk :-)

I had talked a bit with Sigge during the speakers dinner on monday about exploratory testing, so of course I had to go and hear his presentation about developers during exploratory testing. It was great to hear his experiences, and I need to take a further look at his presentation to learn more about how they  implemented and uses session based exploratory testing. In a company where the number of testers are limited, it sounded like a really good idea - actually no matter how many testers there are it sounds like a great idea! get developers involved in testing on higher levels than unit testing, it will be a win-win, they know more about the application on system level, they know a bit more about what testing is all about and they help ensuring that testing doesn't always end up as the bottleneck.

Last activity of the day was the keynote from Lass about self coaching. It was a very different topic than the rest of a the day, but very intersting (and fun). He did an effort to make us understand how the brain works, how it reacts when we get negative input, how noise makes it harder for us to focus on the signals we receives... and makes it easier to take the wrong decision and byt that ending "in the box".

A general thing to take with me as a presenter after day number two is:

1. Never make your presentation so filled with text that people focus on understanding that rather than listening to you
2. Never put other people down in order for your self to look bigger
3. Unicorns can get a very big place in the head of agile testers :-)

 

Agile Testing Days 2012 - Day 1, Tutorials

Already after day one the head is filled with new inspiration and ideas, with stuff to bring home and look more into.

Monday I attended the Management 3.0 workshop with Jurgen Appolo. The workshop was inspiring and it was great with a tutorial that wasn't just classroom education but where we got involved, discussed and tried stuff out in practice.

One of the things I will bring home from that is the "Moving motivators" game. I thought I had a clear picture of what motivates me, what is important for me when it comes to my joblife, but by playing the game it actually occured to me that the real picture might be slightly different. When we then took it one step further and looked at in what way the motivators could be affected by changes in our work life (change to agile, new job etc) it really got interesting. I am going to introduce this to a couple of friends when I come back home and hear what they think. If you want to learn more about this exercise, the visit Jurgens site here
I borrowed a picture from the home page just to show you the game - hope it is okay :-)

Another thing was that I actually for the first time realized the seven different ways of delegation, and it was great fun to play the game and hear from the others in the group why the choosed to delegate in the way the did. We simply told a story about a thing we should deside on as leaders (e.g. selection of new test management tool) and then played "delegation poker". Highest and lowest score should then explain why they had chosen that type of delegation. It made me think; how good am I at delegating... how good was I as a programme test manager in Systematic back then... hmmm
But all in all a great workshop with food for thoughts. Read more about the game here.
Also borrowed a picture to show you that

The last part of the workshop was a presentation about change mangement, how do you bring change into an organisation. I had already read his book "how to change the world" but it was great to get a recap on it, and it is really something I can use and have used with my current assignment with a large IT company in Danmark - defining and implementing a test process across the organization.

All in all - a great Monday and a great start for Agile Testing Days for me :-)

/Gitte

Agile Testing Days 2012 - A New Type of Test Conference for me!

During the years I have participated in a number of software test conferences, both in Denmark, Europe and the US - but always "generic test conferences". My favorites are the two American STARs and EUROSTAR, I have really learned a lot from participating - both as a delegate and speaker. It is an amazing chance for getting new inspiration, discussions with peers and a lot of networking – If you haven’t tried it yet then hurry, you’ll love it.

Earlier this year I submitted my presentation on Exploratory testing to the conference "Agile Testing Days" and was so lucky to get it accepted. So now time has come to take the next step - participating in my very first agile test conference, and that will happen the coming 4 days in Potsdam Germany.
And what do I hope to get out of it?  - A LOT!

• Discussions with peers within testing about how to approach the problems we see when immature IT companies decides to take the journey towards agile.
• Inspiration from some of the most experienced agile testers in our community
• A good discussion after my presentation on Exploratory Test – does it make sense? Have other testers tried other clones? Is there new stuff to try out?
• Experience with a new type of conference – with new types of communication to try out (open space and consensus talks)

I hope to get time to keep you posted on how it turns out – both here on the blog and on twitter – my profile is @godtesen.