“I am an Agile Tester” article

I have been actively recruiting to find agile testers for over a year now at different companies I have worked for.  This has been a very hard position to fill.  As part of the recruiting process, I had to come up with a job description for an agile tester.  Not a trivial task J  So, I was very excited to see an article through StickyMinds.com called “I am an Agile Tester.  And this is Why” by Erik Boelen. 

All in all, I think Mr. Boelen covered a pretty good checklist for what makes an agile tester (especially from the soft-skill perspective).  His checklist was the following: 

1.    I love my customer

2.    I work in a very structured way

3.    I adore unconventional test tools

4.    I communicate from an open position

5.    I am a VIP in my project team, just like the others

6.    I don’t spend time ‘covering my ass’

7.    I know my boundaries

8.    I am a tester 

On his list, my favorite item was #6.  I have never really thought about that before but it is so true.  I have wasted hours of my life on traditional software projects playing the CYA game.  However, since I have moved to agile projects, I don’t waste time doing this any more.  It is so refreshing!  Instead, the entire team works together to get things done.  No one is blaming others, we aren’t ‘signing off’ on documents to prove anything, and we aren’t wasting time documenting things to protect ourselves. 

I do think that Mr. Boelen missed one crucial item on his checklist, though.  I would add the following:         

I love to automate tests. 

Agile testers should embrace, practice, and live test automation.  Without it, your projects will never become truly agile.

Advertisements

Software Testers: Have we become our own worst enemy?

More and more companies are either switching to agile practices or talking about switching to them.  Agile development highlights high-quality software delivery and yet the testing community seems to be the most resistant to adopting agile.  Have the qualities that make us great software testers become our own worst enemy when it comes to adopting agile practices?

I recently attended the Agile2007 conference in Washington DC.  I went to almost all of the testing focused talks and tutorials and as the week wore on, I came to an interesting yet disturbing realization.  After listening to dozens of testers ask questions during presentations, I realized that Software Testers, QA analysts, QA engineers, or whatever your team calls them have become their own worst enemy.  What gives me the right to say this?  I am a software tester and have been one for over 10 years.  I know how testers think and why we are the way we are. 

Agile development is all the rage these days.  If your company isn’t currently trying it out in one way, shape, or form then chances are that someone is talking about it.  After attending several sessions at the agile conference (and talking to dozens of testers there), the testing community seems to be the one that is resisting agile practices the most!  What really shocks me about this is that we (the testers) have the most to gain from good agile practices!  Agile focuses on high quality.  So, why are we resisting this so much?   

Let’s start by taking a look into the mind of a tester.  Testing is not just a skill set, but it really is a way of thinking.  Some people would even go so far as to say it is a way of life.  We generally have a “guilty until proven innocent” mentality.  When we are given code to test, the first thing we want to do is to prove that it doesn’t work.  That is our job.  That is why we get a paycheck.  That is why we come to work every day.  We are hired and paid to break things.  So, it is no surprise that when a new process (Scrum, XP, etc) is introduced, our first inclination as testers is to “break” the process.  We start looking for all of the ways that the process will fail and try to find defects in it.  We immediately assume (whether we realize it or not) that we don’t trust that the process has really been unit tested well and it is therefore our job to find all of the issues and challenges with it.   

So, all of you testers out there, I challenge you to change your way of thinking for a few minutes.  Instead of immediately trying to “break” agile practices, I challenge you to first analyze the process you are using today and list out the defects with it.  Here is a quick list of the typical “defects” that testers complain about on software projects: 

1.     We are never invited to meetings early in the project to discuss requirements, design, etc.  We have no input into what is being built so we have a hard time creating test plans.

2.     By the time we start testing, the requirements have changed 10 times and no one has told us.  So, we have no idea what we are testing anymore and our test plans are not valid.

3.     We have no idea what development is doing when they are coding and code is “thrown over the wall” for us to test.

4.     We never have the amount of time we need to test.  If development delivers late, then we don’t get to push out our testing time.

