Saturday, 2 July 2011

Testing Methodologies

Leave a Comment

Testing Methodologies 

Testing Methodologies / Testing Strategies:

Testing Methodology is a Scheme / Approach / Strategy that explains what kind of methodology can be utilized at different phases of the SDLC.
Testing Methodologies are also called testing strategies.
There are 3 Testing Methodologies available.
1) Black Box Testing
2) White Box Testing
3) Gray Box Testing

1) Black Box Testing:
(This is especially for Testers).
It is also called as Functional Testing (Functional based Testing).
It is also called as requirements based Testing.

Definition: The process of testing the application without consideration of the code but with consideration of the Functionalities / Requirements of the application.
In Black Box Testing, Testers will never bother about the code and Testers will not bother about the software environments. (Software environment = coding language).
Testers will mainly focus on requirements and the behavior of the application (Functionality of the application), based on the functional requirements testers will have to design test plans and test cases.
And later what is the coding is done application build is release to QA and now testers will execute the Functional Test Cases on the application build.
Black Box testing has the following testing types as part of it.
1) Smoke Testing
2) Functional Testing.
3) Integration Testing
4) System Testing
5) Regression Testing
6) Automation Testing
7) UAT

2) White Box Testing:

(This is especially for developers).
This is also called structural testing (structural base to testing).
This is also called code based testing.
This is also called clear based testing.

Definition: The process of testing the application with consideration of the code (like loops, structures, conditional statements, Functions, Procedures, and Structures and so on) focusing the code level executions.
Developers consider each and every Module level code, all the loops, conditions, functions in their code and so foe such White Box Testing.
White Box testing as following testing types as part of it.

1)      Unit Testing
a.       Code base Testing
b.      Statement coverage
c.        Loops coverage
d.       Functional coverage
e.        Module coverage
2) Integration Testing
a. Top-down approach
b. Bottom-up approach
c. Hybrid-approach

3) Gray Box Testing:
The process of testing the application in both the considerations like considering the code and considering the functionalities of the application is called as Gray Box Testing.
This is also called as Hybrid Testing.
With the gray box testing methodology we lose both the White Box Testing methodology and Black Box testing methodology while testing the application.
Usually this kind of testing is carried out by the developers who have testing experience also (person = Dev + QA).

Read More...

Roles and Responsibilities of Testers

Leave a Comment
o   Roles and Responsibilities of Testers

ü  Test manager:
o   SPOC for any QA related activities
o   Estimating test efforts and schedule the testing process.
o   Act as an interface between the testing team and development team
o   Carry out QA requirements analysis.
o   Test and review the requirements and provide feedback to the Business Analysis team.
o   Coordinate QA activities with complete QA tasks.
o   Review all QA deliverables from Company.
o   Scenario Test Case design and review test cases
o   Participate for the Defect Review meetings
o   Defect Tracking and Management.
o   Co-ordinate with Onsite / Offshore QA
o   Execute the Acceptance testing for Customer

ü  Test lead:
o   Primary contact for QA activities for App
o   Prepare the Quality Assurance Test Plan.
o   Carry out QA requirements analysis.
o   Test and review the requirements and provide feedback to the Business Analysis team.
o   Coordinate QA activities and complete QA tasks.
o   Review all QA deliverables to Onsite.
o   Design and Review QA Test Cases.
o   Design the Test Automation Procedures.
o   Conduct Sanity, Functionality, Integration, System and Regression, UI testing on the required components with the team.
o   Defect Tracking and Management.
o   Create Defect Summary Reports and Test Results document.
o   Set up the QA test environment.
o   Assist the team members in creating test data.
o   Create the QA Release Note.
o   QA Status updates


