How to test software requirements specification?

Software requirements specifications is often called “SRS” in its short form. We
can simply put it as a specific requirement for a software system or application.

PURPOSE OF SOFTWARE REQUIREMENTS SPECIFICATION

- These requirements specifications give a view of how exactly the system should and how it should behave.
- The software requirements specification comes with a set of cases describing all the possible interactions of the users with the software system or application.
- Such test cases have been termed as ‘use cases”.
- The software requirements specifications contains both kinds of requirements i.e., functional requirements as well as non functional requirements.
- Software requirements specification is an important sub field under the software engineering field.
- The software requirement specification provides a way to enlist all the requirements necessary for the development of the software project in one place.
- It deals with the following issues with regard to the software system or application:


1. Specification
2. Elicitation
3. Analysis and
4. Validation


OVERVIEW OF SOFTWARE REQUIREMENT SPECIFICATION

1.Introduction
This mentions the purpose of the software along with its scope, definitions, a brief overview and a set of references.

2.Overall Description
This section of the SRS describes the perspective, functions, user characteristics, constraints, dependencies and assumptions of the software application.

3. Specific Requirements
This is the most important part of an SRS and includes description of functions, interfaces, logical data base requirements, performance requirements, design constraints and key features.

HOW TO PRODUCE AN EFFECTIVE SOFTWARE REQUIREMENTS SPECIFICATION?

- For producing an effective software requirements specification, you need to test it.
- Therefore a software requirements specification testing has been designed.
- It is popularly known as requirements analysis.
- Requirements analysis analyzes all those tasks that help in identifying the requirement specifications of the software system as well as the requirements specifications itself.
- This actually forms the initial stage of the requirements engineering which is again concerned with the above listed activities.
- The analysis of the requirements specification is crucial for any software system or application.
- All the identified requirements should have the following properties:


1.Actionable
2.Can be documented
3.Testable
4.Traceable
5.Measurable and
6.Defined


PHASES OF SOFTWARE REQUIREMENTS SPECIFICATION TESTING
The software requirements specification testing comprises of the following three phases:

#1. Elicitation of the Requirements:
- This phase involves the identification of the requirements of the consumers.
- This process of communicating with the users and gathering requirements is very well known as requirements gathering.

#2. Analysis of the Requirements:
- This phase involves the determination of the clarity, completeness, ambiguity, contradiction of the requirements.
- If issues are found, they are resolved.

#3. Recording of the Requirements
- There are various ways in which the requirements might be documented.
- Whatever the way maybe, it should be clear and concise.
- Some commonly used methods are: natural language documents, user stories, process specifications and use cases.

What is the difference between conventional and unconventional testing?

Conventional testing and unconventional testing are a less heard testing methodology. Before we discuss about these two methods, let's discuss about the “quality management system” or QMS as it is called in its short form.

QUALITY MANAGEMENT SYSTEM
- Quality management system can be thought of as an organizational structure which states and manages the processes, procedures and resources to be implemented for better quality management.
- Earlier random sampling and simple statistics were used for predicting the output of a test in production line.
- But eventually by the end of the 19th century the entering the data manually for these test cases was considered to be a costly method.
- Later in the 21st century the quality management system succeeded in overcoming this problem.
- It came with a new transparent and sustainable technology which gradually achieved a wide customer satisfaction.

CONVENTIONAL AND UNCONVENTIONAL TESTING
- Conventional testing is nothing but a similar initiative of quality management system.
- Conventional testing is entirely based up on the standards and conventions of the testing as defined by the quality management system.
- It is a way of maintaining the testing standards.
- Since the conventional testing is guided by some conventions, hence it was named so.
- Unconventional testing, we can say just by looking at the name that it doesn’t follow any conventions.

DIFFERENCES BETWEEN CONVENTIONAL & UNCONVENTIONAL TESTING

DIFFERENCE #1:
- In conventional testing, only features and functionality of a software system or application are tested by the engineer in charge of the testing cycle.
- In unconventional testing, only the documentation is verified on the basis of the quality assurance principles.

DIFFERENCE #2:
- In unconventional testing, the documentation is tested from the starting phase of SDLC (systems development life cycle) by the testers of quality assurance.
- Conventional testing comes into play only during the testing phase of the systems development life cycle.

DIFFERENCE #3:
- In conventional testing, the developed components of the application are checked by the tester for whether they are working according to the expectations of the consumers or not.
- A typical unconventional testing starts from the coding phase of the systems development life cycle.

DIFFERENCE #4:
- Unconventional testing keeps a track of the whole software development process on the basis of the quality assurance principles i.e. whether or not the software has been developed according to the guidelines and specifications provided by the client company.
- The conventional testing is focused more up on the functionality of the software system or application.

