AMA on All Things SDET with Sahil Puri

Welcome to the session on all things SDET with Sahil Puri, Tech lead Manager, at Zupee.

Before beginning the blog we would like to thank “BrowserStack” our exclusive sponsor for all events and Premier sponsor for all our conferences.

Sahil is a seasoned SDET professional with about 9.5 years of experience. He has worked with some of the Marquee companies like Adobe, Samsung, and dream 11, on which some of you would have made a team right now also Farm companies like Google.

Sahil is currently managing and leading a team at Zupee to create Best Class quality in the automation ecosystem, is extremely passionate about user experience, user First Development approach, engineering productivity principles, quality culture, processes, and CICD Pipelines.

Find Sahil on LinkedIn. 

Let’s get started!

Who is an SDET?

There are a lot of myths or different forms of definition that we’ll find today when we talk about what exactly and who exactly is an SDET.

Let’s take 2 minutes and go back in time and understand how this SDET role came into the picture.

The term SDET was initially coined in early 2000 by Microsoft and then subsequently picked up by other companies. This was the time when the agile Manifesto was being framed and introduced. 

The industry was going through a transition to improve the release velocity and also to be able to deliver to the client or the in a much more agile way. Testing was a phase, which is that part of the funnel where things became slow. So, any improvement here would have increased the overall Tech speed. 

So, the SDET role was introduced to bridge the gap between QA and Dev. This bridge would have constituted automation, coding, reading and writing skills, shift left, shift right, understanding the test pyramid, unit, integration, contract testing, and many other skills that would have ultimately helped in improving the overall release velocity and feedback times and so on.

Over the years, this role has evolved a lot and has been used in many forms across the industry finally able to see some consensus among the companies over the roles and responsibilities of this role right.

So, a very apt definition of an SDET is – 

An SDET is an engineer who can play almost every agile role with a focus on quality and user experience.

What are the skills required to become an SDET?

If you see any job description for an SDET role it sounds like a wide list and in reality, also there’s a wide list of skills that companies expect when you apply for this role. However, the top few mandatory skills you definitely should have before applying for such roles are:

First and foremost the fundamental core of this role is that you should be a great tester/with your testing skills.

Before learning anything, you have to clear your concepts of the testing fundamentals, like –

• what are the levels of testing,
• what are the different types of testing,
• how to follow the testing pyramid,
• and what are the different new processes that you can bring to test better?

The second is where coding comes even in this order.

•  While the first was being a great Tester, the second is about having an end-to-end product understanding, and this product understanding should be from the tech perspective – the engineering perspective. Like, what’s happening behind the curtains?
• So, this includes knowing your front-end or web application framework. Knowing your middleware, what cache layers, what DB layers, what servers, what’s the backend architecture that you’re using, and then applying all of that to your daily test plans and test strategies.

The third skill is product understanding, but this time from a non-technical, that is, business and marketing point of view.

There is one more aspect that most of us miss which is the requirement of being very comfortable with coding. It’s like the ability to read and write code, having your fundamentals revised, OOPS concepts revised, and we always use this term revised because we have all gone through the OOPS concepts and the fundamentals of coding at some point or the other in our education years. Then comes the practical knowledge of at least one automation tool, be it front-end or back-end or any form of automation that would give an idea about the 5H and 1W of automation like – when to apply, where to apply, what to do, and so on.

Last but not the least, it’s the kind of a role that has its edges around all the other different cross-functional roles, so you have to have clear, concise, and confident communication. And finally, the curiosity to learn and continuously evolve.

How many coding skills are required, and are DS questions on LeetCode enough to prepare for SDET Roles?

Let’s spend a few minutes and go deeper into the aspect of coding. So, first, you have to be comfortable around code, as mentioned earlier. It’s seen sometimes that test Engineers have a sort of repulsion and kind of fear of code. First, be fine around reading the code.

For that, what you can do is start reading the code of an existing automation infrastructure in your company. Or better than that, start reading the code of your developer on the ticket or the feature that you are testing. Ask for the PR from the developer, and understand what code is written. At the start, you might not understand anything, so it might take a day or a week or a month, or even a year for you to start understanding, but once you break that fear or that barrier in your mind, you’ll be more comfortable in having that urge now to write your own 10 lines of code or first code.

So, that’s the way you can be very smoothly introduced into the world of coding. That’s like the first part where people face repulsion, and they’re not able to cross that barrier.

How much coding or how many DS questions are required depends on the kind of role company that you are applying to. If on a generic level in the industry, having a logical mindset or approach is very much necessary.

For example, if in an interview someone is asking a coding question based on a tree or a graph or a simple array, they are judging you on three or four points and they are even marking you on three or four points. So, it doesn’t matter if you are not even able to reach a solution you might pass the interview. 

