Responsibilities of a Software Test Engineer

Written by Heather Flockton, Bluefruit Test Engineer

Hi, I’m Heather and I’m a Test Engineer here at Bluefruit. In this blogpost, I’m going to explain what Test Engineers at Bluefruit do, and how this can be of benefit to both software teams and clients. Testing is a vast, and tremendously important topic in software development. To be a good tester, you don’t necessarily have to know how to code, though you must be extremely inquisitive and have a good eye for detail.

We aim to have a ratio of one tester to two developers, and our main role is to assist the team in achieving the highest quality in our software releases. In order to achieve this we need to have a deep knowledge of the project and the products we are working on and have regular involvement in client liaisons.

Testing in an Agile World

In much of the world of software development, it’s not uncommon for testing to happen at the end of a project, after weeks or months of work. Even some Agile software teams still test at the end rather than at each sprint (or even in the middle of the sprints).  However, at Bluefruit we believe in being Agile at every layer of our process, which means testing thoroughly throughout and using Test-Driven Development.

To establish what the development criteria is, we have a 3 Amigos meeting with our client, the lead Software Engineer and a Test Engineer, this is the minimum number of attendees (often they feature additional attendees). During the discussion, the Amigos work together to outline a selection of features, implemented by the Software Engineers, and their acceptance tests, carried out by the Test Engineers.

The main benefit to this methodology is that it is iterative, allowing for extreme flexibility and delivery of high quality software. Activities can be regularly communicated, reviewed and adjusted to suit the requirements of the client. Each project is completed in sprints; typically, a two-week cycle of processes resulting in a software release, a detailed test report and a demo video.

Types of Testing

At Bluefruit we carry out a range of different type of tests, by both Software Engineers and Test Engineers.

Software Engineer tests include the following:

●  TDD (Test-Driven Development): A test is written and made to fail, then code is written to pass that test. Do you like to know more about TDD? Please have look at this blog on TDD .

●  Unit Tests: Unit tests are run when software is built. These are often the tests written during TDD, but further Unit Tests are sometimes added, dependent on the project.

●  Code Review: When a feature is completed, it is checked over by another software developer, before it is merged into the rest of the software.

Tests carried out by a Test Engineer include:

●  Acceptance Tests: These are tests that confirm the features from the current sprint are performing correctly and match the specification.

●  Regression Tests: Acceptance testing covers only the current sprint. Regression tests are done to ensure that previous features have not been affected by recent work.

●  Exploratory Tests: Though all the features may be working correctly, it may be that other behaviour is incorrect, this is often discovered with Exploratory testing.

Mid-Sprint Testing

From the moment the 3 Amigos depart, the testers at Bluefruit busy themselves with research. Though the developers are writing the software, it is often the testers that hold the broadest knowledge of a project and the products, as they are constantly thinking about the entirety of the product and all it’s functionality, unlike the developers who concentrate on the components they are writing.

As the software develops, the Test Engineer is involved in expanding and refining the suite of acceptance tests that, alongside the Unit Tests will uncover any bugs. As each feature is completed, it is “Mid-Sprint Tested”, and “Defects” are raised if any bugs are discovered. These defects often are resolved within the sprint, otherwise they are discussed with the client, and dealt with accordingly.

Release Testing

When the developers finish a sprint, their releases are tagged, ready for “Release Testing”. Once testing is complete, a detailed report is completed by the Test Engineer; the software, release report and demo video are then forwarded to the client.

Release Report

The release report is somewhat like a receipt; it details the features that have been included in the release, and the way in which they were tested. The report may include other tests such as remaining Defects, Unit Tests, Regression Testing, Exploratory Testing and more.

Demo Video

Here at Bluefruit, we are aware that not everyone is acquainted with technical jargon but may have a vested interest in the project. Alongside the written report, we provide our clients with a demonstration video, showcasing a selection of the main features included in that release.

Retrospective

Following the release, a Retrospective meeting is held, ideally joined by our clients. Each party is given the opportunity to discuss the success of the recently elapsed sprint and outline any potential upcoming adjustments.

Testing that matters

As you can see, at Bluefruit testing is far more than a last check, it is at the core of everything we do. It is the constant check that what we are creating for our clients not only achieves everything they have asked for, but that it is also reliable and durable.

Our thorough practices give us robust code that our clients can trust and our extra work providing documentation ensures they have a record of what’s been done and evidence that it works. Beyond ticking boxes, our testing provides our clients with a reassurance that the software works and will continue to work well into the future and is part of our commitment to quality code.