Section 1.3. Fit and Business Roles

1.3. Fit and Business Roles

Fit is relevant to people in four types of business roles.

1.3.1. Businesspeople, Business Analysts, and Systems Analysts

You want a better way to influence the software development process. Too often, people misunderstand what's required. The developers expect you to make decisions about details when you're still trying to sort out the value of various approaches to solving important business issues.

This book will help you see the value of well-expressed examples that help clarify business rules. Realistic examples will help everyone involved better understand what's needed of the system. You will learn how to develop concrete examples in tables, a design process that helps people to communicate with clarity about what's needed. With successful experience, you will find that many of your frustrations with the development process will be reduced, as important enhancements happen more quickly.

1.3.2. Managers

You see a lot of wasted effort, with much rework being done. The bugs have grown to an extent that you need special tools to track them. Staff people are stressed, have lower morale, and seem reluctant to respond quickly to changes that are important for business. As the software has grown, it seems to limp more and more. You may be concerned about losing the confidence of upper management when it comes to in-house development.

This book will teach you how tests can improve communication about business rules between the people who understand the rules and those who incorporate them into a software system. You will realize that the introduction of Fit tests will require careful change management. Once Fit tables become established successfully, you will begin to see benefits in improved morale and software quality and in faster response to change. You plan for the day when the bug-tracking software can be retired; it's now clear that a lot of unnecessary work was centered on it.

1.3.3. Testers

Although automated tests would be great, there's not been time to get started on automation. Or, much of the automation you've used has been too fragile, with GUI (graphical user interface) changes invalidating many tests. Many expensive tools are available, but it's not easy to determine how much value they will provide. It's a struggle to work out what the system should do, and there is never enough time to carry out tests before the panic at the end of a release. Users are reporting too many bugs, and it takes time to filter out the ones that make sense. Manual testing is necessary in many parts of the system because it is simply too difficult to automate, and many errors are not picked up.

This book will teach you that testing can be an essential part of the software development process, not something tacked on in a rush at the end of a release. Rather than testing after the fact, your role will shift to the front. You will play a role in helping business analysts to structure and write tests that help spell out business rules. You will also use the table structures to develop sets of tests that provide good coverage, based on your knowledge of what is likely to go wrong. You will find that your tests will change in character as the impact of the Fit tests propagates throughout the development cycle. As tests cover more of the software and as regression testing becomes a daily occurrence, you will find fewer bugs returning after they have been "fixed." You will have more time to focus on finding those difficult bugs rather than on the many trivial ones that used to slip through.

This book does not try to teach testing. Instead, the book aims to leverage the general testing skills that you have already by using Fit for automated testing of business rules.

1.3.4. Programmers, Software Architects, and Software Engineers

It can be difficult to get answers at the right time to your questions about what's needed; this means that you simply have to guess and change it later. The pressure is always on to change a large, complex piece of software. It takes longer to make changes and to fix bugs as the system grows. Often, a bug fix simply leads to more bugs (in 16 percent of the time, according to Steve McConnell [McC99]). You know from experience that it's unwise to change some parts of the system; inevitably, bugs result. So you tend to add similar code, because changing what's there is risky.

This book will teach you that Fit tests can improve your fitness to develop software. Fit tables can provide you with a clearer understanding of what's needed. Some of the design decisions about the whole system will be affected or driven by businesspeople, but that's OK, as you will have more time to focus on the hard architectural design decisions. The tests give you more confidence that you have completed a task and that you haven't broken any other code in the process. This encourages you to use a unit-testing framework, such as JUnit, for your programmer tests, as you appreciate the value of clarifying with tests what is needed beforehand. You are relieved to at last feel confident about tackling the mess that has built up in the tangle of software, as you have the tests to support your refactorings. As the quality improves, you find that you spend less and less of your time on rework and fixing bugs. Enhancements now go smoothly, with much less effort.

In order to communicate with testers and business stakeholders, you will need to read Fit tests, and understand how they evolve. And you will be needed to develop the "glue" code that connects those tests to the system under test.