Firefox’s add-ons are proving invaluable to me as a web tester but there are also some awesome tools for improving the efficiency of everyday tasks too. I’ve compiled my favourite Firefox Add-ons here (in no particular order).
I’m in the process of putting together a fun little eBook consisting of a collection of sticky notes from testers around the globe.
The simple premise is that each sticky note contains a personal response to the following question:
“Why do you enjoy software testing?”
Although the eBook will offer no quantitative measurement of testing prowess, knowledge or skill, it may enlighten us as to what gets testers out of bed in the morning….
And even if it doesn’t do that, at least it will add a little bit of visual testing fun to our testing world.
If you want to take part do the following:
1. Write down your answer to “Why do you enjoy software testing?” on a paper sticky note
(Post-it note or whatever you personally call them – http://en.wikipedia.org/wiki/Post-it_note).
Your answer can be as long or short as you like.
If you don’t enjoy testing then let me know that too.
One submission per person.
A fair few years ago I encountered a story about an environment where “bean counting” was priority.
testers should produce X number of tests per day.
testers should be raising X number of defects per month
Monthly prize awarded for most defects raised
No exploratory testing – no time for it – no need for it – test cases in advance was the norm
Test cases must have X number of steps irrelevant of complexity or feature set or skill set of tester
Step by step test cases only – no vagueness or open ended questions. Must have expected outcomes for each step. Nothing should be left to the tester to think about
No data extraction to central repository meaning test cases were a maintenance nightmare.
Detailed test plans up front and then ignored by whole team
Detailed resource scheduling months in advance – no contingency and all staff working 100% capacity
Staff treated as resources rather than people
I’m sure this sounds familiar to most testers. It’s certainly a common discussion point on most testing forums.
At this work environment there was a lot of negativity. The atmosphere reeked with contempt, finger pointing and blame. There was a lot of tick boxing just to meet quotas. Random checks of “passed” test cases revealed several defects that were not found. Was the test really run?
People were raising multiple defect reports for the same issue but in all the different flavours they showed (like operating systems, locales) just to raise their totals. Don’t forget, there was a prize available for the most defects raised, regardless of how sensible they were. 62 individual reports for one issue was the record. A one minute, one line code fix solved all 62 issues. Oh and yes, there was also a prize for most defects resolved by the programmers.
Then something strange happened. Through no serious planning or collaboration some test leads (and their teams) started flying below the radar. Doing things the best way (to them and their team), not the corporate way.
They continued providing the metrics needed for the managers but let their teams “just get on with it”. So they prepared shells of test cases as guidance and to report metrics on, but encouraged exploration and learning. After all, one of the most difficult challenges facing the team was the lack of communication between departments and the use of bad specs. So they explored and wrote tests during the testing. Constantly learning about the system. Constantly fine tuning the process.
They started to automate the tedious processes and the deployments to test. All off the record of course. Within about 3 weeks the “off the record” teams were motivated, dedicated and passionate about testing. They were also working fast, but disciplined. They were creating their own structure.
They were, as the agile world would call them, self organising, even though this was waterfall through and through. They had automated huge amounts of tedious regression freeing up time for more interesting exploration and scripting.
All the time they ticked boxes to appease management. All the time they flew below the radar. All the time the Test Leads risked the wrath.
Instead of pandering to the enforced corporate structure they instead created their own environments and worked to their own strengths and weaknesses.
More importantly though, they started to have fun doing their jobs. They started to find meaning in what they were doing. It made sense and it provided interest. It was now a meaningful job. When something is meaningful we want to do it. We want to get out of bed in the morning. It becomes a passion for us. It is highly motivating.
Eventually the “off the record” teams were exposed and the leads were reprimanded and the teams were forced back in to the enforced structures. The leads were moved around or their roles were changed. In essence, the structure took over again. The “trouble makers” were banished from the project and watched more closely than ever before.
And then something obvious happened. The reprimanded team members started to leave, moving off to other jobs. In the space of about 2 months 25 people had left.
Despite the real success and improvements these people made the management couldn’t see the value in good software, motivated teams and rapid delivery. No reports or formal processes were being followed – so to management it was all wasted effort. Null and void in the grand scheme of delivery. Software isn’t tested unless a test case is produced. Reports and charts were more important to the management than good software. Defects don’t count if no test case rooted them out.
Also though, the management saw the testers as resources. The numbers were more important than the people. The numbers were more important than the actual end quality. The numbers were more important than the ethos, environment and vibe. The numbers were deemed to tell the full story. The numbers were mostly faked, twisted or irrelevant. The numbers were valued more than the tester creativity, enthusiasm and flow.
I’m not advocating low flying testing.
I’m also not advocating no reports or metrics. We need some of this in order to record what has happened and to give us an indication of where we are in the process. Management still need to know where we are in the grand scheme of things. But balance is needed. Balance for the good of the product, the customer and the organisation – not for the good of management who can’t see past false numbers.
In the end the test leads essentially lost their roles and ultimate this low flying ended their careers at this organisation but it also resulted in this organisation losing extremely valuable and skilled testers. It showed clearly to me that when structures and enforced constraints start to affect morale then people will go to extremes to do a good job.
More importantly, if these people fly below the radar and still can’t get the job done there will be 2 outcomes.
1 – they will leave and the organisation will lose invaluable testers.
2 – their enthusiasm and creativity will be sapped, they will stay but offer little value. Essentially the organisation still lose invaluable testers.
A good manager should be isolating teams from the corporate politics, enforced structures and metric only assessment of quality and testing. We should all be persuading those around us that the effectiveness of the tester is at risk with excessive structure in place.
A balance should be sought between providing useful indicators of testing (metrics, burndowns, defect numbers) and letting the teams just get on and do the job.
A creative, happy, empowered and proactive tester can be worth a thousand demoralised testers structured out of self thinking and creativity.
Instead of looking at how to measure, structure and enforce global testing “best practices” we should instead be empowering the team to solve the problems. We should grab the talent we trust and give them the platform to grow. And we should be standing on our soap boxes and advocating that:
I’ve been noticing posts, comments and tweets about agile recently where people are being incredibly derogatory and negative. Almost to the point where their comments are bordering on offensive. The trouble is most of these people openly admit they have never actually worked in an agile environment. So what gives?
You know what I think? I think agile scares some people. I think they worry that they won’t have a job, that their role will change so much they can’t cope and that maybe, they will be exposed as a tester who is not capable of testing. Harsh, but even a well known testing presenter (who shall remain nameless) identified that this often happened when teams make the transition to agile. The move to agile identified those who are “not so good”.
I’ve been talking a lot about agile recently because for me the turning point in my career came when I started on an agile project.
At first I hated it. Then I quite liked it. Then my passion for testing was re-ignited and I started to really thrive in an agile environment.
Agile put me back in the zone. It cut out the bureaucracy, the admin side of test artifacts and left me (and the team) in control of creating great software. And this scares many teams.
What? Us in control? Really? Are you sure? But how will we cope? What do we do when? Eh? You want us to create our own structure? Are you mad?
And hence many teams flounder, fumble and stumble back to traditional ways of working.
I remember my first agile project and the first “kick off” meeting. It was an eye opener. It terrified me. I couldn’t believe people worked this way.
Before the meeting I read the agile manifesto, I read the scrum alliance website, I read some books and I read some blogs. I didn’t understand it at first, so I rewound and read it again until my brain hurt. And I still didn’t get it. It still didn’t make much sense. Theoretically it sounded fab. In reality though, how could it work?
In that first meeting I was informed by the Tech Lead that the UI would be the design and that we don’t need to worry too much about the requirements (backlog). Seriously? No design? No planning? I believe I gave the same look my careers adviser gave me when I told him I wanted to be a ventriloquist (thanks Seinfeld for the joke). I almost choked with rage.
From that point on though it started to make sense. And more importantly, it started to really work. I started to feel passionate about delivering software again. My job felt meaningful. We rolled out software….fast (and to top notch quality).
To sum up why though, here’s four reasons why I believe adopting an agile mindset will help you re-ignite your passion for creating fab software (I also included the slide). Agile gives you:
1.Freedom for the team to choose its own framework based on theirlocal context. (team, customer, skills, experience, organisation ethos)
2.Freedom for the team to choose its own way of providing rapid and accurate feedback. (feedback to all team members as soon as possible is critical to success)
3.Freedom for the team to work to its strengths and weaknesses enabling them to inject the fun back in to software development
4.Freedom for the team to take control. No Excuses. Scary.
I’ve been doing a series of talks recently about agile being a mindset and not a methodology. At the core of the presentation (and the end talking points) are three questions:
1.At what point are you “agile”?
2.Are too many teams craving structure?
3.Is agile a methodology?
I’ve also had some feedback that the graphs and cheesecake pie sum up the current state of agile testing.
So here they are, included in this post. Let’s include some perspective on them though.
Agile is cool. No doubt.
The graph shows how the more you use the word “agile”, the cooler you become. It starts to take a downward turn the more you use the word “agile” though as you start to become a sort of freakshow if the only thing you say is “agile”.
“You want to go out for lunch?”
“hmm, ok, did you want me to grab you a sandwich?”
“right. You fancy a beer later?”
“Got anything planned for the weekend?”
“agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile, agile”
The thing is though, you’d still be cool, but only on YouTube and daytime TV.
The Pie Charts
The pie charts show agile adoption and failure within the IT industry in 2009. As we can see EVERYONE tried agile in 2009. And EVERYONE failed. At least that’s what it feels like.
The Agile Cheesecake Pie
Agile Pursuit is by far the most common behaviour I see. It’s based around the board game “Trivial Pursuit”. Playing pieces used in Trivial Pursuit are round and divided into six sections. A small, plastic wedge can be placed into each of these sections to signify when a question from a certain category has been correctly answered. – http://en.wikipedia.org/wiki/Trivial_pursuit
Instead of questions, development teams use techniques or processes that once mastered, result in a tiny piece of cheese, or pie, or cake – hence the name “cheesecake pie” being available.
Some teams are so determined to become agile that they set themselves a list of about 6 – 8 techniques they think they need to be doing. They then enter the lengthy, and often never ending game of agile pursuit, even if the process they had to start with was working fine.
They face problems, questions and queries on their way to filling their agile cheesecake pie. Only when the cheesecake pie is complete do they declare themselves agile. Ironically though, in the pursuit they loose sight of the reasons why they wanted to be agile and end up with so many techniques that they just can’t get the software out of the door. Either that or the game gets abandoned because everyone got bored…or left…or retired.
As a team relaxes about declaring themselves “agile” they actually end up gravitating towards the complete cheesecake pie as they strive to offer rapid feedback and tweak their process. (sounds painful).
After each of my talks there has been a resounding and common conclusion to the three questions I pose:
1.At what point are you “agile”?
You are agile when “you stop wondering whether you are agile and just get the job done”
2.Are too many teams craving structure?
Structure is a killer for most teams, especially in the testing world where we are used to formal documents, formal test cases and formal metrics. Making the shift is terrifying and for some it’s a step too far. But for some organsations and teams that *can* be a good thing.
3.Is agile a methodology?
Agile is not a methodology. It’s a mindset. It takes a new outlook on software development. It’s an attitude. It’s about inspecting and adapting. It’s an approach.
Let me know what you think (and no doubt there will be some interesting feedback) as comments to the blog post.