Some areas where you might be judged in a coding round, how many questions you asked after the interviewer tells you the original coding question; what’s your approach, are you comfortable with time and space complexity. Things like, are you comfortable adopting a new approach halfway; what is your patience level as a techie; then after you have written or tried to write a code or think of logic, what are the test cases you’re able to see because after all, you’re in SDET – a test engineer. So, what are the test cases you’re able to think of and your way of communicating, and so on?

These are all the soft skills and personality traits that you are being judged on even in a coding interview. So, you must brush up your logical skills every day either on LeetCode or any such platform, and slowly and steadily you will reach that point.

For someone slow in understanding the code, how can they stay motivated and keep learning?

Look, it’s like learning how to swim. It might take a day, a week, or a month or greater than that. But once you break out of that fear of water you’ll start playing in it, playing with it, and you will develop your method of swimming. That’s exactly the anecdote we want to portray for coding.

Yes, it might take a day or years or months some days would be you’re not able to think of anything or even understand anything. The next morning, you can understand everything depending on the state of your mind. So, to keep yourself motivated, foremost you have to change your mindset. You have to be ready to be out of your comfort zone and find the right sort of mentors for you. Having platforms, having paid subscriptions, and training is all one part that is very much required. But having the right set of mentors who motivate you in times when you don’t feel confident is the key to being up in the low times.

How to get business, technical or product knowledge when you enter a new company?

The meaning of this question has changed, especially in work-from-home scenarios. Normally when you go to the office you overhear and sort of develop your knowledge by just entering into the groups or having lunch, and some coffee chats, but in a work-from-home scenario, this has become exponentially difficult especially when you enter a new organization and too when you enter a startup with less or no almost no documentation and already set up processes. So, what is preferred is if anyone joins a team, the first thing is to understand the product, download the app, install the app and as a user try to use the entire end-to-end product so that you develop the user experience and user understanding.

Then use some debugging tools, again this might be very much specific to the product having front ends but use some debugging tools Charles or Fiddler so that you can see what network calls are being made. Now what we are doing is connecting the product or the business to Tech, now we are seeing, how the application or the product looks on the front and then trying to go into the back end to understand how that works.

The second most important aspect is collaboration and communication, so you have to be kind of a professional extrovert here and go out and reach out to people, leads and service owners from each team and not just Tech, from marketing, from a product, from project management and customer service and understand their role understand what are the key highlight problem that they are facing today and what can you solve, what can you bring to the table, and once you start that kind of Channel, open those kinds of channels and start collaborating with all the cross-functional teams including Dev, that would open a like a flow of the river of information for you both ways, and then you will be able to swim from there yourself.

How can you transition to an SDET role from a QA, and how to gain the required skills?

Let’s start by not assuming it to be a completely different role than a QA. They have an overlapping boundary, you have to understand that, so they are not the eastern and westernmost points of the earth, so let’s not overwhelm ourselves by seeing it as something like that.

The second is we have to be very clear and break the myth that SDET is not just about automation. Yes, automation is a very integral part of SDET, but it is much more than that. It’s a bigger role, it’s a universe.

Let’s also discuss how to make the transition while being on the job or playing your current role.

First, change your mindset. Be ready to get out of your comfort zone and find the right reason. Find your reason to be an SDET, that would keep you motivated.

Second, we can all start from even tomorrow. Go to the office tomorrow, and do what you have planned but, one level deeper. Test whatever you have planned but one level deeper and connect it to three nodes. These nodes are engineering, user impact, and last is business impact. Understand how whatever you are doing is working from the engineering perspective and the coding perspective. Determine how it is helping your company to create value, to create the business, and to create revenue.

Find out how the user experience will be enhanced when you release a feature to production. So, when you compare or dig anything with these three nodes you will be able to find better, complex, and hidden scenarios. It would help you to bring value to your organization and this is the first step of being enlisted.

The third is coding. Be very comfortable. Start with reading and writing code, take small patches of code that you can write and understand, starting from Loops to conditional statements, etc. and then try the platforms like leet code, and hacker rank, to solve more complex data structure-based algorithms.

After all this, you can start asking questions, and try to find that opportunity to advocate quality in different phases of a software development life cycle – from product management, to project management, to DevOps, and customer service agent. Try to build those channels, especially if you’re working in a product company. Making use of those channels as holding the flag of quality is everyone’s responsibility, that’s our ultimate motto. You have to ensure to build a quality-focused culture in each of these cross-functional teams as well as functions.

