The Corrello Blog

Thoughts on Scrum and Agile with Trello

Month: November 2015

How much automated testing is enough automated testing?

I had been a proponent of automated testing for a long time before we really adopted it at my last company. It was one of those things people wanted to do but never felt they had the time for. When we all actually started writing tests for our code was at the start of a new project, a rewrite of an existing product. The fact that on day one we could create and maintain 100% test coverage was a strong driver in writing more tests. I knew that code coverage was an imperfect metric, but it’s so easy to track it’s natural to use it. This is, I think, the key problem with automated testing that leads people to think that 100% is what they should be aiming for. When measuring coverage is so easy, and 100% coverage of your first piece of code is possible it’s natural to try and maintain that.

I think a lot of people who haven’t really considered what tests they should write also assume 100% coverage is what they should aim for. This seems to be the default opinion people come to the question with, if they even realise that there is a question to be asked.

Why 100% test coverage is actually a bad goal

I believe you should definitely not try to write “as much automation as possible” or fall into the common trap of thinking that 100% automation is an ideal to be aimed for.

Writing automated tests takes time, running them takes time and maintaining them takes time. Imagine for the sake of argument that only 50% of your tests are useful. In this case you have wasted time writing the remaining 50%. You need to wait for the other 50% to finish executing to get the results of the useful ones. And, you need to spend time maintaining them. Most of the work in software development is in the maintenance, not in originally creating the code. Less code is a laudable aim, this also applies to your tests.

So, you may well ask, how can we decide if we’ve written enough tests for a piece of code or not? Which is lucky because that’s what I’m going to tell you next :).

How to know if you’ve written enough tests

I propose splitting your tests into four groups:

  1. Core functionality of your app. If your app is a website monitoring tool then this would probably be any alerts which need to fire if a site has problems. If these go wrong your app isn’t serving its core purpose so having automated regression tests to run on every code change makes sense.
  2. The basics (often called a smoke test). For example you could use Selenium to click all the links to navigate through a web app and make sure the server responds with a 200 for each page. Note, I don’t mean checking the content of the pages, just that you can navigate the app and it’s not obviously broken. These tests ensure any manual testers aren’t having their time (and morale) wasted with obviously broken builds.
  3. Anything fragile which is likely to break. This is hard to define for new code, but if you’re working on some legacy code which you know to be bug prone then building tests around any changes you make is a good way to build towards being able to refactor more safely.
  4. Things the developers wanted to automate because it was easy to do. Sometimes it makes sense to add tests while you’re building something, that shouldn’t be discouraged.

By structuring your test cases along the above lines, when one fails people know why it was created. If it is the test that is wrong and not the code under test they should understand why it’s important to fix the test rather than delete/disable it. Or if it’s not important to maintain, they can delete it if that’s what they want to do. Note, I would suggest explicitly laying out your code using these four categories so anyone reading it knows which group the test is in.

Code review of the tests then becomes easier as someone can look at the functionality under test and form their own opinion about the tests which should appear in each category. This is where a code coverage report is useful, a scan through that as part of a code review may show something up which you think should be tested.

You can obviously adapt the above to your own needs, but I think the categories are vague enough they would suit most teams.

Agile team? Using Trello? You should check out Corrello – Dashboards for agile teams using Trello.

How to create recurring tasks in Trello

Update: If you are looking for a simple way to create recurring tasks and whole lot of other cool automation within Trello you should check out Butler bot.

Something I’ve seen over and over again is people creating recurring tasks in Trello. There’s a joke somewhere in that last sentence. Maybe not a good one admittedly, but it was only a short sentence.

There are a couple of manual work-arounds people adopt to deal with these situations. Let’s not worry about those, because today I’m going to show you how to automate recurring tasks in Trello. There are two versions of the story I’m going to tell. Firstly, the longer one for those of you who have 5 minutes to learn how to use If This Then That (IFTTT), and secondly a quicker one for those of you who just want to get your recurring tasks set up already and aren’t interested in any of my jibber jabber! Take pity on a fool and scroll down to the bottom if that’s you.

For both you’ll need an account on IFTTT, a free service which works as a kind of magical web glue for sticking your internets together. Clear? Fear not, it will be.

The long(er) version

Get an IFTTT account (free) by clicking the signup link on their homepage, which should take you here.

They will walk you briefly through how IFTTT works. It’s pretty simple. You pick two events, a this and a that. If this happens then we want that to happen. For example:

  • If ‘the weather is sunny’ (this)
  • Tweet ‘weather looks nice, let’s all go to the beach!’ (that)

Or in our instance, if the time is 9am on a Monday create a new card in Trello. Each of those is called a recipe by IFTTT.

So now you’re logged in, click on ‘My account’ and then ‘Create a recipe’ to get started. Or, you can go here which should do the same thing. You should see something like this


IFTTT has a bunch of what they call Channels which can trigger your recipes. Click on this and you will see some of them. Now, stop looking at all the channels and idly imagining the possibilities of wiring up every service you’ve ever heard of. We know we need the time channel, so type time in the search box and select ‘Date & Time’.


You now need to choose how frequently you want to create your new Trello card. Daily? Monthly? Annually? I’m sure you can work it out, you got this far!


I’m using the “Every day of the week at” trigger which doesn’t fire every day of the week, but every day of the week which you select. Ie, every Monday or every Tuesday and Friday.


Pick the time of day you want your trigger to fire on, and the days of the week (or whatever is appropriate for the frequency you selected) and click on create trigger.


We’re half way there! Click on that and search for the Trello channel.


When you click on Trello you will need to log in to your Trello account and let IFTTT access your boards. You will then need to choose which action you want to take in Trello when the trigger fires. Luckily there’s only one action…


So let’s choose ‘Create a card’.

From there you get to set which board and list to create your card in. Choose a title and description as well as assign members, add labels and link attachments. All pretty handy.

Finally you’ll be asked to confirm your choices and create your recipe. You should end up back on your My Recipes page and see your new recipe there. Now, just sit back, relax and wait for 9am Monday morning to roll around and your new robot overlord will tell you what to do :).

The quick version

Head over to IFTTT using one of these links, depending on the frequency of your recurring task

If you’ve got an IFTTT account sign in and add the relevant recipe. If not, click the signup link and follow the instructions.

Need a dashboard to keep on top of your Trello boards? Check out Corrello – Dashboards for Agile teams using Trello

Powered by WordPress & Theme by Anders Norén