So just over a month ago, the Ministry of Testing started a challenge called “30 days of testing” and I decided to have a go at tackling it. I had intended to actually achieve it and post all of the progress I made here but I didn’t make much progress in the end.
However, I’ve decided to post the progress anyway because I really liked this initiative and the behaviour it encouraged in the community. Even if I didn’t manage to achieve over half of the challenge, I’d like to encourage others to have a go and share the experiences anyway! If you only achieved one of the challenges, that’s still a good thing, especially if it was helping others to test.
Why didn’t I complete it?
Lame excuse time but basically it was because work and life in general got pretty busy in the second half of last month. I also made the mistake of trying to bundle some of the challenges together - so I was thinking of completing the “mind map”, “5 bugs from a mobile app”, “accessibility bug” and “user experience bug” into one but then spent ages trying to find a mobile app I’d like to explore. I should have just dived into any old app but ended up postponing it and then becoming too busy with work and life in general.
I was also keen on getting a photo of my team but due to illness or holidays I couldn’t get a good time to take a picture of everyone.
But basically I just ran out of time.
What did I achieve?
Day 1 was easy, I already had in mind some books I had been meaning to buy, so this was just an easy motivator to go buy them! I started Dear Evil Tester but I didn’t finish reading it by day 30, so I didn’t successfully complete this one, but at least I got my hands on these books! I’ve enjoyed Dear Evil Tester so far and I’m keen to get started with Explore It too! I definitely recommend both!
Day 2 needs some further explanation (which is why I wanted to write this blog post!) - one of the things I’m working on at the moment is writing some simple scripts to help speed up some aspects of our testing at work. With a shift to a microservices architecture, this provides more opportunities to test much faster at a service level, rather than always at a GUI level. So I’ve been keen to help the testers in my team get on board with this by providing some scripts to quickly generate test data and therefore allow more time to focus on testing a particular feature rather than spending time setting up data or environments in general. Funnily enough, a month after posting this tweet I am automating a bunch more stuff to try and free up more of our time away from the crazy-busy project we are on at the moment.
Day 3 was one that I was looking forward to because I had never considered listening to a podcast before. Well, I had listened to testing podcasts before, but not on any kind of regular basis. The Let’s Talk About Tests Baby! podcast caught my eye as the topic of telling stories in testing resonated with me as I’ve always felt communication is critical in testing, starting from learning a project to reporting a bug. I find myself studying the language, social interaction and psychology aspects of testing more and more lately. I liked that the podcast itself was short but thought provoking - definitely worth a listen if you’ve got a spare 15 or so minutes!
Day 4 I decided to trade blogs with a great developer at work, I didn’t like the idea of just telling someone to read a blog, I felt I should reciprocate and I like the idea of understanding what other people read too! So I shared Michael Bolton’s blog, particularly this post on what is a tester because I feel it sums up how I view my own testing. In return I got Joel Spolsky’s blog which was quite an illuminating view on how perhaps many developers feel about their work too.
Day 5 I basically thanked Rosie Hamilton for all of her hard work on the testing survey she has conducted the last few months. I think we all make a lot of generalisations and assumptions on what the state of the wider testing community and I really value any work done to try and provide some data to consider. The more that people do this kind of thing the better, because it means we can hopefully start to measure the difference we could make by constantly improving the testing community. I’d like to see the results of improving come out in data like this. Or if not, at least we can try and learn and understand why not. I also like the theme of talking about our backgrounds in testing because I think we all bring a variety of different backgrounds and skills that we use in our day-to-day testing!
Day 6 I really struggled with because I had no idea what could be described as a “crazy” test (I generally take the word ‘crazy’ to mean something non-sensical or illogical). I decided it would be “crazy” to test weather forecasting due to how unpredictable it can be, or so I thought! I made a record of what weather accuweather predicted for particular hours in 2 days time and checked if it was correct. Turns out it was pretty accurate, it had predicted cloudy weather for most of the day, rain showers at 11am, 1pm and 3pm and it did indeed rain at those specific moments. Or maybe it was just lucky that I live in Manchester and that is pretty regular weather around here haha.
Day 7 I did a little research and found this neat little tool for tweaking the colours on websites to account for colour blindness. I found a couple of places on this blog that needed tweaking (specifically the main one was the shades of blues for the link text have been ever so slightly changed so they are easier to read on a white background).
I also managed to complete days 10 and 16 - the former I heard about Ministry of Testing’s “Masters of the Ministry” and I’ve booked myself into Richard Bradshaw’s awesome-looking week of workshops. The latter I attended a non-testing event in the shape of Manchester Tech Nights, partly because I’ve attended before and was curious to see what the numbers of testers were like and also because the head of HR at ResponseTap, Rebecca Taylor, was speaking.
What I almost achieved or technically did achieve
- Number 14 “Step out of your comfort zone” - I’m hoping to do this soon by appearing on the Let’s Talk About Tests, Baby! Podcast! I hate listening to myself so definitely not comfortable with it, but looking forward to giving it a good go anyway! I think I might enjoy it though!
- Number 19 “Find and use a new tool” - I think I technically achieved this with the colour blindness tool, but I wanted to really use this challenge to get my teeth into one of the many tools I keep seeing mentioned from time to time around the testing community.
- Number 21 “Pair test with someone” I probably achieved as well because in my current role I try to do this as much as possible anyway. I did pair test with a developer last week in fact.
- Number 26 “Invite a non-tester to a testing event” I regularly keep plugging TestBash at every meetup I attend so I’ve invited a lot of them technically!
No more excuses, here’s some I can at least achieve right here
- Number 17 “Find and share a quote that inspires you” - “At the simplest level, people are doing testing all the time. You often run and analyze tests without even knowing it.” - Gerald Weinberg Perfect Software and other illusions about testing, 2008.
- Number 22 “Share your favourite testing tool” - well the tool I use the most is a pen and notepad, but my favourite testing tool is probably the programming language Python. I write a lot of tools for my own testing with it and I love how versatile it is thanks to its popularity. I don’t think I like any tools that describe themselves as testing tools, I’ve not used one that I’ve liked - for example TestLink or DevTrack.
- Number 27 - “Say something nice about the thing you just tested”. Ok so I’ve recently been testing a particular new application at work and I love how easy it is to test it in isolation. It’s a service that consumes messages from other applications so its reliant on these messages in order to test its logic. However, the developers helpfully included some API endpoints to simulate the messages so where necessary it was possible to test the logic of the service in isolation quite easily. It has meant we can test some things a little earlier and quicker than waiting for a fully integrated environment (although obviously we still need to test that too).