I signed up for the late June Rapid Software Testing course. Looking forward to learning a lot.
I’m closing in on completing one of my new years resolutions this weekend. That resolution was to drastically cut down the number of books in our house.
We moved in to our current house about three years ago and I think we brought in more than forty moving boxes full of books. This was all the books that I collected over many years. Many were books that I knew I would never get around to reading and they were taking up a lot of space in the garage that we could use for other purposes.
When thinking about how to approach getting rid of excess books, I thought one way to do it was to have a “budget” for the amount of books we will keep in the house. Since we had a couple of big bookcases in the bonus room I thought that a good idea would be to have that be the amount of space in the house we could allocate to store physical books. Then, I would go through all the books and only keep an amount of books that could fit on the bookshelf. If the shelf was full and I found another book I wanted to keep I would have to make a decision: which book(s) on the shelves would I get rid of to make room for the new book I wanted to keep. In the future, every new book I wanted to buy would be subject to that same decision making process. I’m now closing in on the end of going through the boxes of books. There’s about three more boxes to go through and the shelf is now full.
This process has helped a lot in accomplishing my goal. In some ways, I feel a weight lifted off of me with much fewer books but another benefit is that I think I have a sustainable method of preventing “book buildup” in the future. Another benefit is the process is a method of keeping an awareness of the consequences of some of what would in the past be “impulse buys.”
Thinking about this example it seems to me that it could be useful in a number of areas of work and life. Music and movies are a natural extension. A less direct analog that could apply at work is automated tests. In my time as a tester I’ve run into many people who are loathe to retire tests*. They keep them around even though they don’t really know what they are testing anymore. What if we applied this approach to automated tests? Set a budget for the amount of time a test suite could run in and, if you add tests to the suite that cause the suite to exceed the budget, you have a decision to make about which tests to keep and which to retire. Aside from the benefit of keeping the runtime of test suites under control, it would also incur other benefits:
- Cause prioritization of tests to make sure the ones we run are the most valuable
- Cause re-evaluation of tests to consider their continued relevance
- Cause consideration of ways to make tests more efficient in the dimension of the budget (here, time)
There are likely others.
Based on my past experience, this idea would make a number of people uncomfortable. I think that it is something that should be considered and tried. It’s been a benefit to me in accomplishing my new years resolution.
* For those in the audience that bristle at the idea of calling automated tests “tests,” please substitute the word “checks.”
…another sprint end. Today was the second sprint on my new team. I think we are making progress but there’s more progress to be made. It is only the second sprint.
Thinking about how we can “gel” more as a team…
…and I will be in a few minutes. But first a few words.
I seem to go in spurts of posting on this blog alternating with periods of no sign of activity.
I’m not really a fan of blog posts that just talk about how the blog author hasn’t posted in a long time but now they’re going to blog more often. I want to do better than that. I’m realizing that if you want to post every day you should not talk about how you’re going to post every day, or more frequently, or whatever thing you think you can do and want to do but haven’t done up until now. You should just do it and let your actions speak for themselves. So I better shut up for now…