Part-1 API Basics (If you know basics go To Part-2)

a. API Basics

b. Rest API Components and Basics

Part- 2- API Project (Manual and Automation)

1.Agile meetings discussion before Sprint get started

2.QA Activities in Agile

2.1 Finalizing Required user stories for QA

2.2 Estimations for API User Stories

3. Writing Scenario’s for API Testing (Project Started)

3.1 How and what kind of scenario’s do we write for API’s

3.2 Requirement coverage for API’s

4. Automation code for Scenario’s in framework Format (BDD Approach)

4.1 What all concepts should we perfect in Automation

5.Code Deployment in different Servers/Environments and Testing

5.1 Manual Testing (if only Manual applied)

5.2 Automation Testing

6. Execution and Bug Reporting for API’s

6.1 Bug report preparation /JIRA

7. Preparing Testing Artifacts

8.Submitting testing Artifacts

8.1 What all documents should we need to submit

8.2 Submission Process

9.Detailed QA Sign Off (1 to 8 Steps continues for 3 Sprints for one Project)

10.API Testing Challenges and Solutions

Part-3. Interview Questions and Answers

Part-1 API Basics: - What is API Testing: -

An API is a set of codes which allows two or more than two applications to communicate
each other internally or externally and provide a result to end users or to another API.

Example:

 You launch Gmail URL on a browser and enter your credentials. If you provide
correct credentials, you should view home page of your account. If you provide
wrong credentials, you will see some error message. 
 How it happens actually? When we pass credentials, some information is being sent
to Gmail backend through messenger/channel. These credentials information is
validated, and response is sent back to end user through messenger.

API vs Webservice: -

Detail Description about API

 In general, when we speak about APIs, we are likely speaking about web APIs [APIs
that are accessible over the internet].
 This is not always the case though. APIs can be exposed through local files (such as
a JAR file in a Java program, .H file in C/C++ programs, etc.) to allow two local
applications to communicate with each other.
 This does not require a network as the two applications are communicating within a
single device. (Read Again and be clear this point)

Webservice: A Web service is a way for two machines to communicate with each other

over a network.

Detail Description About Webservice:

A web server running on a computer listens for requests from other computers. When a

request from another computer is received, over a network, the Web service returns the

requested resources.

 This resource could be JSON, XML, an HTML file, Images, Audio Files, etc.

It is important to note the requirement of the request being made over a network.

(Read Again this point and understand well)

Difference: -
A web service and an API are two very similar concepts, so it can be difficult to understand the similarities and
differences.

a) You might be wondering to yourself, APIs and Web services sound like the same thing. It’s a way for two

computers to communicate with each other over the internet, right? Well, not quite.

As we mentioned in the section about “What is an API?,” not all APIs are accessible over the internet(a

network), while Web Services must always be accessed through a network. That’s the difference right

there.

why we should do API testing: -

At a very high level, an application has three components:

 Back end (Data Layer): Where data is stored and retrieved.

 Front end (Presentation Layer):  User interface.
 Middle ware (Logic Layer): It connects front end and back end of application.

Let us understand above point with an example:

You must have heard about Gmail.

Explanation: If you want to create an email id, you visit to Signup page of Gmail where you provide all details like
name, age, mobile number etc. You provided details using Front end or presentation layer of Gmail application.
Once you enter all details and submit, An API creates a request with data provided by you and hits an end point
which creates a new user and stores information to a specific table of database. This API is middle ware. Data
provided by end user and credentials details are stored in database. This is back end. You can see how all layers
are interconnected using middle ware i.e. API.

So As per current development process, maximum functionalities are exposed/built as an

API. For example: Consider a hospital application. This application provides below
functionalities:

1. Register a patient.
2. Login to patient dashboard.
3. Logout from patient dashboard.
4. Retrieve list of patients.
5. Delete a patient record.
6. Book an appointment.

Developers will develop all these functionalities as APIs which will be integrated by back end
and front-end teams. When development of application is completed, you start testing.
Explanation: An API for “Register a patient” will have logic to register a patient and all types of error or warnings if
something goes wrong. You can test status, speed and data accuracy of an API independently.

