Monthly Archives: September 2017

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

What does my exploratory testing look like?  I have tried a few different approaches to it and my ‘process’ around it continues to develop and change as I try new things, but right now it looks something like this.

Starting

When I start testing a new feature I first do a reconnaissance session where I just try it out and see what it does and how it works and what ways I can gather more information about it (logs generated etc.).  By this point hopefully I have had a conversation with the developer and I have pretty good idea of what is involved in this feature.

Often during this first session I will find a few issues and many times while chasing down those bugs I end up in a ‘bug rabbit hole’ where I find new issues while trying to explore around an issue to reproduce it.  To help me find my way back out of the hole, I leave myself little signpost along the way in the form of notes jotted down in my notebook about where I branched.  Basically these are very short reminders to myself that there was a goal I was after which I had been distracted from.  This way I can make sure to come back later and continue on to that original goal.

Tracking

At this point, I’ll have a decent idea of what is involved in the feature and I’ll make up a list in a spreadsheet of a bunch of test ideas that I want to consider. For me this list is made up of short phrases that range from a couple words to a sentence or two that serve as indicators of the kinds of things we need to dig into or think of as we test this.  I’ve started doing this in a spreadsheet rather a mind map or some other format as this seems to be the easiest way to collaborate on the testing.  Often the developer and other testers will be pulled in to work on or discuss the testing and using an online spreadsheet makes it easy to track who is looking at what and what kinds of things have been found and discussed.

Documenting

In terms of tracking or recording my exploratory testing, I usually write down a few notes and comments on the kinds of things I’ve tested and those together with the test ideas make up the documentation of the testing performed.  I than add this information as a test case in the user story for this feature and go through the required QA procedures from there.

Comparisons

I know other people will take a more rigorous session based test management approach to exploratory testing and some will approach it with mind maps or do more planning up front. I have tried different approaches over the years but I don’t worry too much about what other people do for their testing except as things I might experiment with, because at the end of the day my approach has to be something that works well for me in making me an effective tester.

What works for you?  How do you explore the product?

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

Reflect on the Agile manifesto and it’s implication for my role.  Today’s challenge strikes me as being approachable from a couple of different perspectives.  I could look at it in terms of how the manifesto affects my day to day work, or I could look at it from the perspective of how it ought to affect my day to day work, or I could even look at it from the perspective of how the manifesto affects testing as an industry or how well my company as a whole does at following the principles.

For the purposes of this article, I’ll be primarily thinking about this in terms of how it ought to affect my work.  What implication does the manifesto hold that go against some of the things I’m doing right now and is there anything I can do to change?  What things do I do that align well with the ideas in the agile manifesto?

Individuals and Interactions over Processes and Tools

How well do I do this?  In some ways I score high on this one. I really value individuals and interactions and I certainly value them over processes.  I probably even at times shift to far away from processes.  But tools?  I love my tools! To be honest, I don’t think the manifesto is implying we shouldn’t have tools, but I must confess that sometimes I am too quick to turn to a tool when the job could (or should) have been more easily done through interaction.  I guess in some ways I also score low on this one.

I do well in valuing individuals and interactions over processes, but I need to continue to grow in having my response to seeing a problem be about how we can solve the problem instead of how I can solve it. I like to strap on my tool belt and get down to business, but without collaboration, am I really following agile principles and (more importantly) am I really being as effective as I could be?

Working Software over Comprehensive Documentation

I very much value working software (what tester doesn’t?) and I’m not a documentation kind of guy.  I dislike exhaustive test cases – they feel wasteful to me. I’d much rather do the testing (and record notes on it) then write about the testing I’m going to do. I think this principle does guide a lot of what I do in my day to day testing.  Do what I can to get working software and figure out what level of documentation is necessary for effective communication.

Customer Collaboration over Contract Negotiation

I’m not sure how much this one applies to me.  I don’t have a lot of direct customer interaction, either to collaborate or negotiate.  I would think that I’d value the former over the later but I don’t have a lot of experience in either realm, so I’m going to move on to the next one.

Responding to Change over Following a Plan

