Bringing external content in-house…

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!

 

katrina_tweet
Go and follow @testingcurator

 

 

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!

 

hipchat
Hipchat messages

 

 

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.

 

zapier_hipchat_integration
5 blogs Zap

 

 

message_configuration_
Configuring the Hipchat message

 

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.

Cheers!

Hipchat Custom Commands – Continually Improving our processes!

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 and 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 some 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.

 

mvp
My MVP

 

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.

  • Entry point
    • /notes (I wanted this to be the only entry point)
    • /NOTES (I didn’t want this to return anything)
    • /NoTeS (I didn’t want this to return anything)
  • What could the user enter?
    • /notes valid number (/notes 12345)
    • /notes without a number
    • /notes number of digits (1, 2, many)
    • /notes and repeatedly entered 5 digit strings (/notes 12345 12345 12345)
    • /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.

 

app_logging
Giving It A Voice

 

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.

 

release_notes_helper
Making It Friendly

 

error_handling
Appropriate Error Messages

 

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…

 

cloud_request
Location Matching Feature

 

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.

 

email_notification
Email Notification

 

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!

Distribution…

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.

You can grab the code here: https://github.com/DannyDainton/node-hipchatbot

That was an epic read but hopefully, it makes sense and encourages other people to give things a go and try and improve a process that annoys you too!

Cheers!!

I kinda didn’t go to TestBash…

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!!

testbash_05

 

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.

testbash_challenges

Photo by Phil Hargreaves

All is not lost…

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!!

My experiences as a Remote Worker

This week I had the honour and pleasure of being interviewed for an episode of the wonderful Testing In The Pub podcast. I love this podcast and it’s one that I’ve really enjoyed listening too since the first episode went Live. Stephen Janaway asked me if I’d like to come on and talk about being a tester on a remote team…

I was actually a little bit nervous, which is strange but I didn’t want to sound like a fool and let anyone down. I obviously missed points that I wanted to talk about and glossed over some of the points that I did talk through – This post hopefully adds to the topic and fills in some of the missing blanks.

You can check out the full podcast episode here: http://testinginthepub.co.uk/testinginthepub/testing/testing-pub-episode-36-part-remote-team/

How did I become a remote worker…

Being a remote worker is not all fun and games, it’s really not for everyone but it works for me. For the last 18 months, I’ve been pretty much a remote worker – The pure hardcore remote people would probably call me a fraud as I’m not full-time at home but I feel I do this more than enough to have some personal experiences to share.

I joined NewVoiceMedia at the beginning of 2014, it was always going to be a move that would either make me or destroy me. I wanted to work for them, they had a huge reputation in the test community, Rob Lambert was leading the test team at the time and they had some amazingly talented people who I knew I can learn so much from – The trouble was that it was just under a 4 hour round trip to get there and back. Looking back now, I think I had my rainbow-tinted glasses on and was only seeing the learning and personal development aspects of the job and not the huge strain physically, financially and mentally that I was about to put myself under.

Luckily, the role involved the ability to work from my home during the week and that was key to me jumping on board and accepting the job offer.

During my 3 month probation period I was in the office 5 days a week, it was a killer! I was overwhelmed by new surroundings, new people, new well….everything! I’ve always said that this is when I became a tester, this was my first proper testing role so as well as all the new environmental changes I was learning how to be a tester!!

Thankfully they wanted to keep me on after the probation period and then after establishing a good working relationship with my feature team and the members of the test team, I started to work from home once a week, this over time, increased to 4 days a week and that where I find myself now…

My pattern of life…

Most people, in my experience, have a Pattern Of Life that they follow. They tend to wake up at the same time, have a standard morning routine in regards to getting ready/having breakfast, they catch the train or bus at the same time and sit roughly in the same seat, they read, watch or listen to something similar on the commute each day, get the same coffee at the same shop before going into the office etc.

A daily routine has always been part of my life in the British Army, for 11 years I was told what time I had to get out of bed, what time to eat, what uniform to wear, what location I had to be at certain times of the day, etc. – It was an extremely structured life.

My daily routine during the week would always follow something similar to this:
0600 – Reveille/Rouse
0630 – Block Jobs (Cleaning)
0700 – Breakfast
0800 – First Parade
0830 – Platoon Administration
1000 – Physical Training
1230 – Lunch
1330 – Rifle Drill
Etc.

