I appreciate this is annoying for people following my work and no doubt a number 1 no-no for generating a social media presence but I simply cannot get on with the wordpress publishing site. I tried forward posting from posterous (which is where I have moved to) but having two blogs identical in content is kind of pointless. As posterous auto posts to twitter, flickr and delicious it seemed the obvious choice to move to.

Thanks to all readers and those who left comments and I do hope you will find my new blog enjoyable too:

http://thesocialtester.posterous.com/

Thanks

Rob

But a good team isn't just about getting a group of genius' or 5 star employees together. It's about diversity and creativity. And this is exactly why great development teams can churn out huge amounts of software of exceptional quality. It's why some open source projects are so successful and social media collaborative projects are so exciting, interesting and productive.

It's because of people. It's because the people in the team are usually self governing, highly motivated, creative and directing their own work in line with the whole team approach. It's partly because these teams are made up of cross disciplines whose outlooks on life, work and play can be so very different.

As a manager or team builder don't be too hasty to build a team of just one discipline, gender or personality. Instead, search out the creative, individual, accommodating, communicative and motivated individuals and bring these people together irrelevant of experience. (Note: Obviously some teams require certain unique skills sets which cannot be ignored)

The interconnection of ideas, thoughts and opinions is where real learning and development takes place. It's where great ideas are born and plans are made.

Sir Ken Robinson said that "creativity is the interaction of disciplinary ways of seeing things."

Whenever I build a team I look at the team as a whole, not as individual members. I don't dictate ideas down to the team. I get them all in a room (of all levels) and we brainstorm and generate ideas together, as a unit.

It's this team work that generates ideas, plans, actions and a team unification that is so often missing from many test teams. If you can include programmers as well, then you are on to a winner.

Creativity is a core fundamental in software testing. How can I find more bugs? What questions can I ask the software? How can I report my findings in a way my audience will interpret them as I want them to? How can I make myself more efficient? How can I leverage Bob's skills even though he is not on my team?

So a good team is not only about the people (their skills or experience) but the teams outlook on life as well (attitude, understanding, communication skills etc). And don't become complacent, it's often the juniors who have the freshest and most interesting take on testing too………..

Posted via email from The Social Tester

The process of adopting agile for a manual tester is tricky. It's incredibly difficult and often it is the testers who offers the most resistance when teams make the move. Stories about testers being negative, throwing their toys out of the pram and generally being a bad egg are common.

And I completely understand why.

When I made the transition from traditional to agile it felt like my face was melting and my mind was bursting.

It was the toughest challenge of my career. I hated those first few weeks and wondered whether I had a role in the team or not. I was contemplating a change of career and feeling completely and utterly under valued. I hated it. I was terrified that this was the future of software testing and I didn't get on with it.

For a tester, it's not just about doing the same work in a different order or with tighter time constraints, it's about changing your outlook on testing and how you fit in to the team. It's about redefining your role (and your skills) and evolving to stay relevant. You need to do a mind shift that at first seems completely alien. A mind shift that seems so very wrong.

In the end I just let go, took the rough with the smooth and worked at seeing what all the fuss was about. And here's what I found out.

The focus of the whole team shifts to quality

• You will become the quality expert. You will no longer be the person who tests just at the end
• You may need to devise tests with little to no formal documentation…fast
• You will need to feedback your test results rapidly
• You will need to be confident, vocal, capable, responsive and communicative, often taking charge and leading on quality
• The rest of the development team will come to you for feedback to their tests and code early

You will bridge the gap between the business and the techies

• Your role should now mean you liase closely with the customer. You will need to adopt a customer satisfaction role
• You will help to define the stories and acceptance critiria – these will become your tests and guidance so your input is essential
• You will have to report finding about quality to the customer and stakeholders….fast, timely, accurately and with diplomacy

You will need to put your trust in the Product Backlog

• Traditional projects with 100 requirements often end up delivering a large percentage of that 100 but with poor quality, misunderstanding and often incomplete
• Agile projects with 100 requirements at the start *may* end up delivering only 60. But these will be complete, exactly what the customer wanted and of course, be superb quality.
• This original number of 100 may grow and shrink with changing markets and business decisions. Trust the backlog.
• The customer will define and decide the next sprint of work for your team.
• You will simply advise, manage expectations and communicate
• This is a tough one – letting the customer decide what to do next….
• You will need to consider the longer term and bigger picture, but your main focus is the sprint in hand

You will need to increase your exploration and automation