USES & LIMITATIONS OF CONVENTIONAL TESTING
- Conventional testing is being used in migration projects these days.
- It sometimes happens that the testers performing the conventional testing have a very little knowledge about that particular application software which they are testing. In that the comparison testing is employed.
- This is preferred because here it is not required that the tester should know what will be the outcome.
- This problem can be solved also if the development team has already prepared the test scripts for the tester.
- Conventional testing is a bit expensive as it requires a lot of time to test, verify and validate each and every test script.
- There will be a certain number of errors in a program that is of course obvious and depends up on the degree of complexity of the program
- Errors also depend on the kind of migration process being followed in the project.
- The aspects of the software system or application failing these tests have to be corrected and retested accordingly.

What is build verification testing technique?

Build verification test is often abbreviated to “BVT”. This test is more commonly known as “build acceptance test”. We can make out from the term itself that this test consists of test cases that are executed on the build of a software product in order to verify that the build of that particular software system or application is testable before the software product is passed on to the testing team for testing.

ABOUT BUILD VERIFICATION TEST
- The main build verification test consists of smaller test cases and these test cases exercise the functionality of the mainstream of the software system or application.
- Any further testing on a build is performed only if it passes the build verification otherwise it is simple rejected.
- In the place of this build, the testing is continued to be carried up on the previous one.
- There should be at least one build that should pass the build verification test.
- Build verification is important to be carried out prior to the commencement of the testing phase.
- It tells the software developers whether the build of the software has been rightly developed or not.
- It also tells if the build is having any major issue.
- A build verification test also avoids time being wasted by carrying out unnecessary testing on the faulty builds.
- A typical build verification test is usually automated.
- When a build is rejected during the build verification test, it is again revered back to the software developer for correcting it.

Build verification test is also called by another name “smoke testing”. In build verification testing two aspects are mainly checked:

1. Build acceptance
2. Build validation


BASIC THINGS TESTER SHOULD KNOW ABOUT BVT

1. A build verification test consists of many smaller sub tests and each one of these tests verifies one functionality of the software system or application.
2. Build verification tests are very effective in saving the efforts of the testing team.
3. The build verification testing methodology can be used to test a build even if its major functionality are not working or are broke.
4. The build verification tests are designed very carefully so as to make them cover a major part of the functionality and features.
5. A certain time limit has been set for the build verification test to 30 minutes.
6. The testing time for running build verification should not exceed this limit.
7. Build verification testing is somewhat similar to the regression testing in the way that it is carried out on each and every build.
8. Build verification test is a way to test the integrity of the software project.
9. It checks whether or not all the modules have been integrated well with each other or not.
10. Maintenance of integrity between the modules is very important since any lag in the cooperation can cause the whole system to go bizarre.
11. Initially, the build verification testing technique was employed to check whether or not all the new features, functionality and modules have been included in the project to be released or not.
12. It also checks for the correctness of the formats of the included files.
13. Even the flags associated with a file are checked.
14. You should be very careful while deciding what all the test cases have to be carried out under the build verification test.
15. Your build verification test must include all the critical test cases and these test cases should not be unstable.
16. Another point to be kept in mind is that you should have an idea of the result of the test cases that you are including in the BVT.

What are application testing tools?

It requires some tools to carry out application testing and such testing tools are called application testing tools. Application testing tools are divided in the following sub categories:

1.Source test tools
2.Functional test tools
3.Performance test tools
4.Java test tools
5.Embedded test tools
6.Data base test tools

NEED OF APPLICATION TESTING TOOLS
- All the application softwares need to be tested before they are released to the consumers.
- For application testing either specific or particular testing tools can be used or a combination of various types of testing tools can also be used.
- Testing tools are employed to aid the tester in finding the bugs, errors or loop holes in the software system or application.
- Discovering bugs and errors at the early phases of development can avoid potential troubles.
- The bugs and errors should be resolved as soon as possible after discovering them.
- Testing can be made more effective by using proper testing tools.

TYPES OF APPLICATION TESTING TOOLS
Now let us see what all types of tools are available for application testing.

1. Source Test Tools
Tools falling under this category are used for finding bugs and errors in the source code of the application software’s program. Few popular source test tools are:

(a) Ada test: Effective for dynamic testing for applications written in Ada.
(b) AQ time: This tool tests the applications based on the languages like Visual C++, Intel C++, and visual Fortran etc. It comes with many memory usage pro-filers.
(c) CMT++: This tool is used for static testing of the application software having C or C++ as its source code language.
(d) Code Wizard: This tool has been specially designed for analyzing the applications written in C++ language.

2. Functional Test Tools
These type of tools are required to test both the functional as well as non functional requirements of the application:

