UK Tester Forums

Testing is Long Overdue for a Change

Rumours of the death of testing were greatly exaggerated, but even so, the changes we predict will be dramatic. My own company has been heralding the demise of the 'plain old functional tester' (POFT) for years and we’ve predicted both good and bad outcomes of the technological and economic change that is going on right now. Some time ago, I posted a blog, Testing is in a Mess where I suggested that there's complacency, self-delusion and over capacity in the testing business; there is too little agreement about what testing is, what it’s for or how it should be done.

But there are also some significant forces at play in the IT industry and I think the testing community, will be coming under extreme pressure. I summarise this change as ‘redistributed testing’: users, analysts, developers and testers will redistribute responsibility for testing by, wait for it, collaborating more effectively. Testers probably won’t drive this transition, and they may be caught out if they ignore the winds of change.

In this article, I’ll suggest what we need from the leaders in our industry, the market and our organisations. Of course, some responsibility will fall on your shoulders. Whether you are a manager or technical specialist, there will be an opportunity for you to lead the change.

read more

I love to see creative work from people in the industry, and Martin Jansson always impresses me with his insatiable desire to learn, to do better and to take risks with ideas to push the craft forward. While I have been looking at gamification lately, it was exciting to learn that he and his colleagues had already been applying some of these ideas by looking at storytelling and games, and using some of those ideas to add more fuel to test idea generation during exploratory testing work.

Cem Kaner’s work on scenario testing is a powerful approach to testing. This is an approach to quickly create useful testing scenarios and ideas where we create a compelling story about the people who use our software, describe typical usage, possible outcomes, and human activity patterns surrounding usage. One of the most interesting outcomes of this kind of work is that it puts us in the role of our end users, and helps us quickly identify problems that they are likely to encounter. It also helps us understand when our software actually delivers, we can tell project stakeholders that our software works within the narrative of real-life scenarios. So not only do we uncover important problems, we also provide information that validates what we have done. “Yes! It works in an emergency scenario we didn’t think of during requirements definition!”

There are a lot of ways that we can frame scenario tests to provide structure and help with creative test idea generation. Using gaming as an influence, Martin Jansson and Greger Nolmark wrote a paper on adding structure to scenarios during exploratory testing sessions using storytelling as a guide:
Exploratory Test Adventure – a Creative, Collaborative Learning Experience.

I got excited when I started reading this paper because any kind of creative structure that we can add to test idea generation helps us be more thorough, and helps create more and better ideas. As Martin says, “…by setting up scenes, just like in a roleplaying adventure (or RPG game), you and your testers will have an increased learning experience that lets you explore beyond regular boundaries, habits and thought patterns.”

I often lament that testing information focuses too much on the negative, when we should also tell stakeholders when the team has done a great job. As a designer and programmer, sometimes I get worn down by constant criticism and ask the testers to also give me some positive feedback along with the criticism. After all, critiquing isn’t all about the bad news. It sometimes feels hopeless if all we get is the negative, with no positive feedback at all. Testers on the other hand, often feel like they are failing if they don’t find bugs and provide consistent negative feedback. But if we look at a story, some of them have happy endings. They have twists and turns and there are negatives, but there are also positives. Both are important factors to a story or game (or else they are too sappy and silly if it is all positive, or too depressing if they are all negative) and they are also important factors for determining whether a product or project has merit, or if we are ready to ship. Storytelling is one mechanism we can look to to help us get beyond mere bug hunting, and to provide quality-related information, both positive and negative. This pleases me.

Check it out, it is another example of looking at game mechanics, and applying one gamification aspect to software testing to help us make testing more valuable, more effective, more creative, and hopefully, more fun.

Flicking through a blog the other day, I was impressed by the author's insight, the breadth of material, his interest in the semantics, theory and practice of testing. I chuckled at the sense of humour and I adored the modesty and humility he displayed.

And then I noticed that of the seven images I could see on the blog's front page three (1, 2, 3) were record sleeves.

I was distracted by this, my train of thought moving away from the content and onto the relevance of my observation and speculation about the author's interests: is it significant that there are so many record sleeves here? Will I have a look at the archives to see what images were used there? Is this chap a record collector? Are these records personal favourites? Why is he using images on every post, anyway? What value do they add? What was this blog about, again?