I’m a creature of habit and some things have stayed with me since leaving, I follow a loose routine when working at home. These actions ensure that I’m not letting my own personal standards slip and that I have a level of structure to my working day, while at home.

I tend to stick to this daily routine more or less, there are occasions that timings slip but I don’t let myself feel bad about that:

0700 – Morning Dog Walk
0730 – Breakfast including reading a selection of blogs from my backlog
0830 – Showered and Dressed for work
0900 – Get into my office and fire up my laptop
0915 – Daily Stand Up
1230 – Lunch (Timing dependent on the morning meetings or tasks )
1700 – An hour of personal learning

I only have semi-set times on the things that I can control, every day is different in terms of the work that I’m doing so those activities are harder to predict. This might seem far too rigid for a lot of people but if you look back and analyse your day in the office you may be doing something slightly similar without even knowing it.

Feeling like part of the team…

In your office environment, people can physically see you with their own two eyes, remote workers don’t really have this as an option. Members of my team obviously know that I’m working because they would have seen and spoken to me during the daily stand up but after that call – It’s very easy to become invisible. I love talking, I’ll talk to anyone so I’m often on a text chat or video chats with my developers. Collaboration is key and the only way to ensure that we’re all talking to each other is by…actually talking to each other!

We use Hipchat as our main method of communication, every team has their own room that people can drop in and out of if they need anything but teams also have “banter” rooms where its open season. I work with some very funny guys and if I haven’t laughed at least once from something that has been posted to the room, there’s something going wrong.

I also stay very active with people outside of my team, this can be asking questions in the other rooms or responding to other people’s questions if I know that answers. I love to try to improve things for the test team at NVM, I have created a personal Trello board with areas that I would like to make changes – Communicating these ideas and changes to the team via Hipchat or Emails, has indirectly made me more visible. It’s also made me feel less isolated and part of a bigger team.

Access to all the things…

A big part, for me, in knocking down any home vs office mindsets is ensuring that I have access to everything that I can get my hands on. I don’t want to every use the excuse of “I can’t get to that internal page from home” – I don’t ever want my location to dictate what I can and cannot view. Nothing is impossible to get access too, it may take a little time and effort but it’s not unachievable.

I’m inquisitive and I also love having control over my own environment, If I can’t get to an admin page on the local network because the firewall is blocking me from doing so at home – I’m going to be contacting the relevant people to set up a proxy or provide me with a workaround. You never want to feel reliant on someone in the office to make changes for you, you lose the element of control and that’s never a good thing.

One person is remote, we’re all remote…

I’m not the only person in my team that works from home, during the week we will have at least 1 person from the team at home. We have an ethos within my team, if one person is remote then we are all remote. This basically means that all of our meetings are done online and not in an office meeting room. We could only have 1 of the team at home and the rest in the office and we will all still jump on the call individually. This ensures that we can all hear and see each other, one person will share their screen so we are all looking at the same thing – It works really well for us and saves us all fighting to hear each other in an echo-filled meeting room with terrible audio and visual equipment.

This has really helped with things like 3 Amigos, Sprint Planning and Retrospectives. We are able to have a productive meeting rather than fighting with any sort of tech issues or getting access to meeting rooms. Personally, I feel that we are more focused and productive during our meetings.

The challenges…

Currently, we’re in a very good place. We all know what call to be on and at what time. We have team specific permanent Skype links that we always use or tools that we know work for us to achieve a certain goal. I don’t ever feel like I can’t get hold of someone quickly or feel like I’m on my own. It hasn’t always been this way…

Working from home used to be a very painful experience, I remember a couple of things in particular. We would have our morning stand-up meeting in the office, the guys in the office would gather in a circle and run through the standard set of questions. We had 1 person remote working so we would grab an Ipad and dial them in via Hangouts. We would then pass the Ipad around like “pass the parcel” style – god knows why it even began let alone lasted for as long as it did! Another painful one was everyone using their own favourite tool for communication, at one point I was monitoring…Lync, Hangouts (lot’s of different ones), Hipchat, Email, GoTo Meeting – it was insane!! I don’t know how we actually got anything done!!

One last thing that we have thankfully sorted ish, the audio and visual equipment in the meeting rooms was very poor – Pair that with the dodgy network at the time, this made being part of meetings a non-event. I had several occasions where I just dropped out of the meeting completely because is was absolutely unworkable.

