SDET is a highly skilled resource, having both development and testing skills, whereas manual testers have limited programming skills and can only prepare and execute the test cases.

SDET can develop test automation tools and can use it, but testers are not expected to develop the automation tools, they can only use the various automation tools.

Below are the roles and responsibilities of SDET:

• Participation in design and architectural discussion
• Understanding the project requirements
• Creation of Automation framework and perform the testing through the framework
• Build different test scenarios and tests acceptance criteria’s
• SDET works with the development team and helps in resolving the issue
• Creation of defect reports and managing communication with the team

• He should attend sprint-planning sessions
• He should attend daily stand-ups
• He should be able to communicate with stakeholders and business people for a better understanding of the functionality of the software
• He should communicate with other teams like the development team continuously to understand the actual flow of code and short hand-off demonstrations
• He should not wait for the development to end and then start testing. The testing should go in parallel with development throughout the sprint
• He should be able to automate the maximum test cases using effective testing tools

Quality Assurance involves in process-oriented activities. It focuses on the approaches, techniques, methods, and processes and ensures that they are implemented correctly.

It basically focuses on the prevention of defects in the process used to make a software application.

Quality Control involves in product-oriented activities. It ensures that the approaches, techniques, methods, and processes that are designed in the project are following correctly.

It focuses on the execution of a program or code to identify the defects in the software application.

Severity is defined as the degree of impact a defect has on the application, whereas Priority defines the order in which a defect should be fixed.

For, e.g.: A site maintaining the employee’s record doesn’t allow saving the record on click of Save button. So this would be a very severe defect as this is blocking the main functionality.

This should be fixed in high priority because primary functionality is breaking.

Submit button is not working on a login page and customers are unable to log in to the application.

For e.g.: Any site which allows access to authorized users only by giving the valid credentials and clicking on Login button.

But the login button of the page doesn’t allow the authorized user to enter the site. Then this would be the high severity and high priority defect.

There is a crash in some functionality which is going to deliver after a couple of releases.

For e.g.: A link provided in FAQ page is not opening, but this link is rarely used by end-user. So it can be fixed in some later release. So, this would be a high severity defect because some link of the page is not opening but since this is not used by the user, so it can be set to low priority.

Verification Validation It is a process of checking if the software being developed meets the specification.

It is a process of checking whether the specifications that are developed meet the customer’s requirements. It does not involve the execution of the code.

It involves the execution of the code. It is done at the time of development. It is done after the completion of development by the testing team. It describes whether the outputs are as per the inputs. It describes whether the software is accepted by the customer or not.

Test Scenario describes any functionality that can be tested.

The test case is a document that contains the steps that have to be executed.

For e.g.:

Test Scenario: Login into the application

This test scenario is the functionality of the application, and it will include a number of Test cases like:

TC1: Verify whether an email is valid.

TC2: Verify whether valid email ID and valid password are entered.

TC3: Verify that proper error messages are displayed if wrong email ID or password is entered.

A Test Plan is a document that describes the scope, approach, resources, and schedule of testing activities.

Find the Test Plan template in the next slide:

• Test Strategy
• Test Objective
• Entry and Exit Criteria
• Resource Planning
• Test Deliverables

Test Script is written in a programming language and is a short program to test part of the functionality.

For e.g.: to click any button, we can write the script as:

click(“buttonName”);

Alpha testing is pre-release testing performed by an end-user representative at the developer’s site.

Beta testing is the testing performed by customers at their own location.

For e.g.: When any new Android version is released, then alpha testing is done first with the developer to verify its functioning.

Once alpha testing is completed, Beta testing is done by the end-user to verify that it's working fine without any bugs and crashes.

Sanity Testing is a surface level testing in which the tester checks whether the whole functionality of the software works properly.

Regression testing is a process of testing changes to programs to make sure that the older functionality still works with the new changes.

Retesting is a process of checking the bugs that are fixed by the development team.

For e.g.: If in any release, say 1.1, some defect is introduced which is fixed by developers and then released to the tester in 1.2 release. Thus, in 1.2 release, the tester will again test the defect to verify whether it’s been fixed or not. This process of checking the defect again is called as Re-testing.

Boundary Value Testing is testing on boundary conditions, below and above the edges of input and output equivalence classes.

For e.g.: Some text box takes only values from 3 to 8.

Minimum boundary value: 3

Maximum boundary value: 8

Testing with Invalid inputs: 2(below range) and 9(above range)

Testing with valid inputs: 3(min),4(min+1),7(max-1) and 8(max)

Traceability Matrix is a document that shows the relationship between test cases and requirements.

It is prepared before test case designing.

It ensures that all the requirements and change requests are tested.

For preparing the Requirement Traceability Matrix, follow the below steps:

• Gather all required documents. Documents include Business Requirement
• Document, Functional Specification Document, Technical Specification Document.
• List down all the requirements from Business Requirement Document one by one with Requirement ID#.
• Go to Functional Specification Document and list all functional requirement for each business requirement.
• Open Test Scenario or test case document and link available test case IDs to respective functional requirements.