Agile TD Scandinavia

So it was finally time for my first testing conference, Agile TD Scandinavia and i was also there as a speaker. Here are some of my observations and thoughts from the days.

Arriving to the hotel the day before and walking to the reception to meet up for the speakers dinner. Seeing some familiar faces was good as i may not be the most outspoken person, so at least i have someone to start talking to. As the trip and dinner progresses so does the discussions, covering everything high and low. This is a great icebreaker especially for me as this is the first time, but it quite obvious that for many this is second nature. Aiming for a fairly early night, which i almost succeeded with.

Conference day
Arriving early at the venue and at once the organisation is top notch, everything is prepared and you just walk straight in. at this point my nerves are starting to make themselves noticed. Talking to a few colleagues and i start to calm down. Finally the welcome speak and the first Keynote is starting, good as i can now start thinking about anything else then my own talk. First out is Bent Myllerup, talking about organising and setting up agile teams. Biggest take away is the way they have been creating the teams by letting the members actually select themselves, instead of some manager pointing. Short break and then moving to the New Voices room to listen to Göran Bakken and Lisa Mellegård. Both are sharing their experiences from various assignments. Unfortunately the time is set to only 20 minutes which means that both need to finish their presentations a bit abruptly, and there is really no time for questions. Short break and then it's time for my session, but first Mirsad Vojniković talks about test automation and common pitfalls and misunderstandings, he is making a few quite bold statements, but again time runs out so no real discussion around this. My time: after being presented, and of course stumbling a bit in the beginning i start to feel a flow. Until i check the time and realize i am on the second to last slide after only 8 minutes. Well just keep going and finish the talk. A few questions and i am done. Despite missing a few comments, quite happy with my work.

Now time to really enjoy the conference, and realize quite quickly that the new voices section is the one that keep pulling me in. Robin Bergh’s talk about how he redesigned the scum board was brilliant and gave a lot of new thoughts. Like the way they use the backlog as a starting grid instead. Clear and concise way to show the priority. After lunch a long time was spent on Open Space and different Games. It's a good way to challenge the mind. Mob Testing by Maaret Pyhäjärvi was a really excellent key note and a way of testing and developing that i didn't know existed. Something i will definitely read more about, sounds like a fun way of working, and a different way as well. After a full day one is quite exhausted, but the mingle after both at the venue as well as at the hotel was equally rewarding. 

General thoughts.

• Organization of the conference: could not be better, D&H really know what they are doing. 
• Most presentations are experience based, which is really good as it shows what can work and how to get there. 
• As most people attending have a similar thinking about test and processes there are not really any major discussions. 
• Would have loved someone to present “why waterfall rocks” or “detailed test cases is the future” just to see how the discussions would go. 
• Maybe change the timings a bit, have 15-20 min for a talk and leave 10-15 min for discussions, Especially if the setting is a smaller room. 

A massive thanks to the organisers and all of you who attended.

Learning from chaos

Started to create a presentation about working as a Test Manager / Test team lead and noticed that projects or assignment that has been in a bad state is where I really picked up knowledge and experience.

Suddenly one is put into situations never before seen and must act accordingly. this could range from pure political project discussions to arguments within the team on what approach to use on certain items.

At the time it seemed overwhelming and slightly panicky, but once i took a step back I realized how much i had learned, on so many different levels. It also made me aware of what i need to improve and work on.

The improvement could range from the simple: the realization that you actually know what you are doing, to accept decisions regardless if you don't agree and stop arguing.

Nowadays i try to reflect on my own work and actions fairly regularly, but also make sure to ask the people i work with to comment on my work.

There is always room for improvement so don’t be afraid to ask.

Slipping on test

As winter has arrived for a short while in Sweden a discussion got me thinking.

A friends mother has apparently decided that it will be slippery everywhere, as there is about 1 mm of snow on the ground and therefore is a bit scared to actually go out.

Do we experience similar behavior when testing ?

Do we test in different ways depending on the state of the software?

If the software is in a bad state, or early in development, where issues are common:

You are expecting issues and therefore test in a different way, as: “it will not work anyway”, and you catch the small issues and might miss the big one. Or even worse give up before even trying one scenario.

I.e one is expecting to slip on the ice and therefore stiffens up and walks completely different and is probably more likely to actually slip on each little patch of ice

Or do you “walk” normally but is aware of the ice and prepared that the foot might skid a bit. ie you test as you normally do and if you “slip” are prepared for it and can handle that issue and continue to the really important ones

Keeping the focus

After doing some interviews for possible new assignment, the approaches have been quite different. They have ranged from the “traditional” question - answer to one that felt more like I held a presentation. And given the interaction with the interviewer my own performance have been quite different.