When you will be doing all the above points that we discussed, you will be falling short of time, you will be craving for something that gives you more time or saves you time and it is the best time to introduce automation. So, what you can do is start learning a Tool as per the project you’re working on parallelly and start automating it with hands-on experience. It would be the best way and that would also help you save time and apply it to some meaningful tasks in transition in your project.

Last will be the books – the resources. Which way you find your passion and find your habits linking to. Be very updated about what is happening in the industry, subscribe to newsletters, to keep yourself updated, watch Tech talks, join these communities, attend events, and invest your time. It is helpful because that would keep you relevant, and updated on what’s happening in other companies along with what other SDET Engineers are doing and how they are implementing their skills in their organization such that you can take inspiration and tweak it according to your project.

The book that everyone should read is Leading Quality, and Perfect Software: And Other Illusions About Testing, there is also one book by Pradeep Soundarajan – Buddha in Testing: Finding Peace in Chaos.

Any specific language/platform to focus on while entering SDET?

There is no specific answer to this question. It depends on your current project. You can use the language that is being used in your current company as that can help you contribute and bring value which is the whole motive. Coding is a way of communication; you can choose any language. If you can learn how to communicate, you can either code in Java or JavaScript, you would not have any difficulty switching later.

Easy, intermediate, or hard? Which level of DS on LeetCode is sufficient to solve the SDET role?

Irrespective of the role, any task, if there are three levels – easy, medium, and hard, anybody would want to start with the hard first, but always start with the easy one. That’s the best way to go and once you have completed the easy ones you are ready to start with your interviews.

Start with applying, and parallelly you can keep on practicing the medium ones, and yes, hard ones are rare to come by, especially when talking about the SDET rule. But there can be exceptions, so you can parallelly continue your effort but easy ones are very much mandatory so you feel confident about life.

How to improve logical skills in coding effectively? Many times we get stuck in simple problems for a long time and are not able to think of a solution.

Everyone has faced this and has gone blank thinking about a logical solution in a coding interview. So, the one thing that you should always do is practice.

It’s like mathematics, the more you practice, the more patterns your brain or mind will create and the better you will be in your logical thinking and problem-solving skills, keep practicing.

If you see a new question that you are not able to break, kudos to you, that’s like an achievement for that day because you have learned a new pattern. Your mind has learned a new pattern and tomorrow, you’ll be able to solve 20 such questions based on that pattern. Don’t leave it, come back from the interview, solve that one and feed your mind with that pattern then you’re good for the next interview.

Can people with basic knowledge start building a framework from scratch by watching videos and learning concepts parallelly?

This is the way to go. Whenever you are trying to build a framework, don’t try to build something which is top-notch or something that touches the level of perfection of development. Start with a very simple framework, start with what it is, and what to do, run your test cases and then build upon it. It’s kind of a continuous improvement loop.

If you follow Udemy or Youtube, there is a lot of content. The content is not in order, so choose wisely, and digest that content. Build your network and ask people one to one specifically. Sometimes you can understand a concept in one hour that you are trying to understand for months. So, be selective about how you choose your learning source.

What does a typical day of SDET look like?

Be it as SDET or any Tech Role, it’s very difficult to plan out a day because even a single production glitch can spill water on all our plans but here’s what an average day for an SDET looks like:

The first 5-10% time should go to your Stand-ups on daily updates and not more Than that.
The next around 10-20% would be going to meetings or collaborating with cross-functional teams that include your developers, your DevOps, your project management, and all sorts of different teams in an attempt to ensure that the right quality and culture are being maintained, and everyone is working and setting up goals with the right mindset – a quality mindset.

Then around 10% of your time would go into debugging and maintaining your automation scripts and builds. This is to focus because many times we leave our existing automation to rot in while creating new automation suites on a better framework. So, spend at least 10 percent of the time making your current automation relevant, maintaining and correcting the failures and fixes because of the flakiness.

The remaining 60% can be broken down into two major buckets. One is 30 percent of your time would go in actual testing. Using your intelligence to test a feature, running automation, reporting bugs, and then sending out the reports to all the stakeholders and risk reports, etc.

The remaining 25 to 30 Percent would be spent on a focus time, and you would be either coding like programming and trying to automate whatever repeatable pieces of the process and test execution that you can.

What are the leadership roles or personal growth paths for SDET?

The current trend is that many test engineers with 6 or 8 years of experience look out for different roles like TPM, and PM. Many SDETS are concerned about their paths in leadership.

Ideally, there was always a requirement for test leaders and managers. What has changed with the advent of agile methodologies and with the kind of overhaul or the skill enhancement of the SDET role is that there is now a lesser demand for pure people managers and a higher demand for tech-savvy leaders. You can say that there is a need for technically strong leaders and managers who can guide the team through automation fundamentals, automation designs, testing fundamentals, and so on.

