There's an up an coming website to learn about different investing methods
http://moolah.asia/single_blog.php?b_id=225
Wednesday, April 13, 2011
Friday, October 26, 2007
Integration Testing: Why? What? & How?
Integration Testing: Why? What? & How?
Introduction:
As we covered in various articles in the Testing series there are various levels of testing:
Unit Testing, Integration Testing, System Testing
Each level of testing builds on the previous level.
“Unit testing” focuses on testing a unit of the code. “Integration testing” is the next level of testing. This ‘level of testing’ focuses on testing the integration of “units of code” or components.
How does Integration Testing fit into the Software Development Life Cycle?
Even if a software component is successfully unit tested, in an enterprise n-tier distributed application it is of little or no value if the component cannot be successfully integrated with the rest of the application.
Once unit tested components are delivered we then integrate them together. These “integrated” components are tested to weed out errors and bugs caused due to the integration. This is a very important step in the Software Development Life Cycle.
It is possible that different programmers developed different components.
A lot of bugs emerge during the integration step.
In most cases a dedicated testing team focuses on Integration Testing.
Prerequisites for Integration Testing:
Before we begin Integration Testing it is important that all the components have been successfully unit tested.
Integration Testing Steps:
Integration Testing typically involves the following Steps:
Step 1: Create a Test Plan
Step 2: Create Test Cases and Test Data
Step 3: If applicable create scripts to run test cases
Step 4: Once the components have been integrated execute the test cases
Step 5: Fix the bugs if any and re test the code
Step 6: Repeat the test cycle until the components have been successfully integrated
What is an ‘Integration Test Plan’?
As you may have read in the other articles in the series, this document typically describes one or more of the following:
- How the tests will be carried out
- The list of things to be Tested
- Roles and Responsibilities
- Prerequisites to begin Testing
- Test Environment
- Assumptions
- What to do after a test is successfully carried out
- What to do if test fails
- Glossary
How to write an Integration Test Case?
Simply put, a Test Case describes exactly how the test should be carried out. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together.
The various Integration Test Cases clubbed together form an Integration Test Suite Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application.
As mentioned before a dedicated Testing Team may be created to execute the Integration test cases. Therefore the Integration Test Cases should be as detailed as possible.
Sample Test Case Table:
Additionally the following information may also be captured:
a) Test Suite Name
b) Tested By
c) Date
d) Test Iteration (One or more iterations of Integration testing may be performed)
Working towards Effective Integration Testing:
There are various factors that affect Software Integration and hence Integration Testing:
1) Software Configuration Management: Since Integration Testing focuses on Integration of components and components can be built by different developers and even different development teams, it is important the right version of components are tested. This may sound very basic, but the biggest problem faced in n-tier development is integrating the right version of components. Integration testing may run through several iterations and to fix bugs components may undergo changes. Hence it is important that a good Software Configuration Management (SCM) policy is in place. We should be able to track the components and their versions. So each time we integrate the application components we know exactly what versions go into the build process.
2) Automate Build Process where Necessary: A Lot of errors occur because the wrong version of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors.
3) Document: Document the Integration process/build process to help eliminate the errors of omission or oversight. It is possible that the person responsible for integrating the components forgets to run a required script and the Integration Testing will not yield correct results.
4) Defect Tracking: Integration Testing will lose its edge if the defects are not tracked correctly. Each defect should be documented and tracked. Information should be captured as to how the defect was fixed. This is valuable information. It can help in future integration and deployment processes.
Summary:
Integration testing is the most crucial steps in Software Development Life Cycle. Different components are integrated together and tested. This can be a daunting task in enterprise applications where diverse teams build different modules and components. In this article you learned the steps needed to perform Integration Testing.
Source: http://www.exforsys.com/tutorials/testing/integration-testing-whywhathow.html
Introduction:
As we covered in various articles in the Testing series there are various levels of testing:
Unit Testing, Integration Testing, System Testing
Each level of testing builds on the previous level.
“Unit testing” focuses on testing a unit of the code. “Integration testing” is the next level of testing. This ‘level of testing’ focuses on testing the integration of “units of code” or components.
How does Integration Testing fit into the Software Development Life Cycle?
Even if a software component is successfully unit tested, in an enterprise n-tier distributed application it is of little or no value if the component cannot be successfully integrated with the rest of the application.
Once unit tested components are delivered we then integrate them together. These “integrated” components are tested to weed out errors and bugs caused due to the integration. This is a very important step in the Software Development Life Cycle.
It is possible that different programmers developed different components.
A lot of bugs emerge during the integration step.
In most cases a dedicated testing team focuses on Integration Testing.
Prerequisites for Integration Testing:
Before we begin Integration Testing it is important that all the components have been successfully unit tested.
Integration Testing Steps:
Integration Testing typically involves the following Steps:
Step 1: Create a Test Plan
Step 2: Create Test Cases and Test Data
Step 3: If applicable create scripts to run test cases
Step 4: Once the components have been integrated execute the test cases
Step 5: Fix the bugs if any and re test the code
Step 6: Repeat the test cycle until the components have been successfully integrated
What is an ‘Integration Test Plan’?
As you may have read in the other articles in the series, this document typically describes one or more of the following:
- How the tests will be carried out
- The list of things to be Tested
- Roles and Responsibilities
- Prerequisites to begin Testing
- Test Environment
- Assumptions
- What to do after a test is successfully carried out
- What to do if test fails
- Glossary
How to write an Integration Test Case?
Simply put, a Test Case describes exactly how the test should be carried out. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together.
The various Integration Test Cases clubbed together form an Integration Test Suite Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application.
As mentioned before a dedicated Testing Team may be created to execute the Integration test cases. Therefore the Integration Test Cases should be as detailed as possible.
Sample Test Case Table:
Test Case ID | Test Case Description | Input Data | Expected Result | Actual Result | Pass/Fail | Remarks |
Additionally the following information may also be captured:
a) Test Suite Name
b) Tested By
c) Date
d) Test Iteration (One or more iterations of Integration testing may be performed)
Working towards Effective Integration Testing:
There are various factors that affect Software Integration and hence Integration Testing:
1) Software Configuration Management: Since Integration Testing focuses on Integration of components and components can be built by different developers and even different development teams, it is important the right version of components are tested. This may sound very basic, but the biggest problem faced in n-tier development is integrating the right version of components. Integration testing may run through several iterations and to fix bugs components may undergo changes. Hence it is important that a good Software Configuration Management (SCM) policy is in place. We should be able to track the components and their versions. So each time we integrate the application components we know exactly what versions go into the build process.
2) Automate Build Process where Necessary: A Lot of errors occur because the wrong version of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors.
3) Document: Document the Integration process/build process to help eliminate the errors of omission or oversight. It is possible that the person responsible for integrating the components forgets to run a required script and the Integration Testing will not yield correct results.
4) Defect Tracking: Integration Testing will lose its edge if the defects are not tracked correctly. Each defect should be documented and tracked. Information should be captured as to how the defect was fixed. This is valuable information. It can help in future integration and deployment processes.
Summary:
Integration testing is the most crucial steps in Software Development Life Cycle. Different components are integrated together and tested. This can be a daunting task in enterprise applications where diverse teams build different modules and components. In this article you learned the steps needed to perform Integration Testing.
Source: http://www.exforsys.com/tutorials/testing/integration-testing-whywhathow.html
Thursday, October 25, 2007
Software Testing - Boundary Values Testing
Software Testing - Boundary Values Testing
WHAT IS BOUNDARY VALUE ANALYSIS IN SOFTWARE TESTING?
Concepts: Boundary value analysis is a methodology for
designing test cases that concentrates software testing effort on cases
near the limits of valid ranges Boundary value analysis is a method
which refines equivalence partitioning. Boundary value analysis
generates test cases that highlight errors better than equivalence
partitioning. The trick is to concentrate software testing efforts at
the extreme ends of the equivalence classes. At those points
when input values change from valid to invalid errors are most
likely to occur. As well, boundary value analysis broadens the
portions of the business requirement document used to generate tests.
Unlike equivalence partitioning, it takes into account the output
specifications when deriving test cases.
HOW DO YOU PERFORM BOUNDARY VALUE ANALYSIS?
Once again, you'll need to perform two steps:
1. Identify the equivalence classes.
2. Design test cases.
But the details vary. Let's examine each step.
STEP 1: IDENTIFY EQUIVALENCE CLASSES
Follow the same rules you used in equivalence partitioning. However,
consider the output specifications as well. For example, if the output
specifications for the inventory system stated
that a report on inventory should indicate a total quantity for all
products no greater than 999,999, then you d add the following classes
to the ones you found previously:
6. The valid class ( 0 < = total quantity on hand < = 999,999 )
7. The invalid class (total quantity on hand <0)
8. The invalid class (total quantity on hand> 999,999 )
STEP 2: DESIGN TEST CASES
In this step, you derive test cases from the equivalence classes. The
process is similar to that of equivalence partitioning but the rules for
designing test cases differ. With equivalence partitioning, you may select
any test case within a range and any on either side of it with boundary
analysis, you focus your attention on cases close to the edges of the range.
The detailed rules for generating test cases follow:
RULES FOR TEST CASES
1. If the condition is a range of values, create valid test cases for each
end of the range and invalid test cases just beyond each end of the
range. For example, if a valid range of quantity on hand is -9,999
through 9,999, write test cases that include:
1. the valid test case quantity on hand is -9,999,
2. the valid test case quantity on hand is 9,999,
3. the invalid test case quantity on hand is -10,000 and
4. the invalid test case quantity on hand is 10,000
You may combine valid classes wherever possible, just as you did
with equivalence partitioning, and, once again, you may not combine
invalid classes. Don�t forget to consider output conditions as well. In
our inventory example the output conditions generate the following test cases:
1. the valid test case total quantity on hand is 0,
2. the valid test case total quantity on hand is 999,999
3. the invalid test case total quantity on hand is -1 and
4. the invalid test case total quantity on hand is 1,000,000
2. A similar rule applies where the, condition states that the number of
values must lie within a certain range select two valid test cases, one
for each boundary of the range, and two invalid test cases, one just
below and one just above the acceptable range .
3. Design tests that highlight the first and last records in an input or
output file.
4.Look for any other extreme input or output conditions, and generate a
test for each of them.
SUMMARY
In this lesson, you learned
how boundary value
analysis refines these test cases and derives others by examining output
specifications as well as inputs. Using either of these techniques,
preferably, the second, wherever possible , you'll be able to test your,
system. But what if the system is complex? In that case, there are bound
to be many modules to test How do you plan the order in which to test them?
That is the subject of the next lesson.
------------------------------------------------------------------------------------------
Definition of Boundary Value Analysis from our Software Testing Dictionary:
Boundary Value Analysis (BVA). BVA is different from equivalence
partitioning in that it focuses on "corner cases" or values that are usually
out of range as defined by the specification. This means that if function
expects all values in range of negative 100 to positive 1000, test inputs would
include negative 101 and positive 1001. BVA attempts to derive the value often
used as a technique for stress, load or volume testing. This type of validation
is usually performed after positive functional validation has completed
(successfully) using requirements specifications and user documentation
A definition of Equivalence Partitioning from our software testing dictionary:
Equivalence Partitioning: An approach where classes of inputs are
categorized for product or function validation. This usually does not include
combinations of input, but rather a single state value based by class. For
example, with a given function there may be several classes of input that may be
used for positive testing. If function expects an integer and receives an
integer as input, this would be considered as positive test assertion. On the
other hand, if a character or any other input class other than integer is
provided, this would be considered a negative test assertion or condition.
Equivalence partitioning definition from From Wikipedia, the free encyclopedia.
A technique in black box testing is equivalence partitioning. Equivalence
partitioning is designed to minimize the number of test cases by dividing
tests in such a way that the system is expected to act the same way for all
tests of each equivalence partition. Test inputs would be selected from each partition.
Equivalence partitions are designed so that every possible input belongs
to one and only one equivalence partition.
END BOUNDARY VALUE ANALYSIS IN SOFTWARE TESTING.
Source: http://www.geocities.com/xtremetesting/BoundaryValues.html
WHAT IS BOUNDARY VALUE ANALYSIS IN SOFTWARE TESTING?
Concepts: Boundary value analysis is a methodology for
designing test cases that concentrates software testing effort on cases
near the limits of valid ranges Boundary value analysis is a method
which refines equivalence partitioning. Boundary value analysis
generates test cases that highlight errors better than equivalence
partitioning. The trick is to concentrate software testing efforts at
the extreme ends of the equivalence classes. At those points
when input values change from valid to invalid errors are most
likely to occur. As well, boundary value analysis broadens the
portions of the business requirement document used to generate tests.
Unlike equivalence partitioning, it takes into account the output
specifications when deriving test cases.
HOW DO YOU PERFORM BOUNDARY VALUE ANALYSIS?
Once again, you'll need to perform two steps:
1. Identify the equivalence classes.
2. Design test cases.
But the details vary. Let's examine each step.
STEP 1: IDENTIFY EQUIVALENCE CLASSES
Follow the same rules you used in equivalence partitioning. However,
consider the output specifications as well. For example, if the output
specifications for the inventory system stated
that a report on inventory should indicate a total quantity for all
products no greater than 999,999, then you d add the following classes
to the ones you found previously:
6. The valid class ( 0 < = total quantity on hand < = 999,999 )
7. The invalid class (total quantity on hand <0)
8. The invalid class (total quantity on hand> 999,999 )
STEP 2: DESIGN TEST CASES
In this step, you derive test cases from the equivalence classes. The
process is similar to that of equivalence partitioning but the rules for
designing test cases differ. With equivalence partitioning, you may select
any test case within a range and any on either side of it with boundary
analysis, you focus your attention on cases close to the edges of the range.
The detailed rules for generating test cases follow:
RULES FOR TEST CASES
1. If the condition is a range of values, create valid test cases for each
end of the range and invalid test cases just beyond each end of the
range. For example, if a valid range of quantity on hand is -9,999
through 9,999, write test cases that include:
1. the valid test case quantity on hand is -9,999,
2. the valid test case quantity on hand is 9,999,
3. the invalid test case quantity on hand is -10,000 and
4. the invalid test case quantity on hand is 10,000
You may combine valid classes wherever possible, just as you did
with equivalence partitioning, and, once again, you may not combine
invalid classes. Don�t forget to consider output conditions as well. In
our inventory example the output conditions generate the following test cases:
1. the valid test case total quantity on hand is 0,
2. the valid test case total quantity on hand is 999,999
3. the invalid test case total quantity on hand is -1 and
4. the invalid test case total quantity on hand is 1,000,000
2. A similar rule applies where the, condition states that the number of
values must lie within a certain range select two valid test cases, one
for each boundary of the range, and two invalid test cases, one just
below and one just above the acceptable range .
3. Design tests that highlight the first and last records in an input or
output file.
4.Look for any other extreme input or output conditions, and generate a
test for each of them.
SUMMARY
In this lesson, you learned
how boundary value
analysis refines these test cases and derives others by examining output
specifications as well as inputs. Using either of these techniques,
preferably, the second, wherever possible , you'll be able to test your,
system. But what if the system is complex? In that case, there are bound
to be many modules to test How do you plan the order in which to test them?
That is the subject of the next lesson.
------------------------------------------------------------------------------------------
Definition of Boundary Value Analysis from our Software Testing Dictionary:
Boundary Value Analysis (BVA). BVA is different from equivalence
partitioning in that it focuses on "corner cases" or values that are usually
out of range as defined by the specification. This means that if function
expects all values in range of negative 100 to positive 1000, test inputs would
include negative 101 and positive 1001. BVA attempts to derive the value often
used as a technique for stress, load or volume testing. This type of validation
is usually performed after positive functional validation has completed
(successfully) using requirements specifications and user documentation
A definition of Equivalence Partitioning from our software testing dictionary:
Equivalence Partitioning: An approach where classes of inputs are
categorized for product or function validation. This usually does not include
combinations of input, but rather a single state value based by class. For
example, with a given function there may be several classes of input that may be
used for positive testing. If function expects an integer and receives an
integer as input, this would be considered as positive test assertion. On the
other hand, if a character or any other input class other than integer is
provided, this would be considered a negative test assertion or condition.
Equivalence partitioning definition from From Wikipedia, the free encyclopedia.
A technique in black box testing is equivalence partitioning. Equivalence
partitioning is designed to minimize the number of test cases by dividing
tests in such a way that the system is expected to act the same way for all
tests of each equivalence partition. Test inputs would be selected from each partition.
Equivalence partitions are designed so that every possible input belongs
to one and only one equivalence partition.
END BOUNDARY VALUE ANALYSIS IN SOFTWARE TESTING.
Source: http://www.geocities.com/xtremetesting/BoundaryValues.html
Tuesday, October 23, 2007
Sunday, October 14, 2007
QuickTest Professional Q&A
QuickTest Professional (QTP) Questions and Answers Part # 1http://softwareqate stings.com/ content/view/ 188/38/
QuickTest Professional (QTP) Questions and Answers Part # 2http://softwareqate stings.com/ content/view/ 189/38/
QuickTest Professional (QTP) Questions and Answers Part # 3http://softwareqate stings.com/ content/view/ 190/38/
QuickTest Professional (QTP) Questions and Answers Part # 4http://softwareqate stings.com/ content/view/ 191/38/
QuickTest Professional (QTP) Questions and Answers Part # 5http://softwareqate stings.com/ content/view/ 192/38/
Source: QuickTestPro@yahoogroups.com
QuickTest Professional (QTP) Questions and Answers Part # 2http://softwareqate stings.com/ content/view/ 189/38/
QuickTest Professional (QTP) Questions and Answers Part # 3http://softwareqate stings.com/ content/view/ 190/38/
QuickTest Professional (QTP) Questions and Answers Part # 4http://softwareqate stings.com/ content/view/ 191/38/
QuickTest Professional (QTP) Questions and Answers Part # 5http://softwareqate stings.com/ content/view/ 192/38/
Source: QuickTestPro@yahoogroups.com
Friday, October 12, 2007
New added link in Related Links
See the new added lin in Related Links located in the Sidebar. Regarding most common Interview Questions in Testing.
Tuesday, October 9, 2007
Tester/Developer Perceptions
Testing is a difficult effort. It is the task that’s both infinite and indefinite.
No matter what testers do, they can’t be sure they will find all the problems,
or even all the important ones.
It is hard to find individuals who are good at testing. It takes someone
who is a critical thinker motivated to produce a quality software product,
likes to evaluate software deliverables, and is not caught up in the assumption
held by many developers that testing has a lesser job status than development.
A good tester is a quick learner and eager to learn, is a good team
player, and can effectively communicate both verbally and in written form.
The output from development is something that is real and tangible. A
programmer can write code and display it to admiring customers who
assume it is correct. From a developer’s point of view, testing results in
nothing more tangible than an accurate, useful, and all-too-fleeting perspective
on quality. Given these perspectives, many developers and
testers often work together in an uncooperative, if not hostile, manner.
In many ways the tester and developer roles are in conflict. A developer
is committed to building something to be successful. A tester tries to minimize
the risk of failure and tries to improve the software by detecting
defects. Developers focus on technology, which takes a lot of time and
energy when producing software. A good tester, on the other hand, is motivated
to provide the user with the best software to solve a problem.
Testers are typically ignored until the end of the development cycle
when the application is “completed.” Testers are always interested in the
progress of development and realize that quality is only achievable when
they take a broad point of view and consider software quality from multiple
dimensions.
Source: Software Testing and Continuous Quality Improvement 2nd Edition
No matter what testers do, they can’t be sure they will find all the problems,
or even all the important ones.
It is hard to find individuals who are good at testing. It takes someone
who is a critical thinker motivated to produce a quality software product,
likes to evaluate software deliverables, and is not caught up in the assumption
held by many developers that testing has a lesser job status than development.
A good tester is a quick learner and eager to learn, is a good team
player, and can effectively communicate both verbally and in written form.
The output from development is something that is real and tangible. A
programmer can write code and display it to admiring customers who
assume it is correct. From a developer’s point of view, testing results in
nothing more tangible than an accurate, useful, and all-too-fleeting perspective
on quality. Given these perspectives, many developers and
testers often work together in an uncooperative, if not hostile, manner.
In many ways the tester and developer roles are in conflict. A developer
is committed to building something to be successful. A tester tries to minimize
the risk of failure and tries to improve the software by detecting
defects. Developers focus on technology, which takes a lot of time and
energy when producing software. A good tester, on the other hand, is motivated
to provide the user with the best software to solve a problem.
Testers are typically ignored until the end of the development cycle
when the application is “completed.” Testers are always interested in the
progress of development and realize that quality is only achievable when
they take a broad point of view and consider software quality from multiple
dimensions.
Source: Software Testing and Continuous Quality Improvement 2nd Edition
Wednesday, October 3, 2007
Project: Automation Framework
I am currently developing Automation Framework using QTP for my company and want to share the processes i undertook and will undertake in the next couple of months.
The BEST online resources i got are the following:
http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm - This site will tell get you started in developing you very first Automation Framework.
http://www.sqaforums.com/showflat.php?Number=337920 - This is a forum for the QTP Framework Demo and get continous update from experts around the world. I got most of the coding idea in this demo. You need QTP 9.2 to run this though.
http://www.sqa-test.com/method.html - Provides summary of how different types of Automation Framework works.
Step 1: You need to define the Coding Standards first. I researched the Coding Standards for VBScripting since QTP uses this code. This will make the scripts easier to maintain and track. Also if you want to assign specific tasks to other members of your team your codes will be much easier to read and comprehend.
Step 2: Choose the right framework for you. If you can't decide then i suggest you use the most flexible and common which is the Hybrid of Data-Driven and Keyword-Driven framework (see sources above). This might take longer to implement but its worth it since it's comparable to using the latest technique or technology available.
Step 3: Learn that framework and all its concepts.
Step 4: Understand the flow of the QTP Framework Demo.
Step 5: Design the pseudocode first and all the process flows before coding. This will save you a lot of time in revisions. Make sure you already visualize all possible scenarios and improvements you need to make before coding. That way you will just concentrate on making the code work and not thinking of the plan on the fly which is prone to error and inefficient.
Things to consider.
- Data of your source document
- Things that needs to be dynamic like browsers, Window title, Page title, etc
- Your framework must support running a single test case only or group of test cases
- Your Test Report should indicate the Step Name or Suite Name or Group Name
- Be consistent. If you use .xls then use .xls all throughout.
- Visualize using the framework on an actual project so that you can formulate the features you may need
Cont...
The BEST online resources i got are the following:
http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm - This site will tell get you started in developing you very first Automation Framework.
http://www.sqaforums.com/showflat.php?Number=337920 - This is a forum for the QTP Framework Demo and get continous update from experts around the world. I got most of the coding idea in this demo. You need QTP 9.2 to run this though.
http://www.sqa-test.com/method.html - Provides summary of how different types of Automation Framework works.
Step 1: You need to define the Coding Standards first. I researched the Coding Standards for VBScripting since QTP uses this code. This will make the scripts easier to maintain and track. Also if you want to assign specific tasks to other members of your team your codes will be much easier to read and comprehend.
Step 2: Choose the right framework for you. If you can't decide then i suggest you use the most flexible and common which is the Hybrid of Data-Driven and Keyword-Driven framework (see sources above). This might take longer to implement but its worth it since it's comparable to using the latest technique or technology available.
Step 3: Learn that framework and all its concepts.
Step 4: Understand the flow of the QTP Framework Demo.
Step 5: Design the pseudocode first and all the process flows before coding. This will save you a lot of time in revisions. Make sure you already visualize all possible scenarios and improvements you need to make before coding. That way you will just concentrate on making the code work and not thinking of the plan on the fly which is prone to error and inefficient.
Things to consider.
- Data of your source document
- Things that needs to be dynamic like browsers, Window title, Page title, etc
- Your framework must support running a single test case only or group of test cases
- Your Test Report should indicate the Step Name or Suite Name or Group Name
- Be consistent. If you use .xls then use .xls all throughout.
- Visualize using the framework on an actual project so that you can formulate the features you may need
Cont...
Friday, August 17, 2007
Proud to be a tester (Post from QuickTestPro@yahoogroups.com)
Proud to be a tester
Posted by: "Ismail A" http://us.f510.mail.yahoo.com/ym/Compose?To=ismail.ami@gmail.com&Subj=ismail.vellore
Wed Aug 15, 2007 11:27 pm (PST)
This is True Story that happened in some company ___A digital camera was released in the market and after sometime a customercame back complaining that……..
Problem: The camera's software was crashing continuously while he tried tocapture images.
FIR: They first asked some basic information from the customer and made anattempt to reproduce the issue but it was not reproducible.
Analysis:
1) Software is crashing - so they listed out all possible scenarios wherethe software could crash.
2) Tried putting the camera to all listed possibilities.
3) Giving a report to the management that it was unable to be reproduced.
Further Analysis:Taking this as a challenge, a great tester had the following concern
1) He was concerned what festival was it?
2) He was concerned what was the customer was trying to capture?
3) He was concerned what is the frequency of the crash the customer noticed?
4) He was concerned about all other surrounding factors like temperature,place where the festival was celebrated … etc?
Outcome of Analysis:
1) The festival was Diwali or Deepavali!
2) The customer was trying to capture fire crackers, explosion, fireworksdisplay in an open ground at around 22 00 hours (night).What a fantastic tester was he!He identified the problem and told the developers"The camera software is crashing when the viewfinder is black (because ofdark night) and a sudden gush of light through the firecracker explosion isputting the DSP (digital signal processor) to a load/stress beyond itsboundaries to display the image. And at this point of time when the usertries to capture it simply crashes"
What he said?Was right!Finally they fixed it and now today it's a robust digital camera!____ End of a probable true story _____
Summary of lessons
1) Collect real time data for testing a product/application .
2) When you are unable to reproduce an issue, think out of the box, thinkout of the black box.
3) When you are unable to reproduce an issue call someone who can dig deeperthan you.
4) Don't assign test case draft to the person who is going to test it; he may omit complicated cases to bring down his/her complexity in executingit.
5) Review the cases with a non team member/customers/ domainspecialist/tester network.
6) When you release a product: anticipate and be prepared to face suchsituation.
7) Hate the product while testing and love the product after its release -Emotional testing (new concept )
8) Good Testers not only report bugs, they suggest a solution!
9) Keep learning to be a good tester!10) Test all your products in India, its The Testing Bowl of the world!
11) Don't terminate an issue just because you are unable to reproduce, itcould kill a company!How was it….?—if possible fwd it to the larger team.
*Be proud of being TESTER coz
*All programs are Poems,
its just that not all programmers are poets
ALL TESTERS ARE TERRORS,
ITS JUST NOT ALL TESTERS ARE TERRORISTS
-- Thanks &Regards,Ismail A
Posted by: "Ismail A" http://us.f510.mail.yahoo.com/ym/Compose?To=ismail.ami@gmail.com&Subj=ismail.vellore
Wed Aug 15, 2007 11:27 pm (PST)
This is True Story that happened in some company ___A digital camera was released in the market and after sometime a customercame back complaining that……..
Problem: The camera's software was crashing continuously while he tried tocapture images.
FIR: They first asked some basic information from the customer and made anattempt to reproduce the issue but it was not reproducible.
Analysis:
1) Software is crashing - so they listed out all possible scenarios wherethe software could crash.
2) Tried putting the camera to all listed possibilities.
3) Giving a report to the management that it was unable to be reproduced.
Further Analysis:Taking this as a challenge, a great tester had the following concern
1) He was concerned what festival was it?
2) He was concerned what was the customer was trying to capture?
3) He was concerned what is the frequency of the crash the customer noticed?
4) He was concerned about all other surrounding factors like temperature,place where the festival was celebrated … etc?
Outcome of Analysis:
1) The festival was Diwali or Deepavali!
2) The customer was trying to capture fire crackers, explosion, fireworksdisplay in an open ground at around 22 00 hours (night).What a fantastic tester was he!He identified the problem and told the developers"The camera software is crashing when the viewfinder is black (because ofdark night) and a sudden gush of light through the firecracker explosion isputting the DSP (digital signal processor) to a load/stress beyond itsboundaries to display the image. And at this point of time when the usertries to capture it simply crashes"
What he said?Was right!Finally they fixed it and now today it's a robust digital camera!____ End of a probable true story _____
Summary of lessons
1) Collect real time data for testing a product/application .
2) When you are unable to reproduce an issue, think out of the box, thinkout of the black box.
3) When you are unable to reproduce an issue call someone who can dig deeperthan you.
4) Don't assign test case draft to the person who is going to test it; he may omit complicated cases to bring down his/her complexity in executingit.
5) Review the cases with a non team member/customers/ domainspecialist/tester network.
6) When you release a product: anticipate and be prepared to face suchsituation.
7) Hate the product while testing and love the product after its release -Emotional testing (new concept )
8) Good Testers not only report bugs, they suggest a solution!
9) Keep learning to be a good tester!10) Test all your products in India, its The Testing Bowl of the world!
11) Don't terminate an issue just because you are unable to reproduce, itcould kill a company!How was it….?—if possible fwd it to the larger team.
*Be proud of being TESTER coz
*All programs are Poems,
its just that not all programmers are poets
ALL TESTERS ARE TERRORS,
ITS JUST NOT ALL TESTERS ARE TERRORISTS
-- Thanks &Regards,Ismail A
Wednesday, July 18, 2007
Check out my new Related Links section
I added a new section called Related Links. First link is Advance QTP Concepts which discusses the ffg:
1. Error Handling
2. Calling External Files
3. Using VBScript for Validation
4. Dynamic Database Validation
5. Descriptive Programming language
6. QTP Coding Standards
7. Designing a script
Personally i like the QTP Coding Standard part. Just in time for creating my very first framework. I'm leaning towards combining Functional Decomposition and Data-Driven with Business Function Utilities and Parametarization. See Automated Testing Methodologies link.
1. Error Handling
2. Calling External Files
3. Using VBScript for Validation
4. Dynamic Database Validation
5. Descriptive Programming language
6. QTP Coding Standards
7. Designing a script
Personally i like the QTP Coding Standard part. Just in time for creating my very first framework. I'm leaning towards combining Functional Decomposition and Data-Driven with Business Function Utilities and Parametarization. See Automated Testing Methodologies link.
Tuesday, June 26, 2007
Advice for budding software test professionals ...
Here are few points of the post that I made for QTP yahoo groups - in response to a query made for FAQ/interview questions on QTP. The main motivation for me to post this is that I see most of the new entrants in this field, do not know where to invest time and effort to know the field of testing. Often they end up reading some FAQ or Typical interview questions posted on some site and think that they have arrived. Software testing today suffers from lack of education and awareness about "What it takes to be a software tester" and "how to successfully carry out and add value to the overall process of software development.
Read on .....
Here is my advice to all aspiring QTP or Test engineers and professionals. These are lessons I learnt personally and useful for any software professional who is serious in testing.
1. Do not look for short cuts to learn and get knowledge. Have a long term plans to get good mileage in this profession. FAQs, etc are good to read only for knowing top line. To succeed in the interview you will have to win it from inside of your heart, invest honestly in studying and expect fruits. Banking on FAQs, interview questions etc may get you the job but will not keep you there.
2. Most important for a tester is to understand what makes a good tester? How he/she is different from a developer? What value tester brings to the table? How to find talent in testing and nurture it? How testing is different from QA or any flavor of process (CMM, Six sigma) etc.
3. Invest in sharpen problem solving and "thinking out of box" abilities. Read good stuff on testing. Participate in conferences, discuss with test professionals in other companies, participate in activities in SPIN, etc. Solve puzzles ( zig saw or shankuntala devi). Never stop learning.
4. Sharpen Technology skills. Know about "How web works" , DNS, Networking, protocols, XML, Web services, Cryptography, databases, Datawarehousing, UNIX commands, Fundas of J2EE, .NET, system admin list is endless. Today testers are expected to know the basics. I take lot of interviews for various positions. Most of the people do not have these basics. It is difficult to survive in this world of testing only banking on "Automation tool" knowledge.
5. Lean programming languages like , C#, Java and scripting languages like PERL, python, Unix shell etc. This will increase utility value of yours. Developers and PMs will respect you.
6. Improve communication skills - take English class. Improve vocabulary. Read Read and Read.Most of the people I have seen ignore this important skill. They can not write a paragraph on their own without spelling and grammatical mistakes. Make a habit to learn a new word a day.
7. Read and write on blogs ( Google to find out what is blog- if you don’t know already). Here are few blogs that I suggest for every test professional.
http://www.testingeducation.org/ - cem kaners free testing courses.http://www.testing.com/cgi-bin/blog - Brian Merick sitehttp://blackbox.cs.fit.edu/blog/james/ - James Bach - highly respected Visionary in testing.http://www.qualitytree.com/index.htmlhttp://blogs.msdn.com/micahel/ - Microsoft’s Famous Braidy Testerhttp://www.developsense.com/blog.html - Michael Bolten - Testing in plain Englishhttp://www.stickyminds.comhttp://www.kohl.ca/blog/ - Jonathan Kohlhttp://www.io.com/~wazmo/blog/ - Bret Pettichord - Automation testing Guruand
my own blogs -http://blogs.msdn.com/shrinik ( my Microsoft blog - is closed since left that company)http://shrinik.blogspot.com
Last but not the least, Be a person with positive outlook in the life. Believe in yourself other wise nobody else will believe you
All the best. Let us build a next generation test professionals community and change the way world does testing today.
Read on .....
Here is my advice to all aspiring QTP or Test engineers and professionals. These are lessons I learnt personally and useful for any software professional who is serious in testing.
1. Do not look for short cuts to learn and get knowledge. Have a long term plans to get good mileage in this profession. FAQs, etc are good to read only for knowing top line. To succeed in the interview you will have to win it from inside of your heart, invest honestly in studying and expect fruits. Banking on FAQs, interview questions etc may get you the job but will not keep you there.
2. Most important for a tester is to understand what makes a good tester? How he/she is different from a developer? What value tester brings to the table? How to find talent in testing and nurture it? How testing is different from QA or any flavor of process (CMM, Six sigma) etc.
3. Invest in sharpen problem solving and "thinking out of box" abilities. Read good stuff on testing. Participate in conferences, discuss with test professionals in other companies, participate in activities in SPIN, etc. Solve puzzles ( zig saw or shankuntala devi). Never stop learning.
4. Sharpen Technology skills. Know about "How web works" , DNS, Networking, protocols, XML, Web services, Cryptography, databases, Datawarehousing, UNIX commands, Fundas of J2EE, .NET, system admin list is endless. Today testers are expected to know the basics. I take lot of interviews for various positions. Most of the people do not have these basics. It is difficult to survive in this world of testing only banking on "Automation tool" knowledge.
5. Lean programming languages like , C#, Java and scripting languages like PERL, python, Unix shell etc. This will increase utility value of yours. Developers and PMs will respect you.
6. Improve communication skills - take English class. Improve vocabulary. Read Read and Read.Most of the people I have seen ignore this important skill. They can not write a paragraph on their own without spelling and grammatical mistakes. Make a habit to learn a new word a day.
7. Read and write on blogs ( Google to find out what is blog- if you don’t know already). Here are few blogs that I suggest for every test professional.
http://www.testingeducation.org/ - cem kaners free testing courses.http://www.testing.com/cgi-bin/blog - Brian Merick sitehttp://blackbox.cs.fit.edu/blog/james/ - James Bach - highly respected Visionary in testing.http://www.qualitytree.com/index.htmlhttp://blogs.msdn.com/micahel/ - Microsoft’s Famous Braidy Testerhttp://www.developsense.com/blog.html - Michael Bolten - Testing in plain Englishhttp://www.stickyminds.comhttp://www.kohl.ca/blog/ - Jonathan Kohlhttp://www.io.com/~wazmo/blog/ - Bret Pettichord - Automation testing Guruand
my own blogs -http://blogs.msdn.com/shrinik ( my Microsoft blog - is closed since left that company)http://shrinik.blogspot.com
Last but not the least, Be a person with positive outlook in the life. Believe in yourself other wise nobody else will believe you
All the best. Let us build a next generation test professionals community and change the way world does testing today.
What’s the Boundary Value Analysis
by Mayank
Boundary Value Analysis is one of technique which is used in Black Box Testing. In this technique we are analyzing the data that which type of data we shall use in test inputs? Actually when we test any application which have some fields and required test inputs then we analyze the data values like which type of data it will accept and how many data and how long? We can say that Boundary Value Analysis is data selection technique includes maximum value, minimum value, error value, abnormal values and assume that when application work with these different types data then it will work all type of data in between. Assume that you have one text field which is accept only 1 to 10 number then we can test this text field with these data 0.1, -1, 11, 10.0, and some character. Please let me know if I’m wrong.
Boundary Value Analysis is one of technique which is used in Black Box Testing. In this technique we are analyzing the data that which type of data we shall use in test inputs? Actually when we test any application which have some fields and required test inputs then we analyze the data values like which type of data it will accept and how many data and how long? We can say that Boundary Value Analysis is data selection technique includes maximum value, minimum value, error value, abnormal values and assume that when application work with these different types data then it will work all type of data in between. Assume that you have one text field which is accept only 1 to 10 number then we can test this text field with these data 0.1, -1, 11, 10.0, and some character. Please let me know if I’m wrong.
Choosing a test automation framework
by Sachin Dhall
There are lot of resources on the internet explaining different types of automation frameworks and how to go about selecting one of them those suites your environment.
Below are few links which provide you solid understanding of the software test automation frameworks.
http://www.ibm.com/developerworks/rational/library/591.html
www.research.ibm.com/journal/sj/411/rankin.pdf
http://www.wilsonmar.com/WRSAFS/Docs/CHAPTER1.doc
http://en.wikipedia.org/wiki/Test_Automation_Framework
www.michaeldkelly.com/images/Choosing_a_Test_Automation_Framework.PDF
www.logigear.com/resources/articles_lg/Automation_Framework.pdf
Subscribe to:
Posts (Atom)