Omni Converter Challenge - Retrospective

To quickly recap: The goal of this project was to practice my testing skills and figure out a structure for further projects. For a target to test, I found the Omni Converter Challenge which is a RESTful web service explicitly designed for testing practice. I started by reading its documentation and performing exploratory testing, and used the knowledge gained to write a regression testplan. At the same time, I set up an Ubuntu workspace with a local instance of the OCC service, plus SoapUI and a JIRA instance. I then automated that testplan in SoapUI and executed it, turning up a handful of unique bugs which I entered into JIRA.

Now it's time for the last and most important step of this project: figuring out how to improve for next time. Ideas have been building up in my mind over the past few days, so I'll launch straight into their analysis.

There are four big issues that I want to address:

1) The project took too long

Back in May, I guessed that this project would take a couple of weeks, and here I am in the middle of August writing the final part. The thing is, I think that if I actually took the number of hours I spent working in those three months and compressed them into 6-8 hour work days, I probably would've finished on schedule. But being home in Toronto in summer with no deadlines led to a lot of time spent not working. 

Of that lost time, I'd estimate about half of it came from lack of focus. When I get up in the morning and finish my breakfast, I could sit down at the computer and start working, but I could just play a video game instead. Or go ride my bike, or work out, or any number of other things. Once I start working I can usually lock onto some goal and keep working until it's done, but the challenge is to get myself started, and I think a goal is key. Maybe If I can decide what piece of work to finish and when, before considering other things I could do, then that goal will stick with me and impel me to start working.

Come to think of it, what I'm talking about here is integrating an Agile stand-up into my daily life. At the start of my day, take just two minutes to think about the status of some ongoing task, analyze the issues and pick a piece to do today. I'll start this tomorrow morning, and consider adding it to this website as a sort of daily "status."

2) Functional-testing a RESTful web service with SoapUI is something I've done before

I knew going into OCC that it would be similar to work I've done in the past, and I don't think it was a bad thing. Constructing my work environment and determining a process was a lot of newness already, so diving into brand new technology may have been too much. Now that I have this website and OCC as a foothold, I think it would be best to move on to new technology and new techniques. Off the top of my head, I have almost no experience with performance testing.

3) I didn't keep useful exploratory logs

This is a simple one: I tried keeping notes without using any particular format, which produced easy-to-read but difficult-to-use notes. I had eloquent descriptions of a few issues, but didn't keep tight track of what I had and had not tested. I should research popular exploratory log formats, pick one appropriate to a given project, and stick to it. 

4) I didn't know what details to record in my bug reports

Like any piece of writing, bug reports should be tailored to some audience so that unnecessary details can be removed. For OCC, I had no audience, so I couldn't decide what details to include, resulting in very short bug reports. Going forward, at the start of each project I should imagine the development team that would've created the software I'm testing and create a bug report template appropriate to that team.


Lastly: retrospective of the retrospective

It's been about 3 hours since I sat down to start writing this piece, and I think it's gone well. I accomplished my basic goal, which was identify issues and come up with practical solutions. It's hard to judge whether this was the best way to do a retrospective, since I haven't considered alternatives nor put any of the solutions into practice yet. It's also likely there were important issues that I just didn't think of.

For the next project, I'll keep a list of critical issues for its retrospective to ensure I don't forget them. Before the next retrospective, I'll also spend some time researching formal retrospective formats and see if anything piques my interest.