Test Policy and Practices

Copyright © 2020 Talentica Software (I) Pvt Ltd. All rights reserved.
Test Policy and Practices
• What is Testing
• Challenges in Testing
• Levels of Testing
• Testing Best Practices and Policies
• Test Driven Design (TDD Testing)
• Behavioral Driven Design (BDD Testing)
• TDD v/s BDD
2

Software testing is a process, to evaluate the functionality of a software application
with an intent to find whether the developed software met the specified requirements or
not and to identify the defects to ensure that the product is defect free in order to
produce the quality product.
4

Software Test Cycle
5

Software Testing Challenges
• Inadequate Product/Business Knowledge
• Changing Requirements
• No or Less Documentation
• Frequent Regression Cycle
• Lack on Communication
• No Quality Measurements
• Agile Becomes Waterfall
• Tool Selection
6

Testing Levels
• Unit Testing
• Component Testing
• Integration Testing
• System Testing
• Acceptance Testing
• Alpha Testing
• Beta Testing
7

Testing Levels (Cont.)
Unit Testing
• Unit Testing is a level of software testing where individual units of a software are tested.
• The purpose is to validate that each unit of the software performs as designed.
• A Unit is a smallest testable part of Application like classes, Interface or a function/procedure.
Component Testing
• Component testing Unit Testing is a level of software testing where individual components of a
software are tested.
• It's also referred to as Module Testing.
8

Integration Testing
• Integration Testing is a level of software testing where individual units/ components are combined
and tested as a single unit.
• The main function or goal of this testing is to test the interfaces between the units/modules.
System Testing
• System Testing is performed on a complete integrated system to evaluate the compliance of the
system with the corresponding requirements.
• The purpose of this test is to evaluate the system’s compliance with the specified requirements.
9

Acceptance Testing
• Acceptance testing, a testing technique performed to determine whether or not the software
system has met the requirement specifications.
• The main purpose of this test is to evaluate the system
• Acceptance criteria may be defined on the basis of the following attributes :
-- Functional Correctness and Completeness
-- Data Integrity
-- Data Conversion
-- Usability
-- Performance
-- Confidentiality and Availability
-- Scalability
10

Alpha Testing
• Alpha Testing is a Pre-release activity and one of the types of Acceptance Testing.
• Testing activity is carried out in a much-controlled manner and it is not accessible by the end-
users/market.
Beta Testing
• Beta testing also known as user testing takes place at the end users site by the end users to
validate the usability, functionality, compatibility, and reliability testing.
• It allows the "real" customer an opportunity to provide inputs into the design, functionality, and
usability of a product.
11

Testing Best Practices and Policies
• Analyze the Risk.
• Never/Ever Ignore a Bug.
• Think from End User Prospective.
• Start Automation post analyzing available tools.
• Keep yourself Updated with latest QA Market Trends.
• Test Early, Test Often.
• Implementing Test Coverage and Code Coverage
• Don’t rely just on Black Box Testing, go for White Box/Grey Box Testing.
• Take Scalability and Application Performance into consideration while Testing.
• Automate as much as possible to avoid redundant work.
12

Common Mistakes we make as QA
• Not taking Bigger Picture/Business into Account.
• Gaps in Requirement Understanding.
• Not thinking from End User Prospective.
• Starting Automation without analyzing available tools.
• Criticising developers
• Frequently changing the focus
• Not asking developer’s help
• Incorrectly evaluate the impact of a new functionality/fix
13

Test Driven Development (TDD)
• TDD stands for Test Driven Development.
• In this software development technique, we create the test cases first and then write the code
underlying those test cases.
• TDD is a development technique, it can also be used for automation testing development.
• TDD, take more time for development however, probability of finding defects is low.
• TDD results in improved quality of code and the code that is more reusable and flexible.
• TDD also helps in achieving high test coverage.
• The most challenging thing for developers/qa following TDD is to write their test cases before
writing the code.
14

Test Driven Development (TDD)
15

