Tag Archives: Test Development

The Dangers of Tribal Knowledge

On her first day, Jayne spent a lot of time collecting data from teammates to become familiar with the company’s systems and procedures. Since she appreciated the hands-on approach being taken with getting her settled in, she made her own notes and never stopped to ask if there was a corporate wiki or central document system where this information was stored. Six months later, Jayne had become a valuable member of the team, had gained significant knowledge from her team, and was given a product enhancement project. While reviewing the code for the necessary changes, she noticed some oddly designed features. She asked her team lead, Tim, where the original specification of the app could be found so that she could understand why the application had been written that way. Tim gave her a confused look as said, “You’ll have to talk to Carrie. She’s the only one left from the team that wrote that. I think she’s in DevOps now.”

If you have run into a situation like this then you have already experienced the effects of Tribal Knowledge. This happens when enough people know how something works so it is believed that documenting it would be a waste of time. This common knowledge is ok for situations that everyone must deal with every day, however, relying on it for more obscure information can lead to lost data, increased project time, and decreased morale. Let’s check in with Jayne to see how this plays out.

After learning where Carrie now sits, Jayne heads over to ask about application.

“Carrie?”

“Yeah.”

“I’ve been assigned to enhance the shipment tracking system. I’m looking for the original specification, design plans, notes, whatever documentation there is on it and Tim told me to talk to you.”

“Good luck with that. I was only on the team for about two weeks before release and I never saw any documentation. We had meetings where we kicked some ideas around and then we went off and made it work. Josh and Kate were the ones that really knew that system. We’ve been hoping it didn’t break since they left.”

All too often (especially in IT), a source of knowledge will change jobs or companies and that resource will be lost. If the teams rely too heavily on tribal knowledge then it becomes likely that they will fall to the trap of reinventing the wheel or relearning lessons. This cycle results in inefficient use of both time and money. In a worst case scenario, it also depletes the moral of the team members assigned.

The easiest way to avoid the negative effects of tribal knowledge is through documentation. I expect that some people cringed after reading that and/or pictured writing tomes explaining every intricacy. Documentation doesn’t have to be tedious nor does it have to be extensive. Sufficient documentation to avoid a situation like Jayne’s could have been a short comment explaining the unusual approach in the code. Alternately, it could have been kept with the design records in an archive of stories or specifications. The key to good documentation is to eliminate the unnecessary and focus on what is important. Obvious functionality such as basic field validation (eg., number fields do not except letters) can be ignored while business logic should be called out in some way. If a developer needs to come up with a “clever” solution to an issue, there should be a comment in the code to explain why it was necessary and possibly how it works. Whether you write traditional specifications, Agile stories, or take notes in a team wiki, a few minutes of writing can save hours of review and frustration.

Advertisements

How to Configure a Virtual Ubuntu Server

Virtual machines are useful tools for both development and testing of applications. The following video shows how to setup an Ubuntu server using Oracle VirtualBox.

There Is No Right/Wrong Way: Writing Tests

Over the years, I have encountered and practiced many different ways of creating, documenting, and executing tests. I have also worked with a number of testers, including myself at times, who harbored strong opinions about how tests should be handled. As a result, I’ve found that the “right way” to handle tests depends upon your environment and your team.

If we look at the methodology and maturity of any team’s development life cycle, we will see that certain approaches to testing are better suited than others. For example, a waterfall team that has a high turn over rate will get more value out of high detail, scripted tests because there will be a smaller product knowledge base among testers. Alternately, an Agile team dedicated to a project/product will likely benefit from more generalized tests and exploratory testing. A company’s culture, regulatory bodies, and procedures also play into how testing is performed and documented.

With this in mind, it is important for testers to keep an open mind and consider their processes carefully. Small changes can result in major savings in time and costs. A good example of this would be changing the test team’s charter from exhaustive to risk-based testing. This change will quickly switch their focus from reviewing every possible combination of data paired with a complete review of the system’s functionality to examining the changes and identifying the sections of the software with the greatest need for testing, which typically results in a significant reduction of test time. As a counter-point to that example, there are situations in which the team may need to perform more in-depth testing, such as when there is a major refactoring and the project is disturbingly light on unit tests.

The point of my ramblings here is that as professionals, we should focus on learning and improving our skills and finding solutions to our pain points rather than arguing over who’s methodology is better. The reason there are so many ways to approach testing is because each situation is different and cannot be handled by a one-size-fits-all solution. Keep learning and remember there is no right or wrong way, it’s just a different style.