Understand Terms URN , URL ,URI & API

This is a frequently asked interview question for API testing.

Let us see abbreviations of each terms: 

URI (uniform resource identifier) identifies a resource (text document, image file, etc)

URL (uniform resource locator) is a subset of the URIs that include a network location

URN (uniform resource name) is a subset of URIs that include a name within a given space,
but no location

That is:

And for an example:

Understanding Of basic HTTP Methods: - CRUD Operations-

GET:

This HTTP method is used to read/retrieve resource representation only. It is called Safe
methods as it cannot modify information. It should retrieve same information for multiple
identical requests until any other API has changed the state of resource. That’s why it is
also called as idempotent method. Response is returned in JSON/XML format. 

Status Codes:

200 (OK) –> If GET API finds the requested resource. 

404 (Not Found) –> If GET API does not find the requested resource.

400 (Bad Request) –> If GET request is not formed properly. 

POST:

 A HTTP POST method is used to create a new resource in collection of resources with
a request body passed as a JSON/XML. If resource is created successfully at the end
point, it returns a status code 201(Created) (Not always) and returns response body.
It may return 200 (OK) and 204 (No Content) status code as well based on how it is
created.

 POST is not safe method as it is related to data creation. It is also not idempotent
and invoking two identical POST requests will result in two different resources
containing the same information with just different resource ids.

PUT:

 An HTTP PUT method is used to primarily update the resource information, but it also
can be used to create a new resource (Depends on API development) if requested
resource is not available.
 If PUT request is made to update resource, it should return 200 (OK) and 204 (No
Content) status code. If PUT request is made to create a new resource, it must
return a status code 201(Created).
 PUT is not a safe method as it performs data creation and modifications, but it is
idempotent as if we hit the same request again, it operates on same existing
resource. But note here that a PUT request can be made as non-idempotent as well.

DELETE:

 An HTTP DELETE method is used to delete an existing resource from collection of

resources. On successful deletion of resource, it returns 200 (OK) and 204 (No
Content) status code. It may return as 202 (Accepted) status code if request is
queued.
 It is not a safe method as it performs on modification of data. If we hit the same
request again after first hit, it will give you 404 (Not Found) . So, DELETE request
are idempotent after second call onward.

PATCH:

 An HTTP PATCH method is used to update information of resource partially. It is

different from PUT as PUT updates/replace complete information of resource while
PATCH updates some information of resource. It returns 200 (OK) and 204 (No
Content) status code

Introduction of HTTP methods:

All HTTP methods can be categorized in two categories: Safe methods & Unsafe
methods. 

Safe methods: -

If an HTTP method does not change/modify the resource information on the server side or
perform read only operation, is called a SAFE HTTP Method
 The reason it is called as a safe method as it does not alter resource information and
prevents actual resource state. GET, HEAD and OPTIONS HTTP methods are safe
methods. These methods perform read only operations. POST PUT etc. are unsafe
methods.

HTTP Status Code Must To Be Remembered

Below are most commonly HTTP status codes which you may encounter during API testing.
You should remember meaning of these status code

State The Core Components of an HTTP Response?

Every HTTP response contains four key elements.

 Status/Response Code – These are response codes issued by a server to a client’s

request. For example, 404 means Page Not Found, and 200 means Response is OK.
 HTTP Version – describes HTTP version, for example-HTTP v1.1.
 Response Header – Includes information for the HTTP response message. For
example, Content-type, Content-length, date, status and server type.
 Response Body – It contains the data that was requested by a client to server.
How would you receive API Requirement specification document?

 Developer would document detailed required details using Swagger editor about Any
