This month, Caplin held its biannual hackday event. Developers got into teams of up to 3 and had 24 hours to produce something befitting this year’s theme: Speed. Along with my colleague Andrew Voneshen we formed the team “Driving Miss Daisy”; a film that personifies the term speed like no other!
Our first idea was to create a motorbike that travelled at the speed of light, but we soon realised the headlights might not work when travelling at top speed. So instead, we tapered our ambitions somewhat, and set out to speed up the monotonous admin involved with running our internal bug bashes.
Intro – Caplin Bug Bashes
It goes without saying, when it comes to catching regressions, here at Caplin we have a comprehensive automated test build that allows our QAs to sit back, relax and let the GitLab runners do all the hard work. However, as a second line of defense, we also hold weekly bug bashes to catch the occasional bug that slips through the net. Of late, bug bashes have been held remotely. Various members of the product teams meet virtually and use a bug bash Slack channel to report any issues they find while bashing one of Caplin’s many apps.
One issue we repeatedly face is a lack of relevant detail in the bug descriptions. There’s little worse than picking up a 3 month old bug ticket called “Thingy no worky“. On our Jira backlogs, tickets with such poor descriptions are about as welcome as a scrabble board on Love Island. Having bug bashers provide more relevant details at the time they find the bug would be preferable.
HR informed us that the use of electroshock therapy to re-educate our colleagues was not an option (pesky EU regulations). We would have to find another way to enforce better bug descriptions.
Another gripe with the bashes is the admin. At the end of the bug bash, a designated person (usually a QA) will face the unenviable task of scanning the messages for legitimate bugs. Then deciphering the content to create Jira tickets, oftentimes having to chase the bug raisers for additional info. There must be a better way…
The Hackday Plan
Our main objectives to improve the bug bash process were:
- Reduce the admin involved in collating the bugs found and generating Jira tickets.
- Ensure we capture the right amount of detail and acceptance criteria in each ticket.
We figured the best approach would be to utilise the Slack development api to enhance the tooling and provide an easier interface for bug bashers to 1) seamlessly input new bugs with an adequate amount of detail, and 2) automagically collect all the relevant bugs into a set of Jira tickets.
To accomplish these objectives in time, we decide to piggyback on the fruits of a previous hackday: Scoop (it’s only cheating if you don’t get away with it). Scoop is a chatbot created to aid the discovery of slack conversations one may find interesting, for example, by notifying the user when certain keywords or emojis are being used. An automated bat signal for nerds if you will.
The Hacking
Step 1 – building bug modal to input the bugs
We knew we needed a way to simplify (and enforce) the capturing of bug info, as opposed to just typing a message into Slack. For this we designed a Slack modal using Slack’s block building kit:
Slack blocks not only allow the simple creation of stacked layouts within apps/modals, they also provide a mechanism to identify the details captured in each field, which will come in handy later when we collate the details.
Step 2 – add a mechanism the collate bugs and upload to Jira.
Once we have a Slack channel full of detailed bug messages, we need a simple way to tag the pertinent bug messages and, in one fell swoop/scoop, swallow the details Hungry Hippos style and transfer the bugs into a set of Jira tickets.
Once again, we put on our hard hats and used the block building kit to create a modal to be launched using a newly created Slack shortcut called digest. Shortcuts are the entry point to a Slack app or modal.
Here we can specify a time range, channel and the unique emoji that has been used to tag the bug messages (e.g. :ladybird:). On the backend, the Scoop slackbot would iterate over each bug message, convert the blocks of info to Jira fields and generate rows of bugs in a csv file. The csv can then be parsed to jira tickets, either using a Jira API call or via the Jira UI, in a matter of seconds
The generated descriptions would include all the details captured in the bug modal along with a link to the Slack thread where further discussion about the bug usually takes place during the bash.
Demo Time
We had around 10 minutes to present and demo the new Slack functionality. The demo was split into 4 parts:
1. Using the new bug shortcut, we generated some fake bug messages in a Slack channel
2. We scrolled through the bugs and tagged a few of them with the :bug: emoji
3. We used our custom Slack shortcut, digest, to parse messages with the bug emoji. As if by magic, we then received a private message from the Scoop bot, containing a CSV file with all the necessary fields required by Jira.
4. We then demonstrated the 5 second process of importing these rows into Jira tickets.
… and the crowd went wild, or at least I assume they did, it was hard to tell on hangouts with everyone muted.
Next Steps / Hackday Result
While the Scoop bot is ready to aid upcoming bug bashes, we do have some plans to build on our hackday work to further improve the bug bash experience:
- Bespoke bug modals for different projects that have different mandatory Jira fields.
- Support for attaching images/video to the bug message
- Conditional fields depending on the app under test, e.g. component name or backend env.
So, how did Driving Miss Daisy get on against the 21 other teams competing? As a team, we decided it would be inappropriate and gauche to reveal the result. Also, hackday is not about the competition; it’s about the camaraderie and the fun we all had along the way. Merry Christmas everyone.
You’re a treasure, Dan Owen
Only thanks to your tutelage, Pre 😉
xxx