Magazine: Better Software
Issue: March/April 2011

By Hans Buwalda, Chief Technology Officer, LogiGear Corporation

Introduction

This is the last in a series of four articles that started with "Key Principles of Test Design". In these four articles I present what I view to be three key principles to make test design successful (the "Holy Grails of Test Design"):

1. Effective break down of the tests
2. Right approach per test module
3. Right level of test specification

If you followed the instructions of the previous articles you should now have a list of well-defined and differentiated "test modules". For each test module you should have "test requirements", and you should know what the test cases are going to be. Now a last crucial step is to write down the test cases as clearly and efficiently as possible.

By Hans Buwalda, Chief Technology Officer, LogiGear Corporation

Introduction

In the article "Key Principles of Test Design" I presented three key principles (the "Holy Grails of Test Design"):

1. Effective break down of the tests
2. Right approach per test module
3. Right level of test specification

This article discusses the "second Holy Grail", namely finding the right approach per test module. In the text of the first Holy Grail article ("The First Holy Grail of Test Design") we saw that a first important step is the breakdown of tests into test modules, a step that can make or break your test design (and subsequent test automation).

By Hans Buwalda, Chief Technology Officer, LogiGear Corporation

Introduction

In my previous article "Key Principles of Test Design" I discussed a vision for test design, built around three key principles (which I call the "Holy Grails of Test Design"):

1. Effective break down of the tests
2. Right approach per test module
3. Right level of test specification

This article focuses on the first principle, the effective break down of the tests. I also like to refer to it as the "high level test design". In this step you divide the tests that have to be created into manageable sets like chapters in a book, which I call "test modules". Each test module should typically contain between a few to a few dozen test cases. The next steps in test development deal with designing the individual test modules ("holy grails" 2 and 3) and with effective automation.

Magazine: Better Software
Issue: September 2006

When I write and speak about testing, it’s usually about methods, techniques, and project experiences. But when I’m actually testing, I’ve found that the testing team itself is a major factor in a project’s success or failure. I want to share some experiences and ideas about building a successful QA team. Remember that circumstances and people differ, so you will have to determine which techniques will work best for your team.

By Hans Buwalda, CTO, LogiGear Corporation and Maartje Kasdorp

In an effort to counter test automation challenges, Hans Buwalda and Maartje Kasdorp cite test clusters, test lines and navigation as tools for teams to execute testing projects. With descriptive explanations and accompanied diagrams, the authors argue the importance of how test designs should be strictly separated from the automation of tests.

This article first appeared in STQE, November/December 1999.

Download the Article today

By Hans Buwalda, CTO, LogiGear Corporation

Divide and conquer was a strategy successfully employed by ancient Persian kings against their Greek enemies. It is a strategy that can still be used successfully today. Fundamentally, by dividing something into smaller more manageable pieces (in the case of the ancient Persians, they divided the Greek city states), it becomes much more manageable.

By Hans Buwalda, CTO, LogiGear Corporation

Introduction

Keyword driven testing is a software testing technique that separates much of the programming work of test automation from the actual test design. This allows tests to be developed earlier and makes the tests easier to maintain. Some key concepts in keyword driven testing include:

By Hans Buwalda, CTO, LogiGear Corporation

Models can be an invaluable testing tool. Unfortunately, they are often difficult to automate—requiring specialized model-based software and advanced programming skills. One solution is to have testers use action words, or action-based testing, to express models, enabling them to design action-based models that can then be easily automated by a programming expert.

This article is provided courtesy of STQE, the software testing and quality engineering magazine. It appeared in STQE in March/April 2003.

Download the Article today

By Hans Buwalda, CTO, LogiGear Corporation

Introduction

Test design is the single biggest contributor to success in software testing. Not only can good test design result in good coverage, it is also a major contributor to efficiency. The principle of test design should be "lean and mean." The tests should be of a manageable size, and at the same time complete and aggressive enough to find bugs before a system or system update is released.

By Hung Q. Nguyen, CEO, President, LogiGear Corporation