API and he provides I receive in the form of Swagger url from the developer (with
the help of swagger url I can see the request and expected response and functional
conditions for each API’s (you will learn more next section)

What would you analyze in Requirement specification document? Read well

 API architecture, API is synchronized or non-synchronized calls, Request fields

(which are mandatory, and which are optional in Request body and Business
conditions and Error conditions
 Requirement document or Swagger should contain
 Functional description
 Type and syntax of error message that may occurred
 Syntax, elements and sequence needed for each parameter
 Links regarding functions

How can we check response for any API for manually and confirm?

 We can use postman and based on given parameters we can perform operations and
get the response in postman

Tools used for API testing are:

 Parasoft SOAtest
 PostMan
 AlertSite API monitoring

What exactly needs to verify in API testing?

In API testing, we send a request to API with the known data and then analysis the
response.

 We will verify the accuracy of the data.

 Will see the HTTP status code.
 We will see the response time.
 Error codes in case API returns any errors.
 Authorization would be check.
 Non-Functional testing such as performance testing, security testing.

What is Call sequence?

When you have multiple end points for specific application/project .Those end points may
need to be executed in a particular sequence in that process you may need to capture one
API end point response and may need to use next end point .If you miss execution
sequence those may not get execute successfully
Example: Suppose application Authentication/Login endpoint getting generated SessionID
value in response .So this session id should be used for next endpoints then only other
endpoints will get executed so until you execute Authentication/Login endpoint and capture
and reuse in other endpoints so here you should know first call would be
Authentication/Login then only next end point will be executed

Login User-- generating session id--- until I use session id of login request i get bad
Request -400

What are the major challenges faced during API testing Manual (Read well )

 A major challenge is providing input values which are very difficult because GUI is
not available.
How to Overcome: Understand very well business conditions and check from where
data can be gathered for API from Developer or From Documentation (Swagger or
any other system is there to find data based on business conditions it varies based
on organization to organization-will be explained by Lead or Manager)
 Call sequencing (We can get from the developer or from documentation

2 ) Project-Testing basics (API) and Project

Assumptions: -

1. Before starting any project, Test plan and Test Strategy would have submitted

2.Project is following Agile approach for Development

Manual and Automation QA responsibilities in daily basis

Responsibilities:

- understanding requirements
- writing scenarios for requirements
- executing and reporting bugs
- preparing testing artifacts and submitting them
- attending release and readiness meetings

all these you will be understanding in detail with practical/real time environment how would
be performed as QA

Project: Online Shopping Portal

Project Team /Actors: 4 Developers, 1 QA, Scrum master, Business Analyst/Product

Owner

Sprint Duration: 2 weeks

Day1: meeting1:Sprint Backlog grooming meeting:

Here all would meet and discuss which all requirements/user stories should be picked for
the current Sprint. Majorly here Product owner guide to the team which user stories are
higher priority and should be taken initially for specific application

QA Activity: Check in meeting where I should get requirements for the current
sprint to understand it. Once meeting done follow step 1

Step -1 Analyze requirements these below parameters as we need to give Estimations

Parameters:

1.Architecture

2.How many requirements developers are taken for this sprint

3. Are those independent services or has any dependency

4.How complex business conditions to understand and to test

2.1 Finalizing Required user stories for QA

Day 1: Meeting2: Sprint planning:

After analyzing above parameters here from QA side we should provide estimation by
providing QA user stories

Users stories: -

1) Writing Testcases (manual)/Feature files (automation)

2) Executing Testcases
3) Designing Automation scripts (If automation testing Applies)

2.2 Estimations for user stories: -

1) We should provide estimations in the form of story points based on step parameters
2) For each one-story point = 8 hours of work
3) Suppose to write feature file/Testcase it is going to take 16 hours so story points for
the user story 1 would be 2 story points we would give
4) So according to our user stories and time which will take for us we would provide
story points in sprint planning meeting

Day 2

Scrum meeting- Scrum master, Developers team, QA Team all will be involved and
discussed each status, Progress ,About blockers in work .It’s daily call which happens for
15 min

3. Writing Scenario’s for API Testing (Project Started)

Scenario’s:

We should have Request Body for each Endpoint url to write scenario’s
Let assume end points which are getting developed for the current sprint

Endpoint-1: /RegisterUser - Method: Post Request Body as given below

Headers: content Type- Application/json ,channel ID- Online_MB

userInfo:{ -Required Objcet/Array

“First Name” : “Hari”, -String*

“Lastname” : “Manadi”, -String*

“DOB” : “dd-mm-yyyy’, -Date*

“Country” : “ ” -String*

“Gender”: “Male/Female” -String*

},