5.     The code we get from developers is really hard to automate and is of poor quality.

6.     We feel the full burden of quality.  If we miss a bug, everyone will blame QA! 

How does agile solve these issues?  The beauty of agile development (when done correctly) is that it puts quality first every step of the way.  This sounds like a testers dream come true, doesn’t it? 

Let’s take a closer look at the 6 problems listed above and how good agile practices help solve these issues: 

1.     Agile is all about including the entire team in release planning, iteration planning, estimation, etc.  Testers are involved upfront and in every step of the way.  If priorities change, the entire team knows about it, including the testers.

2.     Agile promotes test first activities.  On good agile teams, the acceptance tests are written before development even starts.  The entire team sees the tests and agrees that they need to pass in order for that story to be considered “done.”   

3.     The tests are written first, so the testers always know what the developers are doing – they are writing code to make the tests pass!  The testers and developers are sitting side by side working as a team to ensure the tests are passing.  There are no walls on agile teams….just constant collaboration and communication.

4.     In agile teams, nothing is considered “done” until it has passed the acceptance tests.  Therefore, developers don’t talk about being “done” until the tests pass.  We don’t discuss design complete, coding complete, and testing complete.  Nothing is done until the tests pass and that is what matters.

5.     The developers know what the tests are before they start coding.  This encourages them to build code that can be automated easily.  Their focus is to build code that makes the tests pass.

6.     It the entire team’s responsibility to drive stories to completion with all tests passing.  The entire team carries the responsibility of producing high quality software. 

So, why do testers want agile to fail?  Why in the world would we want to stay in our waterfall world full of problems when there is clearly a better, higher quality way of building and delivering software?  What are we afraid of?  I think there are 4 main reasons that make testers resist a change to agile.  Fear, accountability, skill set, and the need to be right. 

Most testers out there are afraid of the unknown.  We may not like the delivery process we are currently in but it is comfortable and we know what to expect.  Moving into the “unknown” means a loss of control.  That isn’t a happy place for testers.  We tend to fall into the Type-A, control-freak side of the spectrum.  I know this because I am one.   

Our current waterfall process gives us something to blame when we miss bugs that go into production.  We can always say, “I didn’t have enough time” or “the requirements changed and I didn’t know it” or “I couldn’t automate the tests so we didn’t have time to run them more than once.”   

We are also comfortable with our current skill set, especially if we are manual testers.  Agile testing relies heavily on test automation to be successful.  Therefore, when teams start discussing a change to agile, we hesitate to get on board because we are scared that we won’t provide value on those teams with our current skill set.  When you think about this, it is really a double standard for developers and testers.  As technology changes, we expect our developers to learn new languages, architectures, etc.  Why should we as testers be allowed to stay stagnant in our technologies and skill set?  We should constantly work to increase our skill sets to match the changing needs of the software industry, too!  Testing on an agile team is very different then testing on a waterfall team, especially if all of your testing has been manual.  Adopting good agile practices may require new skills, tools, and techniques.  Instead of pushing back, I challenge you to look at this an opportunity to beef up your skill set and learn new things.  Get engaged!     

Testers do not like to be wrong.  It is our job to ensure that what we are testing is “right.”  I believe that many testers worry that if they start championing agile practices, they will be looked at as having been “wrong” with their former processes.  I argue that learning a new process or skill doesn’t mean that the old one was wrong.  That is just as crazy as saying that old development languages were “wrong” and everyone that used them were wrong.  In reality, we were all doing what we knew to be the best at that time.  Processes and technologies improve and evolve over time.  Testers need to embrace this as much as the development community does. 

As testers, we are champions of quality at our organizations.  If you are a tester that is currently resisting a change to agile practices, I ask you to take an honest look as to why.  If you can truly say that your process has no room for quality improvement, then I would love to hear what you are doing.  You must sleep very well at night J  If not, then push yourself out of your comfort zone and take that first step.  Stop trying to “break” agile and start practicing it.