Articles

Please enter an article title, author, or keyword
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
Circle made of arrows Why You Need Continuous Testing in DevOps

DevOps is more than adopting the right set of tools; it's a cultural shift that incorporates testing at each stage of the agile project lifecycle. Continuous testing is key to unlocking this culture change because it weaves testing activities into every part of the software design, development, and deployment processes, which helps everyone involved communicate more, collaborate better, and innovate faster.

Tom Alexander's picture Tom Alexander
Hand holding black rotary telephone When DevOps Gets Lost in Translation

The waterfall method of developing software is a bunch of translation activities: The design is a translation of the requirements into the language of architecture, the code is another, and a formal test process is a third. And with each translation, there’s the opportunity to introduce error. When your DevOps team is isolated, it creates another handoff, and another point of failure.

Matthew Heusser's picture Matthew Heusser
Padlock on a fence 4 Keys to Protecting Your Data in a DevOps World

It may seem like the desires for end-to-end DevOps and protection of sensitive data are in conflict, but if done correctly, they can be two sides of the same coin. DevOps processes such as version control and delivery automation introduce the very measures needed to properly protect production data. The key to keeping data safe while using it during your DevOps process is to focus on these four areas.

Tom Austin's picture Tom Austin
Row of cupcakes decorated with blue frosting and rainbow sprinkles, photo by Brooke Lark Shifting Testing Left Bakes In Quality from the Start

“Shift left” is one of the latest buzz terms in software testing. Movements like agile and DevOps recommend that testers shift left, but what does that mean, exactly? Here's how one tester became a believer in the shift-left movement; how he got his team's developers, analysts, designers, and managers on board; and how his entire organization has benefited from the shift.

James Espie's picture James Espie
Icons showing test optimization 5 Ways to Optimize Tests for Continuous Integration

Many teams have existing automated test suites that are not included in a continuous integration program. Maybe the tests take too long to execute, or they are not reliable enough to give accurate results. Here’s how to assess your test suites in terms of value added and time to execute, along with five proven strategies to optimize those suites for CI.

John Ruberto's picture John Ruberto
Icon of a dial showing good system performance Measuring the Performance of Your Operations Center

Many organizations have problems with consistently tracking and measuring system outages. Issues aren't logged, admins make changes to systems without going through change management, and a high number of issues turn out to be recurring problems. Implementing a performance measurement process calculates system reliability and can help you improve consistency.

Nels Hoenig's picture Nels Hoenig
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.

Three different colored keys 3 Keys to Mastering Test-Driven Development

From his decade of teaching thousands of professional software developers how to be effective with test-driven development, David Bernstein has learned that there are three key ingredients for mastering TDD: understanding what it really is, making code reliably testable, and getting hands-on experience. Let’s look at each of these factors to see what it takes to use TDD effectively on your projects.

David Bernstein's picture David Bernstein
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

Pages

Upcoming Events

Apr 28
Jun 02
Sep 22
Oct 13