AddressDetails:{ -Optional Object/Array

“H.No” : “ “, - String

“Street” : “ “ , - String

“Pin” : “” - String*

},

“appLoginDetials” :{ -Required Object/Array

“apprequiredUsername”: “ “, -String*

“password”: “” -String*

*indicates mandatory field

Business Conditions: -

1) If you are passing Address Details optional object…if you mention address details you
have to pass pin
2) Gender field accepts only Male or Female Strings

Analyze and understand above request before writing scenario’s

- Which all Objects/ fields are Required

- Which all fields are optional
- Fields data types
- Any business conditions are there in above request
These below scenario’s we need to write in form of testcases for manual testcases
and in BDD format for Automation testing

- We should write all scenario’s which should cover complete functionality for
Any API
- Scenario 1: Happy Path - With valid data and complete request (Mandatory+
Optional Objects & Fields)
- Scenario 2: Happy Path – with valid data and only mandatory data (Only
mandatory request)
- Scenario 3: With business validations gender field and address fields
conditions

- Scenario 4: Interface validation – with invalid headers

- Scenario 5: Interface validation -Schema validation -Request fields

datatypes and response fields data types

Before Code Deployment What should QA Does:

Manual Testcases for Manual Testing: - (If only manual testing applies)

If we are going to perform only manual testing for API’s we need to write manual
testcases for A the given Endpoint as mentioned below for each endpoint before code
deployed into server. So that once code is deployed into server

Manual Testcases For Endpoint:

Pease find Testcases for one end point for considering online shopping registration end point

APITestcases_Onlin
eShopping.xlsx

Scenario’s for Automation: - (IF only Automation applies we don’t need to write
Testcases ,BDD Scenarios are enough)

BDD Format Scenarios for Automation:

Happy Path cases starts from here

1) Scenario : Given register User When user requested to register with all fields Then
receive Success response
Given RegisterUserAPIPath
And Header content-Type = ‘application/json’
And header channelId = “Online_MB’
And Request = {give request with mandatory + Optional data)}
When method POST
Then Status 200
And match response.Message = “successfully User created” (this expected
messages will be given by Developers )
2) Scenario: Given registerUser When user requested to register with only mandatory
fields Then receive Success response
Given RegisterUserAPIPath
And Header content-Type = ‘application/json’
And header channelId = “Online_MB’
And Request = {give request Only with Required/mandatory fields data)}
When method POST
Then Status 200
And match response.Message = “successfully User created” (this expected
messages will be given by Developers )
Business validations starts here
3) Scenario: Given register User When user requested to register with invalid gender
string Then receive 400 BadRequest
Given RegisterUserAPIPath
And Header content-Type = ‘application/json’
And header channelId = “Online_MB’
And Request = {give request Only with invalid geneder with some random string)}
When method POST
Then Status 400
And match response.Message = “Invalid geneder please pass male/female” (this
expected messages will be given by Developers )

4) Scenario: Given register User When user requested to register with address details
and invalid pin string Then receive 400 Bad request
Given RegisterUserAPIPath
And Header content-Type = ‘application/json’
And header channelId = “Online_MB’
And Request = {give reqest with invalid pin in address details object)}
When method POST
Then Status 400
And match response.Message = “invaid pin please check pin detials” (this
expected messages will be given by Developers )
5) Scenario: Given register User When user requested to register with address details
and missing pin field in request Then receive 400 bad reuest
Given RegisterUserAPIPath
And Header content-Type = ‘application/json’
And header channelId = “Online_MB’
And Request = {give request with address details object but miss mandatory pin
field)}
When method POST
Then Status 400
And match response.Message = “Please pass pin Field and correct value” (this
expected messages will be given by Developers )

Negative scenarios
6) Scenario: Give register User when user requested to register with missing few
mandatory fields LastName etc Then user should receive 400 bad request
 Given RegisterUserAPIPath

And Header content-Type = ‘application/json’

And header channelId = “Online_MB’

And Request = {give request with invalid data like DOB format,lastname with
combination of numbers and chanractes etc.. )}
When method POST
Then Status 400
And match response.Message = “Please pass verify data format for DOB and name
fields” (this expected messages will be given by Developers )

