Krystsina Sauhen has been with Godel Technologies for over 5 years, as part of the quality assurance team. She recently a transferred from manual testing to automation testing, and now officially represents Godel’s QA division, as a Junior Specialist for their SDET stream. This required Krystsina to change her ways of working; her thought processes as well as her work processes, which has undoubtedly been a challenge. We discussed the changes, as well as the challenges, which have occurred along the way.

Krystsina, you have quite a lot of experience in manual testing. What was the reason to start digging into automation?
More than two years ago I started thinking that I wanted to further my knowledge in regards to automated testing as at that time, nobody had such a role in my team, and so I began talks with my Talent Manager. While this was happening, the client had chosen to introduce automation testing into the stream I was working on, meaning I was able to further my knowledge without having to change engagements. The industry is beginning to see a demand for both manual and automation skills, and I would rather be ahead of the game, so I’d say this is what sparked my interest.

If another Manual QA had the same idea, and wanted to transition to Automated QA, where should they start?
Personally, my transition to automation began with reading. I needed knowledge of some programming language, so I looked at the different directions and different tools in automation. The more I read, the more I began to understand the principles of automation and found that I liked it…so I decided to take the leap. I didn’t have a mentor, but when the client decided to introduce automation to the workstream, it was their Chief Architect who decided on the technology and approach we would use before sitting down to draft the framework. My responsibility was to sketch the basic architecture in Python and present the strategy. Following that, the manual QA on the client’s side joined me in organising tests for new product features.

I found it quite easy to pick up automation for Python, so I was able to get involved quickly. At first, we only dedicated around 20% of our time to automation testing. Once this had increased to around 50%, the client hired a further two developers to help facilitate this.

By this point the team was formed, and we travelled together to visit the client in London to expand our knowledge of Python. During our time there, not only did we get to know each other, but we managed to determine our next steps and increase our capacity to 70% automation. However, I was still involved in manual testing.

Six months later, I was appointed as a technical lead for our automation team, thanks to constant practice, training and general experience in my team.

How hard is it to jump from Senior Manual QA to Junior SDET and almost feel like you’re starting all over again?
I think this comes down to your determination and attitude towards work, and thankfully this isn’t something I struggle with. At the beginning of the year, I asked my Talent Manager at Godel to check where my progress was up to, in relation to our other automation engineers. It was interesting because although I am engaged in automation in the workstream, we started from scratch, and I am somewhat self-taught. Despite this, my Talent Manager agreed that my skills had vastly improved. Thanks to this, I recently officially moved to Godel’s SDET Stream QA Division with a new title – Junior SDET.

The most helpful thing to come from this assessment was the detailed explanation of where I could improve further. I now have a Talent Manager from the SDET team assigned to me, who helps me direct my work towards closing these gaps. I am very driven towards my goals and striving to improve my position.

Given that you were one of the first developers at Godel to transition from Manual to Automated QA, what were the main challenges you faced?
The main difficulty was precisely the lack of experienced people in my team from whom I could learn. Teaching yourself is like constantly stepping on a rake. Naturally, this takes longer, as with technology, things are constantly evolving, and I’d say keeping up with this is probably the most significant difficulty.

Have you changed your mindset from manual to automated? How do you now look at your previous position of Manual QA?
Firstly, I believe that learning automation should be tackled after having the experience of manual testing, because manual testing is closely involved in the software development process. I understand that it is different for every piece of work, but on our Manual QA workstream, there is more communication with developers, and with the BA. Additionally, manual testing allows you to work closely with the product and understand it from the user’s point of view, meaning you’re fully aware and aligned with the end goal. Therefore, you’re then able to help manual testers improve the quality of the product.

After expanding my knowledge, I took a slightly different approach in deciding what should and shouldn’t be automated. Before my experience in Manual QA, I would have thought that more products should undergo automated testing but as a new SDET, I understand that this is not always best.

Being a manual tester is all about testing. A SDET – it’s more about testing or about programming?
I’d say it’s a bit of a mix. If a Manual QA tests a product and finds problems, then manual testing will ensure the quality of a product even when the software needs to be delivered at speed.

If the stream operates many releases per day, for example, 20, but there is a requirement to increase this to 60, then it is physically impossible to provide the necessary quality by using manual testing alone, which the client understands. In this case, automation would be essential to help ensure quality within the existing functionality. As for programming, this is simply just a tool, without which, we would be nowhere.

Do you think every Manual Tester should consider expanding their knowledge into Automation Testing?
No, not everyone. Naturally, everyone has their strengths and weaknesses. Some testers don’t enjoy writing code, and there are roles which would suit them ideally like manual QA. However, if they are interested in automation testing, they should take the time to understand how it can be applied in practice and what will change from their current role, and then tackle the technical knowledge. Otherwise, if technical problems aren’t your forté, then your knowledge will undoubtedly be better applied elsewhere.