There are hundreds of openings for the role of Lead, EM, AVP, and VP in SDET and quality on LinkedIn and other platforms even today. So, there is no scarcity of leadership growth in the testing domain plus the companies, right from the startups to MNCs have to create a ladder in order to sustain the role for a long time.

The only thing to do is that you have to now keep yourself updated and be updated with the technological advancements.

For an SDET, is the way forward only to become managers or can somebody grow as an individual contributor (IC) also?

Suppose you don’t want to manage a team, definitely, there are roles in the industry like staff SDET or principal architect, enterprise architect, or test architect. These are sort of architect roles, as long as you are ready to technically guide the team, and share your experience and knowledge of what to do and what not to do, you can bring value to the team and the company. So, even if your company doesn’t have this role, if you talk to your leaders and manager, they’ll surely carve out a separate ladder for you if you bring enough value in any way possible. So yes, it is 100% possible to stay in the IC role.

Is the pay scale for an SDET role significantly higher as compared to a testing or automation profile? Is there any difference?

Pay scale is in direct proportion to the value that you bring to the organization and to the leadership. We discussed the SDET role – the sort of skills, roles, and responsibilities that SDET must possess. It surely is bound to bring enhanced value to the leadership. So, we would not shy away from saying this, “Yes, once you know the role of an SDET, it is on the higher pay scale charts of every organization”.

In the past, testing has not always been at the top pay scales as compared to its tech counterparts. But now things are changing because of this rise in the demand for SDET roles and quality engineering culture by most companies and leadership teams. The SDET role is reaching and breaching all the pay scale levels. It is a piece of good news for us, that’s the thing to celebrate for everyone in our community.

However, it has an effect, it might have created some internal segregations that are transitory. It is certainly for the good that it personally gives an inspiration to upskill ourselves every day and keep ourselves updated, bring more value and reach the standards which the SDET role has now created for all of us.

Where to learn about framework creation from scratch for automation?

Anyone can follow any tutorial video on an open-source GitHub project and start with a very simple framework. Start with what you are required to do and that is just basic enough to run your automation suite. There is no need the starting to follow all the design principles at once or to build something that is so top-notch that it takes months for any new journey.

So, start from a very low level, from the very scratch. It will be an improvement of the framework as well as your own skills. It would help in building a true top-notch framework that takes around two to three years to build. That’s why you have to start from the very basics and not be in a rush to use everything and anything that you see in your framework from the very start.

What kind of DevOps concepts should an SDET know?

The boundary between SDET and DevOps roles is overlapping. A very practical example – after you build your 50 or 100 test case automation suites, the questions like, where do you run it, how do you run it, when do you run it, would come from your DevOps knowledge so you have to enter that world. You have to keep yourself very open to learning tools like CI tools like CircleCI or Jenkins.

Be very comfortable around AWS, and tools like docker and Kubernetes, since they are very necessary nowadays in order to not only create but maintain your own test environments, which is one of the very important aspects of your tester automation engineering. So yes, all in all, you have to keep that space open and there is an overlapping boundary, do learn about these tools when the need arises in your current project.

What makes SDET & automation roles different?

SDET is much more than automation. Automation is not a separate role in itself because without having that knowledge of testing or the product, you can’t be a good automation engineer. If it was separate then you will not have the answers to what to automate and how to prioritize it. Automation is a subset of a larger SDET role. That’s the practical version of the actual comparison between these two roles.

Examples of roles of SDET beyond usual automation tasks.SDET uses automation just to improve the release velocity and save their or the team’s time while having the regression or sanity or the feature testing. But the core value of an SDET is to do testing in a better and deeper way. So, let’s connect everything that we do when we are testing to check user impact, business impact, and engineering.

The second is bearing the flag of quality. Being everyone’s responsibility and implementing it practically according to the structure and the size of your organization by opening channels with cross-functional teams is something we must do. Understanding the entire SDLC model in different phases along with contributing in whatever way we can in these different phases, holds more importance than the automation here.

How the SDET role will evolve in the next few years?

Let’s quickly go to the growth of the SDET role. We can agree that SDET’s role has now been able to do what it was brought for, and also to show us a bigger picture for quality, testing, and other aspects of user experiences and so on.

It would not be sustainable for the industry to have two parallel roles of QA and SDET with so many overlapping boundaries. Five years or seven years down the line and we’re expecting these two roles to merge into one a much larger quality engineering or even larger and a combined role.

If we discuss, what’s the future of testing then given the competition in the market, given the choices that the user has, today – the leadership and the companies are investing heavily in quality engineering or in routine. So, the prospect and the future of testing as an entire role are very bright, promising, and better than ever provided. We keep ourselves evolving.