Question No. 6: Design at least five Functional Test Cases for Login page.

https://www.studocu.com/row/document/bahria-university/software-quality-assurance/midterm-1-
2020-questions-and-answers/8550180

Sample Test Cases for a Login Page (Includes ALL important

functional and non-functional test cases for login page)
Whenever you will be asked to write the test cases for the ‘Form with
some controls’, you need to follow the list of rules for writing test cases as
mentioned below:
 Write a test case on each form object.
 Written test cases should be a combination of both negative and
positive test cases.
 Also, test cases should always be a combination of functional,
performance, UI, usability, and compatibility test cases.
 Test Cases – Login Page
 Following is the possible list of functional and non-functional
test cases for a login page:
 Functional Test Cases:
Sr.
No.
Functional Test Cases
Type- Negative/ Positive
Test Case
1
Verify if a user will be able to login with a valid username and
valid password.
Positive
2
Verify if a user cannot login with a valid username and an
invalid password.
Negative
3
Verify the login page for both, when the field is blank and
Submit button is clicked.
Negative
4
Verify the ‘Forgot Password’ functionality.
Positive
5
Verify the messages for invalid login.
Po
SOA
SOA is a method of integrating business applications and processes together so as to meet the
business needs.

In Software Engineering, SOA provides agility and flexibility to business processes. The changes
to the process or application can be directed to a particular component without affecting the whole
system.

The software developers in SOA either develop or buy chunks of programs called SERVICES.

Services can be a functional unit of application or business process, which can be reused or repeated by
any other application or process.

(For example, in the above image, Payment Gateway is a service which can be reused by any e-
commerce site. Whenever a payment needs to do, the e-commerce site calls/Requests the
Payment Gateway service. After payment is done on a gateway, a response is sent to the e-
commerce website)

Services are easy to assemble and easy to reconfigure components.

Services can be compared to building blocks. They can construct any application needed. Adding
and removing them from the application or business process is easy.
Services are defined more by the business function they perform rather than as chunks of code.
SOA Testing

SOA consists of various technologies. Applications built using SOA has various services which
are loosely coupled.

SOA Testing should focus on 3 system layers

Services Layer
This layer consists of the services, services exposed by a system derived from business

functions. For example –

Consider a Wellness Website which consists of

Weight Tracker

Blood Sugar Tracker

Blood Pressure Tracker

Trackers display the respective data and date they are entered. Services layer consists of the
services which gets the respective data from the Database–
Weight Tracker service
Blood Sugar Tracker service
Blood Pressure Tracker service
Login Service

Process Layer

Process Layer consists the processes, collection of services which are part of a single functionality.
The processes might be a part of user interface (for ex – A search engine), a part of an ETL tool (for
getting data from the database).
The main focus in this layer will be in user interfaces and process.
The user interface of the weight tracker and its integration with the Database is the primary focus.
Below functions will be of consideration
Adding new data
Editing existing data
Creating new tracker
Deleting data

Consumer Layer

This layer mainly comprises of user interfaces

 Based on the layer, the testing of an SOA application is distributed into three levels.

Service level
Interface level
End to End level

Top Down approach is used for Test Designing.

Bottom Up approach is used for Test Execution.

Functional Testing of Mobile Application

The Functional Testing of Mobile Application is a process of testing functionalities of mobile

applications like user interactions as well as testing the transactions that users might perform. The
main purpose of mobile application functional testing is to ensure the quality, meeting the
specified expectations, reducing the risk or errors and customer satisfaction.
The various factors which are relevant in functional testing are
Type of application based upon the business functionality usages (banking, gaming, social or
business)
Target audience type (consumer, enterprise, education)
Distribution channel which is used to spread the application (e.g. Apple App Store, Google play,
direct distribution)

The most fundamental test scenarios in the functional testing can be considered as :