I like having plans in place, but I think I’m pretty good at ‘rolling with the punches’ so I guess this one is pretty good.  In my own personal life, I’ve actually had to shift a bit more towards having plans in place so that the tides of change didn’t just push me around. In thinking about this, my personality is probably such that I might even take the responding to change thing a bit to far at times.  Sometime having the discipline to stick with something for a while longer, rather than changing plans or directions will get better results in the long run.

Conclusion

So in reflecting on the Agile Manifesto, in my own estimation, I came out better than I would have thought going into the process.  I guess my values align pretty well with the agile philosophy.  I just need to keep working on putting it into practice and working with those on my teams to become more ‘agile.’

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

Today’s challenge asks us to watch a Youtube video about agile testing.  I choose to watch this one about the role of the tester in the agile life-cycle.  The video gives a bit of an overview of what a software development life-cycle looks like as compared to a more waterfall approach.   He then goes on to talk about some of the ways that testers can and do participate in the agile process.

He talked about 6 main things that testers do in agile testing

1. They are the voice of the customer
2. They add focus
3. They help facilitate clarification of software expectations
4. They are always testing
5. They help find bugs early and fast
6. They help make sure automation is a continuous process

There were some good foundational points here.  I don’t think there was anything too earth shattering for me, but it was still a helpful quick overview.

That’s it for today folks. See you tomorrow for the next challenge in the series.

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

Ok, in yesterday’s post most of the work for me was deferred as I have an entire book to read (I’m making good progress on it and should have insights to share).  For today the challenge is to write down in some way what I think Agile testing is. I actually found this very difficult to do, because the short answer is that Agile testing is just testing and to define what testing is, is not an easy job.  But I’ll give it my best shot.

What is testing?

Before considering what Agile testing is, I want to first take the more general question of what is testing?  Obviously the answer to that is going to vary from person to person, and for me testing is not something that can be encapsulated into one succinct sentence.  I think there are a few different aspects of testing we need to consider:

What is the purpose of testing?

Why do we test?  That question has helped me define what I think testing is.  Why do I test – what is it that my company is paying me for?  What value do I bring to the team and to the company as a whole?  I think the perception is that we have hired testers so that we can reduce the risk of releasing poor quality products.  In that way you could think of the role of the tester as helping teams ship better quality products.  One definition I really like is Brent Jensen’s view that a tester’s job is to accelerate the achievement of shippable quality. If I was going to try and define testing in one sentence that would probably be it.  We do whatever it takes to help get the product to a shippable level of quality as quickly as possible.

What does a tester do?

But what is involved in doing that?  What kind of things does a tester actually do?  Well I don’t know about you, but I do many many different things.  I write automated tests.  I do exploratory testing.  I set up virtual machines so I can run automation.  I put together build scripts. I work with developers to identify the testing they need to do on their changes. I debug failing regression tests.  I file bugs.  Sometimes I even fix bugs. I push developers for a better understanding of the product.  I question things.  I ask why?  I spend time thinking about how to improve the way we work. I teach and coach others. I propose changes to our processes. In short, I do anything I can that I believe will help us release good quality code more quickly.

What distinguishes Agile testing for other forms of testing?

So is that agile testing?  Is there anything that would be different in the above description if we were add the descriptor ‘agile’ in front of it?  Fundamentally I don’t think so. It is true that the emphasis on the kinds of things you do in your day to day work will change if you were working in an agile context, but that will also change as you move between two departments in the same company. At the end of the day you’ll be doing whatever it takes to get to shippable quality more quickly.  The day to day work that you end up doing will look different and have a different shape to it, but that is because helping achieve shippable quality is a context dependent activity.  This is exactly why it is so hard to define what a tester is and does.  We do what it takes to improve things in the context we are in.  Will that look different in an agile context as compared to a more waterfall approach?  Yes of course! But at the same time the fundamentals of what makes up good testing will stay the same.

Conclusion

So I guess to conclude this, to me agile testing is just testing.  The particular details of what a team needs in order to get to shippable quality more quickly will vary from team to team and process to process, but the core work of identifying quality risks and quality blockers will remain the same.  A good tester will do things differently in an agile context than in some other context, but that is because a good tester will be about doing what it takes to get done what needs to be done.