(a).TEST: It is a typical unit testing tool and is used for testing classes that are based up on the .NET framework.
(b) AETG Web: This tool is very useful when it comes to the generation of the test cases. This tool has proved to be very efficient.
(c) Aberro Test: This is a typical interface testing tool. It can also be used for the verification of the requirements.
(d) Avignon Acceptance testing system
This tool basically makes use of XML language to define the language syntax and is used for writing test cases in the language of your choice.
(e) Automated test designer
This tool creates test cases based on the functional requirements of the application.

3. Performance Test Tools
As the name suggests, these tools are used for testing the performance level of the application softwares:
(a) App loader: This tool is used to carry out functional testing as well as load testing. it simulates the usage of the application. This tool is completely independent of the protocol.
(b) Bug timer: This tool is used basically for the documentation purpose of all the bugs and errors found during the performance testing of the application.
(c) Load runner: It is a load testing tool designed basically for the integrated web applications.

4. Java Test Tools
These tools test applications powered by java.
(a) Abbot: This tool tests java based GUIs.
(b) Agile test: It is used for unit testing in java applications.

5. Embedded Test Tools
These tools are used to test the application software components that are embedded in the code:
(a) Message magic: It is used for testing the subsystems.
(b) Tbrun: It is an automatic testing tool used for C, C++ etc.

6.Data Base Tools
It is used for testing data base of the application softwares:
(a) AETG: It is used to generate test cases.
(b) Data generator: It is used for generating input test data.

What are low level and high level test cases? List out the differences?

IMPORTANCE OF TEST CASES
- Test cases are such an important part of software testing that they can’t be neglected.
- Test cases form the basis of any software testing methodology.
- After all, the efficiency of the software testing depends on how effective are the test cases developed for that particular type of software testing.
- The test cases are developed keeping in mind all the important aspects of the software testing.
- Aspects like the components of the application, its attributes, its features and functionality, kind of coverage needed, aim of the testing methodology and requirements of the software system or application.
- One test case tests only one feature, functionality or aspect of the software system or application.
- It is necessary that the test case is implemented properly and according to the specifications.
- If the test case is not implemented properly then it makes no sense of testing no matter how effective and efficient is the test case.

LOW LEVEL & HIGH LEVEL TEST CASES
There are basically two types of test cases about whom we shall be discussing in this article. These are namely low level test cases and high level test cases.

DIFFERENCES BETWEEN LOW LEVEL & HIGH LEVEL TEST CASES

DIFFERENCE #1:
- Low level test cases are developed pertaining to the low level bugs in a software system or application.
- On the other hand high level test cases are concerned with the bugs of high levels.
- Wherever a low level bug is suspected in the program code a low level test case is used for testing and wherever a high level bug persists, correspondingly a high level test case is used.

DIFFERENCE #2:
- High level test cases are developed for testing the major functionalities and features in a software system or application rather than just testing high level bugs.
- Major functionality may include display, update data base, retrieval and so on. They can be rather called test cases related to functionality.
- The low level test cases can be appropriately called test cases related to the user interfaces as they are very effective in testing the application’s user interfaces besides low level bugs.

DIFFERENCE #3:
- While carrying out the software testing, the high level test cases based on the requirements test the corresponding functionality.
- Requirements need to be identified properly so that there is no faltering while performing the test. This is called high level testing.
- Similarly testing carried out using low level test cases is called low level testing and is employed to test the software system or application at the micro level i.e., the expected outcome and the actual outcome.

DIFFERENCE #4:
- Low level test cases include the following test cases:
(a) For integration testing
(b) For unit testing
- On the other hand, the high level test cases are further sub divided into the following test cases:
(a) Test cases for system testing
(b) Test cases for functional testing and
(c) Test cases for acceptance testing.

DIFFERENCE #5:
- The high level test cases are able to provide better test coverage.
- They don’t focus much on the features and functionality but only to the extent that they should work properly and well in accordance with each other.
- The low level test cases are focused up on each and every minor detail of the program code.
- The program is tested in depth.
- Therefore we can say that the low level testing involves more detailed work than the high level testing.

DIFFERENCE #6:
- Low level testing and high level testing belong to the category of white box testing and black box testing respectively.

What is meant by error guessing methodology?

Errors and bugs are perhaps the worst enemy of a software system or application and of course cause a lot of nuisance in the programming and give nightmares to the program developers and testers. Till date several methodologies have been developed to cope up with these errors and bugs but, the problem of errors is something which cannot be rooted. It can only be controlled.

Error guessing and error seeding are two such technologies about which we will be discussing in this article.

CHARACTERISTICS OF ERROR GUESSING
- Error guessing is a self explaining term.
- It can be thought of as a software testing methodology or technique that employs test cases to dig out the bugs buried in the software program.

