Test more, document less

Today, one guy from my test team said that the documentation is not very important for him. The thing is that used to write very extensive documentation. Lot's of details were covered. A lot of knowledge were put into one document - one for each requirement.

Unfortunately, as people start working, the different aspects of a requirement will likely to change - the user interface, the data bounds, important functionality gets added, redundant things gets removed or redone. Anyways, something changes. All these changes are being tracked by people during the work process, on the communication level - as it is the most efficient way to share things. But the documentation remains intact, and the problem is - it gets old, retired, and then I simply delete it or reqrite anew one.

Anyway, the process of getting a very good document is pretty complicated, and boring.

On the other hand, the documentation is an important artifact on the project. As it has information right about the thing it describes. So it helps people work - they know how to do their job from the documenation.

I may be reaching out from the point I started. They guy said he does not need the documents any more. What's changed?

The thing is that we introduced a scrum-like two-week iterations some time ago. But there was a problem. As soon as we released a build, let's say three days before the release - we had plenty of problems right away. As a result, a number of iterations were blown up, the date were shifted to the future, customers put on hold, etc.

Therefore, we dicided to perform a two-phase testing. The first phase, it when the feature gets implemented - the build is being moved to the development (!) server where tester can look at it, study it, suggest (!) improvements or report bugs. The second one, when the build if ninaly gets released with all features planned for the iteration. This time we do integration testing (?) and verify that everything is performing correctly.

The outcome is amazing:

• testers study functionality by using it, not making guesses from documentation
• we reduce risks failing the deadlines by performing additional verification
• we reduce risks of deployment failures, as we do it more often
• testing takes the same time as it would take it we did regular "develop, then verify" process
• now we can think how we can make our documentation more efficient, so it would not go on retirement

Open Source and Commercial Software

Many people would like to use open source frameworks and tools, however, for a certain reason they choose something they can call commercial software and pay money the same quality product.

One of the "benefits" of commercial products sounds similar to the following:

commercial product has support so I know whom to contact when I will be trouble (be sure you will %99), while open source has no support

OK, while this may be true think of the followin please: do you compare equal products. I can think of both products as equal when I have commercial product on one side and open source product with active development on the other. Assuming open source is in active development I can conclude it has the very support we did not saw earlier, hasn't it?

The other argument, again:

commercial product has support that can promise me a deadline...

Yeah, guys, do you really think that something is different with planning in open source software? I guess not. The planning is done as we usually do for our projects. Same ideas applies to the mighty commercial software we tend to buy instead of using the one that is useful and at no cost.

Anyway, it is your choice. Just think of it, please.