banner-649x60

Monthly Archives: February 2014

LogiGear Magazine – February 2014 – Test Methods and Strategies

LogiGear Magazine – February 2014 – Test Methods and Strategies

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Son Doong: The World’s Largest Cave

With the discovery of the world’s largest cave early last year, international visitors have been putting down huge sums of cash to explore its forests and waterfalls.

By Brian Letwin, LogiGear Corporation

Vietnam’s beaches and mountains are popular draws for tourists visiting Vietnam but there’s one attraction that takes the cake – Son Doong (which literally translates to Mountain River), the world’s largest known cave.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Test Methods and Strategies Glossary

Test Strategy

A test strategy describes how the test effort will reach the quality goals set out by the development team.

Sometimes called the test approach, test strategy includes, among other things, the testing objective, methods and techniques of testing and the testing environment.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Key Principles of Test Design

Regardless of the method you choose, simply spending some time thinking about good test design before writing the first test case will have a very high payback down the line, both in the quality and the efficiency of the tests.

By Hans Buwalda, LogiGear

Test design is the single biggest contributor to success in software testing and its also a major factor for success in test automation. This is not that intuitive. Like many others, I initially thought that successful automation is an issue of good programming or even “buying the right tool”. That test design turns out to be a main driver for automation success is something that I had to learn over the years, often the hard way.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Black-box Testing Techniques

Most software engineers intuitively perform BVA to some degree. By applying these guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection.

By Robin Roy

Software is tested from two different perspectives:

1. Internal program logic is exercised using “white box” test case design techniques.

2. Software requirements are exercised using “black box” test case design techniques.

In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Book Review of The Domain Testing Workbook

By Keith Stobie, Salesforce

The Testing Domain Workbook is the most extensive and exhaustive work you will ever find on a specific testing technique (or related techniques if you include equivalence class analysis and boundary testing as the book does).

What I like best is the combination of academic background and roots combined with practical experience and industrial practice. All the concepts are presented in a simple and approachable manner with pointers to more details for those desiring more.

While the book appears daunting in size, it is only because of the extensive examples and exercises. The core of the book is very approachable and less than 100 pages. To gain mastery, working through the exercises is most useful, but you can do that over time.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Action-Based Testing, A New Perspective

The best part of Action-Basted Testing is that it is for thinking people. It is intelligent and creative. It is a much saner way to evolve a testing project.

By Michael Hackett, LogiGear

All testers and quality engineers hear about Action-based testing (ABT) or keyword-driven testing somewhere. There are automation tools focused on keywords and actions. Maybe people have read an article about it. But do you actually do ABT as a test method? Probably not. What’s the big deal with ABT? Why don’t more teams do it?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Why Exploratory Testing Should be Part of the Test Plan

A test plan should always include exploratory tests as part of the approach. Without them, the number of defects that find their way into production will always be higher.

By Brian Heys

Exploratory testing is a key testing technique that is often left out of formal test plan phases such as system testing, system integration, and regression. Instead, these phases favor planned, scripted tests that are easily repeatable and measurable.

While sometimes labelled as ‘ad-hoc’, and frowned upon in some circles because of the more unstructured nature, the truth is exploratory testing can be extremely fruitful in finding elusive bugs that may not otherwise have been discovered until user acceptance testing (UAT) or beyond.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

In The News – February

Video: The Importance of Regression Testing

JoEllen West says that development shops must conduct thorough Regression testing to mitigate the instances where a change to the codebase breaks a feature in the software. Iterative development, Unit testing, Automated testing, Continuous Integration, and testing early and often are the more accepted design practices in regression testing. Regression testing can be either continuous or you can have a regression testing iteration at the end of every development cycle.

West says it’s also preferable to automate many regression tests, especially if you’re using the Continuous method.  West concludes by explaining how a manager will know if their regression testing strategy is working. You can watch the interview here: http://agile.dzone.com/videos/importance-regression-testing.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Letter from the Editor – February 2014

“Why do we need to understand a bunch of test methods? I write test cases from user stories or requirements, automate what I can and execute the rest manually, and its fine.” If this is your situation: good for you.

If you are time crunched, if your automated tests have lost relevance, are hard to maintain or regularly miss bugs, if you do not have useful and meaningful ways to confidently measure and report coverage and risk, if you are doing what you have always done, if you document too much, or document too little, if testing is “a mess”, if the dev teams do not trust your testing, if you wish there was a better way……then arming yourself with new test methods or examining the methods you currently use will, without a doubt, be beneficial!

Facebooktwittergoogle_plusredditpinterestlinkedinmail