DIFFERENCE BETWEEN ERROR GUESSING & OTHER SOFTWARE TESTING METHODOLOGIES

Then what is the difference between error guessing and other software testing methodologies? Though they may seem similar, there is a considerable difference which lies in the composition of the test cases.

DIFFERENCE #1:
- The test cases used in other types of software testing methodologies are based up on the requirements specifications of the software system or the application. - But, in error guessing, the test cases involved are based up on the past experiences of the testing as well as on the experience of the program that is to undergo testing.

DIFFERENCE #2:
- These test cases are created by the tester who has been involved in the whole programming of the software system or application.
- The tester has a past experience of the older versions of the programs so that he can easily put forth the situations and conditions that can cause the system failure or give rise to errors like null pointers, division by zero or use of parameters that are invalid.
- Error guessing methodology like exploratory testing does not follow any explicit rules or regulations.
- The tester is free to choose the basis to base the test cases on whether be it on functional or non functional requirements, experience, and situation and so on.

ASPECTS USED BY TESTERS IN USING ERROR GUESSING
Testers who have an experience of using error guessing make use of the below mentioned aspects:

1. Knowledge about the methods and techniques used in the AUT like implementation technology and designing method etc.
2. Past experience of software testing in different phases. Such experience is required during the phase of the regression testing.
3. Past experience of testing similar software system or applications and a knowledge of the factors that caused defects in them.
4. Knowledge of typical errors like those mentioned above in the article which are implemented unknowingly in the code.
5. General Thumb rules of heuristics.

ADVANTAGES OF ERROR GUESSING
- Error guessing when implemented properly can gradually increase the efficiency and effectiveness of your software testing life cycle.
- The error guessing skills of a tester gradually improve with the gradual experience of software testing.
- Error guessing is the easiest software technology that a tester can ever use.
- It is just like a guessing game, you guess where all the errors might be hidden.
- This methodology does not require any specially designed tools.
- Error guessing involves seeding out of errors.
- Error guessing methodology can be applied while carrying all other software testing techniques so as to get much better outcomes since the error guessing helps a great deal in improving the quality of the test cases.
- Error guessing is a technique that roots those defects that appear to be an intuition in the AUT.

What is meant by severity of a bug? What are different types of severity?

We all know what a software bug is! It is a flaw, error or mistake in the software system or application that can cause it to crash or fail. Pretty much simple!
But very few of us are actually aware about the severity of a bug i.e., how much destruction it can cause to a software system or application.

- Bugs are of course results of the mistakes made by the software programmers and developers while coding the software program.
- Sometimes incorrect compilation of the source code by the program can also cause bugs.
- A buggy program is very hard to clean.
- Bugs can have a chain reaction also i.e., one bug giving rise to another and that in turn giving rise to one more bug and so on.
- Each bug has its own level of severity that it causes to the software system or application.
- While some bugs can work out total destruction of the program, there are some bugs that do not even come in to detection.
- Some bugs can cause the program to go out of service.
- In contrast to these harmful bugs, there are other bugs which are useful such as security bugs.

WHAT IS SEVERITY OF A BUG & ITS TYPES

-"Severity can be thought of as a measure of the harm that can be caused by a bug."
- Severity is an indication of how bad or harmful a bug is.
- The higher the severity of a bug, the more priority it seeks.
- Severity of the bugs of software can sometimes be used as a measure of its overall quality.
- Severity plays a major role in deciding the priority of fixing the bug.
- It is important that the severity of the bugs is assigned in a way that is logical and easy to understand.

There are several criteria depending on which the severity of a bug is measured. Below mentioned is one of the most commonly used ranking scheme for measuring severity of bugs:

1.Severity 1 Bugs
bugs coming under this category cease the meaningful operations that are being operated by a software program or application.

2.Severity 2 Bugs
Bugs coming under this category cause the failure of the software features and functionalities. But, still the application continues to run.

3.Severity 3 Bugs
Bugs coming under this category can cause the software system or application to generate unexpected results and behave abnormally. These bugs are responsible for inconsistency of the software system.

4.Severity 4 Bugs
Bugs coming under these categories basically affect the design of a software system pr application.

COMPONENTS OF SEVERITY
Severity has two main components namely the following:

1. Impact
- It is a measure of the disruption that is caused to the users when they encounter a bug while working.
- There is a certain level to which there is an interference with the user performing a task.
- Even the impact is classified in to various levels.

2. Visibility
- It is the measure of the probability of encountering the bug in future or we can say that it is measure of the closeness of a bug to the execution path.
- It is the frequency of the occurrence of a bug.

The severity is calculated as the product of both the impact as well as visibility. A measure of perceived quality and usefulness of the software product is given by the severity. Therefore it would not be wrong to say that the severity provides an overall measure of the quality of the software system or application.