And then I remembered that it was my blog and that I had started off scanning for typos.

The signal I was giving out, from an aggregation of discrete decisions taken over time, was not one that I had intended but was one that revealed (or at least gave an observer cause to suspect it revealed) something about me and my interests, priorities, decision-making.

In software development we're constantly making discrete decisions - should we aim to put that feature in in this cycle? Can we get away without that widget? Will we have time to fix that bug and test it? Could we risk changing the format of this file given the benefits it would enable? Is it time to refresh the interface?  These will generally be taken with good intent for the issue at hand but they can still add up into something unintended that users notice, that takes them away from the task they're trying to perform, that they will use to form an opinion about us and the way we operate. Be sure to step back and look for the patterns from time to time.

And then I wrote a new post. With an image that can't be misinterpreted. Probably.
Image: http://flic.kr/p/ZRBo

The nice folk at Diaz Hilterscheid have made the video of my track talk "Continuous Delivery of Long Term requirements" at Agile Testing Days 2012. The original write up ran:

read more

Huib Schoots asked me to name my top 10 books for testers. Initially, I was reluctant because I'm no fan of beauty parades and if an overall 'Top 10 Books' were derived from voting:

1. The same old same old books would probably top the chart again, and
2. Any obscure books I nominated would be lost in the overall popularity contest.

So what's the point?

read more

I messed up this week. And the week before. And the week before that, the one prior, most weeks last month, most months this year, most weeks in most months most years ... Basically all the time. And I do it on purpose because it puts me in a position to find bugs that I wouldn't otherwise come across.

I'm not talking about deliberately entering junk content into applications, configurations, data and the like. I'm not talking about random clicking in a system under test or trying to engineer corner cases by artificially restricting disk space or RAM or some other resource or any other of those legitimate test vectors that benefit from experimenting with the available parameters.

I'm talking about sympathetic testing - or even just plain usage - in an untidy way to try to increase my test coverage in passing. Here's some examples:

• If your application is in the cloud, maybe don't log out of it when you've finished your current task. Look for odd effects next time, perhaps after you've moved between networks or not accessed the system for a few days.
• If you start an application daemon or service at the console, don't close it immediately, but leave the console open while the system runs. Check in on it now and again as you move between tasks and look for exceptions, unexpected errors and so on.
• If you have an instance of your application open already and want to try something, sometimes don't use the open instance but open another and watch for effects due to cross-contamination.
• At the end of  a session, don't close down cleanly. Instead, leave the application in the middle of an interaction - with a dialog open, say - and see what happens when you come back to it.
• If you're testing a web-based application don't always use the same bookmark to get there. Use your browser history, or type into the URL bar and get some old URL from your history or paste a URL from an old email to find a new starting point and see what the server does with it.

This can be extremely productive and has the side-benefit of forcing you into a state of mind where you're alert to issues from the moment you begin your task. You should be looking to automatically log wherever and whatever is possible, record exceptions and other error trace immediately you see it, take screenshots of anything you think might be unexpected behaviour and so on because one of the consequences of this approach is that reproduction steps can be harder to obtain and the evidence can help you to return to the bad state later.

People talk about setup, test, teardown sequences and in some cases that's exactly what's required. You may need to understand your starting context as precisely as possible so that when running a sequence of test ideas you can return to that context each time. But your users won't be running inside a sterile laboratory, so make sure you don't always do that either.
Image: http://flic.kr/p/9RnnTK

Posted in Software Testing

This job at smug mug inspired me to write this post as it sums up one of those great opportunities to relate your day-to-day job (and your skills) to a passion you may have, as well as joining a company that seem to be making big changes to the way photographers get their work out (and get paid for it).

I often hear testers say that they hate testing but I believe this strong statement is more about the job they have, than the work that a tester does.

There are numerous factors at play in any role, but I believe one of the biggest factors to affect your work is the product that you test.

