The Latest

What Counts?[magazine]

In the testing business, we are infected with counting disease–we count test cases, requirements, lines of code, and bugs. But all this counting is an endemic means of deception in the testing business. How do we know what numbers are truly meaningful?

Michael Bolton's picture Michael Bolton
Tools for Our Time[magazine]

Software development has really changed over the years, and programming languages have evolved along with it. Learn more about D, one of today's more interesting languages; it's a high-level, type-safe language with the efficiency of C++ and the convenience of Java.

Chuck Allison's picture Chuck Allison
Hidden Messages[article]

A defect management system contains data such as how many defects have been raised, the priority and severity of individual defects, and even who is raising them. This information is regularly used by program and test management to guide decision making. In this article, Dan Minkin proves that an experienced test manager can gather useful information by looking at more than just the defect management system's data.

Dan Minkin
Top 10 Best Practices in Configuration Management[article]

Joe Farah identifies the top ten "best" practices in configuration management and goes even further by listing ten more runner-up practices.

Joe Farah's picture Joe Farah
Constructing a Configuration Management Best Practice[article]

The construct of a practice can be a good way to help an organization understand and execute on a process. A good practice construct will include the components that are needed to implement a process within an organization in a successful manner for adoption. To move forward on a practice, there are areas of focus to attain a "best" practice.

Mario  Moreira's picture Mario Moreira
Don't Let the Engine Run out of Fuel[article]

Clarke Ching's friend Gary is one of those quietly clever people who hated school, so he left as soon as he could to go work in a factory. Nowadays, years after their schoolboy days in New Zealand, Clarke works in Europe as a management consultant and Gary owns and runs a small farm in New Zealand. Their lives couldn't be more different, yet Gary taught Clarke one of the most valuable lessons Clarke has learned during his career. In this article, Clarke describes that lesson and how it has changed his approach toward dealing with customers and key players in developing a product.

Clarke Ching's picture Clarke Ching
3... 2... 1... Liftoff![magazine]

The amount of effort put into a project's initiation lays the groundwork for all the work that follows. Learn six activities every project manager perform at initiation to ensure the project starts (and finishes) strong.

Karl E. Wiegers
Twelve Ways Agile Adoptions Fail[magazine]

Agile methodologies have taken some heat when they appear to have failed to deliver expected benefits to an organization. In my travels as an agile coach, I have found that agile practices don't fail—rather the variations on agile adoption fail. Here are my top twelve failure modes. See which ones may be painfully familiar to you:

Note: This article was originally published on StickyMinds.com as "11 Ways Agile Adoptions Fail."This updated version includes additional information that explains why some agile adoptions that appear to have failed may never have been truly agile to begin with.

Jean Tabaka's picture Jean Tabaka
A Story About User Stories and Test-Driven Development: The Setup [magazine]

While "testing" is part of its name, many TDD pundits insist TDD is not a testing technique, but rather a technique that helps to focus one's design thinking. Drawing on real events from the authors' combined experience, this story follows a fictional team as it encounters some of the pitfalls of using test-driven development.

Behind the Scenes[magazine]

Have you ever found a major defect while testing an unfamiliar system and been unable to explain exactly how you found it? The Framework for Exploratory Testing can help. These four activities help you explain your thought processes and allow you to train others to be better exploratory testers.

Erik Petersen's picture Erik Petersen
The Measure of a Management System[magazine]

Traditional management systems were designed to measure conformance to plan, not adaptability. So in order to achieve truly agile, innovative organizations, a change in our approach to performance management systems is necessary. Find out why a switch to an adaptive performance management system can unleash the full potential of agile methods.

Jim Highsmith
Buddy, Can You Paradigm?[magazine]

Contrary to popular belief, object orientation is not the One True Paradigm--there isn't one, each programming style has its own claim to fame, and one is not necessarily better than another. So, even more important than being proficient in multiple languages is the addition of multiple paradigms to your development arsenal.

Chuck Allison's picture Chuck Allison
How Testers Think[magazine]

People think in models and metaphors, which help us make sense of the world and deal with new things. Citing material from the book "How Doctors Think", Michael draws a comparison between how doctors diagnose illness in patients and how testers find problems in software.

Michael Bolton's picture Michael Bolton
The Blind Leading the Blind[magazine]

When a team decides to go agile but its management fails to acknowledge the changes to each team member's role and provide support during the transition, frustration ensues. Find out how recognizing the needs of each new role can help smooth the way to a successful agile adoption.

Jennitta Andrea's picture Jennitta Andrea
one way to categorize and organize questions Capturing Implied Requirements[article]

Sometimes the user, project sponsor, and other key stakeholders haven't provided in the requirements documentation all the expectations of the software you're building. Instead, these expectations are only implied. In a perfect requirements-gathering process, there would be no such thing as an "implied requirement" because every requirement would be captured in the document. But no process is perfect, in theory or in practice. This article should help you look for and recognize the presence of implied requirements and learn how to capture them and convert them to documented requirements.

Robert Rose-Coutre's picture Robert Rose-Coutre

Pages

CMCrossroads is a TechWell community.

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