Is there a similar interaction when you test ?

Regardless if you are running test cases or using an ET approach, the way the system under test responds might dictate they way you continue to interact with the system.

for example if the test scenario takes a long time, ie running large sql queries, one might lose focus during the waiting time and might miss issues once the system actually responds. On the contrary if the system responds quickly you can keep focus better and more likely to spot the possible issues.

For me the more challenging the interview is and if there is a good interaction with the interviewer I seem to perform better. Its a similar feeling when running tests. Early in the project the system is new and its challenging to test. One must get “to know” the system/function and issues are often common. You get continuous feedback and expand you knowledge.

But the longer the testing runs you start to know the system and issues have been handled so the interaction and response might not be that immediate. which in turns might mean the focus is dropping of and issues can be missed

How do you keep focus if the interaction and response from the system drops, or when the test phase is long ?

Handing over the project to maintenance

Finally the project is nearing the end and handovers are being planned, kick-out dinner is booked and the next project is being staffed up. But there are still some open defects, how can this be?

Shouldn't we deliver a complete software, there should not be any defects, or ?

As stated over and over testing can continue until the fingers bleed, and yet there will be new issues found or some issues might not have been solved. So how do you handle this ?

A good handover is the key, and as usual good communication. The receiving organization must be aware of the current status and if they can accept a delivery with open issues. Also there should be a plan for handling these open issues.

Usually some tool is used for tracking issues during development, QC, Jira or similar. But when it's handed over to maintenance, they might not use the same tool, or the issue handling process is completely different as the product is now in production.

Make sure the open defects are clearly described with steps to recreate.

Ensure that when handover is done that the receiving organization understands the issue and the possible impacts. Also make sure that they understand the issue, what seems obvious to you might not be for another person.

Good practice is also to do a follow up later to see how these issues have been handled. As it is easy to forget and if not fixed they will come back in one way or the other.

Emergency room

After spending an afternoon and evening in the hands of healthcare due to bike crash and resulting fracture in the arm, i started thinking on how this is similar to development and test.

The scenario.

I am biking home from work and colliding with a pedestrian resulting i a short flight and a stiff and throbbing arm.

Defect report was raised to “first line support” and providing scenario and symptoms. The initial investigation showed that it most likely was nothing serious and rest was prescribed.

So a minor defect and nothing that needed to be re-written or was a show stopper.

A few days later the arm still was not better so a new call to First-line was made and as the symptoms had changed slightly it was decided that a doctor should look at it.

The minor defect now re-appeared, and was re-opened, but in a slightly different way and a little different outcome.

Finally arrived at the doctors office and was meet by the nurses who made an initial investigation and decided that x-ray was needed. This was done and the images show to the doctor.

Investigating the defect to find the seriousness of it.

Quick meeting with the doctor confirms the fracture and a cast is needed

Product owner checks the defect and decides it needs to be fixed.

Once again meeting the nurses and getting a cast. Information on what to think about and how to handle the cast.

Defect fix information and a workaround provided by the developers. Final fix to be delivered in one to two weeks.

Conclusion

It is important to verify the defect, can it be recreated, and if so will it affect more than one area. A minor defect in one system might affect another part and then become a major.

So remember to test around the defect, as they tend to live in groups

Stop29119 - A Tempest in a Teapot ?

It has been a few months now since CAST 2014 which seems to have been the starting point for the “great ISO29119 debate”. But what has actually happened since then ?

• The Stop29119 petition was started and got over 1000 signatures and this was then presented to the ISO-group.
• Numerous blog posts have been written
• Mostly posts against the standard, but a few pro-ISO have appeared
• Debate on Twitter and other media
• Ranging from personal beef to factual discussions
• Local discussions appears to have happened
• Probably quite a few people have bought the standard (me included)
• No information if any company has actually started to implement this

But what now ?

• The debate seems to have abated and things have gone a bit silent.
• No response to the petition, at least to my knowledge
• We are still waiting for the two final chapters of the standard.
• Awaiting to see if any organization will pick this up or not

So was the whole debate a storm in a water glass?

Well in a way it was. Probably because only a small number of people did the open discussions.

In another way it was not. It brought the attention to the general community on what is going on and even if most stayed silent, many local discussions seem to have happened. And the information has been spreading.

Some discussions might have gotten a bit out of hand and might have lost focus, but thats normal when you really stand for something. Then again we are testers and discussing is what we do, and question how things are.

Looking forward to read the last chapters and also to see what will happen both within the community as well as within organizations in regards to the standard