The job at smug mug is interesting because I found it through my photography network on google plus. If you have an interest in photography it sounds like a good job. You get to test  a platform for showcasing photography. You get to test a community site based around the love of photography. You get to test a platform that is changing the way photography is managed, distributed and paid for. You get to work with other people who have a love of photography. If you enjoy photography this role sounds perfect. If you don’t enjoy photography then it probably doesn’t sound too interesting.

In fact, in order to do the role well you probably need to know more than most about photography to ensure that the terminology used, the technical details about each photo and the process flow that photographers go through is accurate. Sure, there may be specs, but I suspect you will add more if you have experience and knowledge of photography.

If you like cars wouldn’t a job testing car sites or car apps or on board car software be interesting?

If you like writing wouldn’t a job testing writing software or a platform for writer’s to collaborate be good to work on?

I’m not saying testing can only be interesting if we are working on a product that is related to our interests. We can also find enjoyment testing products that we can relate to. I enjoy testing call centre software because I can relate to it. I’ve enjoyed testing anti virus products because I can relate to this also. I enjoyed testing online voting because I can relate to it. I didn’t enjoy testing banking payments and settlements because I can’t relate to it and found it overly complicated. Each to their own. What I can relate to, others may not find interesting at all.

The product under test isn’t the only aspect of an enjoyable role for sure (culture, management, autonomy, team, office space etc), but I firmly believe that we enjoy our testing more, and can explore the limits of our own skills, if we have some connection and affinity to the software we are testing.

If you’re not enjoying testing could it be that you don’t have a connection to the product you are testing? If so, what could you do about it?

P.S

Do you really enjoying testing a product you can’t relate to or have no interest in? Let me know.

The 37th Test Management Forum will take place on Wednesday 24 April 2013 at the conference centre at Balls's Brothers, Minster Pavement.

The meeting is as usual, FREE to attend.

Click here to book a place

PROGRAMME

13.30pm	Tea/Coffee
14.00pm	Introductions
14.15pm	Paul Gerrard, Gerrard Consulting, Goldfish Bowl: Ad-Hoc Discussion - bring your HOT Topics	Michal Janczur, Deutsche Bank: BA and QA Communities of Practice at Deutsche Bank - Working to improve Quality of Requirements	Susan Windsor, Gerrard Consulting, Delivering Business Value not just Software!
15.30pm	Tea/Coffee
16.00pm	Paul Gerrard, Gerrard Consulting, How Techy Should a Non-Techy Tester Be?	Graham Thomas, Independent Consultant: Software Testing Secrets We Dare Not Tell	Susan Windsor, Gerrard Consulting, Transitioning to Outsourcing? What’s the impact on your role?
17.15pm	Drinks Reception

Session Abstracts

Graham Thomas, Independent Consultant: Software Testing Secrets We Dare Not Tell I firmly believe that “There are some fundamentals of software testing that we really don’t understand or know the answers to yet.” Here are some simple questions. They are very easy to ask. Unfortunately they are very difficult, if not impossible to answer.

1. What is the purpose of Software Testing?
2. Just how effective is the way we test – and how do we know? (Trad, V-Model, Structured Testing, agile or any other form of testing for that matter?)
3. If checking isn't software testing, then why is it that ‘checking’ is what our stakeholders are paying us to do?
4. If software testing is so difficult, demanding and challenging, then why is it that we keep on assigning the least skilled or experienced to perform it?
5. Why do software testers spend so much of their time running tests that do not find bugs?

These questions are important because they drive at the very heart of what we are doing in the software testing industry today, and understanding the answers will surely prime the future direction that our industry will move in. This session has been designed to be a highly interactive discussion which many people might find challenges their basic understandings. I will act as facilitator, give an introduction to each question, then actively moderate the debate and if needed take on the role of arbiter. Come along, expect to be involved, and if you have a view then please share it. Help to drive forward the discussion – and potentially the software testing industry.

Susan Windsor, Gerrard Consulting, Delivering Business Value not just Software!

When a business initiates a project, they have a vision of what value will be delivered. Frequently projects have to compete for budget and so the value of potential benefits is critical in securing budget. A great deal of time and effort goes into identifying these potential benefits and defining measures to track their realisation. But, how often is that information lost once the software element of the project kicks off?

