Every Tester needs to be an Agile Tester

An Agile Tester

My wife is one of the smartest people I know.  The only dumb thing she ever did was marry me :-).  She’s also a superb project manager, orchestrating operations that are often way too complex for me to understand.

A couple of weeks ago she was listening to a podcast about Agile project management.  After the session we talked about Agile and how we are seeing it all over the place now.  We also noted that up to now she hasn’t used Agile on any of her company’s projects.

This made me realize that some organizations today are still missing out on the Agile revolution/party/”clown-filled-parade” taking place around them.  And maybe more importantly, that some managers are misinterpreting Agile altogether and incorrectly thinking that adopting Agile principles is too complex and difficult for them and/or their teams.Agile tester- clown

Some people are taking Agile to unforeseen (and strange) places

Not everyone missed climbing on the “Agile Bandwagon”.  On the contrary, sometimes I feel like some people are taking Agile a little further than originally intended.

For example, I heard about a restaurant where they define everything from their menus, to the way the tables are arranged, and even how the waiters are dressed, based on an Agile approach.

Based on the feedback they get from their customers, they make incremental changes on a weekly basis. The team even carries out retrospective sessions where everyone (workers and external providers) can raise their concerns and ideas.

They claim that this Agile approach helps them meet the changing needs of their customers at all times.  Still, to me it sounds a little strange, but as long as it works for them who am I to complaint!

Another story I heard was about an Agile coach who was organizing (managing?) his house and kids using Scrum, Kan-Ban boards, and weekly retrospectives.

I did not get into the details of the operation, but to me this specific case crosses some parenting red lines that I’d prefer were left untouched formal structures of this type.  Then again, each of us has his or her parenting methods, so who am I to criticize this one in particular.

Applying Agile to every type of testing

Agile testing is not trivial – I even wrote about it here – but it is not rocket science either.

So that we are all on the same page, let’s review the 10 Principles of Agile Testing proposed by L. Crispin and J. Gregory in their book:

– Provide continuous feedback.
– Deliver value to the customer.
– Enable face to face communication.
– Have courage.
– Keep it simple.
– Practice continuous improvement.
– Respond to change.
– Self-organize.
– Focus on people.
– Enjoy (this one is optional…)

When you look at these principles, it is easy to see that regardless of the methodology (or lack of methodology!) followed by your development team you can still choose to manage your testing process and team based on an Agile approach.

To be a little more concrete let’s focus on a handful of these principles.

 1.  Deliver value to the customer

This one is, in my opinion, the most important point: The focus of the Agile tester is on delivering value to his customers – or better said, to the people he is working to serve.

Wait a minute…  SERVE???  Yes, testing is best defined as a service – a service that provides visibility into the status of the product under development and the process being used to develop it.

If this is the case, then who is this service for? Who are its customers??

Of course in the end the customer is the “End-User”.  All the company’s work is for the end user.  But our specific service (testing and visibility) is first and foremost for our internal customers:  the development team, the product management team, the company’s executive team, etc.

A good (Agile) tester should always know who his customers are and what they’re looking to gain from the testing service.

If your development team is currently working on a specific and dangerous feature, and the best testing value is to provide them feedback on it (instead of running a regression load test), then go and test the feature and provide them the feedback (and the value) they require.

If your executive team needs to get visibility into the process (for example, the number of bugs being volleyed back and forth between the QA and the development teams) then make sure to provide the information and the value.

If in order for the product to be delivered on time you need to run the load tests NOW (because there won’t be enough time to fix bugs later) then make sure to run those tests and provide the value.

In short, when you work based on Agile Testing you need to understand your customers and their needs, and run the tests that best provides the value they require.

2.  Respond to change

Can you predict the future?  I guess not.

Are you able to plan what you and your team will be doing 7 months from now?  Unless you replied YES to the question above then I think the answer will also be NO.

If this is the case, why do you try planning ahead your testing schedules in detail four, seven or twelve months in advance?

It is good to have a list of operations and tests that need to be done (e.g. tests for each feature, regression testing, load testing, Alpha, Beta, etc). You should also have constraints for this tasks-list, and using these constraints have a general idea of what tests and operations should be done around specific timelines.

But trying to schedule the work of each member of your team on a weekly (or daily?!) basis many months in advance is not only useless but in many ways also absurd.

It’s better to have the ability to respond to change, to be flexible and to accommodate (embrace!) the changing reality of your project.

For example when a feature is introduced late, or when part of the development takes longer to achieve, then make sure you have the capacity to adapt and schedule your work based on these changes.

3.  Keep it simple

There are always a number of ways to carry out any operation.  If so, why not stick to the simplest?

This principle should be written on the walls of QA managers and testers offices who always respond to requests to change their work plans (see point 2!) with the phrase: “you don’t understand, it’s more complicated than you think…”

IS IT REALLY SO COMPLICATED???  Or are we making it more complicated because we don’t know how to be flexible?