To validate whether all the required mandatory fields are working as required.
To validate that the mandatory fields are displayed in the screen in a distinctive way than the non-
mandatory fields.
To validate whether the application works as per as requirement whenever the application
starts/stops.
To validate whether the application goes into minimized mode whenever there is an incoming phone
call. In order to validate the same we need to use a second phone, to call the device.
To validate whether the phone is able to store, process and receive SMS whenever the app is
running. In order to validate the same we need to use a second phone to send sms to the
device which is being tested and where the application under test is currently running.
To validate that the device is able to perform required multitasking requirements whenever it is
necessary to do so.
To validate that the application allows necessary social network options such as sharing, posting
and navigation etc.
To validate that the application supports any payment gateway transaction such as Visa,
Mastercard, Paypal etc as required by the application.
To validate that the page scrolling scenarios are being enabled in the application as necessary.
To validate that the navigation between relevant modules in the application are as per the
requirement.
To validate that the truncation errors are absolutely to an affordable limit.
To validate that the user receives an appropriate error message like “Network error. Please try after
some time” whenever there is any network error.
To validate that the installed application enables other applications to perform satisfactorily, and it
does not eat into the memory of the other applications.
To validate that the application resumes at the last operation in case of a hard reboot or system
crash.
To validate whether the installation of the application can be done smoothly provided the user has
the necessary resources and it does not lead to any significant errors.
To validate that the application performs auto start facility according to the requirements.
To validate whether the application performs according to the requirement in all versions of Mobile
that is 2g, 3g and 4g.
To perform Regression Testing to uncover new software bugs in existing areas of a system after
changes have been made to them. Also rerun previously performed tests to determine that the
program behavior has not changed due to the changes
To validate whether the application provides an available user guide for those who are not familiar
to the app
 LECTURE 11: TEST CASE TEMPLATE

A test case can have the following elements. Note, however, that a test management tool is
normally used by companies and the format is determined by the tool used.

Test Suite ID The ID of the test suite to which this test case belongs.

Test Case ID The ID of the test case.

Test Case Summary The summary / objective of the test case.

Related Requirement The ID of the requirement this test case relates/traces to.

Any prerequisites or preconditions that must be fulfilled prior to executing the

Prerequisites
test.

Test Script / Procedure Step-by-step procedure to execute the test.

The test data, or links to the test data, that are to be used while conducting the
Test Data
test.

Expected Result The expected result of the test.

Actual Result The actual result of the test; to be filled after executing the test.

Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed
Status
and ‘Blocked’ if testing is blocked.
Remarks Any comments on the test case or test execution.

Created By The name of the author of the test case.

Date of Creation The date of creation of the test case.

Executed By The name of the person who executed the test.

Date of Execution The date of execution of the test.

Test Environment The environment (Hardware/Software/Network) in which the test was executed

Test case review process

When the test engineer writes a test case, he/she may skip some scenarios, inputs and writes wrong
navigation steps, which may affect the entire test execution process.

To avoid this, we will do one round of review and approval process before starting test
execution.

If we don't go for the review process, we miss out some scenarios, accuracy won't be there, and
the test engineer won't be serious

Traceability Matrix

Traceability matrix is a table type document that is used in the development of software
application to trace requirements. It can be used for both forward (from Requirements to Design or
Coding) and backward (from Coding to Requirements) tracing. It is also known as Requirement
Traceability Matrix (RTM) or Cross Reference Matrix (CRM).

It is prepared before the test execution process to make sure that every requirement is covered in
the form of a Test case so that we don't miss out any testing. In the RTM document, we map all the
requirements and corresponding test cases to ensure that we have written all the test cases for each
condition.

The test engineer will prepare RTM for their respective assign modules, and then it will be sent to
the Test Lead. The Test Lead will go repository to check whether the Test Case is there or not and
finally Test Lead consolidate and prepare one necessary RTM document.

This document is designed to make sure that each requirement has a test case, and the test case is
written based on business needs, which are given by the client. It will be performed with the help
of the test cases if any requirement is missing, which means that the test case is not written for a
particular need, and that specific requirement is not tested because it may have some bugs. The
traceability is written to make sure that the entire requirement is covered.

We can observe in the below image that the requirement number 2 and 4 test case names are not
mentioned that's why we highlighted them, so that we can easily understand that we have to write
the test case for them.

Generally, this is like a worksheet document, which contains a table, but there are also many user-
defined templates for the traceability matrix. Each requirement in the traceability matrix is
connected with its respective test case so that tests can be carried out sequentially according to
specific requirements.
Note:

We go for RTM after approval and before execution so that we don't miss out on any Test Case for
any requirement.

We don't write RTM while writing the testing because it can be incomplete, and after writing the
test case, we don't go here because the test case can be rejected.

RTM document ensures that at least there is one test case written in each requirement, whereas it
does not talk about all possible test cases written for the particular requirement.