There is a lot of discussion in our industry about delivering business value rather than just software, but what does this really mean? How can the role of Business Analyst and Test Analyst work together in support of that goal? What techniques really work in terms of delivering value? We’ll explore all these questions and then I’ll share some ideas on how we can demonstrate that delivered software components relate back to the original project benefits. We’ll then open up a discussion to share ideas and experiences on how we can collaborate together to improve the value we deliver to our business stakeholders.

Michal Janczur, Deutsche Bank: BA and QA Communities of Practice at Deutsche Bank - Working to improve Quality of Requirements

• DB is an organisation of over 90,000 people with thousands in technology delivery
• DB have promoted Communities of Practice within Technology groups
• Collaboration across COPs should result in improved practices across the organisation
• Quality and timely requirements are essential to quality software delivery
• What are the priorities and opportunities for cross BA and QA professions?

Paul Gerrard, Gerrard Consulting, How Techy Should a Non-Techy Tester Be?
There seems to be an increasing demand for testers who have technical skills. The range of skills being requested varies very widely in technologies and depth of knowledge and capability. Some are the traditional technical oriented testing skills like automation tools and performance testing, but other roles sound like 'developers who test'. Recent roles I've seen include:

• Performance testing (proprietary and e.g. JMeter, The Grinder etc.)
• GUI test automation and frameworks (proprietary and e.g. Selenium, Watir, RobotFramework etc.)
• Database manipulation, query and other SQL-based products (e.g. Oracle, DB2, MySQL etc.)
• Scripting languages for text processing, job control, build and release processes (e.g. Python, Ruby, Perl, PHP)
• Programming languages proper e.g. Java, C#, C++ and JavaScript
• Developer/unit testing frameworks e.g. xUnit
• Behaviour-Driven Development tools e.g. Fitnesse, Cucumber, RSpec, JBehave etc.
• Oh, and did I mention open source?

In this session, we'll explore the range of technologies testers are increasingly needing and how non-techies and teams can acquire transferable technical skills to enhance their capabilties (and CVs).

Susan Windsor, Gerrard Consulting, Transitioning to Outsourcing? What’s the impact on your role?
When considering outsourcing or off-shoring activity, it’s normally development and/or testing activity that will transition over to the supplier. Whatever the relationship, there is always an impact on the role of Business Analysis.

One aspect to consider is where the ownership of requirements sits within a new operating model? Where is the analysis activity actually performed? If the supplier has domain knowledge, is it reasonable for them to undertake analysis and guide development and test activity? If all the analysis is still performed in-house, how can the supplier obtain the level of support required to fully understand requirements? Is there a hybrid solution where ultimate responsibility lies in-house but much of the analysis is performed by the supplier?

During this session, we’ll explore these different models and share experiences of supporting the transition to an external supplier. In addition to these questions, how else is the role of the BA affected by outsourcing? Is there a role to perform as part of the supplier selection? Is it necessary to more fully define your method? Do you need to change your method to align with your new supplier? What about additional skills you may need to support your new role, particularly with respect to management skills?

At the start of this session, we’ll review the types of models and additional skills; prioritise those we’d like to discuss as a group and then open up for discussion on our views; knowledge and experiences.

Click here to book a place

• By Paul Gerrard at 4 Apr 2013 - 11:09
• UKTMF.COM
• Paul Gerrard's blog

© UK Tester Forum
hosted by Gerrard Consulting

The 37th Test Management Forum will take place on Wednesday 24 April 2013 at the conference centre at Balls's Brothers, Minster Pavement.

The meeting is as usual, FREE to attend.

Click here to book a place

PROGRAMME

13.30pm	Tea/Coffee
14.00pm	Introductions
14.15pm	Paul Gerrard, Gerrard Consulting, Goldfish Bowl: Ad-Hoc Discussion - bring your HOT Topics	Michal Janczur, Deutsche Bank: BA and QA Communities of Practice at Deutsche Bank - Working to improve Quality of Requirements	Susan Windsor, Gerrard Consulting, Delivering Business Value not just Software!
15.30pm	Tea/Coffee
16.00pm	Paul Gerrard, Gerrard Consulting, How Techy Should a Non-Techy Tester Be?	Graham Thomas, Independent Consultant: Software Testing Secrets We Dare Not Tell	Susan Windsor, Gerrard Consulting, Transitioning to Outsourcing? What’s the impact on your role?
17.15pm	Drinks Reception