Headers validations starts from here

7) Scenario: Give register User when user requested to register with invalid header as
ChannelID Then user should receive 400 bad request

Given RegisterUserAPIPath

And Header content-Type = ‘application/json’

And header channelId = “Online_MB_abc123’

And Request = {Give valid request body )}
When method POST
Then Status 400
And match response.Message = “Please verify headers detials” (this expected
messages will be given by Developers )

Schema validations starts from here (Data types of the response)

8) Scenario: Give register User when user requested to register with valid request Then
user should receive 200 success response

Given RegisterUserAPIPath

And Header content-Type = ‘application/json’

And header channelId = “Online_MB’

And Request = {Give valid request body )}
When method POST
Then Status 200
And match response. Message = “String” (in schema validation we check
response fields data types wether response message fields have expected data types
for entire response or not as given by the developer)

Internal Server Error:

9) Scenario: Give register User when server is down Then user should receive 500
Internal server error
Prerequisite- Server should be down and not running -Developer can do
server down
 Given RegisterUserAPIPath

And Header content-Type = ‘application/json’

And header channelId = “Online_MB’

And Request = {Give valid request body )}
When method POST
Then Status 200
And match response. Message = “String” (in schema validation we check
response fields data types wether response message fields have expected data types
for entire response or not as given by the developer)

Day 8 or Day 9:

5.Code Deployments once code is ready from developer:

Deployment steps:
Once code is ready from the developer. He will deploy into servers we would get
deployment emails from the CI /CD Jenkins .So we would ready to start testing

So there will be different servers QA/Stage environment –

If code is deployed into QA environment, we would start testing

If not deployed into QA environment we would raise JIRA ticket for code deployment
to QA environment, so that Developer will push code to QA environment

5.1 Manual Testing: -

Postman few basic questions and answers:
We need to execute the testcases which we have written and need to update the
status and need to take screenshot for each Testcase Response as well as we need to
upload in JIRA for each user stories
Response Details:
 1. In which type of encoding does postman accept authorization credentials?
Postman accepts Base64 encoding only. This is provided inbuilt in postman or else you
can also refer 3rd party websites to convert the credentials in base64.

2. Why does Postman accept Base64 encoding only?

We use base64 particularly because it transmits the data into the textual form and
sends it in easier form such as HTML form data. Also, we can rely on the same 64
characters in any encoding language that we use.

3. What is a Postman Collection?

A Postman Collection lets us group individual requests together. Simply it allows us to
organize the requests into folders.

4. What is the purpose of Postman cloud if we are working in a company? Why?

A Postman cloud is a common repository of companies to access Postman collections.
In Postman cloud, work can be saved instantly after logging in. Anyone from the team
can access data/collections from anywhere.

5. Define status code 201?

It means created when a resource is successfully created using POST or PUT request.
It returns a link to a newly created resource using the location header

6. When do we use global variables, collection variables, and local variables?

Global variables are general purpose variables, ideal for quick results, and
prototyping. They are used while passing data to other requests.
Collection variables can be mostly used for storing some constants that do not
change during the execution of the collection. They are used for constants that do not
change during the execution and also for URLs / authentication credentials if only one
environment exists.
Local variables are only available within the request that has set them or when using
Newman/Collection runner during the entire execution. They are used whenever you
would like to override all other variable scopes.

7. Which one has the higher priority in Postman? A global variable or a local variable?
In Postman, if two variables have same name (one being local and one being global)
then the higher priority is of the local variable. It will overwrite the global variable.

8. Define Team workspace in Postman

A workspace is a collaborative environment for a group of users to develop and test

APIs. A team workspace is a workspace which is shared by the whole team working on
same collections of requests. Since it is very time consuming and hard to share the
collections through external drives or other sharing means, team workspace

9. Describe any four response things you receive from a response

 Status Code
 Response Status
 Response time
 Response Size
  Response Headers
 Response Cookies
 Response Date and Time
 Response Session limit
 Response Cookies
 Response Server
 Response type

Response Codes-API Http status codes:-

How to test with Postman: -

