At LogiGear, we often hear statements from testers like these:

• "Testing is bug finding not requirements validation!" "Requirements docs? I wish I got some!"
• "We don’t do automation, is this still as common?"
• "I have no problems with my offshore team. I don’t know what the fuss is about," AND "This offshore team was forced on my team and it’s a complete mess."
• "Do I need to get certified as a tester? What does certification get you?"

The challenge in understanding the current state of testing, then, is to bypass conventional wisdom or educated guesses, and rely instead on actual data.

In an effort to put our thumb on the pulse of the software testing industry, we have developed a series of surveys that are designed to get granular about the real experiences of testers and testing teams.

Enter to win a free iTouch, save on LogiGear University software testing course tuition, and share your opinions with LogiGear's online surveys for testers!>>>

The data we collect will be incorporated into white papers, articles and perhaps even a book - empowering testers who wish to have a positive influence on their profession globally.

• In many languages, a function's local variables keep their values from one call to the next. If a variable is supposed to keep the same value, the function can set the variable's value once and leave it alone thereafter. The function usually has to reset other variables to their starting values.
• In other languages, local variables are erased from memory on exit from the function. Whenever the program calls a function, it must redefine its variables, allocate memory for them, and assign starting values.
• Some languages allow the programmer to specify whether a variable should stay in memory or be erased after each function call.
• Some compilers provide initialization support. The programmer can specify a starting value for a variable; the compiler will make sure that this loads into memory with the program. If the programmer doesn't assign an initial value, the compiler sets it to 0. Other compilers, even for the same language, do not provide this support. The function must set each variable's value the first time it's called. To avoid resetting each variable every time it's called, the function must know whether it's been called before.

• Bad logic: There can be a typing error, like A-A instead of A+A. Or the programmer might break a complex expression into a set of simpler ones, but get the simplification wrong. Or he might use an incorrect formula, or one inapplicable to the data at hand. This third case is a design error. The code does what the programmer intendedóit's his conception of what the code should do that is wrong.
• Bad arithmetic: There might be an error in the coding of a basic function, such as addition, multiplication, or exponentiation. The error might show up whenever the function is used (2 + 2 = -5) or it might be restricted to rare special cases. In either case, any program that uses the function can fail.
• Imprecise calculation: If the program uses floating point arithmetic, it loses precision as it calculates, because of roundoff and truncation errors. After many intermediate errors, it may claim that 2 + 2 works out to -5 even though none of the steps in the program contains a logical error.

• Mishandling of the boundary case: If a program adds any two numbers that are less than 100, and rejects any greater than 100, what does it do when you enter exactly 100? What is it supposed to do?
• Wrong boundary: The specification says the program should add any two numbers less than 100 but it rejects anything greater than 95.
• Mishandling of cases outside the boundary: Values on one side of the boundary are impossible, unlikely, unacceptable, unwanted. No code was written for them. Does the program successfully reject values greater than 100 or does it crash when it gets one?

• functionality
• time to learn how to use the program
• how well the user remembers how to use the program
• speed of performance
• rate of user errors
• the user's satisfaction with the program

• Action Figures
• Agile Test Development with ABT
• Automation and Requirements
• Bonus Bugs
• Business Test Policies
• Capitalizing Testware as an Asset
• Getting Automated Testing Under Control
• Is Action Based Testing an Automation Technique?
• Is Test Automation the Same as Programming Tests?
• Key Success Factors for Keyword Driven Testing
• The First Holy Grail of Test Design
• Key Principles of Test Design
• Key Success Factors for Keyword Driven Testing
• The Potential and Risks of Keyword Based Testing
• The Second Holy Grail of Test Design
• Soap Opera Testing
• Test Automation: Divide and Conquer
• Test Governance
• The Third Holy Grail of Test Design

• Breadth of testing coverage
• Test reusability
• Value of the data reported by software testing
• The quality of the software under test