RTM Template

Below is the sample template of requirement traceability matrix (RTM):

Example of RTM template

Let us one sample of RTM template for better understanding:

Goals of Traceability Matrix

It helps in tracing the documents that are developed during various phases of SDLC.
It ensures that the software completely meets the customer's requirements.

It helps in detecting the root cause of any bug.

Types of Traceability Test Matrix

The traceability matrix can be classified into three different types which are as follows:

Forward traceability
Backward or reverse traceability

Bi-directional traceability

Forward traceability

The forward traceability test matrix is used to ensure that every business's needs or requirements
are executed correctly in the application and also tested rigorously. The main objective of this is to
verify whether the product developments are going in the right direction. In this, the requirements
are mapped into the forward direction to the test cases.

Backward or reverse traceability

The reverse or backward traceability is used to check that we are not increasing the space of the
product by enhancing the design elements, code, test other things which are not mentioned in the
business needs. And the main objective of this that the existing project remains in the correct
direction. In this, the requirements are mapped into the backward direction to the test cases.

Bi-directional traceability

It is a combination of forwarding and backward traceability matrix, which is used to make sure that
all the business needs are executed in the test cases. It also evaluates the modification in the
requirement which is occurring due to the bugs in the application.
Advantage of RTM

Following are the benefits of requirement traceability matrix:

With the help of the RTM document, we can display the complete test execution and bugs
status based on requirements.
It is used to show the missing requirements or conflicts in documents.
In this, we can ensure the complete test coverage, which means all the modules are tested.

It will also consider the efforts of the testing teamwork towards reworking or reconsidering on
the test cases.

What is a bug in software testing?

The Bug is the informal name of defects, which means that software or application is not working
as per the requirement.

In software testing, a software bug can also be issue, error, fault, or failure. The bug occurred when
developers made any mistake or error while developing the product.
While testing the application or executing the test cases, the test engineer may not get the expected
result as per the requirement. And the bug had various names in different companies such as error,
issues, problem, fault, and mistake, etc.

Basic terminology of defect

Let see the different terminology of defect:

Defect
Bug
Error
Issue
Mistakev
Failurev
Terms Description Raised by

Defect When the application is not Test Engineer

working as per the requirement.

Bug Informal name of defect Test Engineer

Error Problem in code leads to the Developer, Automation Test Engineer

errors.

Issue When the application is not Customer

meeting the business
requirement.

Mistake Problem in the document is --

known as a mistake.

Failure Lots of defect leads to failure --

of the software.

Why defect/bug occur?

In software testing, the bug can occur for the following reasons:

Wrong coding
Missing coding
Extra coding

Wrong coding

Wrong coding means improper implementation.

For example: Suppose if we take the Gmail application where we click on the "Inbox" link, and
it navigates to the "Draft" page, this is happening because of the wrong coding which is done by
the developer, that's why it is a bug.

Missing coding

Here, missing coding means that the developer may not have developed the code only for that
particular feature.

For example: if we take the above example and open the inbox link, we see that it is not there
only, which means the feature is not developed only.

Extra coding

Here, extra coding means that the developers develop the extra features, which are not required
according to the client's requirements.

For example:

Suppose we have one application form wherein the Name field, the First name, and Last name
textbox are needed to develop according to the client's requirement.

But, the developers also develop the "Middle name" textbox, which is not needed according to
the client's requirements as we can see in the below image:
If we develop an extra feature that is not needed in the requirement, it leads to unnecessary extra
effort. And it might also happen that adding up the extra feature affects the other elements too.

Bug tracking tool

We have various types of bug tracking tools available in software testing that helps us to track the
bug, which is related to the software or the application.

Some of the most commonly used bug tracking tools are as follows:

Jira
Bugzilla
Redmine
Mantis
Backlog

Jira

Jira is one of the most important bug tracking tools. Jira is an open-source tool that is used for bug
tracking, project management, and issue tracking in manual testing.

Jira includes different features like reporting, recording, and workflow. In Jira, we can track all
kinds of bugs and issues, which are related to the software and generated by the test engineer.

To get the complete details about Jira tool, refer to the below link:

https://www.javatpoint.com/jira-tutorial

Bugzilla

Bugzilla is another important bug tracking tool, which is most widely used by many organizations
to track the bugs.

