Relationships with developers

The good old Tester/Developer relationship. This is a tricky one for many reasons. It’s a known fact that in the Software Testing world some developers frown upon having their ‘homework’ marked. Ultimately it’s our job to find flaws with every bit of the application – it’s not personal – honest! If bugs didn’t exist, this would mean everyone is perfect. Of course we know this just isn’t true. Nothing is perfect (sorry to break it to you).

We are all here to do a job and by finding bugs in the system that is what we are doing – our jobs. This is a good thing, it means the software will go out bug free which is a benefit to everyone involved. This is one of the reasons it is important to involve Testers right from the onset.

Testing times always under constraint

This could be due to a number of reasons and is almost always not the Testers fault. Reasons could include:

• Incorrect estimation in sprint planning
• Reporting/Communication
• Team and capabilities
• Unstable builds or environment
• Unrealistic dates
• Not enough information in acceptance criteria

Testing always seem to fall under the spotlight when a project is behind. This is because Testers are the last in line before an application goes live. In most cases it’s not actually our fault we are held up in Testing. From my experience one of the main reasons is deployments and timescales.

If Testers are not getting regular deployments, this means all the Testing is backed up until we receive said deployments. The more regular this happens, the more up to date we will be with testing. This is one of the many bugbears we face as Testers.

Unstable environments

This is the bane of our lives! Seriously.

We could be part way through a suite of tests and all of a sudden, BAM, internal server error! The most hated 3 words you can see as a Tester. It usually means we have to restart all of our tests as we lose where we are or we have to wait hours (ok maybe not hours, but it seems like it) for the environment to come back up. This is wasted time for us as we can’t actually do anything and it’s cutting the testing time down to an even shorter timeframe.

No documentation

The classic. Many teams still believe in verbal communication and keep little reference material about how the software became what it is today. Rapid development cycles only made this more intense.

This means we have to research the application; set up references looking at similar applications and their standards. Understand the end-user perspective. Get adventurous with exploratory testing which in turn takes up more of our precious ‘Testing’ time. We also often have to sit with developers to understand how a specific piece of functionality will work once it is built as there is little or no documentation.

Some applications just don’t cut it

Have you ever tested or worked on an application and started to wonder,” How can this even be called software when it’s a bug producing machine?”

I work on a lot of projects that require ‘Minimal Viable Product’ which are far from perfect. It’s frustrating for us as Testers knowing that when we suggest a change to improve the functionality, this will mostly be rejected because it’s not MVP. This hurts us more than you will ever know! Well, it’s annoying at least!

Understanding the requirements

Well, this is sometimes just a minefield. Trying to tie down exactly what the Business wants/needs can be a challenge of its own. Then, getting them to explain or document this in a way we can create test cases from is another struggle.

We often just spend hours trying to decipher acceptance criteria or requirements just so we can understand it.

Testing on multiple projects

More often than not, especially here at cap hpi, Testers can be spread over 2/3 projects at a time. It’s quite hard to often lose focus having multiple projects to keep on top of with Testing. As much as we say we don’t favour one project over the other, this is a big lie! We always have our favourite projects and it’s quite hard to not focus more and provide more effort towards this.

It’s hard having to juggle between everything, as well as having time to fit in our other tasks such as development time, one to ones, automation, team meetings, script reviews and other admin tasks.

Summary

I hope you all enjoyed reading the article and it has given at least some of you a helpful insight into the role of a Tester. You never know, you may even decide to take a total different career path and become one! It's not all about breaking things though, we don't necessarily like breaking things, we just like to dispel the illusion things actually work!

Official Testing Definition

To tell somebody that he is wrong is called criticism. To do so officially is called testing.