banner-649x60

Monthly Archives: November 2010

Letter From The Editor – November 2010

Hi everyone and welcome to our fourth edition of LogiGear Magazine. This month we finish Michael Hackett’s piece on “Agile in Testing” with part five, Tools.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

LogiGear Magazine – November 2010

LogiGear Magazine – November 2010

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Testing in Agile Part 5: TOOLS

Michael Hackett, Senior Vice President, LogiGear Corporation

To begin this article, it would be a good idea to, remember this key point:

Agile Manifesto Value #1
Individuals and interactions over processes and tools

Tools work at the service of people. People, particularly intelligent people, can never be slaves to tools. People talking to each other, working together and solving problems is much more important than following a process or conforming to a tool.  This also means someone who tells you a tool will solve your Agile problems knows nothing about Agile. A disaster for software development over the past decade has been companies investing gobs of money into “project management tools” or “test management tools” to replace, in some cases, successful practices of software development, in favor of the process the tool or tool vendor told that company was “best practice”. That made certain tool vendors rich and many software development teams unhappy.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

What is Combinatorial Testing and Why Should Testers Care?

Developers of large data-intensive software often notice an interesting — though not surprising — phenomenon: When usage of an application jumps dramatically, components that have operated for months without trouble suddenly develop previously undetected errors. For example, the application may have been installed on a different OS-hardware-DBMS-networking platform, or newly added customers may have account records with an oddball combination of values that have not occurred before. Some of these rare combinations trigger failures that have escaped previous testing and extensive use. Such failures are known as interaction failures, because they are only exposed when two or more input values interact to cause the program to reach an incorrect result.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Allpairs, Pairwise, Combinatorial Analysis

Last week I went to StarWest as a presenter and as a track chair to introduce speakers. Being a track chair is wonderful because you get to interface more closely with other speakers. Anyway…one of the speakers I introduced was Jon Bach. Jon is a good public speaker, and I was pleasantly surprised that he was doing a talk on the allpairs testing technique (also known as pairwise or combinatorial analysis). I wish Jon dedicated a little more time to the specifics of the technique during his talk and was generally more aware of available tools and information for folks to investigate further, but I think he successfully raised the general awareness and interest in pariwise testing as an effective testing technique among the audience.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Are Use Cases Harmful For Test Automation?

People who know me and my work probably know my emphasis on good test design for successful test automation. I have written about this in “Key Success Factors for Keyword Driven Testing“. In the Action Based Testing (ABT) method that I have pioneered over the years it is an essential element for success. However, agreeing with me in workshops and actually applying the principles in projects turns out quite often to be two different things. Apart from my own possible limitations as a teacher, I see at least one more reason: The way the testing is involved in the development projects.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Combinatorial Software Testing

“Combinatorial testing can detect hard-to-find software faults more efficiently than manual test case selection methods.”

Developers of large data-intensive software often notice an interesting—though not surprising—phenomenon: When usage of an application jumps dramatically, components that have operated for months without trouble suddenly develop previously undetected errors. For example, newly added customers may have account records with an oddball combination of values that have not been seen before. Some of these rare combinations trigger faults that have escaped previous testing and extensive use. Alternatively, the application may have been installed on a different OS-hardware-DBMS-networking platform. Combinatorial testing can help detect problems like this early in the testing life cycle. The key insight underlying t-way combinatorial testing is that not every parameter contributes to every fault and many faults are caused by interactions between a relatively small number of parameters.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

An Interview with Computer Scientist – D. Richard Kuhn about applications development of combinatorial research.

D. Richard Kuhn Computer Scientist, National Institute of Standards & Technology

LogiGear: How did you become interested in developing applications for combinatorial research? What led you to it personally, and what did you find fascinating about it?

Mr. Kuhn: About 12 years ago Dolores Wallace and I were investigating causes of software failures in medical devices. About that time, Raghu Kacker in our math division introduced me to some work on the design of experiments and testing, which had been done by a colleague of his at Bell Labs. The idea behind these methods was that some failures only occur as a result of an interaction between components. For example, a system may correctly produce error messages when space is exhausted or when input rate exceeds some limit, but crashes only when these two conditions are both true at the same time. Pairwise testing has been used for a long time to catch this sort of problem.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Dr. Cem Kaner shares his experiences on software testing and essential skills needed to be software tester.

Dr. Cem Kaner – Director, Center for Software Testing Education & Research, Florida Institute of Technology

PC World Vietnam: What did you think of VISTACON 2010?

Dr. Kaner: I am very impressed that the event was very professionally organized and happy to meet my old colleagues to share and exchange more about our area of expertise. I was also very excited being one of the speakers at the conference and presented on some topics which focused on software testing as well as sharing some of my experiences from my research and work in this field.

Facebooktwittergoogle_plusredditpinterestlinkedinmail