One of the things we use on the team I am currently with is something we call Use Cases.  These are documents with a list of steps to go through that check on some of the important features and workflows in the product.  I was tasked with running through some of these and as I was going through one of them, I came across an interesting comment which was highlighted and in bold. It said: ‘Don’t do action X – not supported yet.’

Perhaps one of the things that make me a good tester is my aversion to doing what I’m told, but in any case, I didn’t listen.  I tried to do X and to my surprise, I found that it worked. Although once I started poking around at it, I actually found that it mostly worked.  It seems that at some point along the way a change was put in that allowed the software to support something we were not previously supporting and we weren’t even aware of this possibility.

This is just one little example, but as I thought about it, I realized that there are probably a lot of lessons to be learned here.  I found out something entirely new about our product because I explicitly disobeyed the script.  It is not every day that we are explicitly told not to do something in a script, but if you think about it, the opposite is true of every scripted type test we have:  we are explicitly told what to do.  I found out something new, by doing what I was told not to do, but might we not also expect to find out new things by not doing what we are told to do?  The scripts that we repeat (whether manually or through automation), tell us something.  They tell us what things have been checked many times, but they also tell us by implication what things might not have been looked at (as much).  So here’s my challenge to you: Disobey your scripts.  Find out something new!


Regression Tests: A Double Edged Sword



We have a problem.  There are lots of regression tests in place and they are even automated (in parallel!) so we can run through hundreds or even thousands of tests on every build.  But we still have a problem.  You see we are in what we call the hardening phase of our release cycle and we are finding many defects.  It seems that despite the many regression tests we run, a lot of bugs still get missed.  Why is this?  With so much automation and with so many good testers working on the product, why do we still struggle with our product quality?

I was recently writing some code and – as I usually do – I wrote some unit tests first.  While writing the code I realized that I was using my unit tests to experiment with the implementation.  I had a basic idea of what my implementation would look like, but rather than work out all the details of it ahead of time, I quickly tried something that I thought might be what I needed.  I ran the tests and got some feedback on what I did wrong.  I then went back to the function, made some changes and tried again.  After a couple of repeats of this I had a working function that did what I needed it to.

However, at this point I realized something.  My function was a bit of mess.  It did what it needed to do as defined by the tests that I had in place, but it was kind of ugly and messy.  There was a lot special case handling and the function had grown a lot of bloat.  Thankfully I had the tests in place that, together with the knowledge I had gaining in the implementation, allowed me to go in and clean things up to make a much more readable and clean implementation.

Retrospecting on it afterwards, I began to wonder if having tests (even the much loved unit tests) in place aren’t a bit of a two edged sword,.  There is a lot of power to being able to experiment and learn about what you trying to do, but if you don’t leverage the information gained from that experimentation you may be in a worse place that if you didn’t have the test at all.  Thinking about it, I realized that if I hadn’t gone back in and cleaned up the code with the knowledge I had just gained through my experimentation I might have had worse code in place than if I had implemented the function without any tests written.  Knowing that I did not have a safety net in place, I would have thought through the implementation more and probably would have written a cleaner initial implementation.

I think the same things happens on a broader scale in our development.  We have many regression tests in place that create a safety net for the developers, but do we leverage the information we get from this to ‘make it work somehow’ or do we use the feedback we get to improve the underlying quality of the code we are working on?  I fear that far to often the time pressures we have in place lead to a ‘make the tests pass’ approach rather than a ‘what can we learn from this failure’ approach.  And so it is that the very thing intended to protect us can turn around and hurt us.  Now all I have to do is figure out how to better wield this regression testing sword so that it can help us get better quality code.  Should be easy right?





Getting Stuff Done


As a salaried employee I believe that I have an obligation to my employer for a certain level of productivity.  The way I look at it, I’m not getting paid for how many hours I clock in a week, I’m getting paid for how much value I can give the company.  This means I have a responsibility to be productive with my time.  There are two sides to this.  One is the idea of how much stuff you can get done in a given amount of time.  The other is figuring out if you are doing the right thing.  It is quite possible that you are very efficient at getting things done, but if you are not doing the kinds of things that add value to the company you really aren’t being productive.

On the other hand, you could be well focused on the kinds of activities that add value to the company, but working on them in a way that keeps you from efficiently getting them done.  We need both things, but in this post I want to talk about the idea of getting stuff done.  Specifically I want to talk about some of the productivity approaches and tools I have used and the kinds of things that didn’t work for me as well as some of the approaches I have found to be effective.

What didn’t work

I’ll start with some of the things I’ve tried through the years that haven’t seemed to work for me.  It is pretty easy to find ‘productivity hacks’ on the internet, but there seems to be a lot less talk about the ways some of these things don’t work for some people.  We are all different and so something that works for you might not work for me (and of course, something that didn’t work for me might just work for you).

One thing that I have tried is the pomodoro technique.  I used it for several months and there are some things I liked about it, but at the end of the day is just didn’t work for me because of the amount of time I spend on collaboration.  I think the technique would work well if you are primarily working in focused time on your own, but I am frequently stopping to answer questions and help other testers or developers, or I am asking questions of my own.  One of my goals is to see testing and development work be more closely aligned and this means an emphasis on collaboration.  I found the pomodoro technique shifted the emphasis too much to my individual work and away from a team based approach to solving the problems at hand. I have, however, been able to apply some of the thinking of this to help with my productivity.  I now schedule a deep work session each day where I have some uninterrupted time to focus on work that requires that type of thinking.  This allows me to balance out responsiveness and collaboration with thoughtfulness, introspection and deep thinking.

