pushpendra sarswat

pushpendra sarswat seo fundamental

pushpendra sarswat

pushpendra sarswat

pushpendra sarswat, pushpendra saraswat

Pushpendra sarswat

pushpendra sarswat

 

 

pushpendra sarswat

BRS --> SRS --> FRS

... this is the hierarchyBusiness requirement specification (BRS) : It's having all the business rules , it will prepared by Business analyst/Client, but we are unable to understand that business rules , so our domain experts will create FRS or SRS, so that we can easily understand. It contains brief description about the application. It is the 1st process that should be followed by every Organization in order to gather the Customer/client business requirements.
A Software Requirements Specification (SRS) is a comprehensive description of the behavior of a system to be developed. It includes use cases that describe all of the interactions that users will have with the software. Use cases are known as functional requirements. An SRS may also include hardware interfaces communication interfaces as well as other non-functional requirements such as performance requirements quality standards and design constraints. It's having all the software requirements information , so totally almost both are same (some what we can say). System Requirement Specification in which PM/PL collect the information of requirements which will be needed for the development of Application. SRS Prepared by the Developer TL/PM/PL by taking inputs from BRS.
After completion of developing BRS, Business Analyst people will concentrate to develop SRS Doc basing on BRS Doc . This Doc defines Customer Use case requirements and system requirements to be developed as new software.
It contains functional and nonfunctional requirements of the project suppose a function is there to add two numbers adding the function is functional requirement the color of the numbers, background color these type of details are non functional requirements.

The contents of SRS are

                 1. Use Case

                 2. Use Case Diagram

                 3. Task Flow Diagrams

                 4. Pictorial Diagrams

                 5. Actors

                 6. Pre conditions, Post conditions etc.

A Functional Requirements Specification (FRS) can be derived from the SRS. This document describes the processes that users employ when interacting with the system. It describes inputs (what a user does) and outputs (how the application responds to user input). This document is often used by members of a test team to create test cases. It's having all the information of functionality which are using in our project , its having all functional rules. Prepared by the developer.

A document that describes in detail the characteristics of the product with regard to its. Functional Requirement Specification in which mentioned all the details of System functionality. How system works. All the conditions and Validation as well as process are mentioned in FRS. Functional Requirement Specification is also called as Business Requirement Specification.
The contents of FRS :

                 1. Purpose

                 2. Objectives

                 3. Scope & Requirements

                 4. Functional & Non Functional requirements                    

                 5. Security levels

                 6. Existing & Non Existing environment

The Functional Requirements Specifications deals with the Client Requirements and the Software Requirements Specifications deals with the Company resources.To begin with, we should understand the difference between the two document types. Software Requirements Specification describes the system's functional as well as non-functional requirements (e.g. performance requirements, security requirements, availability requirements etc.). On the other hand Functional Requirements Specification (FRS) deals with the functional requirements only.

In a particular project, the following four possibilities exist.

1) Both SRS and FRS are available

In this case, you should find out which document is the latest one. As mentioned above, you may understand the non-functional requirements from the SRS and in case the FRS is the latest document, the functional requirements from there. Be warned that sometimes even non-functional requirements are documented in the FRS. The structure of the available SRS and FRS should be able to guide you in your study.

2) Only SRS is available

There is no confusion in this case. You may understand all the software requirements from this document.

3) Only FRS is available

You may understand the functional requirements from this document. However, you should find out about the non-functional requirements from the business analyst/ project manager/ customer support etc.

4) None of these documents is available

This can happen when the project has been running for a long time. Either the SRS or FRS documents will not be available or they will be quite out-of-date and therefore, unusable.

In such a case, you should find out the availability of any other documents/ material e.g. high-level business requirements, existing help files/ user manuals, existing test cases, user stories, customer issues and resolutions etc. In addition, it becomes important to discuss the requirements with various project roles that may be present e.g. system analyst, business analyst, product management, development, support etc. so that you may get your queries resolved. If you notice any discrepancies, you should point it out to the concerned roles and note their resolution.

On top of SRS/ FRS, the Test Engineer should refer Change Requests (mainly enhancements/ modifications to the software) and the resolution of customer issues.

By following the above guidelines, the Test Engineer can understand the requirements and subsequently perform testing.

Testing types by pushpendra sarswat
 

1. Unit Testing

• Unit Testing is primarily carried out by the developers themselves
• Deals functional correctness and the completeness of individual program units
• White box testing methods are employed

2. Integration Testing

• Integration Testing: Deals with testing when several program units are integrated
• Regression testing: Change of behavior due to modification or addition is called ‘Regression’. Used to bring changes from worst to least
• Incremental Integration Testing: Checks out for bugs which encounter when a module has been integrated to the existing
• Smoke Testing: It is the battery of test which checks the basic functionality of program. If fails then the program is not sent for further testing

3. System Testing

• System Testing : Deals with testing the whole program system for its intended purpose
• Recovery testing: System is forced to fail and is checked out how well the system recovers the failure
• Security Testing: Checks the capability of system to defend itself from hostile attack on programs and data
• Load & Stress Testing: The system is tested for max load and extreme stress points are figured out
• Performance Testing: Used to determine the processing speed
• Installation Testing: Installation & un-installation is checked out in the target platform

4. Acceptance Testing

• UAT: ensures that the project satisfies the customer requirements
• Alpha Testing : It is the test done by the client at the developer’s site
• Beta Testing : This is the test done by the end-users at the client’s site
• Long Term Testing : Checks out for faults occurrence in a long term usage of the product
• Compatibility Testing : Determines how well the product is substantial to product transition

Testing Methods :

1.WhiteBox

White box testing is also called ‘Structural Testing / Glass Box Testing’ is used for testing the code keeping the system specs in mind. Inner working is considered and thus Developers Test.

• Mutation Testing- Number of mutants of the same program created with minor changes and none of their result should coincide with that of the result of the original program given same test case.
• Basic Path Testing- Testing is done based on Flow graph notation, uses Cyclops metric complexity & Graph matrices.
• Control Structure Testing- The Flow of control execution path is considered for testing. It does also checks :-

ConditionalTesting:BranchTesting,DomainTesting
DataFlowTesting
Loop testing: Simple, Nested, Conditional, Unstructured Loops

2.

GrayBox
Similar to Black box but the test cases, risk assessments, and test methods involved in gray box testing are developed based on the knowledge of the internal data and flow structures

3.

BlackBox
Also called ‘Functional Testing’ as it concentrates on testing of the functionality rather than the internal details of code.
Test cases are designed based on the task descriptions

• Comparison Testing-Test cases results are compared with the results of the test Oracle.
• Graph Based Testing-Cause and effect graphs are generated and cyclometric complexity considered in using the test cases.
• Boundary Value Testing-Boundary values of the Equivalence classes are considered and tested as they generally fail in Equivalence class testing.
• Equivalence class Testing-Test inputs are classified into Equivalence classes such that one input check validates all the input values in that class.

Load Testing Vs. Performance Testing

Load Testing is:

- Similar to, but not synonymous with performance testing
- About how many requests you can process in an amount of time.
- Concerned with the volume of traffic your website (or application) can handle or verifies capacity for users.
- Not intended to break the system
- Viewing the system from the user perspective
- Associated with black box testing

Performance Testing is:

- A super-set of load testing
- How fast a single request is processed
- Concerned with speed and efficiency of various components of the web application
- Useful with only one user and/or one transaction
- Viewing the system from the architecture perspective (behind the server side curtain)
- Associated with white box testing

Simple Definitions:

Performance Testing = how fast is the system?
Load Testing = how much volume can the system process?