Not everyone in the business likes remote working, your company may have a culture that lends itself to this way of working but companies are made up of people. If they have had a poor experience of remote workers in the past, it’s very difficult to change their mindset.

Things that have helped me the most…

  • Invest (get your company to pay) in a decent Headset and Camera – I had a rubbish headset and my laptop webcam was pointed at the side of my face. As soon as I got some new ones, conversations and meetings were 100% better!
  • Try and organise an office day to get the whole team together. Make it a social event and not just about work. Get to know your team mates!!
  • Have a space in your home that’s just for work – avoid working in your family space. You need to have a clear divide between the two or you never really finish work for the day. Leave work at work.
  • Have patience – People in the office are not actively ignoring you. Their status may say that they are free but they could be talking to someone at their desk. If you really need them, try speaking to someone from another team and ask them to get “eyes on” they can give you a much clearer picture of the office.
  • Don’t be afraid to leave your desk, people in the office do it all the time. Don’t feel like you’re doing something wrong by not being chained to your desk.

I can’t tell you how to succeed at working from home, there’s not a one size fits all approach to it I’m afraid. Experiment with different things and see what works and what doesn’t work for your team. Good luck and if you ever need to speak to someone, give me a shout on Twitter or Skype and we can have a chat about it! Always remember, you’re not on your own.

 

Everyone loves a bit of Bug Magnet!

I’m still in the random data creating mood, so I thought I would extend my last post slightly by showing / explaining how you can quickly add some of the random data that you have created, into Bug Magnet as a custom config file.

If you haven’t heard of this Chrome and Firefox extension…where have you been?! I’m a huge fan of this tool, it’s assisted me during numerous testing sessions since I discovered its existence.  A while back, a new feature was added allowing you to add your own JSON files  – This was a game changer for me, It allowed me to create lots of different custom files specific to my context, for me to use whenever I needed too. Adding and Removing Files is soooo quick and easy that it really makes having something this valuable in your testers toolbox, an absolute no brainer.

A better explanation of what you can do with Bug Magnet can be found here. Neil Studd is extremely good at walking through how you can/could use the tool.

Let’s extend what we have already…

Open a command prompt or terminal, in the directory where you saved the random-data-generator app (Go and check out my last blog post if you’ve forgotten already). We’ll need to bring in the jsonfile module to our app, this will help us create the file that we can use with Bug Magnet.

Type the following command and press Enter. This will install the module and also add it as one of the dependencies in our previously created packages.json file.

npm install --save jsonfile

install_jsonfile

Once that has finished installing, it shouldn’t take very long, create a new file and save this in the random_data_generator directory. For this example, I’ve named the file cardDetails.js. As you can tell by the name, this will create some random payment card details.

Add the following code to the new file:

// Dependencies

var casual   = require('casual');
var jsonfile = require('jsonfile')

var file = 'cardDetails.json'
jsonfile.spaces = 4

// Random Card Data Set

casual.define('cardDetails', function() {
 return {
     Name        : casual.full_name,
     Card_Type   : casual.card_type,
     Card_Number : casual.card_number(casual.card_type),
     Card_Expiry : casual.card_exp
   };
});

// Write the result to a json file

jsonfile.writeFile(file, casual.cardDetails);

Like before, I’ll briefly explain what’s going on here – At the top we are bringing in the modules, casual is our random data helper and jsonfile is the module that’s going help us out with creating the JSON file (Say’s it all in the name really). Next, we have the file variable and this, as you would have guessed, is where we are naming the output file. At the moment this is just getting saved to the root directory of the app but you can specify a location anywhere on your system if you like, entirely up to you. Just down from this is the spaces that you would like to set, I’ve set it to 4 on this occasion as the default value is null and 4 gives you a lovely pretty print feel. Have a play about with it and set what you think is right.

In the middle of the file is the meat of the operation, this is creating your random data. Previously, we used user data and saved this in the user.js file, I’ve just mixed it up a bit and used a different data set. Lastly, we have the line that will write all the output to the JSON file.

Time to create the JSON file…

In a terminal, type the following command and press Enter. This will do the business and create the JSON file.

node cardDetails.js

create_json_file

You should now be able to navigate to the file, in the location that you set in cardDetails.js and it can be opened up in a text editor.

The cardDetails.json file will look something like this (with different data obviously).

