SDET (Software Development Engineer in Test)

SDET (Software Development Engineer in Test) in testing is an IT professional who can work equally and effectively in both development and testing roles. SDETs take part in complete software development process as well as software testing process. SDET professional's knowledge is entirely focused on testability, robustness and performance of software testing and development process.

They are also able to play a contributory or reviewer role in the creation of designs for production software.

Benefits of SDET professional:

1. SDETs professionals can automate the acceptance test by leveraging their coding skills

2. These professionals deal with end users or customers and their experiences. They already possessed engineering skills so they can also think like a developer.

3. Extensive code coverage through unit testing

4. Can build, deploy, run & manage the application individually

5. Influence the development, program management, & design teams on technical implementation and user scenarios

Industries in need of SDET

BDD (Behavior Driven Development)

BDD focuses on defining requirements based on the desired behavior of your software. These requirements can then be converted into code. When BDD was invented, the only way to do something like this was to create a domain-specific language. The result was Gherkin, a formal language for capturing software requirements. BDD is an evolution of Test driven development (TDD).

Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle: requirements turn into very specific test cases. The code is written to make the test pass. Finally, the code is refactored and improved to ensure code quality and eliminate any technical debt. This cycle is well-known as the Red-Green-Refactor cycle. In TDD, we have the well-known Red-Green-Refactor cycle. We start with a failing test (red) and implement as little code as necessary to make it pass (green). This process is also known as Test-First Development. TDD also adds a Refactor stage, which is equally important to overall success. The Refactor-stage is the third pillar of TDD. Here the objective is to revisit and improve on the implementation. The implementation is optimized, code quality is improved, and redundancy eliminated.

Benefits of Test-Driven Development

1. Writing the tests first requires you to really consider what do you want from the code.

2. You receive fast feedback.

3. TDD creates a detailed specification.

4. TDD reduces time spent on rework.

5. You spend less time in the debugger.

6. You are able to identify the errors and problems quickly.

BDD with Gherkin

Gherkin is the domain-specific language for writing behavior scenarios. It is a simple programming language, and its “code” is written into feature files (text files with a “.feature” extension. Gherkin scenarios are meant to be short and to sound like plain English. Each scenario has the following structure:

1. Given some initial state

2. When an action is taken

3. Then verify an outcome

A simple feature file example is shown below:

Feature: Reorder same product on Amazon. As a amazon user, I want to reorder same product without searching with the name of product. Scenario: reorder same product using barcode Given: user is on search bar When :user click on camera icon Then : barcode option to scan barcode of product should be displayed

Scenario: reorder same product using product scan

Given: user is on search bar

When: user click on camera icon

Then: camera button to scan product should be displayed

Gherkin Keywords

Every programming language has its keywords, and Gherkin is no different. The table below explains how each keyword is used in the official Gherkin language.

Feature

• section denoting product or feature under test

• contains a one-line title

• contains extra lines for description

• description should include the user story

• may have one Background section

• may have multiple Scenario and Scenario Outline sections

• should be one Feature per feature file

Scenario

• section for a specific behavior scenario

• contains a one-line title

• contains multiple Given, When, and Then steps

• each type of step is optional

• step order matters

• each scenario runs independently

Given

• step to define the preconditions (initial state or context)

• should put the product under test into the desired state

• may be parameterized

When

• step to define the action to be performed

• may be parameterized

Then

• step to define the expected result from the action taken by When

• may be parameterized