Go to POSTMAN client and select method which you need to perform -> Go to Body –
> Select RAW > pass JSON and select JSON from the dropdown and paste the payload
script.

JSON starts with curly braces and stores data in the key-value format.
 Pass body and hit send button.it will execute and shows response details as I
mentioned in above steps

5.2. Automation Code: -

Which all Automation tools and libraries available in market for API automation
1.Rest Assured Library
2.Karate Framework
3.SOAP UI (Licensed)

RestAssuredLibrary Setup:

Let’s setup a REST Assured project step by step:-

 Create a Maven Java Project.

 Add Maven dependency of REST Assured in pom.xml
 Add Maven dependency of TestNG/JUNIT in pom.xml (Required to manage and
run tests effectively)
 Add Maven dependency of JSON Schema Validator in pom.xml (Needed for
JSON schema validator)
 Add Maven dependency of Jackson JSON Java parser (Needed for mapping Java
objects to and from JSON )
 Add Maven dependency of JAXB XML Java parser (Needed for
mapping Java objects to and from XML )
 Sample Code: (Be strong in Rest Assured basics before we write code for
scenario’s)

We can write code with BDD style and non Bdd Style lets see both to understand
basic

BDD Style Code: -

For POST and PUT we need to pass body, we can send requestBody to post and put
requests (requests will get vary based on requirements for every end point)

Please observe difference for each method highlighted in Orange color in below screenshot

String requestBody = “{ \n” +

“ \name\”: \”tammy\”,\n +

“\salary\”: “2000\” ,\n+

“}”;

Let’s give you a brief idea here about how the above-mentioned code operates:

a. As per the above example, there is no method been passed to ‘given ‘. It means there are no specific
preconditions there.
b. There is a ‘get’ method which is being passed to ‘when‘and it signifies that when we are hitting this URL present
in the ‘get’ method, an event occurs. 

c. When we hit the URL in ‘when’, ‘then‘we are going to receive output as a response, and then we perform
validation on it. Here in this particular example shown in the above image, we are performing an assertion on the
body by validating the size of a specified element.

Non BDD Style: (not much important just get knowledge)

// Create a request specification
RequestSpecification request= RestAssured.given();

//Adding URI
request.baseUri("https://restful-booker.herokuapp.com/booking");

// Calling GET method on URI. After hitting we get Response

Response response = request.get();

// Let's print response body.

String resString = response.asString();
System.out.println("Respnse Details : " + resString);
 
/*
* To perform validation on response like status code or value, we need to get
* ValidatableResponse type of response using then() method of Response
* interface. ValidatableResponse is also an interface.
*/
ValidatableResponse valRes = response.then();
// It will check if status code is 200
valRes.statusCode(200);
// It will check if status line is as expected
valRes.statusLine("HTTP/1.1 200 OK");

More Automation code will be updated in next version in 2 to 3 days and will be given
to all candidates

Yet To add
Code for above BDD scenario’s which we are written
How to validate huge response will be covered here
Check Database validation as well (user creation happening or not)
Data tables
Hooks in depth
Upload files in API testing
Interview Tips and Questions and Answers

Day 9 and Day 10

6. Manual testing Execution and Bug reporting

 As we have written testcases in above steps in Day2 those testcases has to be
executed and need to be updated excel sheet and we need to capture below data
As well

While doing Execution you can observe few more things:

1) Postman Response screenshots

2) Requirements/Users stories coverage matrix to show case in Sprint review
meeting

 Important Note If you have DB access while testing, log into Database you can
check created record is present or not in the Database respective table or not (If
you need DB credentials and Database table details, please check with your lead
for DB access

If there are some scenarios suppose one request response need to use input for next
request (refer below video)

https://www.youtube.com/watch?v=HHASdmCR1bE (important for interviews these

steps)

6.1 Reporting Bugs if Any

Once you test thoroughly above scenarios with post man if you find any Bugs. Create
/Raise Bug in Jira tool

How to use JIRA:

- You need to have JIRA access from the organization you would get check with
lead
- Get access for the project which you are working check with les for the project
access for you

Step for Bug /Defect creation in JIRA:

Create Bug/ Issue in jira by following below steps:

1.Select the Create button at the top of the page (outlined by a red box below).
This will bring up the form to create an issue

The fields of this form are:

- Project - select project, usually ONOS

- Issue type - choose an issue type using these guidelines:
- bug - the issue is reporting a defect
- epic - this will be used by the product owner to create new epics - please do
*not* create issues of this type!
- story - the issue is a user story - typically for some larger change or
improvement to ONOS
 -
- Summary - enter a summary of the issue that is meaningful to someone reading
only summaries in a list
- Story Points - complexity measured with Fibonacci series: 1, 2, 3, 5, 8 (1 is
trivial, 8 is a very complex task keeping a person busy for an entire sprint).
- Priority - choose a priority for the issue, based on the viewpoint of the person
requesting work to be done:

a) Blocker - Highest priority, it is stopping people from doing work

b) Critical - Needs to be addressed right away

c) Minor - Can wait until blocker and critical issues are adder

d) Trivial - very simple issue, address when possible

- Affects Version(s) - select versions affected if it is a bug, otherwise leave

blank

- Fix Version(s) - do not change, will be used by release management

- Assignee - enter person assigned to the issue if known, else choose Automatic
- Environment - enter information to help the person assigned understand the
context of the issue - if it is a bug enter all of the relevant information about the
environment in which the bug was found
- Description - enter a description of the issue so that it is clear what is being
addressed or requested
- Attachment - attach any relevant documents for this issue (log files for a bug,
for example)
- Labels - add a label to help find related issues
- Test - for issues that are related to testing
- Starter - easier issues good for beginners
- Epic Link - select the epic to which the issue belongs, if there is one - ONOS will
have well defined epics during each release cycle for the larger themes being
worked on
- Sprint - if using agile, enter the sprint in this field

Fill out the form and hit the create button. JIRA should generate an issue name linked to a
summary of the created ticket:
If any of the fields need to be changed, the Edit button in the upper left hand corner of the
ticket will open an Edit Issue form with access to all of the fields.

The issue should be visible in both the Work and Plan views of the Scrum board under Agile
> <Project Name> Scrum Board or by searching for the ticket's name in the search bar. 

Reports: (manual or Automation reports)

Execution reports also should be uploaded under each user story which you performed
testing for future reference

Once testing Done

Sprint Final Day:

We will list out list of End points and list of user stories which are automated for the current
sprint .We will create in form of one PPT

Sprint Review meeting: In sprint review meeting Automation tasks we could show what
we have done for the current sprint as we create PPT/Created list once testing done

For sample Testplan,TestStatergy,Testcase template,Tracability matrix you can download

from the below site

https://strongqa.com/qa-portal/testing-docs-templates/test-report

Sprint Retrospective meeting:

During the Sprint Retrospective, the team discusses:

 What went well in the Sprint?

 What went wrong in the Sprint?

 What We had Learn in the Sprint?

 What should we do differently in the next sprint?

Length of Sprint Retrospective Meeting

The thumb rule for the length of a sprint retrospective meeting is that it usually take no

more than 45 minutes per week of sprint duration. The following table illustrates this rule:

Total Sprint Duration Sprint Retrospective Duration

1 week 45 minutes
2 weeks 90 minutes (1.5 hours)
3 weeks 135 minutes (2.25 hours)
4 weeks 180 minutes (3 hours)
Suppose 3 weeks sprint then sprint retrospective should happen ideally 2.25 hours by
discussing what went well, what not went well, how can we do better