{
    "Name": "Kristopher Hickle",
    "Card_Type": "Visa",
    "Card_Number": "4485446830945271",
    "Card_Expiry": "04/17"
}

Add the file to Bug Magnet…

I’m assuming that you have the extension already installed, if not, go do that now.

In the Chrome browser type chrome://extensions/ into the address bar and press Enter, Select the “Options” button on the Bug Magnet extension. 

Select the “Add Configuration File” button.

bm_add_file

The Name that you enter in this field, will be the name that appears within the context menu in Bug Magnet, next to the default ones (Names, Cities, E-Mail addresses etc.).

bm_name

Press the “Select File” button and navigate to the cardDetails.json file. Select the “Open” button and this will then add the new config file to Bug Magnet. That’s it, it is now ready to be used in anger against the site you’re testing.

We’re now done – I’ve taken you this far, it’s now up to you to create the data and start using it in association with Bug Magnet.

To finish off…

These guides are obviously very basic and full of potential problems, I can see loads myself. They are not intended to be perfect, I view them more as a helping hand to get you started. Even if you don’t follow my method of creating random data, please do go and check out Bug Magnet – The default data that comes with the extension has found me so many bugs over the last couple of years!! At NVM, we have created our own repository of JSON files that is in a shared location, these can be tapped into and used by anyone, not just testers. All we need to do is import them into Bug Magnet before a test session and we’re set.

I created a really poor set of instructions for my team on how to create these custom files (using manually added data) a while back – you can find them here.

I’m still learning how to use GitHub and I continued my learning by trying to add all the files I’ve mentioned in the blog posts to a new repository. I think I sussed it but there are a few dodgy commits on there – Feel free to take a look here.

I’ve enjoyed writing these, it helps cement in my mind what i know and whIt i need to improve on, thank you for reading!!

 

My own personal Testability experiment!

Two weeks ago I decided to focus my learning on a particular area each month, historically i’ve been rubbish at concentrating on one thing. Testing is so vast with lots of different interesting areas to research it can become a little overwhelming at times. Something had to change for me:


I wanted the choose a subject that i was aware of and what I thought i knew it to be but i was never too sure about how wide it stretched. Testability was going to be the main focus!

I had a basic plan in mind – Split the month into two parts. The first 2 weeks will be research and observation (My team and the wider Test Team) and the second 2 weeks will be trying to implement some improvements or make improvement suggestions. The test community has massively helped me during the research phase, there’s many great things that have been written about Testability over the last few years and these normally reference other articles or conference talks so it’s actually been a really enjoyable experience discovering a bunch of very interesting things.

Here’s a list of the Blogs, Articles and Talks that i’ve read over the last two weeks:

Blog Posts

Articles

Models

Conference Talks

It’s going to be an interesting couple of weeks coming up, I’m planning doing a follow up post when the time is up to explain what worked and what didn’t work. I’ve had a lot of fun concentrating on one area, i’ve slipped up a few times and wondered down different paths but i’ve been focused enough to indentify these lapses and then got on track.
Huge thanks must go out to Huib Schoots – His Great Resources page was the starting point for my research.

Does anyone else take a similar approach to their learning or maybe you have a different method? I’d love to hear about it!

Creating Random Data on my Lunch Break…

A few days ago I read a great post by Alan Richardson called “How to write a simple random test data sentence generator” and i loved it, it’s exactly what I try and do all the time. In my current context, data is king, without data flowing through our service we effectively have no service. While testing stories, I create tools that do loads of little things but I have a selection of ones that create specific test data. Now, I’m not a developer, I don’t have any sort of development background but what I am, is an inquisitive learner.

I love writing code, not because I’ve been made too or I’ve been told too by my company so that I can automate all the things, I do it because it’s fun! I get a massive sense of achievement when I’ve had an idea for a tool, wrote some code and it’s worked!! It’s not the best looking and most efficient code but it’s my code and i’m proud of it!

So where was I, the random data generator – I read Alan’s post just before lunch and just before i tucked into my food i wrote a very basic app that spit’s out random data. All in all it took me less than 5 mins, it was done as a kind of exercise to prove that absolutely anyone can code something that creates test data. Don’t be afraid of just giving something a go, you might actually surprise yourself!

*This is wrote using Node.js but there’s probably tons of modules and libraries in your preferred language that will allow you to do the same thing*

We need to start somewhere…