I suggest you try it next time someone comes to you with a simple idea that can make a big change.  Instead of explaining why it is flawed, take the main points of this idea and look for simple ways to implement them.

The principle of keeping things simple usually starts with simplifying your mind-set.

4. Practice continuous improvement

It’s not enough to respond to change and to keep things simple.  As an (Agile) tester you should constantly learn from your experience, and change your ways based on the positive and negative results of your actions.

The best way to do this is by collecting inputs from your team and your customers (both internal and external).

In practice this is as simple as setting up a weekly or bi-weekly retrospective session – 10 to 15 minutes where everyone can share their ideas and concerns.

If you work with flexibiliy and responding to change (again, see point 2!), you will be able to implement  and validate these improvements right away

Agile is an approach and not a methodology

If you’ve made it all the way here and didn’t stop reading around point two then you already deserve my professional respect 🙂

I also hope you realize that Agile, in general, and Agile Testing, in particular, is not really a methodology, but an approach to managing the process of your testing team.

As such, you can use this approach regardless of, or even in accordance with, any approach (or methodology) used by your development team (customers) and your product management team (customers) to manage the project.

Agile tester- now/ later traffic sign

What do you think?  Ready to give it a try???

 

(*Images by FreeDigitalPhotos.net)

,

9 Responses to Every Tester needs to be an Agile Tester

  1. Kuznetsova Victoria August 13, 2012 at 8:09 pm #

    Hi, Joel! Nice post. 🙂
    I have only one question:
    “But trying to schedule the work of each member of your team on a weekly (or daily?!) basis many months in advance is not only useless but in many ways also absurd.”
    Does someone really do this?!

  2. joelmonte August 14, 2012 at 2:48 pm #

    Depending on the place you work it may even be required of you.  
    I used to work in a place where a project would last 12-15 months and we were required to have up-to-date Gantt charts for each of our employees that included vacation times, holidays and buffers for sickness (based on the season). Needless to say it was a complete waste of management time, but our PMs still required us to update our Gantts so that they could generate their incorporate Project Plans for the executive team.

  3. Kuznetsova Victoria August 14, 2012 at 11:11 pm #

    Wow… I actually thought you were exaggerating. I can get why PMs want to have plans for few mongths ahead, but it’s usually rough plans (like “this mongth we release feature 1 and 2, then we work on feature 3 and by December we have to release feature 5”), not actual week-by-week tables of what each member of a team should do. What a crazy world!

  4. Thanh Huynh August 16, 2012 at 8:20 am #

    Hi Joel,

    Nice post!

    Btw, how feasible you think it is if besides main Scrum (with Dev and QA), we (QA team) have something like sub-Scrum for our QA team (e.g. organize QA tasks into Backlogs, Efforts; having Review/Planning/Retrospective)?…The thing is that QA team has various tasks and some of them there’s nothing to do with Dev team and Dev team are not so happy to count such testing efforts into their Scrum.

    Thanks,
    Thanh

  5. joelmonte August 16, 2012 at 8:33 am #

    Hi Thanh,

    This is a good question, because unlike development the QA team does have to ware multiple hats as part of his “organizational duties”, so how do you manage that?I imagine there are many approaches to that, but the one I’ve used successfully is to define capacity of the QA for each Sprint for each one of the teams or projects you are working for.So for example if you think you need to do maintenance work on your tests that is not related to the tasks you are doing with development you can say that for the present sprint you will invest only 85% of your capacity (or resource-time) on the tasks related to the development scrum and the other 15% will go to other tasks.This needs to be done with the understanding of higher management, and based on the understanding that even-though your tasks do not contribute directly to the efforts of the development, they are important and required to the benefit of the whole company.  If this is not the case then you should re-think whether these tasks are worth investing your time…Cheers,-joel

  6. Thanh Huynh August 16, 2012 at 11:34 am #

    Hi Joel,

    Thanks for your reply. Your suggest ideas is excellent but I think it’s my bad for not putting more context information before. My context is that my “other tasks” (weekly regression, analyze and investigate system, etc) has 5 times capacity than “in-Scrum tasks” (new feature testing). Actually, we have tried such QA scrum for a few sprints and it somehow works (but I have to admit that I’m following Scrumbut :-))

    Thanks again and have a good day.

    Regards,
    Thanh

  7. joelmonte August 16, 2012 at 3:21 pm #

    Yup, sounds like scrumbut to me 🙂

    I would recommend prioritizing some of your “other tasks”.

    As a rule of thumb, if it takes more time to get dressed for dinner than it does to have dinner then you may want to check your process…

Trackbacks/Pingbacks

  1. Five Blogs – 11 Augustus 2012 « 5blogs - August 11, 2012

    […] Every Tester needs to be an Agile Tester Written by: Joel Montvelisky […]

  2. 5 simple tips to keep testing simple | QA Intelligence - a QABlog - September 20, 2012

    […] any services organization is always about juggling tasks (and yes, testing is a service).  You have many things that need to be done and only a small number of resources to do them.  No […]

Leave a Reply

Shares