Automating test execution is supposed to give tremendous benefits, but often gives disappointing results—because it hasn’t met the objectives set for it. The fault may not lie with the automation itself, but with the objectives you are attempting to achieve. Aiming at the wrong target does not bring success! For example, objectives for automation are often confused with objectives for testing, but they should be different. In this article, learn how to avoid the most insidious traps and how to recognize good objectives for automation.
The mobile arena is in constant evolution, changing the way we approach software development both from a business and a technical perspective. Taking the time to set your plan can make the difference between success and just a good idea. In this article, Luis Carvalho shares some guidelines for bringing new applications into the mobile ecosystem.
A contract represents a service agreement between two parties, the bounded provision of service by one party to the other. This metaphor also applies to how we can think about the relationship between unit tests and code. A contractual mindset encourages test names and partitioning based on clear propositions, backed up with executable examples.
Ben has to make a presentation at the next all-hands meeting. It'll be his very first presentation, and just thinking about it has sent him into a panic. Fortunately, he has the support of an experienced speaker and coach who offers advice and encouragement to help him become a proficient, panic-free presenter.
Whether or not a unit test is considered good is not simply about what it tests: It is also very much about "how" it tests. Is the test readable and maintainable? Does it define the expected behavior or merely assume it? To be sustainable, the style of a unit test is just as important as the style of any other code. Perhaps a little surprisingly, the most commonly favored test partitioning style does not meet these expectations.
Virtual Lab Automation (VLA) is a ground-breaking technology that promises quantifiable benefits for application development and test organizations, including faster lab deployment, less manual setup work, greater resource flexibility and utilization, and easier reproduction of defects. In this article, Skytap's Ian Knox discusses the best practices and common pitfalls associated with adopting a VLA solution. In addition, he outlines the steps to evaluate a virtualization solution for your test organization and provides further resources to help you get started.
This article discusses the dark underbelly of derivation: the fragile base class. It's possible to modify a base class in such a way that, even though you've improved its implementation and all your tests work just fine, you've nonetheless damaged the derived classes, perhaps fatally.
Why do so many people resist change, even when that change will be for the better? It's simple, really. Every change ends something, and endings mean loss. People don't like loss. Even the best changes mean something familiar will end.
Most people don't fully understand the complexities and scope of a software performance test. Too often performance testing is assessed in the same manner as functional testing and, as a result, fails miserably. In this four-part series we will examine what it takes to properly plan, analyze, design, and implement a basic performance test. This is not a discussion of advanced performance techniques or analytical methods; these are the basic problems that must be addressed in software performance testing.
Reloadable test data takes more time up front (as compared to on-the-fly data creation), but saves blood, sweat, and tears in the long term. It also virtually eliminates "works on my machine" bugs, creates a more intricate and realistic environment, and is the first step on the road to test automation.