In recent years, much attention has been paid to setting up test automation frameworks which are effective, easy to maintain, and allow the whole testing team to contribute to the testing effort. In doing so, we often leave out one of the most critical considerations of test automation: What do we do when the test automation doesn't work correctly?

By Hung Q. Nguyen, CEO, President, LogiGear Corporation

This article first appeared in Software Testing & Quality Engineering, May/June, 2000.

Download the Article today

By Hans Buwalda, CTO, LogiGear Corporation

Companies generally consider the software they own, whether it is created in-house or acquired, as an asset (something that could appear on the balance sheet). The production of software impacts the profit and loss accounts for the year it is produced: The resources used to produce the software result in costs; methods, tools or practices that reduce those costs are considered profitable.

By Cem Kaner, Jack Falk, Hung Q. Nguyen

This is the appendix from the best-selling book Testing Computer Software, 2nd ed.

This Appendix describes over 400 bugs.  The descriptions are short, including only what we considered the most interesting information.

Download the Article today

By Hans Buwalda, CTO, LogiGear Corporation

Test processes are successful if they are effective, efficient, manageable, and fun.  A major factor in how well these four objectives are achieved is the approach to making test cases.  One such approach is "soap opera" testing...

Download the Article today

By Hung Q. Nguyen, CEO, President, LogiGear Corporation

The following is a web adaptation of a presentation given by LogiGear founder and CEO Hung Q. Nguyen.

Download the Article today

Michael Hackett, Sr Vice President, LogiGear Corporation

Test Leads and Test Managers very rarely make the decision to offshore. It is typically not a choice, but rather a mandate from company executives who look to offshoring for significant cost reduction. Among US leads and managers responsible for offshore teams, management and oversight of the offshore teams is now cited as their largest source of job stress.

By Hung Q. Nguyen, President and CEO, LogiGear Corporation

Hung Nguyen discusses the evolution of software test automation, and explores how implementing a keyword-driven testing framework can improve the maintainability and scalability of your testing effort.

Download the Article today

By John W. Green and Hung Q. Nguyen, President and CEO, LogiGear Corporation

This presentation discusses testing considerations throughout the life cycle of a web application, including when to use automation, when to test manually, and important considerations in each phase of a project.

By Hans Buwalda, CTO, LogiGear Corporation

Hans Buwalda discusses “bonus bugs,” bugs caused by fixes or code changes and how to avoid them from the point of view of the developer, tester and manager.

Hung Q. Nguyen, President and CEO, LogiGear Corporation

In recent years, much attention has been paid to setting up test automation frameworks which are effective, easy to maintain, and allow the whole testing team to contribute to the testing effort. In doing so, we often leave out one of the most critical considerations of test automation: What do we do when the test automation doesn't work correctly?

Michael Hackett, Senior Vice President, LogiGear Corporation

Today many test team leaders must continue to successfully ensure the quality of their applications under test (AUT) while dealing with the increased challenge of having some or even all of their team members located offshore. This article, part 1 of a two-part discussion, will take a look at the unique risks faced by a test lead when dealing with offshore teams, and how those risks can be mitigated.

By Michael Hackett, Senior Vice President, LogiGear Corporation

In part 1 of this article, we explored the first five of the top ten risks, including:

1. Offshore work can be difficult to measure or quantify, leading to lack of confidence in the offshore effort
2. Lack of visibility into day-to-day work
3. Lack of a competent lead/point-of-contact
4. Lack of contingency plans for downtime
5. Offshore teams lose access to onshore servers and applications

The second five risks are based on the communication and cultural problems that exist between distributed teams, as well as the business climate in popular offshoring locations.

Hans Buwalda, CTO, LogiGear Corporation

In a previous newsletter I discussed Test Governance, the topic of organizing and managing testing activities in an organization. In this article, I want to discuss something called "business test policies." These are statements that serve as basis for the Test Governance, and describe how testing is positioned in the overall company strategy, environment and culture.