Test Driven Development - Process
• Write a test case: Based on the requirements, write all automated test case.
• Run all the test cases: Run these automated test cases on the currently developed code.
• Develop the code for that test cases: If the test case fails, then, write the code to make that
test-case work as expected.
• Run test cases again: Run the test cases again and check if all the test cases developed so far
are implemented.
• Refactor your code: This is an optional step. However, it's important to refactor your code to
make it more readable and reusable.
• Repeat above steps for new test cases: Repeat the cycle for the other test cases until all the
test cases are implemented.
16

Behavioral Driven Development
(BDD)
• BDD stands for Behavioral Driven Development.
• BDD is an extension to TDD where instead of writing the test cases, we start by writing a behavior.
• Once behavior's are written, we develop the code which is required for our application to perform
the behavior.
• The scenario defined in the BDD approach makes it easy for the developers, testers and business
users to collaborate.
• BDD is considered a best practice when it comes to automated testing as it focuses on the behavior
of the application and not on thinking about the implementation of the code.
• The behavior of the application is the center of focus in BDD and it forces the developers and
testers to walk-in the customer’s shoes.
17

Behavioral Driven Development -
Process
• Write the behavior of the application: The behavior of an application is written in simple
English like language by the product owner or the business analysts or QAs.
• Write the automated scripts: This simple English like language is then converted into
programming tests.
• Implement the functional code: The functional code underlying the behavior is then
implemented.
• Check if the behavior is successful: Run the behavior and see if it is successful. If successful,
move to the next behavior otherwise fix the errors in the functional code to achieve the application
behavior.
• Refactor or organize code: Refactor or organize your code to make it more readable and re-
usable.
• Repeat above steps for new behavior: Repeat the steps to implement more behaviors in your
application.
18

TDD v/s BDD
19
TDD BDD
Stands for Test Driven Development Stands for Behaviour Driven Development
The process starts by writing a test case. The process starts by writing a scenario as per
the expected behavior.
TDD focuses on how the functionality is
implemented.
BDD focuses on the behavior of an application
for the end user.
Test cases are written in a programming
language.
Scenarios are more readable when compared
to TDD as they are written in simple English
format.
Might be a better approach for projects which
involve API and third-party tools.
Might be a better approach for projects which
are driven by user actions. For eg: e-commerce
website, application system, etc.
Some of the tools which support TDD are:
JUnit, TestNG, NUnit, etc.
Some of the tools which support BDD are
SpecFlow, Cucumber, MSpec, etc.

Testing framework
– A testing framework is a set of guidelines
or rules used for creating and designing
test cases.
– These guidelines could include coding
standards, test-data handling methods,
object repositories, processes for storing
test results, etc
20

– Mocha
– Jasmine
– Jest
21

• Mocha
– Mocha is a feature-rich JavaScript test
framework running on Node.js and in the
browser
22

• Context, describe, it functions
• Hooks
• Done callback and async code
• Timeouts
• only and skip function
• Mocha opts
• Reporters
23

• Demo
24

Assertions
– Assertion libraries are tools which
provides you a way to verify your expected
output with current output
– Without assertions a test is insignificant
25

• Chai
• expect.js
• should.js
• unexpected.js
26

• Chai
– Chai is a BDD / TDD assertion library
for node
– Has best of both worlds expect.js, should.js
– Has various custom plugins
27

• Demo
28

Mocks/Test doubles
– Test Double are pretend object used in
place of a real object for testing purposes.
– It is used so that a
function/component/object can be tested in
isolation
29

• Dummies
• Stubs
• Spies
30

• Dummy
– Dummy objects are passed around but
never actually used. Usually they are just
used to fill parameter lists.
31

• spies
– A test spy is an object that records its
interaction with other objects throughout
the code base
32

• stub
– Test stubs are fake objects with pre-
programmed behavior
33

• Demo
34

Best Practices
– Don't use arrow function since is binds
"this" and cannot use mocha context
– Use timeouts as when you need to setup
something before test execution
– Do not create multiple tests to test single
scenario with different data
– Test your test code with only/skip
– Add message in assertions
35

Test Policy and Practices

More Related Content

Test Policy and Practices