Articles

Gearbox for a car with a manual transmission Shifting Your Testing: When to Switch Gears

Shifting your testing either left or right can meet different needs and improve different aspects. How do you know whether to make a change? Let your test cycles be your guide. Just like when driving a car with a manual transmission, if the engine starts to whine or you’re afraid you’re about to stall out, switching gears may be just what you need.

Maximilian Bauer's picture Maximilian Bauer
Code on a computer screen Testing a Software Rewrite

Suppose we’re looking at a system rewrite where the stakeholders have none of the original engineering documentation. (This isn't surprising; documentation becomes obsolete—or even misleading—as the system changes, and corresponding docs don't get updated.) What can we do? Here are some tactics to use—and risks to anticipate—when testing a system rewrite.

Steve Poling's picture Steve Poling
Arrow pointing left Shifting Testing Left Is a Team Effort

There is a lot of talk in the testing world about shifting left. Basically, “shift left” refers to moving the test process to an earlier point in the development process, independent of the development approach. This article explores a case in which shift-left has been applied, and the lesson is that shifting left cannot be achieved by testers alone—it must result from a team effort.

Sign reading "Duh!" When the Code Is Too Obvious to Check

How many times does something seem too obvious to check? Most of the time this normal human response is a handy shortcut. Your brain tries to save you time—but you can’t always trust it. If your code malfunctions, each of those "too obvious to check" thoughts will bias your thinking about what caused the malfunction. We have to commit up front, before our thinking crystalizes, that the code will have to prove to us that it is correct.

Steve Poling's picture Steve Poling
Car steering wheel photo by Nicolai Berntsen A Case for Test-First Development

You may feel you don't have time to write unit tests, but you really don't have time not to. Steve Poling makes the case that writing tests first not only will yield better code, but will help you get that code working right sooner. Here's how using a test-first approach changes your thinking about coding, lets you see mistakes immediately, and helps you create more testable code.

Steve Poling's picture Steve Poling
Metrics dashboard on a tablet For Great Performance, Rethink Your Load Testing

The word concurrency is often used to define workload for load testing, as in concurrent users. Too often, it's the only input defined. In reality, there are a number of factors that contribute to workload and affect concurrency, and they all contribute to your load testing abilities—and, ultimately, the performance of your product.

Tim Koopmans's picture Tim Koopmans
Legos 100 Percent Unit Test Coverage Is Not Enough

Many people equate 100 percent unit test coverage with high code quality, but that is not enough. Code coverage tools only measure whether the tests execute the code; they make no judgment on the effectiveness of the tests. Testers should review unit tests, even if they have high coverage levels, and either help improve the tests or supplement them with extra tests where necessary.

John Ruberto's picture John Ruberto
Continuous delivery Test Coverage in the Age of Continuous Delivery

Test coverage is a strategy to help us spend scarce testing time on the right priorities. When things were tested last, how much automation coverage we have, how often the customers use the feature, and how critical the feature is to application are all factors to consider. Here are some ideas for keeping quality high when you're transitioning to continuous delivery.

Matt Heusser's picture Matt Heusser
Service virtualization Overcome Test Automation Plateaus with Service Virtualization

With complex enterprise test automation systems, at least some of the many required dependencies are commonly incomplete, unavailable, or operating incorrectly at the time of test execution. The result is timeouts, incomplete tests, false positives, and inaccurate results. Service virtualization can help you overcome this plateau and increase test automation rates.

Sword Testing in Production: A Double-Edged Sword

Testing in production gives more realistic opportunities to test, increases application transparency between the core product team and users, and supports the idea of continuous development through continuous testing. It's a good technique to embrace in your testing process—but it should not be entered into unprepared. Learn the advantages and pitfalls here.

Rajini  Padmanaban's picture Rajini Padmanaban

Pages

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.