Session Abstracts

Graham Thomas, Independent Consultant: Software Testing Secrets We Dare Not Tell I firmly believe that “There are some fundamentals of software testing that we really don’t understand or know the answers to yet.” Here are some simple questions. They are very easy to ask. Unfortunately they are very difficult, if not impossible to answer.

1. What is the purpose of Software Testing?
2. Just how effective is the way we test – and how do we know? (Trad, V-Model, Structured Testing, agile or any other form of testing for that matter?)
3. If checking isn't software testing, then why is it that ‘checking’ is what our stakeholders are paying us to do?
4. If software testing is so difficult, demanding and challenging, then why is it that we keep on assigning the least skilled or experienced to perform it?
5. Why do software testers spend so much of their time running tests that do not find bugs?

These questions are important because they drive at the very heart of what we are doing in the software testing industry today, and understanding the answers will surely prime the future direction that our industry will move in. This session has been designed to be a highly interactive discussion which many people might find challenges their basic understandings. I will act as facilitator, give an introduction to each question, then actively moderate the debate and if needed take on the role of arbiter. Come along, expect to be involved, and if you have a view then please share it. Help to drive forward the discussion – and potentially the software testing industry.

Susan Windsor, Gerrard Consulting, Delivering Business Value not just Software!

When a business initiates a project, they have a vision of what value will be delivered. Frequently projects have to compete for budget and so the value of potential benefits is critical in securing budget. A great deal of time and effort goes into identifying these potential benefits and defining measures to track their realisation. But, how often is that information lost once the software element of the project kicks off?

There is a lot of discussion in our industry about delivering business value rather than just software, but what does this really mean? How can the role of Business Analyst and Test Analyst work together in support of that goal? What techniques really work in terms of delivering value? We’ll explore all these questions and then I’ll share some ideas on how we can demonstrate that delivered software components relate back to the original project benefits. We’ll then open up a discussion to share ideas and experiences on how we can collaborate together to improve the value we deliver to our business stakeholders.

Michal Janczur, Deutsche Bank: BA and QA Communities of Practice at Deutsche Bank - Working to improve Quality of Requirements

• DB is an organisation of over 90,000 people with thousands in technology delivery
• DB have promoted Communities of Practice within Technology groups
• Collaboration across COPs should result in improved practices across the organisation
• Quality and timely requirements are essential to quality software delivery
• What are the priorities and opportunities for cross BA and QA professions?

Paul Gerrard, Gerrard Consulting, How Techy Should a Non-Techy Tester Be?
There seems to be an increasing demand for testers who have technical skills. The range of skills being requested varies very widely in technologies and depth of knowledge and capability. Some are the traditional technical oriented testing skills like automation tools and performance testing, but other roles sound like 'developers who test'. Recent roles I've seen include:

• Performance testing (proprietary and e.g. JMeter, The Grinder etc.)
• GUI test automation and frameworks (proprietary and e.g. Selenium, Watir, RobotFramework etc.)
• Database manipulation, query and other SQL-based products (e.g. Oracle, DB2, MySQL etc.)
• Scripting languages for text processing, job control, build and release processes (e.g. Python, Ruby, Perl, PHP)
• Programming languages proper e.g. Java, C#, C++ and JavaScript
• Developer/unit testing frameworks e.g. xUnit
• Behaviour-Driven Development tools e.g. Fitnesse, Cucumber, RSpec, JBehave etc.
• Oh, and did I mention open source?

In this session, we'll explore the range of technologies testers are increasingly needing and how non-techies and teams can acquire transferable technical skills to enhance their capabilties (and CVs).

Susan Windsor, Gerrard Consulting, Transitioning to Outsourcing? What’s the impact on your role?
When considering outsourcing or off-shoring activity, it’s normally development and/or testing activity that will transition over to the supplier. Whatever the relationship, there is always an impact on the role of Business Analysis.