• You will need to replace the tedious, checklist type manual tests with automation if possible.
• Your regression suite will get too large unless you make the most of automation and get the basics covered.
• The only other option is to hire a load of undervalued and demotivated testers to simply 'checklist' basic functionality.
• Your automation should be integrated with the continous integration and automated build deployments.
• This constant quality feedback is key to success as it allows you more time to do exploratory testing.
• It also gives you added confidence in your new features.
• http://blogs.imeta.co.uk/RLambert/archive/2009/01/15/selenium-tfs-and-agile.aspx
• Elisabeth Hendrickson summed up agile testing very nicely indeed (taken from her ruminations blog – http://testobsessed.com/):
• Checking and Exploring yield different kinds of information.
• Checking tells us how well an implementation meets explicit expectations.
• Exploring reveals the unintended consequences of meeting the explicitly defined expectations and gives us a way to uncovers implicit expectations. (Systems can work exactly as specified and still represent a catastrophic failure, or PR nightmare._
• "Checking: verifying explicit, concrete expectations"
• "Exploring: discovering the capabilities, limitations, and risks in the emerging system"
• A negative side effect of increased exploration is how you go about managing the test information.
• Most mainstream test tools don't support exploratory testing recording and the agile process tools are just as poor.
•  An idea might be to use Guidance Level Test Ideas in a traditional tool (http://pac-testing.blogspot.com/2009/03/normal-0-false-false-false-en-gb-x-none.html), notepad, various session tools or write your own tool.
• Excel is also often overlooked.

You will need to drop the concept of test case preparation and spec analysis

• It's unlikely you will get a detailed spec.
• The acceptance criteria become your test cases and design.
• The software becomes the UI design.
• As you test and develop, fine tune it and get it right.
• There's no way your upfront design will be 100% accurate (http://parlezuml.com/blog/?postid=760).
• Use wireframes if you must mock. http://www.balsamiq.com/ is awesome for this.
• If you must write a test plan, plan for the sprint only.
• Don't assume you know how or what you will be testing in three sprints time.
• Prepare to be dynamic in your tool selection, approach and thinking to testing. You may need to change your tools to cater for new information.
• Don't be too prescriptive.
• Add a quality toolsmith to your team. They will save you a fortune in the long run.
• Invest time in researching free, open source or cheap tools.
• The more tools you know of, the more likely you will be able to respond to changes.
• Don't even consider what are supposedly Best Practices.
• Do what is right for your team, on that project and at that moment in time.
• Trust me, letting the stories and software guide the UI and design is a revelation. It's just tricky changing your mindset to accept this.

You will need to get over the defect stats and metrics complexion

• Working software is fundamental. It's what the end goal is.
• Each sprint you aim to deliver releasable standard software that meets the acceptance criteria.
• So along the way there is less emphasis on raising and recording every single defect in a tracking system.
• It's more about shouting over to the programmer and getting it sorted between you.
• Look at low tech dashboards as a way of reporting metrics
• Defects that relate to the acceptance criteria and story under test mean the story is not done (even if it has been coded and the programmer has moved to a new story).
• Defects are no longer used to cover our backsides or blame other people.
• Defects that aren't related to the story should be on the backlog, where the customer can prioritise.
• After all a defect is a piece of functionality that either exists and shouldn't or doesn't exist and should.
• Let the customer decide what to do with them.
• They may be less/more important to the customer than you think.
• If you truly must report then this needs to be done in the lightest way possible. And my guess is, that if you really are having to report each and every defect encountered along with test case metrics and stats in a formal way then someone in the process/system has not truly bought in to agile.
• Note: I'm not saying be slack with defect tracking and reporting.
• Far from it, if you need to put a defect on the backlog for the customer then you need to consider how you will describe this successfully for that audience.
• When shouting to the programmer it's often easier as you can show them the defect in action. 
• The people you report to, the information you report and the way you report it changes.

After getting my head around these differences and new concepts I noticed a few unexpected side effects;

• I was re-ignited with my passion for software testing
• I was being consulted far more on quality issues meaning I spent less time complaining and raising obvious bugs after the software was dropped
• I started to use my creativity and critical thinking in a rapid and responsive way, rather than testing a spec and thinking of a few edge cases up front.
• I was being engaged and used for my creativity, skill and critical thinking
• I started to work in teams where the whole team valued quality rather than an 'over the wall' mentality.
• I noticed that the customers were far happier with the process. They were getting to control the focus of the work and ending up with software that meets their needs at that moment in time, not the software they thought they wanted 6 months ago
• I lost a huge amount of negativity and became more positive, motivated and accomodating.
• I spent far less time sitting around after raising a barrel load of defects.
• I no longer waited for the triage, fix, build inclusion, release, retest, close.
• I got them fixed asap, released asap and retested asap.
• My job didn't feel futile. I felt I was adding value.

Now I know there are people with frustrations with agile and there will be teething problems and issues for all new teams. And agile really may not be suitable for all types of work, but there are certainly some awesome principles and techniques we can all learn from agile.

If you have any agile testing stories to share then please let me know in the comments.

Posted via email from The Social Tester

It’s a shame, but I shall not be put off and intend to fully go ahead with next months meeting.

Remember – last wednesday of the month.

Rob..

However, 99%* of the responses always centre around the following items:

1. The format of the actual document (word, font size, font, sections)
2. The entry and exit criteria plus other quality gates
3. The test environment, platform and stack (or lab)
4. The automation strategy and tools to be used

And I guess this is fair enough. If you are asked to write a strategy then these would be great topics to think about. Most people probably download the IEEEIEIEISIIIEISISTIEEEEE 8.4.4.4.2..21.3.21.1.2 template – or whatever it is. They butcher it for months and then sit back and relax. I know they do, because they admit it. I even used to do that myself. ‘A work of art’ – that’s what I called a test strategy once.

But over the years the one very real lesson I have learnt is that the best Test Plan or Strategy in the entire world, begins and ends with the people in your team.

It’s not about the mega framework of doom or the uber gating criteria of ruin that you’ve documented on 8000 trees. It’s not about the test environment or tools you use. It’s about people. The greatest plan is the one that covers the following items:

1. Who is on the team
2. What skills these team members bring to the project and how they complement each other
3. Understand what skills are lacking from my existing mix of people and understand how am I going to get this skill (learning, bringing someone with the skill, or working around it somehow). <– Thanks to Joel Montvelisky for this addition (http://qablog.practitest.com/)
4. How the team communicate
5. How the team are awesome, motivated, passionate, dedicated, confident and self assured in what they do.

And that’s all you need. Because if you have a team that meet all of the above four points, you will succeed in any environment. With or without test plans and strategies.

After all, how many of us have created a mega framework of doom test strategy, had it reviewed, had it signed off and then broken a fundamental gating rule on the first release to test? Everyone say ‘yeah’.

So before you consider the mega framework of doom approach, think carefully about the team you have on board. The right team don’t need wooden plans and strategies, documents and pointless plans. What they need is some software to kick, some requirements to soak up and some customers to please.

*Statistics may have been made up. But then 30% of people know that.

(EXCEPTION: Before the comments fill up with abuse about how we *have* to produce these mega frameworks of doom I thought I would acknowledge that under some circumstance you are required to write test plans outlining key information – but even these documents should be dedicated to the people and how they can solve a problem. Not the tools. A tool in the wrong hand is lethal.)

I’ve received a fair amount of feedback, mostly negative to be fair. Most of it directed to waterfall and how many companies are making it work well. How they can automate their entire backlog of tests and continue to write new test cases, meet project demands and please stakeholders.

Well, that is all cool with me. I’m just saying that if most teams were to perform a little Kaizen they’d soon see where they could improve things. But my main point is that there will be NO escaping collaborative, social media. It’s taking over the internet, the intranet, the mobile phone and is increasingly becoming the main place to find new information.

The number of blog postings by my test gurus is down, but their tweet count is up. Email providers are finding new ways to integrate chat and video conferencing to their web products. There are new social meeting places created each day. Browsers are integrating to social media tools and apps and society is slowly, but surely, moving its way to online collaboration.

So what I thought I would do for the next few blogs is take a few of the reasons and high level statements I made in my social media blog and expand them here. After all, I’m a social tester.

Reason 1 – Point Blank Testing

Point Blank Testing is a term I’ve given to testers who are working on social media products. There are testers working on Facebook, MySpace, Bebo and any other of the social media meeting places. There are people testing Twitter. In fact, many of the testers who use twitter to communicate actively try and find the breaks, and openly record them in twitter.

There are people testing chat rooms, VoIP systems, email systems, video conferencing tools, internal communication tools and video/music streaming systems. These social media sites and tools are out there and being used. But most importantly, they are being tested (at some level).

These very systems and concepts are making their way in to mainstream applications and ‘traditional’ systems too. Collaboration is proving to be a very cost effective way of solving problems.

As the digital native enter the workforce (muted to be this very year) there will be an increase in velocity of social media take-up. Businesses that don’t embrace social collaboration will find they can’t attract the latest talent. They will miss out. They will cease to be relevant. So tools and concepts will need to evolve and someone will need to test them.

If you’ve been working on a social media tool feel free to leave a comment about your experiences.

Rob..

http://www.cityofsound.com/blog/2008/02/the-street-as-p.html

It’s one of those really great articles that makes you think about the way society and our technology is moving. Sure, some of the ideas are already here and in use, but there are some concepts that are yet to be available.

When I read these great articles I’m always thinking about the following three questions:

1. How would I go about testing this stuff?

2. Would I *need* to test this stuff?

3. Could I imagine myself working in these environments?

It’s an ever changing world that we are living in and I for one am quite excited to be a tester right now.

Rob..