ü  QA Engineer / Test Engineer (Tester):
o   Understand customer requirements
o   Understand QATP, test strategy
o   Develop test cases according to Reqs / FRS / SRS / Use Cases / Test plans
o   Review and update test cases
o   Execute test cases
o   Log detail defect report
o   Involve in Sanity, Functional, Integration, System, Regression, and Defect Verification testing
o   Participate in Automation Testing
o   Provide accurate and detailed weekly task reports
o   Update traceability metrics
o   Assist QA Lead for ensuring successful delivery
Read More...

Requirements Flow

Leave a Comment
Requirements Flow 





Requirements Flow:
 
Everyone is aware that the application is designed for end users based on the customer requirements.
But, only few people are aware that there are lot many faces that draw the customer requirements into different layers before converting / reflecting into an application.
Here is the explanation.

Just have a look at the diagram.
More information with regards to the Requirements Flow could be added to the table at the later editions.

Requirement:            
The basic customer needs are called as Requirements.
The set of all customer needs put together is called requirements document or marketing requirements document.

BRS (Business Requirement Specification):
At Business level, all the customer requirements are documented and approved by customer.
All these bossiness requirements should exactly map to end user real-time scenarios

FRS (Function Requirements Specification):
The BRS are segregated into different Functions / Modules and are described in more detailed and such that more detailed information is provided with respect all the functions / modules of the application.
And these documents are called FRS.

SRS (Software Requirement Specification):
In depth of the requirements, such as the detailed information like windows / dialog boxes information, field level information and Just as clear-cut document for coding and prototypes are called as SRS

SRS (System Requirement Specification):
The entire SRS (Software Requirement Specification) are merged together so as to make complete System approach is called System Requirement Specification.

Use Cases:  
Use Case is a document that describes the User actions versus System / Application responses
Read More...

Why does software have bugs?

Leave a Comment


 
Why does software have bugs?

There are many reasons to put forth, let me bring up few points here.

Generally, software may have bugs because of the following reasons.

• Poor Requirements (Unclear Requirements)
• Programming errors
• Software complexity
• Changes in Requirements
• Time pressure
• Poor Project Management
• Inefficient development (Poorly coded modules)
• Poor Documentation
• Other reasons
Read More...

Saturday, 2 July 2011

Testing Methodologies


Testing Methodologies 

Testing Methodologies / Testing Strategies:

Testing Methodology is a Scheme / Approach / Strategy that explains what kind of methodology can be utilized at different phases of the SDLC.
Testing Methodologies are also called testing strategies.
There are 3 Testing Methodologies available.
1) Black Box Testing
2) White Box Testing
3) Gray Box Testing

1) Black Box Testing:
(This is especially for Testers).
It is also called as Functional Testing (Functional based Testing).
It is also called as requirements based Testing.

Definition: The process of testing the application without consideration of the code but with consideration of the Functionalities / Requirements of the application.
In Black Box Testing, Testers will never bother about the code and Testers will not bother about the software environments. (Software environment = coding language).
Testers will mainly focus on requirements and the behavior of the application (Functionality of the application), based on the functional requirements testers will have to design test plans and test cases.
And later what is the coding is done application build is release to QA and now testers will execute the Functional Test Cases on the application build.
Black Box testing has the following testing types as part of it.
1) Smoke Testing
2) Functional Testing.
3) Integration Testing
4) System Testing
5) Regression Testing
6) Automation Testing
7) UAT

2) White Box Testing:

(This is especially for developers).
This is also called structural testing (structural base to testing).
This is also called code based testing.
This is also called clear based testing.

Definition: The process of testing the application with consideration of the code (like loops, structures, conditional statements, Functions, Procedures, and Structures and so on) focusing the code level executions.
Developers consider each and every Module level code, all the loops, conditions, functions in their code and so foe such White Box Testing.
White Box testing as following testing types as part of it.

1)      Unit Testing
a.       Code base Testing
b.      Statement coverage
c.        Loops coverage
d.       Functional coverage
e.        Module coverage
2) Integration Testing
a. Top-down approach
b. Bottom-up approach
c. Hybrid-approach