One aspect to consider is where the ownership of requirements sits within a new operating model? Where is the analysis activity actually performed? If the supplier has domain knowledge, is it reasonable for them to undertake analysis and guide development and test activity? If all the analysis is still performed in-house, how can the supplier obtain the level of support required to fully understand requirements? Is there a hybrid solution where ultimate responsibility lies in-house but much of the analysis is performed by the supplier?

During this session, we’ll explore these different models and share experiences of supporting the transition to an external supplier. In addition to these questions, how else is the role of the BA affected by outsourcing? Is there a role to perform as part of the supplier selection? Is it necessary to more fully define your method? Do you need to change your method to align with your new supplier? What about additional skills you may need to support your new role, particularly with respect to management skills?

At the start of this session, we’ll review the types of models and additional skills; prioritise those we’d like to discuss as a group and then open up for discussion on our views; knowledge and experiences.

Click here to book a place

• By Paul Gerrard at 4 Apr 2013 - 11:09
• UKTMF.COM
• Paul Gerrard's blog

© UK Tester Forum
hosted by Gerrard Consulting

Since reading the last issue of The Testing Planet on leadership I seem to have come across more blogs than usual talking about how to be a great leader, manager, boss or whatever, for instance:

• Evaluate Character AND Performance
• 9 Leadership Tips Anyone Can Use Immediately
• 10 Things Really Amazing Bosses Do
• This is why you need to learn how to talk to developers

I'm interested in improving as a manager, leader, boss and (especially) whatever and this kind of material can provide inspiration. I'm also keen on personal reflection and introspection as a way of identifying areas to work on and over the years I've come to realise that a couple of principles trump most other things for me:

• clear: I will do my best to be absolutely clear about what I think, what my response to any request is, what my motivation for any particular approach is, what I will commit to do (or not do) about some problem and so on. I will encourage and answer any question on any work-related topic to the fullest extent that I can given obvious constraints such as confidentiality.
• present: I will do my best to be approachable, available and responsive. If I can't be responsive I'll try to explain why and give a commitment to respond at some later time.

With these in place, and applied appropriately, I like to think that whatever techniques, approaches or methodologies  that we're using or experimenting with will be well-grounded and, although they apply primarily to how I want to interact with my teams, I try to abide by them when working with any of my colleagues.
Image: http://www.last.fm

Posted in Conferences & Events

Across the world there were similar journeys taking place.

Delegates are boarding planes, trains and automobiles to attend a European conference in the wonderful city of Amsterdam. For some this journey is short. For others it’s epic.

Some delegates would be travelling on their own. Others would be travelling with people they know; colleagues, friends, peers or family.

For the first time conference attendee the journey can be daunting and nerves can start to form around what to expect.

Some journeys go better than others.

In England one conference delegate is flying from a small city airport in a tired looking Bombardier Q400.

 

The noise on-board is deafening, the coffee cold and the seats cramped. Despite these downsides the delegate can’t help but notice that the flight staff are welcoming, well trained and during the safety overview, incredibly well synchronised. He notices the menu in the seat-back and does some impromptu testing of the contents. The first obvious bug he spots is the use of the word “gourmet” to describe the microwaved cheese toastie.

Those who often attend testing conferences are somewhat obsessed. Testing isn’t just a career – it’s a calling (or a lucrative business). It’s something they’ve been doing their whole lives. Some might call this devotion to it strange, weird or sad. Others just see it as a way of life.

Over the Atlantic ocean is one of the conference speakers, asleep on a Virgin Atlantic jet. His journey started several hours ago. It won’t end for a few more hours yet. Tiredness is inevitable.

In Amsterdam there are already a large group of delegates descending on the city’s hotels, hostels, rentals and flats. Pockets of testers are occupying three or four of the main hotels. Many don’t know each other and are destined to spend the rest of their stay oblivious to the fact that the person next to them at dinner is a tester and attending the same conference.

All of the delegates share something in common; testing. They may approach the subject differently. They may oppose each others views. They may dislike each others personalities, but they all have a common thread to at least start a conversation. Yet many won’t. Many will spend the entire time alone. Some may enjoy this, others will inevitably feel isolated.

