Becoming an Automation Tester

Last year, I started a new role with nFocus as a Graduate Software Developer Engineer in Test (SDET). I had graduated from the nFocus Academy and this was my first assignment. The role was to be responsible for creating automated tests, undertaking exploratory testing and working in a team of experienced professionals.

1: Don’t be a stranger to your team

As the newbie on the team, it was daunting at first. I was thrown into the middle of a project, with a team that all knew each other. The temptation was to say little and avoid contact with others at all cost! But that was not going to work.

I took a deep breath and dived in, I was surprised at how quickly I was accepted and very soon, a mutual respect developed.

My approach was to collaborate with the team offering to help where I could. This was especially important with the developers. They may be the stars of the team but they needed my help to ensure their code was as good as it could be.

2: All code is equal, it's just that some code is less equal than others!

My team were more than happy to have me supporting them. After they finished a feature, I would test it for them. Much of the time the code was good and communicating this back provided assurance to the Developer, both that his code was doing what it should and that I was here to help.

Some of the code was not so good. So I needed to be very clear in what I reported back, I listed the issue and exactly how to recreate it; saving them a lot of time investigating.

I did find that I had to be assertive at times. Everyone is working to a deadline and it felt sometimes as if I was “pestering them” or that they may get annoyed if I was bringing up so many issues...which can happen!

I found that having built up a relationship with them and assuring them what was working first, made them more forgiving of my interruptions.

Obviously as a Tester, I mostly liaised with the Developers but I also found that my insights from a testing point of view bought a lot of value to other areas as well.

3: It’s all about the results

I work as part of an agile team who value getting results above following a strict process and that suits the way I like to test. My task is to ensure that the code is doing what it should and is not doing what it shouldn’t. I use a method of documented exploration through experimentation.

This is my usual work flow. I look for what is testable. I ask myself questions such as:

• “What should be happening here?”
• “What action would prove or disprove this function is working correctly?”
• “Who or what is performing this action and why?”

If something is not clear, I ask a BA or the Developers if they can explain it to me in more detail.

4. Documenting your findings

I use notepad to document what I expect the result of my test to be, what is the success criteria that needs to be met.

Having something written down helps me ensure that I don’t miss things when I am testing. I also find that when I have a list of tests, I am able to review them and that trigger other tests that I had not initially thought of.

5. Use the Acceptance Criteria guide