3) Gray Box Testing:
The process of testing the application in both the considerations like considering the code and considering the functionalities of the application is called as Gray Box Testing.
This is also called as Hybrid Testing.
With the gray box testing methodology we lose both the White Box Testing methodology and Black Box testing methodology while testing the application.
Usually this kind of testing is carried out by the developers who have testing experience also (person = Dev + QA).

Roles and Responsibilities of Testers

o   Roles and Responsibilities of Testers

ü  Test manager:
o   SPOC for any QA related activities
o   Estimating test efforts and schedule the testing process.
o   Act as an interface between the testing team and development team
o   Carry out QA requirements analysis.
o   Test and review the requirements and provide feedback to the Business Analysis team.
o   Coordinate QA activities with complete QA tasks.
o   Review all QA deliverables from Company.
o   Scenario Test Case design and review test cases
o   Participate for the Defect Review meetings
o   Defect Tracking and Management.
o   Co-ordinate with Onsite / Offshore QA
o   Execute the Acceptance testing for Customer

ü  Test lead:
o   Primary contact for QA activities for App
o   Prepare the Quality Assurance Test Plan.
o   Carry out QA requirements analysis.
o   Test and review the requirements and provide feedback to the Business Analysis team.
o   Coordinate QA activities and complete QA tasks.
o   Review all QA deliverables to Onsite.
o   Design and Review QA Test Cases.
o   Design the Test Automation Procedures.
o   Conduct Sanity, Functionality, Integration, System and Regression, UI testing on the required components with the team.
o   Defect Tracking and Management.
o   Create Defect Summary Reports and Test Results document.
o   Set up the QA test environment.
o   Assist the team members in creating test data.
o   Create the QA Release Note.
o   QA Status updates


ü  QA Engineer / Test Engineer (Tester):
o   Understand customer requirements
o   Understand QATP, test strategy
o   Develop test cases according to Reqs / FRS / SRS / Use Cases / Test plans
o   Review and update test cases
o   Execute test cases
o   Log detail defect report
o   Involve in Sanity, Functional, Integration, System, Regression, and Defect Verification testing
o   Participate in Automation Testing
o   Provide accurate and detailed weekly task reports
o   Update traceability metrics
o   Assist QA Lead for ensuring successful delivery

Requirements Flow

Requirements Flow 





Requirements Flow:
 
Everyone is aware that the application is designed for end users based on the customer requirements.
But, only few people are aware that there are lot many faces that draw the customer requirements into different layers before converting / reflecting into an application.
Here is the explanation.

Just have a look at the diagram.
More information with regards to the Requirements Flow could be added to the table at the later editions.

Requirement:            
The basic customer needs are called as Requirements.
The set of all customer needs put together is called requirements document or marketing requirements document.

BRS (Business Requirement Specification):
At Business level, all the customer requirements are documented and approved by customer.
All these bossiness requirements should exactly map to end user real-time scenarios

FRS (Function Requirements Specification):
The BRS are segregated into different Functions / Modules and are described in more detailed and such that more detailed information is provided with respect all the functions / modules of the application.
And these documents are called FRS.

SRS (Software Requirement Specification):
In depth of the requirements, such as the detailed information like windows / dialog boxes information, field level information and Just as clear-cut document for coding and prototypes are called as SRS

SRS (System Requirement Specification):
The entire SRS (Software Requirement Specification) are merged together so as to make complete System approach is called System Requirement Specification.

Use Cases:  
Use Case is a document that describes the User actions versus System / Application responses

Why does software have bugs?



 
Why does software have bugs?

There are many reasons to put forth, let me bring up few points here.

Generally, software may have bugs because of the following reasons.

• Poor Requirements (Unclear Requirements)
• Programming errors
• Software complexity
• Changes in Requirements
• Time pressure
• Poor Project Management
• Inefficient development (Poorly coded modules)
• Poor Documentation
• Other reasons