Introduction: Harry Williams 

Hi! I’m Harry, I’m a first-class degree graduate in computer science and have been working as a junior SDET consultant at nFocus for just over 2 years! Throughout those years, I have thoroughly enjoyed my time from the SDET Academy to working with various clients in different sectors of industry. I’ve truly been able to build and improve on the skills that I learnt during university, as well as learn how IT works in the real business world. Software Development Engineer in Test Remote

As a junior SDET consultant, some of the projects I have joined have had established testing suites, and others have had me involved with creating test suites from scratch. For all these projects, I have used automated testing, which has really helped me push my code writing skills.

However, no matter the starting point of the project, there are a few things about starting a new project that I have learnt from my experience. Hopefully, with this blog, I can help you avoid some of the feelings of nervousness that I felt and impart some of the things I have learnt and how to get to know the ins and outs of your projects!

Blog Duet Part 1: Exploring Systems & Enhancing Skills: My SDET Experience

1. Start by Exploring the System

When I am on any project, my first step is to explore the thing that I will be working on. In this instance, it's a website. I will look at all the big, important tabs and consider various questions, such as: What does the company that I’ll be working with specialise in? How does a customer use these?

My experience so far has been working on a system that I initially knew nothing about; some have not even been a system that is commercially used. Unless I am working on a site that I’m very familiar with, my knowledge of the system at the start of the process will be limited.

By exploring the system, I am in a much better position to understand and perform the tasks that I am asked to deliver. For instance, if I need to write a test in an accounting section, it's a lot easier to understand what I need to do if I’ve already explored how the accounting system works, as it’s very useful to have a knowledgeable place to start from.

The exploration of the system not only helps to remove some of those nerves from working in a new environment for a new client, but it also means that I’m better able to create high-quality tests more efficiently. At this point, it should be noted that good practice says that there should also be documents like designs, user stories, and requirements available as well; however, across the projects I have been deployed to, the client’s system had been established for a long time, and this hasn’t been the case. 

There may be manual test cases with detailed individual steps that will help you get this background knowledge. The disadvantage of lack of designs, requirements, or tests was partially resolved, as every client I have worked for has started with them showing me the main parts of how their system works on a call; at that point, communication skills could become key.

If a meeting like this is not suggested for you, you have two options: ask for the meeting yourself or suggest that you will need to speak to the development team to ask more questions so that you can get a clearer understanding of the system. Whichever option you choose, you’ll need confidence and good communication so that the client understands why it’s necessary.

2. Don’t Hesitate to Ask Questions

Even after you’ve been provided with the information and overview, some things may still not make sense to you, especially if your project is in a new area that you are unfamiliar with. This is when it’s helpful to start building relationships with your fellow project team members and to start asking them questions about it.

Within the team, there will be people who understand the system and environment and who will be able to answer the questions that you have. Identifying these people early on means that you will be able to call on them if ever you need clarification on a point and will be able to create tests more efficiently as you know what is required.

3. Build Strong Communication and Team Integration

As a new starter with the client, team, and project, one of the hardest things I found was feeling part of the team. This is because across the board, the companies that I have worked on have been working on their systems for a long time; the development team is well established and therefore knows each other and their roles very well.

It's often very important to understand who is in the clients’ team and how they correlate to your role and how they can help you with any questions about the system or problems, such as bugs, that you might face.

For example, with my previous client, one member of the team was a manual tester who was my conduit for queries for the developers. This meant that if my tests found an issue, I would report these problems to that person, who would then pass it onto the developers.

I could also check with that person that the problem had been resolved, or when they would expect that it would be. Having someone with whom I could directly discuss progress and issues made me feel more like part of the team and made me feel more confident on the new project.

4. Contribute Your Ideas & Seek Feedback

Finally, now that you know the team and have a very solid understanding of the system that you will be using, you can start to give some ideas of your own. As mentioned before, sometimes you will not have a step-by-step test case to work from; instead, you may just be asked to “create some tests for this part of the system.”

Without this understanding and without communication to other members of the team, this could be a challenging situation, especially if you’re working in an area that you know nothing about.

With this knowledge, however, you can start to build the test script yourself. Once this has been done, you can, if you are in a large enough automated testing team, check your work over with your peers to ensure that it makes sense from a “testers eye,” and then ask for the approval of a member of the team who does know the system like the back of their hand.

I have learnt it’s important to get this approval first because if you just storm ahead and create the test itself, you might find that while you’re on the right path to what the test to cover, you haven’t quite hit the nail on the head.

By asking first, you can be steered on the right path before you’ve spent a lot of time on the test itself. It’s basically a mini-agile methodology.

Conclusion

In this blog, I have advised that you get to know everything you can about the system, including exploring the ins and outs of it and, if provided, looking over any documentation you're given access to.

I’ve also highlighted the importance of communication and how you should ask questions to gain a deeper understanding of the system, as well as finding out where you fit into the team as a whole and who you can go to for help within the team. Once you’ve done this, I’ve also suggested that you then begin giving some ideas as well as seeking feedback from the team.

Hopefully following these suggestions will build your confidence, remove any nervousness, and reduce pressure. This and the fact that you’re learning as much about the system as you can should help you improve your skills and be able to create high-quality tests efficiently. 

In my next blog post, I will go over some more things to do when starting out on a new project, including some things that you could also do further on in the project’s lifespan and ways to set yourself up for that future! Thanks for reading!