Bugzilla is an open-source tool, which is used to help the customer, and the client to maintain the
track of the bugs.
It is also used as a test management tool because, in this, we can easily link other test case
management tools such as ALM, quality Centre, etc.

Bugzilla supports various operating systems such as Windows, Linux, and Mac.

Bugzilla has some features which help us to report the bug easily:

A bug can be list in multiple formats

Email notification controlled by user preferences.
Advanced searching capabilities
Excellent security
Time tracking

Redmine

It is an open-source tool which is used to track the issues and web-based project management tool.
Redmine tool is written in Ruby programing language and also compatible with multiple databases
like MySQL, Microsoft SQL, and SQLite.

While using the Redmine tool, users can also manage the various project and related subprojects.

Some of the common characteristics of Redmine tools are as follows:

Flexible role-based access control

Time tracking functionality
A flexible issue tracking system
Feeds and email notification
Multiple languages support (Albanian, Arabic, Dutch, English, Danish and so on)

MantisBT

MantisBT stands for Mantis Bug Tracker. It is a web-based bug tracking system, and it is also an
open-source tool.

MantisBT is used to follow the software defects. It is executed in the PHP programing language.
Some of the common features of MantisBT are as follows:

Full-text search
Audit trails of changes made to issues
Revision control system integration
Revision control of text fields and notes
Notifications
Plug-ins
Graphing of relationships between issues

Backlog

The backlog is widely used to manage the IT projects and track the bugs. It is mainly built for the
development team for reporting the bugs with the complete details of the issues, comments.
Updates and change of status. It is a project management software.

Features of backlog tool are as follows:

Gantt and burn down charts

It supports Git and SVN repositories
IP access control
Support Native iOS and Android apps

Defect Life Cycle

Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect
goes through during its lifetime. It varies from organization to organization and also from project
to project as it is governed by the software testing process and also depends upon the tools used.

Defect Life Cycle - Workflow:

Defect Life Cycle States:
New - Potential defect that is raised and yet to be validated.
Assigned - Assigned against a development team to address it but not yet resolved.
Active - The Defect is being addressed by the developer and investigation is under progress.
At this stage there are two possible outcomes; viz - Deferred or Rejected.
Test - The Defect is fixed and ready for testing.
Verified - The Defect that is retested and the test has been verified by QA.
Closed - The final state of the defect that can be closed after the QA retesting or can be closed
if the defect is duplicate or considered as NOT a defect.
Reopened - When the defect is NOT fixed, QA reopens/reactivates the defect.
Deferred - When a defect cannot be addressed in that particular cycle it is deferred to future
release.
Rejected - A defect can be rejected for any of the 3 reasons; viz - duplicate defect, NOT a
Defect, Non Reproducible.
 Test execution

Test execution is the process of executing the code and comparing the expected and actual results.
Following factors are to be considered for a test execution process:
Based on a risk, select a subset of test suite to be executed for this cycle.
Assign the test cases in each test suite to testers for execution.
Execute tests, report bugs, and capture test status continuously.
Resolve blocking issues as they arise.
Report status, adjust assignments, and reconsider plans and priorities daily.
Report test cycle findings and status.

Risk Based Testing

Risk Based Testing (RBT) is a software testing type which is based on the probability of
risk. It involves assessing the risk based on software complexity, criticality of business,
frequency of use, possible areas with Defect etc. Risk based testing prioritizes testing of
features and functions of the software application which are more impactful and likely to
have defects.

Risk is the occurrence of an uncertain event with a positive or negative effect on the
measurable success criteria of a project. It could be events that have occurred in the past
or current events or something that could happen in the future. These uncertain events can
have an impact on the cost, business, technical and quality targets of a project.

Risks can be positive or negative.

Positive risks are referred to as opportunities and help in business sustainability. For example
investing in a New project, Changing business processes, Developing new products.

Negative Risks are referred to as threats and recommendations to minimize or eliminate them
must be implemented for project success.

When to implement Risk based Testing

Risk based testing can be implemented in

Projects having time, resource, budget constraints, etc.

Projects where risk based analysis can be used to detect vulnerabilities to SQL injection
attacks.

Security Testing in Cloud Computing Environments.

New projects with high risk factors like Lack of experience with the technologies used, Lack
of business domain knowledge.

Incremental and iterative models, etc.