Life as an Apprentice at Bullet Digital Solutions

Where I Started:

I started an apprenticeship here at Bullet Digital Solutions just over a year ago in software testing. Before I applied for the job, I hadn’t really heard about the testing phase of software but since then I have learned that there is actually quite a lot that goes into software testing, the different ways you can test things and the different testing techniques you can use.
Most systems should be tested using both manual and automation testing processes but depending on the systems you build and your development process would determine the ways you use automation and how you use it.

A couple of terms and their meaning…

Manual Testing: this is the process of testing something by clicking around, entering data and performing a variety of functional tests one by one.
Automation Testing: this is where you write a script which will perform a particular process and use or create sample data. Once created the test can be run via one command and the outcomes noted.

When and Where I use Manual Testing:

Since I started most of my testing is done manually. Every time I’ve been given a new project, I start by learning the software functions and then testing it in-depth, manually. Only then when I need loads of test data do I start to write out automation scripts for that or create some automation tests to check the functionality of the site. Then when there are things that need to be tested quickly, I mostly check these manually, unless it is covered by an automated test. The automation tests are then run each time that there is a new release of software or as a new big feature is added, as regression tests to ensure that the main functions of the site are all still working properly.

My Apprenticeship Learning:

The other part of my apprenticeship is the learning side. Having come from school and then a brief stint at college, I was thrown into something that had little to no structure. To begin with, it was a bit vague with what I had to do to cover the 20% learning time that was required this was covered with the time spent on courses up in London and any time I spent writing out statements. Some of this time was then also covered when I sat researching something or learning something new, like automation testing.

One of the courses I attended was an automation testing course. During this course, I was told a lot about the methodology and the best practices for automation – as and when you should use it. Little was shown about how, but after the course, I then came back and started to research and look into automation testing a bit more.

How I Started with Automation:

After researching and watching videos, I decided to give it a go. I think the first script I wrote required logging in and searching for a client used in one of our systems. I managed to get it working, but it was a long horrible piece of code. Since then, I’ve written different scripts for different sites and have created a whole suite of tests for one project. The most beneficial use of automation for me was to use it for generating test data. This can be a much simpler process when you generate some random data and get it to create a user for you. Otherwise, I have mostly used the power of automation for scripts to help with the maintenance of the site – creating something that runs all of the main functions quickly to ensure they are all still working.

Here is a clip of one automation, this creates a referral for a client within one of our systems…

How it Works:

Automation works by the script launching its own browser window and then working through this window to test whatever site you want. You can control the way the browser works, make it wait for 5 seconds, or open a new window or tab. You can get the browser to find an individual element (being a button for example) and then you can work with the element in different ways: such as click it, input certain text into it, or just get the text from the element to use in the script (checking a certain user’s name appears when you search for it). I began testing just looking at checking the general processes, but when it came to creating some test data, I realised I needed to create a general log of the data I created somewhere as well as using lists of names or random options to generate random data. This meant I had to look into how you can integrate using excel spreadsheets within the automation script.

Using Excel Spreadsheets within the Automation:

You can use it both ways, generate something random using data from the script, or outputting a result of something to the spreadsheet. This meant I could create a spreadsheet that included a list of random names, the automation would then take these names and randomise a choice of forename and surname.

This was then written back into the spreadsheet to record the user I had just created. This is where I found the automation most effective as it meant I could quickly create a new user etc to use in my manual tests, or within the other automation tests.

Managing the Struggles with Automation:

I kept to the basics, to avoid a waste of time as well as keeping things simple for other people to understand. There is a fine line between creating a good handful of automation scripts and not wasting time doing so. In the long run, automation intends to save time with the maintenance of the system rather than wasting loads of time while creating the scripts because you’ve gone overboard and created too many, or made them too in-depth and complicated. I did my best to create scripts that didn’t take up a lot of time when creating them and were simple enough to maintain, otherwise, I’d end up wasting time with the automation scripts rather than saving time. It was hard to draw the line though as there are many possibilities with automation and the ways you can use it but I will look into all of that another day.

How I Strive to Continue Using Automation:

With one of our projects, I adapted the way I used the spreadsheets with the scripts and linked one sheet up to all of the scripts and used it as my own logging process. I decided to add in statements so that it could tell whether the test passed or not – eg, whether the test was able to create a new user. This would then be recorded in the excel file. I also record the current date to the spreadsheet under both when it last passed, and when it was last tested. This spreadsheet then acts as an overall test process for that whole project. This means we are able to quickly check the last time that a function was working and run the tests again if needed.

In Summary:

Overall, automation is definitely one of the most valuable things I’ve learned while on this apprenticeship as it provides such big value to the testing and maintenance phase of the product production. It did take me some time to learn the basics and to figure out the best way to use it but it’s definitely beneficial, especially with how quickly we can now check that the basic functionality is still all working. The overall spreadsheet is definitely something I’m going to always use and carry across to other projects because it provides a central knowledge of when things were last working as well as when we should next check these things.