Friday, April 17, 2020
Saturday, March 3, 2012
SELENIUM -- AUTOMATION TESTING TOOL
SELENIUM IDE
The Selenium IDE is an add-on to FireFox.
At basic level it allows us to
1. Record user actions when browsing in FireFox.
2. Replay recorded scripts.
3. Convert recorded scripts into programming languages such as Java, Ruby, and more.
4. Add verification and synchronization steps to the script during the recording process.
The IDE is an excellent support tool for writing automated test scripts in Selenium and it gets better with every release.
JAVA
Java is a programming language created by Sun. The Java that we will be using in selenium is very simple. If your work environment uses a different language e.g. Ruby , .Net , Phython. Chances are that you will be able to use Selenium-RC in that language. But I have chosen Java because it is the language that Selenium Server is written in. It is also mature and very well supported by IDEs ( Integrated Development Environments) which really make it simple for a beginner to learn.
ECLIPSE
Eclipse is free and open-source IDE which supports many programming languages.
Out of the box it provides many useful support aids for beginning java programmers.
1. Wizards for code creation .
2. code completion .
3. automatically fix common coding errors.
It is also simple to install , incredibly popular among developers, and has a lot of additional plugins that you can use to increase your productivity .
SELENIUM- RC
Selenium Remote Control is the server version of selenium. You write your tests using client APIs and these communicate with the server. The server then 'runs' your actions for you in the browser and reports the results back to your client.
Using selenium-RC allows you to write Automated tests in any supported programming language.
Tests written in this way are easier to maintain, more robust and easier to collaborate on as a team.
The Selenium IDE is an add-on to FireFox.
At basic level it allows us to
1. Record user actions when browsing in FireFox.
2. Replay recorded scripts.
3. Convert recorded scripts into programming languages such as Java, Ruby, and more.
4. Add verification and synchronization steps to the script during the recording process.
The IDE is an excellent support tool for writing automated test scripts in Selenium and it gets better with every release.
JAVA
Java is a programming language created by Sun. The Java that we will be using in selenium is very simple. If your work environment uses a different language e.g. Ruby , .Net , Phython. Chances are that you will be able to use Selenium-RC in that language. But I have chosen Java because it is the language that Selenium Server is written in. It is also mature and very well supported by IDEs ( Integrated Development Environments) which really make it simple for a beginner to learn.
ECLIPSE
Eclipse is free and open-source IDE which supports many programming languages.
Out of the box it provides many useful support aids for beginning java programmers.
1. Wizards for code creation .
2. code completion .
3. automatically fix common coding errors.
It is also simple to install , incredibly popular among developers, and has a lot of additional plugins that you can use to increase your productivity .
SELENIUM- RC
Selenium Remote Control is the server version of selenium. You write your tests using client APIs and these communicate with the server. The server then 'runs' your actions for you in the browser and reports the results back to your client.
Using selenium-RC allows you to write Automated tests in any supported programming language.
Tests written in this way are easier to maintain, more robust and easier to collaborate on as a team.
Sunday, October 16, 2011
HR INTERVIEW QUESTIONS AND ANSWERS
1. Tell me about yourself ?
A) You have to tell only about yourself answer should be short and simple first
a. Tell your name and where are you from just tell only the place
Ex: My name is ------- and I am from -------.
b. Tell your highest qualification and work experience (if any)
Ex: I am a b.tech graduate from college name and tell only how much experience in the field name
c. Tell your strengths
Ex: Tell your achievements in college , in your company ,
d. Tell about your family
Ex: My father is employee , mother is housewife, i have one brother and one sister.
2. Tell me about your strengths?
A. Tell all your positive qualities with examples from your previous work experience
3. Why do you want this job?
or
4. Why you want to work for our company?
or
5.What is your dream company?
or
6.What attracted you to this company?
or
6. What do you know about this company?
A)
1. I want to see myself in this position for which ever you are applying.
2. Your company has world class environment
3. Your company is a fortune 500 company
4. Carrier growth is good in your company
5. The company growth is increased at a faster rate
6. Your company is employee friendly , some of my friends working here suggested me openings are
there in our company , to work for your company is my aspiration .
7. Tell about the company profile and ranking and about the work environment.
7. Why should i hire you?
A) Tell about your work experience, your skills in the fields and achievements and rewards in your previous
company. Prove yourself that you are the best person for him to hire you
8. Are you willing to relocate?
A) Yes.
9. Work or Money?
A. As per client requirements
10. Hard Work or Smart Work?
A) If i have the knowledge about the project i can use my smart work and complete the work before the given time
If i do not have the knowledge about the project i will work hard and learn the things quickly and i will complete before the given time as early as possible.
11. Notice period?
A) I already had a informed my HR regarding this job interview i will join your company tell me the date when i have to join.
12. If you have any issue in the office whom will u report first?
A) I will share with my leaders.
Tuesday, October 11, 2011
AUTOMATION TESTING
AUTOMATION TESTING
Making the Manual Testing process automatic is called Automation Testing
or
It is a process of identifying various features to be re-tested in the modified versions developing and executing the scripts to validate the same is called Automation Testing.
BENEFITS OF AUTOMATION TESTING
1. Faster
2. Accurate
3. Repetitive
4. Re-Usable
5.
the automation is additional support for testing activities not a replacement for manual testing.
DECIDING FACTORS FOR AUTOMATION TESTING
1. Program-ability
2. Frequency of testing
3. Cost
TOOL SELECTION CRITERIA
We consider the following parameters for choosing automation testing tool
1.Cost
2.Features offered by the tool
3.Performance
4.Technology supported by the tool
5.Environments
6.Portability
7.Maintainability
8.Vendor Support (HP)
INTRODUCTION TO QTP
QTP is a functional regression testing tool introduced by Astra Incorporation later by Mercury , now it is a product of HP.
ADD-IN
Add-in is a communication software that contains a set of pre-defined methods which enables QTP to automate various Operations on the objects present in your application.
Q.How QTP executes a test?
A.
When you run a test qtp execute the script step by step while executing a particular step qtp goes to depository correct the properties of the object then try to identify when the object is identified then qtp performs the specified actions if not qtp throws error "cannot identify the object".
NOTE: by default qtp wait for maximum of 20 seconds to identify the object
VB SCRIPT
VB script is the scripting language offered by Microsoft which is default with qtp tool
VARIABLE
A Variable is a memory address location that holds a value.There are two types of variables
a. Scalar Variable
b. Array Variable
Again both variables are of two types
a.Implicit
b.Explicit
VB supports both Implicit and Explicit variables
NOTE: you can declare variables using either Dim or Public or Private statements
OPTION EXPLICIT
If Option Explicit is specified every variable must be declared before you use it.i.e, we can force VB script do not allow Implicit variables by specifying Option Explicit
DATATYPE IN VB SCRIPT
VB script is having only one data type called variant which allows any type of data we no need to specify data type while declaring a variable.
While----- End
while loop executes a set of statements for multiple iterations when the conditions written true if condition written false loop will exist
Do---- Loop
It is a flexible loop you can execute a set of statements for the true value written by the condition and also for the false written by the conditon
For loop
For loop is used to execute a set of statements for specific number of times
For Each
It is used to execute a block of statements for each item present in the array
Set Secure
It is used to supply encoded string such as password, cvv number etc in the specified text boxes.
Making the Manual Testing process automatic is called Automation Testing
or
It is a process of identifying various features to be re-tested in the modified versions developing and executing the scripts to validate the same is called Automation Testing.
BENEFITS OF AUTOMATION TESTING
1. Faster
2. Accurate
3. Repetitive
4. Re-Usable
5.
the automation is additional support for testing activities not a replacement for manual testing.
DECIDING FACTORS FOR AUTOMATION TESTING
1. Program-ability
2. Frequency of testing
3. Cost
TOOL SELECTION CRITERIA
We consider the following parameters for choosing automation testing tool
1.Cost
2.Features offered by the tool
3.Performance
4.Technology supported by the tool
5.Environments
6.Portability
7.Maintainability
8.Vendor Support (HP)
INTRODUCTION TO QTP
QTP is a functional regression testing tool introduced by Astra Incorporation later by Mercury , now it is a product of HP.
ADD-IN
Add-in is a communication software that contains a set of pre-defined methods which enables QTP to automate various Operations on the objects present in your application.
Q.How QTP executes a test?
A.
When you run a test qtp execute the script step by step while executing a particular step qtp goes to depository correct the properties of the object then try to identify when the object is identified then qtp performs the specified actions if not qtp throws error "cannot identify the object".
NOTE: by default qtp wait for maximum of 20 seconds to identify the object
VB SCRIPT
VB script is the scripting language offered by Microsoft which is default with qtp tool
VARIABLE
A Variable is a memory address location that holds a value.There are two types of variables
a. Scalar Variable
b. Array Variable
Again both variables are of two types
a.Implicit
b.Explicit
VB supports both Implicit and Explicit variables
NOTE: you can declare variables using either Dim or Public or Private statements
OPTION EXPLICIT
If Option Explicit is specified every variable must be declared before you use it.i.e, we can force VB script do not allow Implicit variables by specifying Option Explicit
DATATYPE IN VB SCRIPT
VB script is having only one data type called variant which allows any type of data we no need to specify data type while declaring a variable.
While----- End
while loop executes a set of statements for multiple iterations when the conditions written true if condition written false loop will exist
Do---- Loop
It is a flexible loop you can execute a set of statements for the true value written by the condition and also for the false written by the conditon
For loop
For loop is used to execute a set of statements for specific number of times
For Each
It is used to execute a block of statements for each item present in the array
Set Secure
It is used to supply encoded string such as password, cvv number etc in the specified text boxes.
Thursday, September 1, 2011
SOFTWARE TESTING
SOFTWARE TESTING:
Testing a software application to find out the defects in it is called software testing.
Testing a software application to find out the defects in it is called software testing.
SOFTWARE APPLICATIONS
Software applications are two types
1.Product
2.Project
PROJECT:
Any software application developed for specific customer requirement then it is called Project.
Any software application developed for specific customer requirement then it is called Project.
PRODUCT:
Any software application developed for multiple customers requirements then it is called Product.
Any software application developed for multiple customers requirements then it is called Product.
SOFTWARE DEVELOPMENT PROCESS
1.Gathering Requirements
2.Planning
3.Design
4.Coding
5.Testing
6. Delivery and Maintenance
ERROR-DEFECT-FAILURE
ERROR: Any incorrect human action that produces problem in the system is called Error.
DEFECT:Deviation between expected behavior to actual behavior of the system is called Defect.
FAILURE: Deviations identified by end user while using a system is called Failure.
EARLY TESTING:
Conducting testing as soon as possible in the software development life cycle to find defects at early stages is called Early Testing.
Early testing is helpful to reduce the cost of fixing defects.
Q. Why do soft ware applications will have defects?
A. Some of the main reasons for the software applications have defects are given below
1. Incorrect Requirement specifications.
2. Wrong design.
3. Poor Coding
4. Complex business logic.
5. Complex technology
6. Work pressure
7. Frequently changing requirements.
PRINCIPLES OF TESTING:
EXHAUSTIVE TESTING:
Exhaustive testing is impossible.
If you test a functionality with all possible valid inputs and invalid inputs then it is called Exhaustive Testing.
An exhaustive testing is impossible Risk Based or Priority Based Testing is recommended.
RISK BASED TESTING
Identifying the operations which most likely o cause failures then testing these functionality as priority is called Priority Based Testing and also called Risk Based Testing.
DEFECT CLUSTERING
The small number of modules or functionality may contain more number of defects , concentrate more testing on these functionality (or modules).
PESTICIDE PARADOX
If the prepared test cases are not helping in finding the defects from software , we can add or modify the test cases for better testing. i.e. to find more defects.
TESTING SHOULD SHOW THE PRESENCE OF DEFECTS
We have to test the application with an intention of showing defects for which negative testing is best approach.
EARLY TESTING
Testing should start as early as possible in the software development life cycle.
TESTING IS CONTEXT DEPENDENT
We have to select appropriate testing approach based in the type of application we are testing.
ABSENCE OF ERROR IS A FALLACY
Bug free software application is impossible.
STATIC TESTING AND ITS TECHNIQUES
STATIC TESTING
Verifying whether we are developing the right system or not is called static testing, it is also called verification.This static testing is carried out with the help or reviews and walk through
REVIEW
Examining or cross checking any project or process related work is called Review.
TYPES OF REVIEWS
1.Management Review
2.Technical Review
3. Code Review
4. Test Case Review
these above review can be formal and informal
FORMAL REVIEW
If any review is conducted with a proper plan and by following proper documentation and procedures are called formal reviews.
Inspections and audits are best examples for formal reviews
INFORMAL REVIEWS
If any review is conducted without following any procedures and documentation then these reviews are called informal reviews.
WALK-THROUGH
Knowledge transfer sessions are called walk through. Where the discussions are made on the project which they have to test.
OBJECTIVES OF REVIEWS
Reviews are helpful to determine
1.Defects in requirements
2.Defects in design.
3.Deviations in coding standards.
4.To confirm the prepared test cases are not enough to validate a software or not and also helpful to improve the organisation process.
DYNAMIC TESTING
It is a process of checking does the source code and the application are working as expected or not.
It is also called validation.
LEVELS OF DYNAMIC TESTING
Dynamic testing will be carried out a four levels
1. Unit testing
2. Integration testing
3. System testing
4. User acceptance testing
UNIT TESTING
A smallest separable portion in the source code of the application is called unit.
Testing conducted on these units to check the code behind the units are working as expected or not is called Unit Testing.
It is also called module testing and also component testing.
INTEGRATION TESTING
Once all units are tested the programmers will combine all units and check the interactions among the units which is called integration testing.
Unit Testing and Integration Testing are collectively called white box testing.
WHITE BOX TESTING
Testing conducted on the source code by developers to check does the source code is working as expected or not is called White Box Testing
Q.What is the need of White Box Testing ?
A.
1. As the source code is visible finding the problems and rectifying the problems is so early for developers.
2. The defects that are identified in White Box Testing is so economical to resolve
3. To reduce the defects as early as possible white box testing is helpful.
4. And to ensure 100% code coverage
White Box Testing is also called Glass box testing , Structural testing , Clear box testing.
BLACK BOX TESTING
Testing conducted on the application by test engineer or by domain experts to check whether the application is working according to the customer requirements are not is called Black Box Testing.
Q. What is the need of Black Box Testing?
A.
1. White Box Testing is conducted in a technical perception where the Black Box Testing is conducted by testing engineer with an end user perception.
2. Programmer will conduct White Box Testing in a positive perception where as testers will conduct Black Box Testing with a negative perception where there is a chance of finding defects are more , the more defects you identify it results in a quality system.
3. White Box Testing will not cover non-functional area as non-functional requirements also very important for live projects to cover the same, Black Box Testing is required.
4. The objective of white box testing is 100% code coverage where as the objective of Black Box Testing is 100% customer business requirement coverage.
Black Box Testing is also called as Requirement Based Testing or Specification Based Testing.
SYSTEM TESTING
Validating the functional and non-functional requirements of the same is called System Testing.
System Testing is broadly classified into
1. Functional System Testing
2.Non-Functional System Testing
Functional system testing will be conducted in both positive perception and negative perception
POSITIVE TESTING
Testing conducted on the application in a positive approach to determine what the system supposed to do is called positive perception.
positive testing is helpful to check whether the customer requirements are justified in the application or not.
NEGATIVE TESTING
Testing software application with a negative perception to check what system not supposed to do is called negative testing.
negative testing is helpful in finding the defects from the software.
ADHOC TESTING
If you test a software application without following any procedures and documentation then it is called adhoc testing also called informal testing
FORMAL TESTING
If you test a software application by following all preplanned procedures and documentation then it is called formal testing.
RISK BASED OR PRIORITY BASED TESTING
Identifying the critical functionality in the system then deciding the order in which these functionality to be testing and applying testing in the same order is called Risk Based Testing.
RE-TESTING
Testing a functionality again and again or testing a functionality repetitively is called Re-Testing
Re-testing comes in the following two situations
1. Testing a functionality with multiple inputs to confirm the business validations are correctly implemented or not
2. Testing a functionality in the modified build to confirm the bug fixes are made correctly or not.
REGRESSION TESTING
It is a process of identifying various features in the modified build where there is a chance of getting side effects and Re-testing these features.
The new functionality added the existing system are the modifications made to the existing system and also bug fixes may introduce side effects.Regression testing is helpful to identify these side effects.
END-TO-END TESTING
Testing the overall functionality of the system including the data integration among all modules is called End-To-End Testing
EXPLORATORY TESTING
Exploring the application understanding the functionality, adding or modifying the existing test cases for better testing is called Exploratory Testing.
Exploratory testing comes under Adhoc testing.
MONKEY TESTING
Testing conducted on an application unevenly .i.e, in a zig-zag manner with an intention to find the tricky defects is called Monkey Testing . Monkey testing also comes under Adhoc testing.
NON-FUNCTIONAL SYSTEM TESTING
Validating various non-fictional aspects of the system such as user interface, user friendliness, security, compatibility, load, performance, stress, etc is called Non-Functional System Testing.
SECURITY TESTING
Validating whether all security conditions are properly implemented in software or not is called Security Testing.
CHECK LIST FOR SECURITY TESTING
1.Check does the secured data such as password, credit card cvv number are getting encrypted or not.
2.Check browser navigation's after session out.
3.Check direct url access of the both secured and non-secured pages.
4.Check for session expiry.
5.Check authorization
6.Check authentication
7.Check cookies
8.Check view source code option for secured pages.
PERFORMANCE TESTING
It is a process of measuring various efficiency characteristics of a system such as
1.Response time
2.Throughput or bandwidth or data transfer rate.
3.Load
4.Stress
5.Transactions per minute.
6. Transaction mix etc.
is called Performance Testing.
LOAD TESTING
Analyzing functional and performance behavior of the application under various load conditions is called Load Testing.
STRESS TESTING
Checking the application behavior under stress conditions is called Stress Testing.
or
Reducing the system resources and keeping load as constant, checking how the application is behaving is called Stress Testing.
RECOVERY TESTING
Checking how does the system is able to handle some unexpected and unpredictable situations is called recovery testing.
GLOBALIZATION TESTING
Checking does the application having a provision of setting and changing languages, date and time format, currency etc .if it is designed for global users is called Globalization Testing.
LOCALISATION TESTING
Checking default language, currency, data format etc. If it is designed for particular locality of users is called Localisation Testing.
INSTALLATION TESTING
Checking are we able to install the software successfully or not as per the guidelines given in installation document is called Installation Testing.
UNINSTALLATION TESTING
Checking are we able to uninstall the software from the system successfully or not is called Uninstallation Testing.
COMPATIBILITY TESTING
Checking does the application is compatible with different hardware and software environment are not is called Compatibility Testing.
SOFTWARE TESTING LIFE CYCLE
TEST PLANNING
It is the first phase of system testing where the management plan the high level and detail testing activities to be carried out.
Once a project is initiated for system testing at first project manager or test manager will define test strategy, based on this test strategy the detailed plan called test plan will be prepared.
TEST STRATEGY
It is a high level plan and approach that provides sufficient confidence on the project being tested.
TEST PLAN
It is a detailed day-to-day work plan that explains scope of testing , approach , resources, work schedules, etc. Test plan will be prepared by test lead/team lead/ test manager/ project manager.
TEST PLAN TEMPLATE (IEEE 829)
1.Introduction
2.Scope of testing
a) In scope
b) Out of scope
3.Test approach
4. Resources
5.Work schedules
6.Entry and Exit criteria
7.Test Deliverable.
OBJECTIVES OF TEST PLAN
1.A test plan document explains various procedures to be carried out while testing a software.
The main objective of the test plan is to determine
a) SCOPE OF TESTING: i.e, what are all features are to be tested and what are all not to be tested .
similarly , what type of testing is applicable and what types of testing is not applicable.
b) TEST APPROACH: i.e, various guidelines to be carried out while designing test cases, test data,
defect reports etc.
c) RESOURCES :i.e, hardware resources, software resources, and human resources.
d) WORK SCHEDULE: when testing is to be started and when to stop , how much time we have to
spend on particular features and etc.
e) ENTRY AND EXIT CRITERIA: i.e, when we have to start testing and when to stop testing.
f) TEST DELIVERABLE: i.e, when to deliver the software product or project to the end user.
TEST PLANNING
TEST ANALYSIS
We have to study the requirement
In these days test engineers will study various project requirement document such as BRS/SRS to understand project requirement.
While analyzing test requirements if there are any questions the same will be recorded in RCN template.
Once analysis is finished you can get the clarifications from the domain experts BRS template.
BRS TEMPLATE
BRS document contains the following sections
1.Client introduction
2.Project introduction
3.Existing system
4.Drawbacks in the existing system
5.Proposed system
6.Project architecture
SRS/FRS TEMPLATE
A typical FRS/SRS document will contain the following sections
1.Overview
2.Prototype
3.Business Validations
4.Use case diagrams or Use cases.
RCN TEMPLATE
A RCN (Requirement Clarification Note) is used to record your questions while analyzing the project requirement
In meetings you discuss about your questions with subject matter experts and get clarifications.
TEST CASE
A Test Case is a set of pre-condition steps to be followed input data and expected behaviour to validate a functionality in the system.
In simple words a test case is a brief description of what to test and how to test.
NOTE: In industries we prepare only functional test cases.
These functional test cases are again 3 types
1. Positive test cases.
2. Negative test cases.
3. Business validation test cases.
POSITIVE TEST CASE
A Test Case prepared in a positive perception to check what a system supposed to do is called Positive Test Case.
EX: Test Case
Check log in with valid inputs
NEGATIVE TEST CASE
A Test Case prepared in a negative perception to check what a system not supposed to do is called Negative Test Case.
EX: Test Case
Check log in with invalid inputs
BUSINESS VALIDATION TEST CASE
A Test Case prepared to check business conditions is called business validation test case.
EX: Check fund transfer with 1000, 10000,10001,50000 etc. is called Business Validation Test Case.
What is a good Test Case?
A Test Case that have high probability of catching defects is called a good test case.
TEST CASE DESIGN TECHNIQUES
Black Box Testing introduced the following techniques which helps in preparing the effective test cases to validate a functionality in the system
1. Equivalence Class Partitioning (ECP).
2.Boundary Value Analysis (BVA).
3.Decision Table Testing
4.State Transition Testing
5.Use Case Testing.
EQUIVALENCE CLASS PARTITIONING
According to ECP at first identified all possible test cases to validate a functionality in the system. Divide these test cases into groups while making a group make sure that all test cases that belongs to a group is producing the same output.Select one test case from each group preferably middle value for testing.
BOUNDARY VALUE ANALYSIS
It has observed that most of the time programmers are committing mistakes while specifying the boundary conditions to determine these defects BVA is helpful
According to BVA once ECP are defined identify the partition where there are ranges then determine outer boundaries and inner boundaries if any.
Consider lower boundary value and upper boundary value for each inner boundary value for positive testing , then consider lower boundary value -1 and upper boundary value +1 only for outer boundary for negative testing.
DECISION TABLE TESTING
It is helpful to derive the test cases if a functionality is depending on multiple inputs
EX: As log in depending on two inputs i.e., username and password to check log in we can cover the following test cases
INPUTS TC1 TC2 TC3 TC4
USERNAME VALID VALID INVALID INVALID
PASSWORD VALID INVALID VALID INVALID
NOTE: If a functionality is depending on more number of inputs we can reduce the test cases based on the application design.
STATE TRANSITION TESTING
Every software application will have various possible states, the state of the application will changes from one to another based on user actions and input supply .
State transition testing is helpful to derive the test cases in-order to cover all possible states of applications
USE CASE TESTING
Validating a software to confirm whether it is developed as per the use cases or not is called USE CASE TESTING.
REQUIREMENT TRACE-ABILITY MATRIX
Mapping between cases and requirements is called trace-ability matrix
ADVANTAGES OF TRACE-ABILITY MATRIX
> To determine the percentage of test coverage
> To identify a group of test cases belongs to a requirement which helps in modified bill testing the change
request easily.
SOFTWARE TESTING LIFE CYCLE
DEFECT REPORTING
Once a defect is identified we have to document the defect and report the same to the developer which is called bug reporting
We report the bug using Excel file or Quality Center or Bugzilla softwares
DEFECT SEVERITY
How serious the problem in the system or the impact of the problem in the system is called Severity .
AGE OF DEFECT
Time interval between detected date to the date of closure is called Defect Age.
or
How long the bug is present in the development life-cycle is called Defect Age
SHOW STOPPER DEFECT
A Defect which is not permitting us to continue further testing process is called Show Stopper Defect.
DEFECT PRIORITY
The order in which the defect has to be resolved is called Defect Priority.
NOTE:
1. Defect severity specified by tester where as defect priority is assigned by developer.
2. In General Defect Priorities and Severities are proportionate to each other but in some situations this may
change.
EX:
1.An example for Defect that takes Low Severity and High Priority
> Incorrect company logo
2.An example for Defect that takes High Severity and Low Priority
> A serious problem belongs to future release module
TEST CLOSURE
It is the last phase of STLC where the management prepares various test summary reports which explains the complete strategy about the reports.
COMMON DEPOSITORY
A Centralized computer system where you store and manage all project resources is called Common Depository
CONFIGURATION MANAGEMENT
Maintaining all project resources in a centralized system , maintaining appropriate version controlling based on changes made to them is called Configuration Management
EX: Visual Source Safe (VSS) , Concurrent Version System (CVS).
NOTE: QC is a test management tool also provided configuration management services
SOFTWARE DEVELOPMENT LIFE CYCLE
SEQUENTIAL MODULES
These are best suitable for small size applications where all development activities are carried out in a sequential order for the entire project.
ITERATIVE OR INCREMENTAL MODELS
These are best suitable for big projects in these models a big project is divided into modules and the application will be implemented module by module.
WATER FALL MODEL
It is a very beginning approach of development model where all development activities are carried out one after another for the entire project in this approach we used to conduct testing .
ERROR-DEFECT-FAILURE
ERROR: Any incorrect human action that produces problem in the system is called Error.
DEFECT:Deviation between expected behavior to actual behavior of the system is called Defect.
FAILURE: Deviations identified by end user while using a system is called Failure.
EARLY TESTING:
Conducting testing as soon as possible in the software development life cycle to find defects at early stages is called Early Testing.
Early testing is helpful to reduce the cost of fixing defects.
Q. Why do soft ware applications will have defects?
A. Some of the main reasons for the software applications have defects are given below
1. Incorrect Requirement specifications.
2. Wrong design.
3. Poor Coding
4. Complex business logic.
5. Complex technology
6. Work pressure
7. Frequently changing requirements.
PRINCIPLES OF TESTING:
EXHAUSTIVE TESTING:
Exhaustive testing is impossible.
If you test a functionality with all possible valid inputs and invalid inputs then it is called Exhaustive Testing.
An exhaustive testing is impossible Risk Based or Priority Based Testing is recommended.
RISK BASED TESTING
Identifying the operations which most likely o cause failures then testing these functionality as priority is called Priority Based Testing and also called Risk Based Testing.
DEFECT CLUSTERING
The small number of modules or functionality may contain more number of defects , concentrate more testing on these functionality (or modules).
PESTICIDE PARADOX
If the prepared test cases are not helping in finding the defects from software , we can add or modify the test cases for better testing. i.e. to find more defects.
TESTING SHOULD SHOW THE PRESENCE OF DEFECTS
We have to test the application with an intention of showing defects for which negative testing is best approach.
EARLY TESTING
Testing should start as early as possible in the software development life cycle.
TESTING IS CONTEXT DEPENDENT
We have to select appropriate testing approach based in the type of application we are testing.
ABSENCE OF ERROR IS A FALLACY
Bug free software application is impossible.
STATIC TESTING AND ITS TECHNIQUES
STATIC TESTING
Verifying whether we are developing the right system or not is called static testing, it is also called verification.This static testing is carried out with the help or reviews and walk through
REVIEW
Examining or cross checking any project or process related work is called Review.
TYPES OF REVIEWS
1.Management Review
2.Technical Review
3. Code Review
4. Test Case Review
these above review can be formal and informal
FORMAL REVIEW
If any review is conducted with a proper plan and by following proper documentation and procedures are called formal reviews.
Inspections and audits are best examples for formal reviews
INFORMAL REVIEWS
If any review is conducted without following any procedures and documentation then these reviews are called informal reviews.
WALK-THROUGH
Knowledge transfer sessions are called walk through. Where the discussions are made on the project which they have to test.
OBJECTIVES OF REVIEWS
Reviews are helpful to determine
1.Defects in requirements
2.Defects in design.
3.Deviations in coding standards.
4.To confirm the prepared test cases are not enough to validate a software or not and also helpful to improve the organisation process.
DYNAMIC TESTING
It is a process of checking does the source code and the application are working as expected or not.
It is also called validation.
LEVELS OF DYNAMIC TESTING
Dynamic testing will be carried out a four levels
1. Unit testing
2. Integration testing
3. System testing
4. User acceptance testing
UNIT TESTING
A smallest separable portion in the source code of the application is called unit.
Testing conducted on these units to check the code behind the units are working as expected or not is called Unit Testing.
It is also called module testing and also component testing.
INTEGRATION TESTING
Once all units are tested the programmers will combine all units and check the interactions among the units which is called integration testing.
Unit Testing and Integration Testing are collectively called white box testing.
WHITE BOX TESTING
Testing conducted on the source code by developers to check does the source code is working as expected or not is called White Box Testing
Q.What is the need of White Box Testing ?
A.
1. As the source code is visible finding the problems and rectifying the problems is so early for developers.
2. The defects that are identified in White Box Testing is so economical to resolve
3. To reduce the defects as early as possible white box testing is helpful.
4. And to ensure 100% code coverage
White Box Testing is also called Glass box testing , Structural testing , Clear box testing.
BLACK BOX TESTING
Testing conducted on the application by test engineer or by domain experts to check whether the application is working according to the customer requirements are not is called Black Box Testing.
Q. What is the need of Black Box Testing?
A.
1. White Box Testing is conducted in a technical perception where the Black Box Testing is conducted by testing engineer with an end user perception.
2. Programmer will conduct White Box Testing in a positive perception where as testers will conduct Black Box Testing with a negative perception where there is a chance of finding defects are more , the more defects you identify it results in a quality system.
3. White Box Testing will not cover non-functional area as non-functional requirements also very important for live projects to cover the same, Black Box Testing is required.
4. The objective of white box testing is 100% code coverage where as the objective of Black Box Testing is 100% customer business requirement coverage.
Black Box Testing is also called as Requirement Based Testing or Specification Based Testing.
SYSTEM TESTING
Validating the functional and non-functional requirements of the same is called System Testing.
System Testing is broadly classified into
1. Functional System Testing
2.Non-Functional System Testing
Functional system testing will be conducted in both positive perception and negative perception
POSITIVE TESTING
Testing conducted on the application in a positive approach to determine what the system supposed to do is called positive perception.
positive testing is helpful to check whether the customer requirements are justified in the application or not.
NEGATIVE TESTING
Testing software application with a negative perception to check what system not supposed to do is called negative testing.
negative testing is helpful in finding the defects from the software.
ADHOC TESTING
If you test a software application without following any procedures and documentation then it is called adhoc testing also called informal testing
FORMAL TESTING
If you test a software application by following all preplanned procedures and documentation then it is called formal testing.
RISK BASED OR PRIORITY BASED TESTING
Identifying the critical functionality in the system then deciding the order in which these functionality to be testing and applying testing in the same order is called Risk Based Testing.
RE-TESTING
Testing a functionality again and again or testing a functionality repetitively is called Re-Testing
Re-testing comes in the following two situations
1. Testing a functionality with multiple inputs to confirm the business validations are correctly implemented or not
2. Testing a functionality in the modified build to confirm the bug fixes are made correctly or not.
REGRESSION TESTING
It is a process of identifying various features in the modified build where there is a chance of getting side effects and Re-testing these features.
The new functionality added the existing system are the modifications made to the existing system and also bug fixes may introduce side effects.Regression testing is helpful to identify these side effects.
END-TO-END TESTING
Testing the overall functionality of the system including the data integration among all modules is called End-To-End Testing
EXPLORATORY TESTING
Exploring the application understanding the functionality, adding or modifying the existing test cases for better testing is called Exploratory Testing.
Exploratory testing comes under Adhoc testing.
MONKEY TESTING
Testing conducted on an application unevenly .i.e, in a zig-zag manner with an intention to find the tricky defects is called Monkey Testing . Monkey testing also comes under Adhoc testing.
NON-FUNCTIONAL SYSTEM TESTING
Validating various non-fictional aspects of the system such as user interface, user friendliness, security, compatibility, load, performance, stress, etc is called Non-Functional System Testing.
SECURITY TESTING
Validating whether all security conditions are properly implemented in software or not is called Security Testing.
CHECK LIST FOR SECURITY TESTING
1.Check does the secured data such as password, credit card cvv number are getting encrypted or not.
2.Check browser navigation's after session out.
3.Check direct url access of the both secured and non-secured pages.
4.Check for session expiry.
5.Check authorization
6.Check authentication
7.Check cookies
8.Check view source code option for secured pages.
PERFORMANCE TESTING
It is a process of measuring various efficiency characteristics of a system such as
1.Response time
2.Throughput or bandwidth or data transfer rate.
3.Load
4.Stress
5.Transactions per minute.
6. Transaction mix etc.
is called Performance Testing.
LOAD TESTING
Analyzing functional and performance behavior of the application under various load conditions is called Load Testing.
STRESS TESTING
Checking the application behavior under stress conditions is called Stress Testing.
or
Reducing the system resources and keeping load as constant, checking how the application is behaving is called Stress Testing.
RECOVERY TESTING
Checking how does the system is able to handle some unexpected and unpredictable situations is called recovery testing.
GLOBALIZATION TESTING
Checking does the application having a provision of setting and changing languages, date and time format, currency etc .if it is designed for global users is called Globalization Testing.
LOCALISATION TESTING
Checking default language, currency, data format etc. If it is designed for particular locality of users is called Localisation Testing.
INSTALLATION TESTING
Checking are we able to install the software successfully or not as per the guidelines given in installation document is called Installation Testing.
UNINSTALLATION TESTING
Checking are we able to uninstall the software from the system successfully or not is called Uninstallation Testing.
COMPATIBILITY TESTING
Checking does the application is compatible with different hardware and software environment are not is called Compatibility Testing.
SOFTWARE TESTING LIFE CYCLE
TEST PLANNING
It is the first phase of system testing where the management plan the high level and detail testing activities to be carried out.
Once a project is initiated for system testing at first project manager or test manager will define test strategy, based on this test strategy the detailed plan called test plan will be prepared.
TEST STRATEGY
It is a high level plan and approach that provides sufficient confidence on the project being tested.
TEST PLAN
It is a detailed day-to-day work plan that explains scope of testing , approach , resources, work schedules, etc. Test plan will be prepared by test lead/team lead/ test manager/ project manager.
TEST PLAN TEMPLATE (IEEE 829)
1.Introduction
2.Scope of testing
a) In scope
b) Out of scope
3.Test approach
4. Resources
5.Work schedules
6.Entry and Exit criteria
7.Test Deliverable.
OBJECTIVES OF TEST PLAN
1.A test plan document explains various procedures to be carried out while testing a software.
The main objective of the test plan is to determine
a) SCOPE OF TESTING: i.e, what are all features are to be tested and what are all not to be tested .
similarly , what type of testing is applicable and what types of testing is not applicable.
b) TEST APPROACH: i.e, various guidelines to be carried out while designing test cases, test data,
defect reports etc.
c) RESOURCES :i.e, hardware resources, software resources, and human resources.
d) WORK SCHEDULE: when testing is to be started and when to stop , how much time we have to
spend on particular features and etc.
e) ENTRY AND EXIT CRITERIA: i.e, when we have to start testing and when to stop testing.
f) TEST DELIVERABLE: i.e, when to deliver the software product or project to the end user.
TEST PLANNING
TEST ANALYSIS
We have to study the requirement
In these days test engineers will study various project requirement document such as BRS/SRS to understand project requirement.
While analyzing test requirements if there are any questions the same will be recorded in RCN template.
Once analysis is finished you can get the clarifications from the domain experts BRS template.
BRS TEMPLATE
BRS document contains the following sections
1.Client introduction
2.Project introduction
3.Existing system
4.Drawbacks in the existing system
5.Proposed system
6.Project architecture
SRS/FRS TEMPLATE
A typical FRS/SRS document will contain the following sections
1.Overview
2.Prototype
3.Business Validations
4.Use case diagrams or Use cases.
RCN TEMPLATE
A RCN (Requirement Clarification Note) is used to record your questions while analyzing the project requirement
In meetings you discuss about your questions with subject matter experts and get clarifications.
TEST CASE
A Test Case is a set of pre-condition steps to be followed input data and expected behaviour to validate a functionality in the system.
In simple words a test case is a brief description of what to test and how to test.
NOTE: In industries we prepare only functional test cases.
These functional test cases are again 3 types
1. Positive test cases.
2. Negative test cases.
3. Business validation test cases.
POSITIVE TEST CASE
A Test Case prepared in a positive perception to check what a system supposed to do is called Positive Test Case.
EX: Test Case
Check log in with valid inputs
NEGATIVE TEST CASE
A Test Case prepared in a negative perception to check what a system not supposed to do is called Negative Test Case.
EX: Test Case
Check log in with invalid inputs
BUSINESS VALIDATION TEST CASE
A Test Case prepared to check business conditions is called business validation test case.
EX: Check fund transfer with 1000, 10000,10001,50000 etc. is called Business Validation Test Case.
What is a good Test Case?
A Test Case that have high probability of catching defects is called a good test case.
TEST CASE DESIGN TECHNIQUES
Black Box Testing introduced the following techniques which helps in preparing the effective test cases to validate a functionality in the system
1. Equivalence Class Partitioning (ECP).
2.Boundary Value Analysis (BVA).
3.Decision Table Testing
4.State Transition Testing
5.Use Case Testing.
EQUIVALENCE CLASS PARTITIONING
According to ECP at first identified all possible test cases to validate a functionality in the system. Divide these test cases into groups while making a group make sure that all test cases that belongs to a group is producing the same output.Select one test case from each group preferably middle value for testing.
BOUNDARY VALUE ANALYSIS
It has observed that most of the time programmers are committing mistakes while specifying the boundary conditions to determine these defects BVA is helpful
According to BVA once ECP are defined identify the partition where there are ranges then determine outer boundaries and inner boundaries if any.
Consider lower boundary value and upper boundary value for each inner boundary value for positive testing , then consider lower boundary value -1 and upper boundary value +1 only for outer boundary for negative testing.
DECISION TABLE TESTING
It is helpful to derive the test cases if a functionality is depending on multiple inputs
EX: As log in depending on two inputs i.e., username and password to check log in we can cover the following test cases
INPUTS TC1 TC2 TC3 TC4
USERNAME VALID VALID INVALID INVALID
PASSWORD VALID INVALID VALID INVALID
NOTE: If a functionality is depending on more number of inputs we can reduce the test cases based on the application design.
STATE TRANSITION TESTING
Every software application will have various possible states, the state of the application will changes from one to another based on user actions and input supply .
State transition testing is helpful to derive the test cases in-order to cover all possible states of applications
USE CASE TESTING
Validating a software to confirm whether it is developed as per the use cases or not is called USE CASE TESTING.
REQUIREMENT TRACE-ABILITY MATRIX
Mapping between cases and requirements is called trace-ability matrix
ADVANTAGES OF TRACE-ABILITY MATRIX
> To determine the percentage of test coverage
> To identify a group of test cases belongs to a requirement which helps in modified bill testing the change
request easily.
SOFTWARE TESTING LIFE CYCLE
DEFECT REPORTING
Once a defect is identified we have to document the defect and report the same to the developer which is called bug reporting
We report the bug using Excel file or Quality Center or Bugzilla softwares
DEFECT SEVERITY
How serious the problem in the system or the impact of the problem in the system is called Severity .
AGE OF DEFECT
Time interval between detected date to the date of closure is called Defect Age.
or
How long the bug is present in the development life-cycle is called Defect Age
SHOW STOPPER DEFECT
A Defect which is not permitting us to continue further testing process is called Show Stopper Defect.
DEFECT PRIORITY
The order in which the defect has to be resolved is called Defect Priority.
NOTE:
1. Defect severity specified by tester where as defect priority is assigned by developer.
2. In General Defect Priorities and Severities are proportionate to each other but in some situations this may
change.
EX:
1.An example for Defect that takes Low Severity and High Priority
> Incorrect company logo
2.An example for Defect that takes High Severity and Low Priority
> A serious problem belongs to future release module
TEST CLOSURE
It is the last phase of STLC where the management prepares various test summary reports which explains the complete strategy about the reports.
COMMON DEPOSITORY
A Centralized computer system where you store and manage all project resources is called Common Depository
CONFIGURATION MANAGEMENT
Maintaining all project resources in a centralized system , maintaining appropriate version controlling based on changes made to them is called Configuration Management
EX: Visual Source Safe (VSS) , Concurrent Version System (CVS).
NOTE: QC is a test management tool also provided configuration management services
SOFTWARE DEVELOPMENT LIFE CYCLE
SEQUENTIAL MODULES
These are best suitable for small size applications where all development activities are carried out in a sequential order for the entire project.
ITERATIVE OR INCREMENTAL MODELS
These are best suitable for big projects in these models a big project is divided into modules and the application will be implemented module by module.
WATER FALL MODEL
It is a very beginning approach of development model where all development activities are carried out one after another for the entire project in this approach we used to conduct testing .
Subscribe to:
Posts (Atom)