Test, Test and Test Again

snikkersnak writes "Richard Collins has written a piece about developers and testers; the article is arguing that in closed development these two roles have to be chained together one-on-one in order to reproduce the 'release early and often' effect of open source development."

Re:One tester per developer?

[aadvancedGIR]

That's the kind of testing you can actually do fast and close to the development team, but the real problems come from the impact your code could have on parts you barely know they exist in the full system.
Parts testing is just step 0 of the testing process.

Re:Closed source does not work like open source

[TheRaven64]

Many Free Software projects (the BSDs in particular) split the tree into three sections:

1. The active development 'this may compile, and if it does, then it may work, but don't expect it to be stable' branch.
2. The 'this stuff seems to work, but may still break' branch.
3. The 'we think this stuff is stable now' branch.

On FreeBSD, for example, these three branches are called -CURRENT, -STABLE, and -RELEASE. Typically, only active developers run the -CURRENT branch, but a lot of people run -STABLE. People running either can file bugs, which make -RELEASE more stable, and people running important services run -RELEASE (and possibly keep a -STABLE box around for testing).

Contrast this with closed development. In this case, the first branch will be internal-only, and snapshots of the second my be released as betas. This reduces the number of people testing both of these branches, which then has an impact on the stability of the third.

Thorough self-testing

[c0d3h4x0r]

I've been a professional software developer for over ten years. Based on my experience, I can say with certainty that there are three main sources of bugs.

In order, they are:

1. Lack of sensible high-level design and architecture. This causes the bugs that require massive amounts of churn or ugly hacks on top of hacks to fix.

2. Source code that was written without regard for human maintainability/understandability/readability. This causes the bugs that take the longest time to investigate and which are the trickiest to fix without breaking something else without realizing it.

3. Lazy developers who neglect to thoroughly self-test their own work before calling it finished. This causes the most bugs in gener, but fortunately most of them are easy and quick to fix as they are mere oversights.