This month I started a mini project on Github to create a small knowledge base, all around the REST Client tool Postman. I’ve been using this tool for a while now and I’m a massive fan, I want to share some of the knowledge that I have gained, with other people.
It’s basically a list of examples that use the tool and its many cool features to interact with a public API. This wonderful resource has been created by Mark Winteringham. Mark has created Restful-Booker, a safe place for people to learn more about API testing and an active platform to try out tools like Postman.
In one of the examples, I explain how to the use Manage Environments feature. This will allow you to create an environment file, then assign pieces of data to variables. That data can then be referenced in any of your Requests within a Collection. This is very handy during the creation of an API, where you may have different environments to test the API like development, staging, pre-production etc. The routes of the API will generally stay the same but the baseURL will change depending on the environment location. Check out the example to learn more about this in more detail.
So why write a separate blog post?
I’m always fully open to learning new things and sometimes you stumble across things by accident or as the result of looking into something else. I love creating visual helpers when I’m trying to explain something – “A picture paints a thousand words”.
To fully explain what I meant by the different environments in the ramblings above, I thought I would just create a couple of super basic Nodejs Express APIs locally and then edit the Hostfile on my local machine to override the DNS for the localhost domain, so that I could show requests being made to dev-restful-booker and staging-restful-booker in Postman.
The code for each API is crazy simple, I wanted to mimic the actual Restful-Booker API so I added the Content-Type header and also made it return a 201 Created status code. The only real difference between my mock dev and staging APIs was the .send() value and the port number that is was running on.
So I added the names to my local Hostfile and started the APIs…that’s when I hit my problem…I wasn’t aware, until I tried it out, that you couldn’t use the IP + port number as an entry in the Hostfile. Using the IP on its own is fine but it didn’t like me adding the port number too! 😦
This meant that my amazing idea of showing this in action on Postman was ruined….or was it?! I headed to Google, that’s what we all do right – Thankfully, It didn’t take long till I found a comment on Stackoverflow, that mentioned that you could just use the HOSTS feature on Fiddler to do this instead. Fiddler is a free web debugging proxy tool and is an absolute must have for Developers and Testers working in the web development space. I use it all the time but because I never had a need to do it, I wasn’t even aware that you could do that within the tool.
To access this feature is simple. In Fiddler, select the Tools menu option and then select the HOSTS… option at the bottom of the list. I added the following entries and hit Save.
I spun up my two mock node APIs and bingo!! We were back in business!!
So that was it, Fiddler saved the day and I was able to add what I needed to the Postman example and learnt something new in the process! Win – Win!!
Please do check out my examples on Github if you’re interested in learning more about different ways that you can use Postman.
I absolutely love Testability as a topic and to my delight, Ash Winter wrote a great post recently where he posed a series of questions – Naturally, I jumped all over these to see how my team measures up against these questions. In fact, I was a little too quick to react and came up with a score that wasn’t actually on the page (Blame the typo on Ash, not my poor reading skills).
I wanted to write this post to try and explain where I feel my team is at right now and give my answers to the questions. Some people may feel that I haven’t really answered the question correctly but I can only answer them based on my current team and in our current context.
1 – If you ask the team to change their codebase do they react positively?
For me, that all depends on what the change is you’re being asked to make and who is requesting the change. No one in the team is massively nervous about making changes to the codebase but the change has to be something that we, as a team, all agree on and believe it to be the right thing to push us forward. With any change, big or small, we will always plan it out together as a full team and walk through the changes to assess any risk that this may introduce, based on the current information and our understanding of our services. If there are gaps in the information during the walk through, we will spike ahead and try to uncover the answers to the known unknowns.
2 – Does each member of the team have access to the system source control?
I believe this is a fundamental part of being a member of a development team. In our team, as it stands today, only the Product Owner doesn’t currently have access. That’s not to say that he doesn’t because he’s not allowed, he just feels that he doesn’t really need it. Everyone apart from him has checked in “something” to source control over the last 18 months. This could be production code, a utility script or a testing tool, a JSON template for one of our monitoring Grafana dashboards etc.
3 – Does the team know which parts of the codebase are subject to the most change?
Every member of the team has been on the project from Day 1, the collaboration and communication are something that I feel we excel in. Everyone is capable of working on any aspect of the project, we identified certain silos forming early on and made changes to spread the knowledge amongst the whole team so we don’t have a single point of failure. People will always be stronger in some areas but we all have a collective understanding of the changes being made at all times. We do a 3 Amigos on every story before starting the work and as we are quite a small team this generally involves every team member so everyone knows what changes are being made to what area.
4 – Does the team collaborate regularly with teams that maintain their dependencies?
Our API was released as a pilot a few months ago to a selected amount of customers who are giving us valuable feedback, as the project matures the data available to them is becoming a lot richer, which is of benefit to the end user, we are always constantly aware that our changes are not breaking ones as the API is being used to create custom integrations. Over the last few weeks, we have picked up some internal consumers that are creating an integration based on the data we provide. This has been very collaborative and it’s awesome from a testing perspective as we get super quick feedback and can react to this and make changes where necessary.
5 – Does the team have regular contact with the users of the system?
Before the internal consumers started their integration we were only dealing with 1 or 2 main external contacts who were providing us with feedback. For me, this could have been better or more structured. The customer was based in the States so there were time zone issues to address and the general information passed back to us was hard to decipher and not clearly presented so it just ended up being a bit too much back and forth. It’s a lot better now but it could always be improved. At the end of the day, we’re creating software for our customers/end users so they should be involved as much as possible.
6 – Can you set your system into a given state to repeat a test?
This is one that I’m extremely happy with, as a tester, having the ability to control the system and put it into any state you want and at any point, is a priority. We have built Testability in from the start, there are hooks in place to stop a specific service, we can easily spin up or tear down services to get to a set point. We have also created a suite of tools to allow us to achieve many things, one favourite of mine is a tool that grabs all the events from any live interaction and replays these in a local environment as if they were happening in real time. This can be done in seconds and helps with debugging issues to get to a solution quicker.
7 – Is each member of the team able to create a disposable test environment?
We use a Vagrant development environment which is just awesome, the instructions are clear and well laid out which allows anyone in the business to bring up their own environment within a few minutes. There are a few requirements for certain applications and languages to be installed but a script has been created to pull down all of these items, this is also attached to the set of instructions. Each service has a set of rake tasks, so building the C# .Net services or the Node.js API and starting them up is just a single line in a terminal. Our team has created an events Simulator that will mimic a live Contact Centre (The core service of NewVoiceMedia) and feed these events into the locally running services. At this point the endpoints are available and requests can be made to get the data. I’ve not timed the installation but it’s pretty bloody quick to go from nothing to seeing a response from the API.
8 – Is each member of the team able to run automated unit tests?
Of course! This goes hand in hand with being able to access the source control and spinning up your own local development environment. I would have serious concerns if this wasn’t the case.
9 – Can the team test both the synchronous and asynchronous parts of their system?
This is very closely related to question 6 in my opinion, knowing what control you have over the system in order to put it into a specific state. More important than being able to test these parts, you first of all need to know where and when they occur in your system.
10 – Does each member of the team have a method of consuming the application logs from Production?
We mainly use Papertrail (we also have other tools available) to aggregate the logs (All Staging, Pre-Prod and Production environments) I have set up groups within the tool to make it easier to see what is happening on all our boxes in one central place. I’m all for consistency and the group names are the same in each environment, apart from the environment identifier. Papertrail is great at what it does but I find the UI not amazing to look at so I use a Chrome extension called Stylish to present it in a way that works for me. It just manipulates the CSS to present the page in a way that you want, I tend to use colour to show specific pieces of information.
11 – Does the team know what value the 95th percentile of response times is for their system?
We have gone a bit mental in this area, the team loves monitoring and performance based metrics. We’ve invested a lot of time and effort so that we are answering questions about the impact of increased load and stress on the services, with data rather than a best guess finger in the air measurement. Not only do we cover performance but we have also exposed the state of the resources (CPU, memory and disk space, etc.) on each box. We have multiple different Grafana boards giving us constant real time feedback.
12 – Does the team curate a living knowledge base about the system it maintains?
At NVM we use Confluence from Atlassian, each team has its own space as well as the wider department spaces. Our team has built up a wealth of information about all aspects of the project. We did this from the start to document our journey but this has grown and improved as the platform has matured. It’s full of useful information about our architecture, environments, how-to guides, team culture, deployment and release information etc. We periodically curate the content to ensure that it’s still relevant and the space is just not full of dead/redundant information.
Hope my answers provide some information about how we function as a team and gives you an insight into things that we feel are important. For things that I would add, currently, we also deploy our services to multiple regions around the world so having a team based understanding of how that all pins together is very valuable. We are still learning and growing as a team, we started out on this project with the intention of having Testability baked in from Day 1 – I personally think we’re doing pretty well but we haven’t stopped yet so maybe I will have an updated list of answers in a few months.
Any questions you would like me to answer based on my responses, please leave a comment below! Cheers for reading!
Sometimes you do certain tasks that become normal and you kind of go into autopilot, blindly repeating the same thing over and over again. It normally takes someone else or something else to spark something in your mind and give you an idea that there is always a simpler solution.
Recently, I’ve been using a strategy when testing, that involves creating “Test Queues” within RabbitMQ (The message broker that we use for our microservices) that siphon all the messages from the queues that our microservices are consuming – The Test Queues hold/store them, so that I can investigate deeper into the message data. Unlike the actual queues, these do not have consumers so the messages will stay there until I choose to delete them, adding an extra layer of control. I could just manually stop the service and grab the messages from the service queues but I like to give myself a separate option.
For context – My Test Queues would live alongside the red ones in the image above but will not have consumers, the arrows to the right of the red queues…hopefully, that makes sense. 🙂
My boring repetitive problem…
RabbitMQ is an awesome message broker and like it says on the site “Messaging that just works” what they haven’t concentrated on is the usability of their UI management console, why should they, that’s not their main focus – they currently just have something that’s good for now. As much as having these queues is really useful, clearing them out or purging them is a tedious task, it’s made worse by the fact that I follow the same process several times a day…
Click on the queue name > scroll to the bottom of the page > Click on the “Purge” button > scroll back to the top of the page > Select the Queue tab to get back to the main view…repeat…yawn!
I’m a fan of getting a local instance of the technologies that we use within our feature team and exploring lots of different aspects so I feel more comfortable and more informed about the tools I’m working within. I knew the RabbitMQ has a HTTP Restful API with a limited amount of features, I can use some of these to my advantage!!
RabbitMQ has been around for about 10 years now so I had a hunch that someone has probably had the same problem as me and wanted to use the API to purge the messages within a queue…I headed over to Google…
Basically, the first result that came back was about 90% of the solution that I required…Bingo! I found this from 5 years ago – Like I said, it wasn’t exactly what I wanted so I needed to adapt the code to suit my requirement.
I only needed to refactor the code slightly and add an IF statement that checks to see if the queue name starts with the “TestQueue_” name if so, purge the queue. All the other queues are unaffected. Job Done!
During the testing of the code, I added some logging just to sanity check that I was getting the correct queues that I wanted and discarding all the other ones. All the “null” entries below are queues that do not start with “TestQueue_” so are ignored.
Once the Snippet was run, I could see that the correct requests are being made…Yay! The messages were deleted from only the queues I wanted.
So I now have a link on my browser that saves me the pain of going through the tedious repetitive task to purge each queue. It’s the simple things in life that make me happy.
Alan wrote a post to accompany his video that references lots of links about how others have used bookmarklets. One of those is this excellent blog post by Abby Bangser, which I read a while ago before I saw the YouTube video. She explains how she utilizes the bookmarklets to quickly fill in form data – It’s really interesting and I would recommend trying to give it a go yourself.
Hopefully, that has been interesting enough to spark something in your own mind and attempt to give this a go – I would love to hear from anyone who has created a bookmarklet to solve a problem.
In the UK we have a chef called Jamie Oliver and over the years he has created lots of TV episodes and also a book on how to make a complete family meal in 30 Minutes – The premise of this, is that time doesn’t have to be an excuse not to make healthy food for the family.
Now, if you’ve ever seen these episodes or tried to follow this, it takes a lot longer than 30 minutes!! It’s more about a “mindset”, which is a lie, it’s about having everything prepped and ready to go so all you’re doing is cooking the food and not chopping things up and getting the pots and pans ready.
So what does this have to do with APIs?!
In my current context, making requests to a RESTful API and analysing the response data is something I’m perfectly comfortable with doing but that’s only because I’ve been working within that space for a couple of years now. I truly take for granted many of the skills that I’ve learnt over the last couple of years and I forget, that you need to start somewhere, in order to build up your knowledge of a certain area.
There are loads of public APIs out there that you can use but these can be tricky to set up. In my experience, most of the documentation that comes with these is confusing and sometimes it’s lacking vital information. Another way forward is to create your own basic API but this can be a daunting task coding it yourself, although a very rewarding once you get it working!
What if there was an even easier way that would allow you to have control over the requests that you make and the data that you want to see in the response?!
I’ve found this node module called json-server that is very handy and super quick to get you started. It’s only a couple of commands from a terminal and you are up and running and making requests within seconds….seriously!
The 30 second API mindset…
So following Jamie’s lead, before starting we need to do our Mise en place…We require a couple of things in place before we get cooking.
Your starting point should look something like this – depending on your terminal/Postman colour preferences…
First of all, we need to globally install the json-server module. In the open terminal, type the following command:
npm install -g json-server
Once this has been installed you’re basically ready to make requests. Quick right?! As you have installed the module globally (using the -g flag), the server can be started from any directory but we will be using our newly created one.
In the terminal, type:
As you do not have a db.json file in that directory, it will conveniently create one for you and populate this with some default values. These are good for now, just to get you started and making basic requests. Later in the post, we will talk through how to create data files containing the data that is more relevant to your context.
We’ll be using Postman to request the data from the db.json file but it’s entirely up to you, use something that you feel comfortable using. You can now send a request and get a response containing data from the file. The available routes are displayed in the terminal, you can use either of these routes in your first request.
Copy one of the routes below and paste this straight into Postman, you will get the data returned from that Endpoint.
Sending a GET request is easy right, the best thing about the json-server module is that it gives you the ability to also practice sending POSTs, PUTs and DELETEs. I would attempt go through each one of these methods but the documentation on the json-serverGitHub page explains these methods better than I ever could. This also covers a number of awesome features that you can make use of when using the application.
I don’t want to use the Default data file…
Fear not, as this is essentially just a JSON file that you’re using, you can have any data you desire. You’ll need to stay within the applications format for the way it parses the routes/endpoints from the .json file but apart from that, it’s up to you!
I’ve used mockaroo to create some random data. You can grab this from here and save the .json file to the same directory. Stop the current server instance (Ctrl+C) and spin up a new one using the new dummyUsers.json file:
If like me, you have applications running on certain ports on your local machine, you will need to either stop that process or give json-server a different port to use. This can be done from the command line before you start the server:
json-server <file.json> -p <port number>
When making changes to the .json file manually in a text editor you will need to stop and start the server instance that you have running, for the changes to take effect, which obviously sucks because you want to be able to see your changes straight away. Luckily, there’s a command line flag to get over this:
json-server –watch <file.json>
Any manual file changes made will be automatically detected and the server will be restarted for you and you’ll be able to continue making those lovely requests.
To Finish Off…
So that’s it, you now have a platform to practice making requests to an API that you have control over and all without writing any code. I’ve only covered a small part of what json-server offers during this post, I would advise you to have a look through the GitHub page once you’re comfortable using the basic function of the application because it offers so much more.
Good luck and let me know if you find this useful. If you have any questions just drop me a message!!
An Extra Helping…
I’ve added some more information about using a collection within Postman to make different types of requests and interact with the dummyUsers.json data. Hope it helps!!
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.
It seems slightly strange to be writing a post about a conference that I didn’t physically attend but the awesomeness that is TestBash, made me feel like I was part of it anyway!!
Testbash has been part of my own personal journey for a number of years now, It was the very first testing conference that I attended back in 2013 and I was hooked! I’ve helped out Rosie at a couple of the events and I have also been an attendee at a couple too, both of which were wonderful and rewarding experiences. When I heard the announcement for TestBash Manchester, I was instantly thinking, I’m going to that event!! I bought my ticket (not before Chris Chant…because no one does…) and was looking forward to seeing the talks, familiar faces, meeting new people and of course learning loads – but I also had something else very important going on this year. My wife and I were expecting our first child so, I had a dilemma and a choice to make. I made the decision, the only one I was ever going to make, to stay at home with Sophie and my Wife.
As a huge fan of Testbash, I wanted to ensure that someone else would be going in my place – It would have been easy to get the money back but I wasn’t really interested in that and I wanted to pay it forward. I’ve sponsored a ticket in the past so this is not a new thing for me and I wanted to do it again. I met Patrick Prill for the first time, in person, at TestBash in Brighton after talking to him on Twitter for several months. This guy is awesome, not as moody as his profile/any other picture suggests and I couldn’t think of a better person to gift the ticket too.
Making me feel part of the day…
I was up early on the day of the event, I normally am anyway since the arrival of our little lady. So there I was, feeding Sophie and a flood of messages came rolling in from Twitter!
*UPDATE* – Can’t believe I missed this photo of Patrick (semi-smiling) and Rosie!!
Patrick had attached a sticker to himself, with my name on, and was having photos taken with lots of lovely people. It made me feel really happy and part of the conference! This is what I love about the test community, you get moments like this that make you feel valued and part of something special. Throughout the day I was getting notifications about different things that were happening and finally, I received a mention/shout out during Patrick’s 99 second talk! It perfectly rounded the day off for me. Thank you!!
From a non-attendees viewpoint…
I’m completely bias, so I’m always going to think that TestBash is awesome, no matter where it’s held! There was something different about this one and I can’t quite put my finger on why. Richard Bradshaw has a huge part in this I feel, along with Rosie, they made TestBash Manchester very special. The social media buzz was amazing to see, maybe because I’ve found myself on the outside looking in this time – Everyone looked and sounded like they were having a really great time!!
One of the things that I felt was a master stroke was “The Teshbash Challenge”. It was an absolutely perfect way to get everyone talking to each other and a fantastic ice breaker. I love talking to other people and I don’t really mind walking up to strangers and having a chat, others are not so comfortable doing this but by having this challenge open as part of the event, it meant that it would be far easier to talk to other people during the day.
Although I missed the event itself, as a Pro Member of the Ministry of Testing Dojo I get to watch the talks back in my own time when they get uploaded to the site. I don’t think I’ll go as far as trying to hold my own TinyTestbash Bristol in my house but I will enjoy all the talks over the up-coming weeks.
If you’re not a member of the Dojo already, I would thoroughly recommend signing up to it. Not only does it have all the previous TestBash talks it’s also home to lots more great content and is getting added to all the time!! Go check it out!!
I’ve already sent out a pre-advance warning to my Wife so I’ll be at the next UK based Testbash event in Brighton next year – Hopefully, I’ll see many of you there!!
Good Luck to everyone involved in TestBash Philadelphia and TestBash Netherlands – I know that those will be equally as awesome!!