Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
What is Test analysis (Test Basis) in Software Testing?
Introduction to Software Testing
Software testing is an examination that is carried out to offer information to stakeholders regarding the quality of the software product or service being tested. Program testing can also give a corporation with an objective, unbiased picture of the software, allowing them to grasp and comprehend the risks associated with software implementation. The process of executing a program or application with the goal of detecting failures and ensuring that the software product is fit for use is known as testing.
Software testing is the process of evaluating one or more qualities of interest by executing a software component or system component. These qualities, in general, reflect how much the component or system under test:
It should satisfy the criteria that informed its design and development
It should respond appropriately to a variety of inputs
It should accomplish its functions in a reasonable amount of time
It should be suitable for use,
It can be installed and used in the locations it was designed for
It should accomplish the desired outcome for all of its stakeholders
Given the virtually limitless number of possible tests for even simple software components, all software testing employs some approach to pick tests that are practicable given the time and resources available. As a result, software testing usually (but not exclusively) involves attempting to run a program or application with the goal of detecting errors caused by software flaws. When one problem is rectified, it can highlight other failures owing to deeper faults, or even produce new ones, therefore testing is an iterative process.
Software testing can give users and sponsors with objective, unbiased information about the quality of software and the danger of failure.
Software testing can begin as soon as executable software (even if only partially finished) is available. When and how testing is done is frequently determined by the overall strategy to software development. In a staged approach, for example, the majority of testing takes place after system requirements have been developed and then implemented in testable programs. Requirements, programming, and testing are frequently done concurrently in an agile methodology.
Test Analysis
In software testing, test analysis is the process of inspecting and analyzing the test artefacts in order to create test conditions or test cases. The goal of test analysis is to collect requirements and create test objectives so that test conditions can be established. As a result, it's also known as Test Basis. Test analysis is the process of assessing the test basis (all papers from which a component's or system's requirements can be deduced) and defining test objectives. It specifies WHAT is to be tested in the form of test conditions and can begin as soon as the testing foundation for each test level is set.
With Test Design, it can be done in parallel, integrated, or iteratively. Test Analysis assesses and reviews the test objectives and product risks, as well as defining precise success measures and goals.
When deciding on the level of detail, keep the following in mind −
The degree of testing; the level of detail and the quality of the test foundation
The complexity of the system/software and the development life cycle used
Risks associated with projects and products
The relationship between the test premise, what should be tested, and how it should be tested.
A tool for managing tests was utilized.
The test process' maturity, as well as the test analysts' abilities and knowledge
The degree of specification for Test Design and other test work deliverables.
Stakeholders' willingness to participate in consultations
The sources from which we derive test information are discussed below.
Software Requirement Specification
A software requirements specification (SRS document) lays out how a software system should be built. Simply said, an SRS provides a project roadmap to everyone involved. It provides high-level descriptions for the software's functional and non-functional specifications, as well as use cases that show how a user might interact with the system once it's finished.
The following elements are commonly seen in an SRS document −
What is the goal of the software that is being developed?
A general overview of the software
The software's functioning, or what it's designed to do
The software's performance in a production environment
Non-functional specifications
External interfaces, or how the software will communicate with hardware or other software.
Constraints imposed by the software's design or those imposed by the environment in which it will run
Business Requirement Specification
It outlines the software's functional specifications at a high level. This is a formal document that describes the client's requirements (written, verbal). It is usually generated by a Business Analyst who interacts with clients and is derived from the interaction and requirements of the clients.
The Business Process is a detailed description of how trading partners aim to perform their roles, build business relationships, and share duties in order to interact effectively with the help of their respective information systems.
Functional Design Document
A Functional Design Specification, or FDS, is a document that explains how a process or control system will work.
There are no highly technical details in the Functional Design Specification. Instead, it explains how the planned system will work, how people will interact with it, and what to expect in various operating circumstances. A functional design specification is useful for a variety of reasons. One of the key reasons is that it is more time-consuming to produce drawings or write PLC code without some type of written consensus on what the system is supposed to accomplish.
The Functional Design Specification can be shared with relevant team members, consumers, and stakeholders for feedback and review until the final document is agreed upon and signed. This review and change process is critical for ensuring that the final design is suitable for purpose and meets the needs of the stakeholders. Following that, the document is given to engineering teams for technical design and programming, with the functional specifications serving as a guide.
The Engineers will know what to design, the Programmers will know what the code should perform, and the Stakeholders will know what will be delivered if the Functional Design Specification is done.
The functional design specification outlines what must be implemented in a typical industrial software engineering life-cycle.
Case Study
Let's look at a case study to better understand Test Analysis.
Consider the following scenario: the customer sends you the following −
Search capabilities should be added to an e-commerce store.
Even if the application isn't finished yet, try to come up with a few test cases for this need. Pause here, complete your homework, then continue with the solution −
Below are a few test cases from among the many you might have considered.
When no term is entered, look at the search results.
When there isn't a corresponding product for the keyword entered, look at the search results.
When a number of corresponding products for the keyword searched are accessible, check the search results.
You examine the Test Basis (the client's requirement), analyze it, and transform it into Test Conditions.
This is what occurs during the various phases of the V-Model. At various stages, test plans/cases are prepared utilizing the associated papers.
3K+ Views