Some delegates arrive on the Monday, others wont turn up until the start of the presentations on Tuesday. The Twitter stream starts to fill with people discussing meet-ups, comments on the tutorials already taking place and general banter about the event.

Chat sessions fire up, text messages are sent and tweets are broadcast to arrange meals, drinks and gatherings. Many of these people are meeting others in the flesh for the first time. Relationships on social channels have paved the way for a seamless ability to meet-up in person. The hard work is done. The relationships can flourish further in person, or dwindle away at the realisation that online personas don’t always match reality.

As the evening comes around small groups of Testers are travelling to bars, hotels and restaurants to catch up and relax before the conference starts.

In an Indonesian restaurant in the city centre, a group of testers are gathered around vast quantities of food and beer. Conversations are flowing about testing, life and work. People are getting to know new people or are refreshing relationships with people they met at other conferences. As more beer flows the conversations become more lucid and discussions about the state of testing inevitably crop up.

As this particular group discuss certification schemes, standardisation and best practices, in the context of them destroying the industry, it is oblivious to them that across town, in a posh hotel where Heineken is served in impossibly tall glasses, there is another group of testers talking about how context doesn’t matter and best practices are what the testing world needs.

Just down the road in a small bistro is a group of well funded testers talking about how maturity models are the future for their giant consulting business. They are busy putting the final touches to new methods of quantifying the true value of testing to an organisation.

Across Amsterdam that evening there are many tribes of testers discussing testing. Some with polar opposite views, some in perfect alignment and some who are too tired, or drunk, to talk about testing. In hotel lobbies and rooms across Amsterdam there are also testers with no-one to talk to.

As Tuesday afternoon spins around the conference centre starts to get busy. In the corner is a tester filming the queues forming using a time delay app on his iPad. Upstairs are testers sitting around talking about strategies for handling regression testing and exploratory testing. Meetings are happening and discussions are flowing.

Many testers are pacing around the venue embroiled in conversations to someone on the other end of a phone call. Are they conducting business? Speaking to relatives? Pretending to speak to someone to look important?

In the Test Lab the lab rats are getting ready for people to do some testing at the conference – a concept that is alien to some delegates.

In the expo centre are salespeople and demonstrators trying to draw attention to their products, services and goods. Some are doing better than others. Some are more involved than others.

For some of the vendor representative it is their 20th conference this year. Some of the vendor reps haven’t been home for the last 8 months, their life is a constant cycle of conferences.

Throughout the event some presentations go to plan, some of the speakers don’t quite communicate their intended message well and some experience a few technical glitches.

Some talks are funny and insightful, others masked in terminology and concepts that aren’t appealing to everyone. Some are about systems, some about space rockets, some about video games and some about standards.

There’s a talk for everyone. Many delegates are complaining that there is too much to see and they are having to make tough decisions on which talk to get to. Some consider that struggle to decide the marker of an excellent conference.

This year sees a real sense of community and involvement. The community hub took a day to get going. But on the last day was well attended with delegates wanting to listen to lightning talks, chat to new people and contribute their views and ideas to the Testa Mappa.

It’s in the community hub that delegates get to talk to the speakers and other attendees in a welcoming and safe environment. Many delegates are changing their mind about the presentation after discussing the topic further with others. Many speakers are learning a lot about themselves, their presentations and their ability to communicate their core message.

Throughout the event there are many smaller and much more focussed meetings happening, some private and by invite only, some open to a wider audience. There is business happening, friendships being made, social connections starting and also ending.

As the conference comes to a close the delegates, speakers, organisers and vendors travel home, many leaving with new friends and connections. Many will return home to families, friends and colleagues more tired than they thought they would be. Conferences take their toll both physically and emotionally. The challenge for many will be filtering and putting in to action many of the interesting ideas they took away from the conference.

The challenge for some will be working out how they can talk to more people next time and how they can ensure they are invited to the many social gatherings that are happening.

For many though the conference didn’t end when the doors closed and they travelled home; the conference continued on the social channels for many more months. And that is often the real marker of a successful conference.

