Interaction Patterns: Tester finds bug!

Consider the following scenario, which probably happens hundred of times every day: Tester finds a bug! That’s great, or really bad, depending on where you look at it, but that’s not the focus of this blog entry. We’re interested in what happens next.

In the less-optimized team, the following sequence, with some variations, may start happening:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements document before I write the ticket.
4. Tester navigates to the root of the version-controlled documentation folder.
5. Tester is savvy, so she gets the latest documentation from the repository. This takes a while. She takes a coffee break.
6. Tester comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
7. Tester: Argh, this requirement document is a joke! Will these guys ever get it right?
8. Tester: It really does not say much about this thing, so I am going to write the ticket anyway. At least someone will take a look at it.
9. Analyst (next morning): QC found a bug, let’s triage it so it gets assigned to someone quickly.
10. Dev Manager: OK, let’s assign it to Developer.
11. Developer (after a day, two): Umm, something looks fishy…This might not be a bug.
12. Developer: Let me check the requirements document.
13. Developer navigates to the root of the version-controlled documentation folder.
14. Developer is savvy, so he gets the latest documentation from the repository. This takes a while. He takes a coffee break.
15. Developer comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
16. Developer: Argh, this requirement document is a joke! Will these guys ever get it right?
17. Developer: OK, here it is - says nothing about this thing. So, it is not a bug.
18. Developer: I am going to reject it and add the comment “Coded per requirements”.
19. Tester (next morning): My bug got rejected!
20. Dev Manager: Can three of you get together and talk?
21. Tester, Developer, Analyst (analysts’ desk, the next day): Let’s open the document.
22. Analyst navigates to the root of the version-controlled documentation folder.
23. Analyst is savvy, so she gets the latest documentation from the repository. This takes a while. All take a coffee break.
24. Everybody come back from the coffee break. Open the requirements document in Microsoft Word and look-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
25. Analyst: Is this the right version? I remember deleting these several lines.
26. Analyst: Let’s get version history. Yes, looks like it was updated six weeks ago. So, where are my changes?
27. Analyst: Oops, I forgot to export it from DOORS/ClearCase and check in to the version control system. What’s coded and tested is really not what the business needs right now.
28. Everybody: Rinse and repeat.

Does this ever happen in your project? I’ve seen it more often than I care to remember and despite that it seems trivial, changing behaviors takes time and perseverance.

What would a highly-effective team do in this situation? Let me attempt to construct an non-exhaustive list of things. This is just one way of achieving efficiency; there are probably infinite number of ways.

First, the team starts with a long-term vision and focus on people, practices and tools. Hire the best people, train them in cross-functional environments and create a reward structure which takes into account individual contributions in addition to team achievements.

Second, [over time] the team accumulated a list of practices and follows them.

Third, it uses tools that support the team practices.

So here is a version of the same sequence in a highly-efficient team, and somewhat shorter:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements WIKI page before I write the ticket.
4. Tester navigates to the root of team WIKI server. Performs a search and the requirements page comes-up first.
5. Tester: Himm, this requirement page has changed 134 times since last year. I wonder which one I am testing.
6. Tester performs another search, this time for the release notes. The search is based on the SCM label dropped to the QC environment. The release notes has an automatically-generated list of requirement numbers along with versions. Cool!
7. Tester: OK, so I am looking at the right version. Still, the requirement sounds ambiguous.
8. Tester chats with analyst in the hallway. Analyst stops by her desk and takes a read at the open WIKI page.
9. Analyst: Yes, this requirement stinks, I am sorry. Let’s edit it together here to add the clarification.
10. Analyst edits the page. Saves it in a new version with the comment: “Adding more clarity to BR:982. No coding required”. Analyst maks this as “Minor change”, so no new version of the page is created.
11. Tester: Thank you for the clarification. This is not a bug.

Now, does this happen in your project? Are there ways to optimize this even further? Probably yes.

Agile 103: Continuous Integration and Agile Development

Compared to other disciplines, software engineering is still in its infancy and as such, it is undergoing significant transformations. This is a challenge because of the relentless innovation and ever changing standards; it is an opportunity because the low barriers of entry make it possible for virtually anyone with a computer to actively participate in the revolution and change course in significant ways.

Let’s take development methodologies for example. In the beginning of the century few people had heard of Agile development. Today, it is growing in popularity and adoption numbers suggest its value and effectiveness.

The Agile movement started largely out of necessity by looking at ways to increasing efficiency by reexamining the way people communicate and create software. The Agile model was explained as a collection of simple principles and practices. One of these practices is Continuous Integration (CI).

Continuous Integration (CI) is the practice of executing series of build steps in a scheduled or automated fashion. The build scripts may be run by a computer or a human; they can be automated or manual. The important thing is to run them often and provide the team with valuable feedback as soon as they need it.

CI can be defined as an umbrella practice enclosing sub-practices such as Continuous Builds, Continuous Database Integration, Continuous Unit Testing, Continuous Deployment, Continuous Functional Testing, Continuous Notifications, and Continuous Reporting. All of these are designed to shorten the time between the problem discovery and the solution. Agile teams can rely not only on the time-saving nature of automated builds, but also on the timely and accurate feedback. Depending on the CI configuration, when one of the steps fails the CI server may choose to continue or suspend further operation until the failure is taken care of.

The typical CI system starts with the compilation and packaging of the application. Any problems at this stage usually cause the CI cycle to fail and the system to notify the submitter or the entire team of the failure. Once the problems are fixed the CI server recompiles the source code and moves on to executing any Data Definition Language (DDL) and/or Data Manipulation Language (DML) scripts as part of the database integration step. This ensures the database gets synced with the source code and that any unit and functional tests that rely on the database changes execute properly. Depending on the server configuration unit test failures may or may not fail the CI cycle. If the application requires packaging and deployment, the CI server packages and deploys the archive into a container. After functional tests pass the CI server labels the source code with an automatically generated label. Finally, it generates a report of the integration cycle and notifies a list of recipients.

CI is an important practice for the Agile team. The CI system can provide feedback to all parties immediately after a problem is discovered. It can also generate valuable deployment artifacts and reports for various roles within the Agile team. Finally, the CI system brings teams closer to having the ability to plan faster and more frequent releases at the end of each iteration.