In order to get your hands on this random data you’re going to have to download Node.js it won’t take very long and it’s so worth it, not only for this but for many other awesome things that you can create using Node.

Once you have it installed, type node -v into a command prompt or terminal. You should be presented with the current version that you have on your machine. If you’re not seeing the version, don’t panic, you might have to add the node directory to the path environment variable. You’ll find loads of step by step guides for this if you Google it.

node -v

node_version

Let’s do the code part!

So first things first, we need to create a new directory for your new and wonderful data generator to live. Open a command prompt or terminal (you may have one still open) and enter the following commands, as seen below. It’s entirely up to you what the root directory should be, after all, you’re doing this on your own machine.

mkdir random_data_generator
cd random_data_generator

*You don’t have to create this but I just like creating it so that i can give the app to other people*

Next, we need to create the package.json file this is the config file for your node app, it lists all the dependencies that you have in your project and also a bunch of other stuff you may need to add, as the app starts growing legs. You can read all about what this file is and what it does here but for now, we’ll crack on…

In the terminal enter the following and press Enter. Press enter through all the questions and type Y or Yes at the end.

npm init

Now we have that json file created we need to bring in the node module that’s going to do all the leg work for us and create the random data. Casual is a great helper module that rapidly speeds up the process of creating random data. There are a couple more great modules out there that do the same thing, like Chance.js and Faker.js but were going to use Casual this time because it’s the first one I thought of and I’m writing this post so that’s what you’ve got!

Install Casual by entering the following command into your terminal and pressing Enter. The –save in the command adds this module to the packages.json file, honestly, go and have a look if you don’t believe me.

npm install --save casual

When it has finished installing the module, leave the terminal open as you’re going to need it in a few mins.

Create a new file with your favorite text editor (Sublime Text, Notepad++ etc.) and save this in the new random_data_generator directory. For this example, I’ve named the file data.js but you can choose a name that’s more relevant to you.

In the file add the following code…

 // Dependencies
var casual = require('casual');

// Using the module to create random data
var number = casual.array_of_digits(n = 4);

var name = casual.first_name;

// Log the result
console.log(number);
console.log(name);

There are a couple of things going on here and I’ll explain (probably really poorly) what they are, so starting from the top, the first line after the comment brings in the Casual module so that we can use all of that goodness. Next, in the middle section, we’re using a couple of the in-built Casual functions that will create the random data and assigning these to the variables. Finally, we are just logging the output in the console. Very basic and extremely simple.

Using the terminal that you previously opened, type node data.js and press Enter to run the command. If everything has been setup correctly, you will be presented with some random data. It’s as easy as that.

data_output_02

 

If you create another file in the same directory and save this one as user.js I can show you a simple way of creating a set of basic user data. Add the following code below to the file and hit save again. To get an idea about what you can do with the Casual module, check out the documentation.

// Dependencies
var casual = require('casual');

// Custom Data Set

var password = '#A#B#C#D#E#F#';

casual.define('user', function() {
 return {
 Firstname: casual.first_name,
 Lastname: casual.last_name,
 Password: casual.numerify(password)
 };
});

// Write the result to the console

console.log(casual.user);

What this file is doing is creating a data set, defined and configured to your needs. Using the define function of Casual you can package this all together in a lovely little ball and do what ever you like with the output. On this occasion, I’m just logging it out to the console again. There are a few other things happening in this data, i’m using a couple of other inbuilt functions to create a different (very rubbish) password.

In the terminal type node user.js and press Enter to run the command. There you go…some more data for you!

data_output

Where do you go from here…

As you can tell this is very basic and the only thing it really does is print data out to the console – Not that helpful. This was only ever a 5 min task to quickly knock something together, we can expand this out to push the data to a certain file format that your system uses or feed the data into an already established test tool that you have been manually creating random data sets for, etc etc….I like the idea of creating Json files that can be added to apps like Bug Magnet so that you have the data there for you, while you’re doing an exploratory session.

We are only ever limited by our own imagination so it’s entirely up to you where you go from here but i’d love to hear about it so drop me a message!

*If you really can’t be bothered to create a tool yourself – Just Google “Random Data Generator” there’s bloody tons of them knocking about!!

Cheers for reading!

I now have a follow on post where you can put some of this beautiful data to good use…https://dannydainton.com/2016/09/28/everyone-loves-a-bit-of-bug-magnet/