Being an active member of the test community, I sometimes don’t appreciate how difficult it must be for other, not as involved testers, to find great resources outside of their workplaces.
I have the benefit of knowing or being aware of certain prominent testers who write about topics or have a specialist area that they tend to blog/talk about – it’s easy for me to say “he’s blogged about that lately” or “she’s spoken at a conference about that topic recently” and straight away I have an entrance point, so that I can expand on an idea I may have and go from there to move things forward.
I’m probably one of the only people left in the test team at NVM that is always on Twitter or watching conference talks etc. People learn in different ways and subscribe to other channels to get their testing information – I get that, it’s a personal learning and development thing. What I wanted to do is expose/share some of the great resources that I love, with the test team, in a not so “in your face” way. I didn’t want to push anything on other people, that they didn’t want to read or watch so I set up something that they could tap into or look at if they have some spare time.
So much to choose from…Where do I start?
There really is so much content out there, that I could absolutely flood my team with lots of blogs, articles and videos but I don’t think that would be useful and could potentially have the opposite effect and scare people away. I started with 2 resources that pack a lot of items in a couple of links.
I saw this tweet from Katrina Clokie where she mentioned one of the resources I had in mind, I love that see was recommending people to follow the Testing Curator!! I’ve followed this account for a while, as it really is something special – well worth subscribing too!! Great job Matt!
Making the content easily accessible…
I’ve blogged in the past about using Hipchat at NVM, although some people may prefer Slack, this is fine for us and suits our current needs. Hipchat has an API, like many other platforms, that allows you to send messages into “rooms”. Our Test Team has its own room where we can exchange test ideas, test improvements, new things that we’re learning etc. This seemed like the perfect place for these new testing resource feeds. As well as the Testing Curator feed, I’ve added Simon Schrijver‘s 5 blogs feed. This is excellent and provides the team with 5 new blogs to read each day! Thank you so much for providing this service!! I love that the blogs are not only about testing, it’s a great mix!
A Helping hand…
Although I’m loving coding little applications at the moment and I could have attempted to do this from scratch but…I thought “What’s the point?!” I would have either epically failed or it would have taken me too long to achieve. I’m a huge fan of integration services like Zapier and IFTTT – they are just really simple to set up and so useful for what I wanted to do. I’ve chosen Zapier for my integrations, I love that it has really intuitive UI and you can test each step as you go, so you can clearly see what’s happening.
This is an example of the 5 blogs “Zap” that I have created, It’s triggered by a new item on the RSS feed and then sends a configurable (see image below) message to the Hipchat room. Simples. The task runs every 15mins, looking for changes – there are different account plans that you can have on Zapier but the free plan is sufficient for what I have it set up to do.
So that’s it…Something that is extremely simple to set up and has hopefully provided my fellow testers with additional testing knowledge. I’m not forcing people to click on the links and read the blogs, it’s all there if they want to take a look.
These integrations can be set up on Slack, etc. in exactly the same way so if you would like to provide your team with some excellent content I’d recommend taking a look. Once it’s set up, it’s going to just run in the background.
I would love to hear if anyone has a similar sort of thing set up already and how it went down with the rest of your team.
At NewVoiceMedia, like many companies, we hold Hackathons each quarter. This is a chance for everyone (not just developers) to create something that will be of benefit to our customers or help improve an internal process of the business. These small projects could be a proof of concept or a small feature that is ready to go straight into the Live product.
In the past, I’ve helped out on tiny projects with a couple of developers but for the last few hackathons, I’ve used it as a chance to improve my coding skills and create tools to help out other people. There has been a process that has bugged me for a while and we do the task every week, so I thought that it was a perfect place for improvement. We manually create/construct a URL that displays the release notes for our service, based on the “start” and “end” commit numbers, the “start” number being our deployed production version. Like I said, this is a weekly task as that’s our current release frequency. I knew there was a better way and more efficient way to get this done. The URL in the images below is an internally used NVM address so it, won’t work anywhere outside of our Company.
A while back I read a great post by Neil Studd, He created a bot that was accessed via a custom slash command within the Slack platform. I thought it was impressive and it was something that I wanted to try to replicate myself! So I had a slight problem at the very beginning, we don’t use Slack at NVM (not my choice), we use Hipchat instead. I needed to figure out how I could get a custom slash command to work with that platform, thankfully, they do have their own version of this feature.
Similar to Neil’s method, I wanted to use Heroku to host my application, I mainly wanted to try this out because it was unfamiliar to me and it was a great opportunity to learn something new!!
Creating an MVP
I’ve recently been dabbling in NodeJS and creating little test tools that I use on my team, we also have a production API that uses this language so I’m quite comfortable in that space at the moment. For what I wanted to create, it was a perfect choice. I created a tiny Node Express app with a single POST “/notes” route, this was going to be the entry point from Hipchat. Once I got those two things hooked up and talking to each other I was sorted – because I’m a noob and couldn’t understand the Hipchat API Documentation fully, it took me bloody ages to figure out what was being sent from Hipchat and how I could grab that data to then start the next phase.
I found a video that really saved my skin and allowed me to move forward, the demo video used a tool called Requestbin that gives you a URL for Hipchat to POST the ongoing request. The Requestbin site then just displays every single piece of information in the request!! I was in business and I could navigate through the JSON, in the body of the request to get what I required.
Now that I had what I needed, I was able to use some Node modules to do most of the donkey work and get a working solution up and running quite quickly – At this point it was quite basic and very buggy, I think I broke it on the second request that I made to the application. I wasn’t actually thinking like a tester during the coding part, I was just trying to get something working. I actually don’t know why I didn’t plan and approach this like I would a normal project but you know, you live and learn.
Bringing a tester onboard….
I needed to put my tester hat on and actually, think how I would use this application from a consumers point of view. I made a short bullet point list of possible ways that I can think that someone might use the tool or possible edge cases that I can mitigate against.
/notes position in the sentence (“some words /notes 12345”)
Is the returned URL in the message a hyperlink? (Hipchat API auto picks up links, if in the correct message type “text/HTML”)
How do the other built-in slash commands behave (/code etc.)
What happens if the external GET resource is not available or returns the wrong data?
These are some of the questions that I was asking myself, I had many more but this is the general gist of the ideas in my head. The whole time that I was making changes to the code and then testing the outcomes I was thinking that I wanted to add something that would let me know what was going on behind the scenes of the application when the users were making requests. We recently had Richard Bradshaw come into our company to deliver his awesome Lego automation workshop, in this he mentioned “Giving your automation a voice” – This wasn’t test automation but I did want to know what was going on, it was only going to tell me if I actually told it too. I added log messages to the application at key points so that I could track what was actually happening rather than just seeing an output in a Hipchat room.
Another approach I was thinking about while testing was Ben Simo‘s FAILURE mnemonic if users were entering the wrong information, I wasn’t telling them (oops), It just didn’t return anything to the Hipchat room. That didn’t sit right with me and I used Ben’s heuristic to guide me, I wanted to give the users some feedback and let them know that “Something wasn’t quite right” with the data that they had inputted. As I could tell which Hipchat user sent the request, I grabbed that information from the JSON and made my returned messages (both good and bad) a bit more “friendly”. Manners don’t cost anything, as my Mum used to tell me.
Finding bugs in the wild…
I wanted to add an additional feature for users to specify a different environment when making the request (e.g. “/notes 12345 cloud4“), I initially defaulted the response to our main production node when users entered “/notes 12345“, as this matches the current behavior of the main internal release notes creation tool. I wanted to be a little bit more flexible, I had the opportunity to add extra functionality and let the users decide what the returned data was going to be. I added the code and rushed through the change, “It worked” so I left it and communicated out the new feature, giving an example of “exactly” how this worked. Great success! Maybe not…
I’ve used Regular Expression in a number of places to capture certain things, I’m new to using Regex so I had a little help from the Regex101 site and also practised some of the Regex in the Chrome Dev Tools console (This was super useful!!). It turned out that my Regexfu is not so good and I omitted the “i” from the expression. meaning it was case sensitive so if someone entered “cloud4” it would return what they thought it would but “Cloud4” and “CLOUD4” wouldn’t return the same thing. From a users point of view, you would still get back a valid URL as it defaulted to a certain value if you didn’t enter exactly “cloud4”. I’ll get back to this issue.
Logging and Monitoring…
Using Heroku, I could access their built-in raw logs and could see what was happening while people started using the application. These were great and showed me what I wanted to see, the only trouble was, I had to go on to the Heroku site each time. At NVM we use Papertrail and I know that I could bolt on this log management tool to my Heroku app and feed the log messages into there. Great, I know this app and the search syntax so I was sorted….not quite, because we use in at NVM it annoyed me that I had to login and logout each time I want to see either the work logs or the ones that my app was producing.
Up stepped LogDNA – it was another option from the Heroku list, so I gave it a whirl. Luckily, the search syntax was very similar to Papertrail and it was extremely easy to get it set up in the way I wanted. It also had a feature where you can set up a notification on certain searches so that you get emailed when things start going wrong or just have something that lets you know who is using the app.
Coming back to the Regex bug that I found earlier, I basically only saw this because of the logging that I had in place. I could see that a user had made a request, that should have failed (in my mind) but it returned the default value. I was able to spot the issue, fix it, test it and then deploy it again in super quick time without it impacting the users. Testability win!
I’ve now added this app to multiple Hipchat rooms and I’ve seen the usage steadily increase, which make it all worthwhile. I’ve also created an internal wiki page so that people can add it to any Hipchat room and it also explains some basic instructions with examples.
As well as doing this internally, I’ve knocked up a very simple bare-bones node app and placed this in a Github repository for anyone to use/rip apart etc.