(I wrote this short observational story at EuroSTAR 2012 last year. It was a great conference and this years looks like it will another great conference too – see you there hopefully.)

We built a tiny (4.5KB, < 200 lines of code) JQuery Bootstrap plugin for MindMup that turns any DIV into a WYSIWYG rich-content editor, and just open-sourced it. Here are the key features:

• Automatically binds standard hotkeys for common operations on Mac and Windows
• Supports image drag & drop, uploading images from desktop and taking photos with mobile cameras
• Allows a custom built toolbar, no magic markup generators, enabling the web site to use all the goodness of Bootstrap, FortAwesome and so on…
• Does not force any styling – it’s all up to you
• Uses standard browser features, no magic non-standard code, toolbar and keyboard configurable to execute any supported browser command
• Does not create a separate frame, backup text areas etc – instead keeps it simple and runs everything inline in a DIV
• (Optionally) cleans up trailing whitespace and empty divs and spans

Posted in Social, Community and TechSoftware Testing

For the last few sprints we’ve been demonstrating our user stories (i.e. completed work) using the medium of video. It’s been really interesting to see how the teams have moved to video with ease.

The videos are often hilarious, some featuring more tech wizardry than others but all of them a great show of creativity.

I tweeted about this a while back and a couple of people asked why we would go to the effort of creating videos to show our features. Well here’s some reasons:

The demonstration were choppy during switch overs as teams had to sign in, get the system to the right state to show the new work and articulate clearly the story to the audience.

All demonstrations are at the mercy of the demo Gods. Sometimes they work, sometimes they fail – even though they may have been working just moments before (mostly it was due to logging in to the wrong accounts, dialling the wrong number, slower connection in the meeting room, nerves, data now in the wrong state after practicing the demo). We now simply line up each video and play them one at a time pausing for questions in between.

If you miss the demo you miss the demo. So for those that can’t make it to the meeting they don’t get to see the demo of the product. Videos let us post them somewhere central for the business to view at their leisure.

Also, as we move forward we will be starting to add the video demos to a central source when the feature is actually finished, which could be just a day in to the sprint. As we release to live weekly when we demo the feature to the wider business it may already have gone live. With regular release comes a new set of communication challenges! This allows the business to see the features as they become available, not just in one big chunk at the end of the sprint.

So the videos have helped this greatly. They have also been a great laugh to create and they are brining out the creative juices in the team. Not only are they experimenting with new video techniques but they are also working hard to communicate the right messages to the right audience, which is a great skill to have.

The only constraint we’ve currently set is that the videos shouldn’t take more than one hour to make. Ideally they will take just 30 mins or less, but some of the features are tricky to explain. We’ll see how it goes. Like most things here we are constantly tweaking and optimising.

Posted in People and RecruitingSoftware Testing

Quite often I hear presentations and discussions from testers who talk about those moments when they feel it appropriate to say “Ha Ha, Told You So”.

You know? Those moments when the testers advice was ignored and it all went pear shaped. Or the time a tester said the company should be testing earlier, only to find a boat load of bugs too late in the day.

Over the years I’ve heard loads of people saying “ha ha – told you so”.

Sure it’s gone pear shaped, but it’s often at these times that you are needed the most; when your skills and ability are required by the business to get software out of the door.

If all you have to say at times like this is “ha ha, told you so” then you will appear petty, annoying and arrogant.

We shouldn’t be offending people and making them resentful because a decision was made that frustrated us. We need to step up and take ownership. Step up and contribute. Step up and make a difference.

At a conference a few years back a tester was presenting on how happy she felt when the project crashed and burned because they had ignored her advice. The crowd were joining in talking about “wiping the smug look off the developer’s face” and saying things like “at their peril will they ignore the tester”. It’s poisonous, unhelpful and downright ridiculous to think like that. (I was in the minority in the room btw – I walked out with a few others who found that session just too much).

So when you hear a tester shout “ha ha told you so” as a project takes a downward spiral, offer them some constructive feedback and ask for their support. Motivate them to act, not gloat in the destruction. How is that negativity going to help the business release good software.

Releasing software is a team effort. And tester’s are a part of that team.