7. Preparing Testing artifacts: (we don’t prepare fo

We should have for release and readiness these below testing artifacts

Requirements list for all sprints

Automation reports for all sprints

Release and readiness Document -by mentioning Number of Opened Bugs, Requirements,
End points list as together in one document. (below created sample document)

Release and Readiness

Please understand well

QA Responsibility: attending Release and Readiness meetings in agile (please read

below content to understand)

The above process repeated and got developed 5 sprints

Below Endpoints for one application are got developed in first 5 sprints and we have written
Testcases (for manual testing), Scenarios (Automation)

1- /RegisterUser
2- /LoginUser
3- /searchProduct
4- /FileterProduct
5- /addtoCart
6- /applyOfferCode
7- /PlaceOrder

So above endpoints are completed, and Business /Client has decided to release this
functionality to production environment 5 sprints

QA Activity for Release and readiness meeting:

1 We should create release and readiness documents for the above all endpoint’s
requirements. Please check below tables which we should have ready for release and
readiness

Project Info

Project ID
Project Name
Release Version

QA Information

Number of Endpoint Sprint Opened Bugs

Requirements
5 /Register Sprint-1 No
10 /Login Sprint-1 No
7

QA Automation execution report

Here we should attach Automation execution report for all endpoints and requirements
which are going to Live

8. Submitting testing artifacts

Once we have Testing artifacts these should be get reviewed by Test Coordinator (for
multiple projects one co Ordinator will be there in few organizations)

If there is no test CoOrdinator we should ask manager to review once before we go for
release and readiness meeting.

9. QA Sign Off Process

Once we submit testing artifacts and got reviewed by manager/Test co Ordinator QA Sign
Off is Done
You can provide your details in Release and readiness meeting regarding any open bugs
how those impacts if application goes into live

If there are no Bugs in Application. good to go Live Environment

Part-3 -API Interview Questions: -

1. Few major questions are covered from 1 to 5th Page (very important)
2. API testing process from 6th page to 17th Page (you will be able to answer any real time
process)
3. What is Query parameter and what is path parameters in RestAPI? (Read well)

What is Query Parameter?

 Query Parameter is used to filter or sort the resources.

For example, In case, if we need to filter out the students based on their class or
section, we are going to use ‘Query Parameter’. (GET /students?class=9&section=B)

 Sometimes there is a confusion between the Query Parameter and URI Parameter (or
Path Parameter). ‘Path Parameter’ is basically used to identify a specific resource.

For example, In case, if we need to identify a student based on his/her rollNumber, we are
going to use ‘Path Parameter’.

GET /student/{rollNumber}

4. API vs UI Testing

If you have API testing, you don’t need UI testing, right?  Don’t say yes

Then if you have UI testing, you don’t need API testing? Don’t say yes

- First, test as much as you can with API testing.  Take a look at all of your
possible endpoints and create a suite of tests for each.  Be sure to test both the
happy path and the possible error paths.  On every test, assert that you are
getting the correct response codes
- Once you have tested all the scenarios you can think of with API testing, then it’s
time to think about UI testing.

UI Testing:
-  For example, if you are testing an address book, the most likely scenario for a
user would be adding in a new address.  You could create a UI test that would
navigate to the address book, click a button to add a new address, add the
 address, save it, and then search the address book to verify that it has been
saved.  

Conclusion: Once you have tests that verify all the important elements on your page,
you can stop writing UI tests.  It’s not necessary to create lots of scenarios where each
field is validated for various incorrect entries, because a) you already created those
scenarios in your API tests, and b) you already have one UI test that verifies that the
error message is displayed. 

5.  Which protocol is used by RESTful web services?

RESTful web services make use of HTTP protocol as a medium of communication

between client and server.

6. Explain the caching mechanism?

Ans. 
The goal of caching is never having to generate the same response twice. The benefit of
doing this is that we gain speed and reduce server load
Caching is a process of storing server response at the client end. It makes the server
save significant time from serving the same resource again and again.

The server response holds information which leads a client to perform the caching. It
helps the client to decide how long to archive the response or not to store it at all.

7. What is Synchronous and Asynchronous API calls?

Synchronous means that you call a web service (or function or whatever) and wait until
it returns - all other code execution and user interaction is stopped until the call
returns. Asynchronous means that you do not halt all other operations while waiting for
the web service call to return.

IF your service is Synchronous call you might need to keep on checking for every 5 to 1
0 seconds for response code by automation code

8. If developer not accepting specific bug what you do?

As we raise bug with detail screenshot and reproducible steps, Still after providing the details if he is
not accepting and not able to reproduce from his side
Then…we need to record one video in a webex or with screen recorder reproducible steps and give path
in bug report so that he will go and check (UI Selenium Testing Question)