Tuesday 7 June 2016

The Copinator!


As a tester, I spend a fair amount of time testing the CMS and also user fields. While testing these fields, I spend a lot of time copy pasting different character types into the same fields in an attempt to ensure they will all work as expected.

I noticed this was using roughly the same characters across different character sets and wanted a consistent and easy way to produce the letters required instead of searching for them every time either in documentation or on the web. So I built a desktop app!

Its nothing sophisticated, just copies a set of characters to the windows clipboard. but saves a lot of time finding these things!

This is going to make using the fields quicker to fill and test, which is a big bonus as it can be passed onto the rest of the test team and everybody will have access to all the character sets that I use.

I have also asked for feedback from other members of the team, for character sets that they use in other projects so that they can all be added. this will allow everyone to see what the other teams are using and use their character sets as an inspiration to further test their own work.

The only negatives I can think of using this is to not become complacent in using our own imagination to find the edge cases and relying solely on the app, not a good idea! The other drawback is a small amount of refactoring if the characters change that the (Testers/ Developers) use, then it will need updating and redistributing.

But overall I think this is a nice time saver!

Leadership Update..The bigger picture

It has been a busy couple of months for the project, multiple streams of work happening at once.

Sometimes taking a step back is a really nice thing to do, allow the other members of your team take stories that you could be doing while allowing you to get the bigger picture of how everything is going to fit together. This can allow you to resolve issues found before getting more people involved meaning leaner testing times and quicker story delivery.

I tried to explain my recent example of this but it got complicated and confusing :) this is a simplified version:

A was trying to talk to B through C
B required something from C that it was not passing through
B rejected C so A could not happen.

We passed A by skipping C as it was just a middle man, but could have spent a lot of time debugging A if we hadn't seen that B didn't need the required variable (even though it was in the requirements!).
B got the variable removed by the developer.
A Could be passed without the completion of B.

As the streams of work are quite close at the moment, passing on knowledge of what the each tester is doing is quite important as shown with the example above, both parts A and B were implemented at the same time by 2 sets of people meaning communication is key :)