Another thing that has not worked out for me is using trello boards or kanban to structure my work.  I like the theory of it and I continue to try and implement the idea of limiting work in progress, but I found that it create too much ‘paperwork’ for me.  I have a strong dislike of paperwork of any sort and creating and maintaining a backlog and moving work through various stages, just felt like too much overhead for me.

What did work

There have been some things that I have found did work well for me.  The system I have found to be most helpful is summarized here. The basic gist of it is that information, communication, scheduling and task management are all different things and ought to be thought of and managed separately from each other.  While I don’t use the same set of tools, that system of thought – breaking those things out into separate tools and managing them each independently of each other – has led to a much more productive approach to life.  Fundamentally this approach to getting things done in a digital culture has transformed the way that I work.

When talking about things that worked well for me, I have to gush for a minute about todoist.  I’ve tried a number of different task management systems over the years and this one blows anything else I have tried out of the water.  It is simple and powerful, probably because it does only one thing – manage tasks. It allows you to manage your tasks in an easy and intuitive way, and best of all for me, to instantly add something as soon as I think about it.  This keeps me from forgetting things and also allows me to quickly add a task without it disrupting  the current work I am doing. And no, I was not paid to say that – this is a tool I have come to love for their disciplined approach to solving just one  problem.

Another thing that worked very well for me is the fact that I have tried many different approaches and tools.  By playing around with different ways of doing things I have been able to learn things from various systems.  I have been able to learn what things work for me, what things don’t work for me, and what things need to be tweaked and changed to work for me.  I have also been able to recognize that some things work well in some contexts and not in others.  Since there is no one size fits all approach to getting things done in knowledge work, experimentation to find out what works for me has been key.

So what kind of approaches and systems do you use in your attempts to get things done?  How do you approach that digital mountain in front of you?


Test links Thursday

Debunking Handbook -This is missing one of the key factors in changing people’s minds – trust and relationship –  but it is still a helpful way to think about more persuasive fact presentation.  Good ideas here for writing defect descriptions for example.

Disorganized Thinking and Deep Work Challenge – two different views on how to be productive.  Should you fight for focus or not? I think both of these can be applied at different times

Simple Models – Keep you models of the product simple and build a lot of them.

Testing Kraftwerk – Some other thoughts on how to build models

A Meeting Heuristic


Who doesn’t like to complain about meetings?  If your job involves creative knowledge work you probably find that meetings interrupt your flow and keep you from getting the things done that you need to.  I’ve had a long and active resistance to useless meeting and I’ve tried to vote with my feet as much as I can, but I was recently thinking about which kinds of meeting I usually find to be wasteful and I think I have come up with a heuristic for identifying wasteful meetings.

If a meeting is run on a regular schedule and the time slot is longer than 1/2 hour, the meeting is most likely wasteful

In my experience, it is often ok to have a longer meeting if it is called on an as needed basis, and it is ok to have a regularly scheduled meeting if it kept short, but as soon as you have a meeting that is both long and regularly scheduled it will end up including a lot of waste.  Team work is vitally important in knowledge work and you can’t have teamwork without meeting together.  So it is not meetings themselves that are the issue.  The main thing is understand what effective team work looks like.  When the team is too big it rapidly changes from team work  to team discussion (or worse, arguments).  If the time slot for a meeting is longer than 1/2 an hour it usually indicates that there are a lot of people in the meeting.  There are times when larger groups need to get together and have discussions, but in the day to day work of the knowledge worker those times ought not to be common.  This is why we should not have regularly scheduled meetings with big attendee list – they end up being wasteful.

What about you?  have you experienced this with meetings?  What kinds of meetings do you dread and try to get out of going to?

On Heros

You may have heard about the dangers of having a hero culture in software development.  The reason this is seen as a problem is that we don’t want to have one person on the team with a great deal of specialized knowledge.  We want to make sure that the knowledge is spread around the team and that we have people who can work in a variety of different roles and places.  I agree with this, but I think that there is still a place for heroes.

What we need is a certain kind of hero.  We don’t need the heroes who take on work so that everyone will come to depend on them.  We certainly don’t need heroes that look down on the lesser mortals on the team and will do it for you but not teach you how to do it.  What we need are old fashioned heroes.  The kind you read about or hear about from war stories.  The kind of person who jumps on a grenade for his buddies.  We need heroes that care about the team and will sacrifice themselves for the sake of the team.  We need heroes who work on reducing negative influences on the team.  We need heroes who know how to build and forge strong relationships.  We need heroes who are willing to do the dirty work and who are willing to share everything they know so that the team can succeed.

In short we need to talk about heroes as those who sacrifice for others.  In many ways superhero movies have taught us that a hero is someone who can save the world on his own, but we need to celebrate a more simple style of heroics on our teams.  The real hero isn’t the one who checks in a fix to an important bug at 2 in the morning.  The real hero is the one who stopped to to chat with the developer at 2 in the afternoon and triggered a thought process in her head that lead to the bug never showing up in the build.  The real hero is not the one who stayed late all week finishing up the new feature so that it could get shipped in time.  The real hero is the one who spent a half hour pulling the team together to explain what was going on so that the team could work together on coming up with a meaningful solution to the problem they were facing.  The heroes we want are the ways that make the team better and that you almost don’t even notice.

Do you know any heroes like this?  Do you celebrate them?  Are you one? Viva La Hero!