Testing is a broad and essential topic for Software Developers. There is a dizzying diversity of testing approaches for different scenarios. However, the typical developer’s inner loop focuses on a few kinds of tests and test selection. That is, choosing which tests need to be written.

A junior developer recently asked for a daily responsibilities checklist. This question made no sense to me at first. A developer’s job isn’t so routine as a daily checklist. However, it sparked me to think about how a developer’s regular activities can be described concisely.

I realized that my Software Engineering Body of Knowledge (SWEBOK) posts reference, but never define, the 15 key knowledge areas outlined by SWEBOK. I intent to fix that with this post.

I recently tried to explain when a developer should be cautious versus when they should freely experiment. This caused me to realize I never learned this lesson explicitly. It’s an intuition I built over time and forgot I had to learn. I believe the answer aligns with what makes a good development environment.

Software Engineers are differentiated from other programming disciplines by economical, repeatable, and reliable results. Such consistency requires measurement, data on which to make informed decisions. I propose that source control and work item tracking are the kernel of such process.

I’ve long understood agile sprints to be a fixed set of work. Lately, I’ve had to examine why. I think the principle still stands, and here’s why.

I was refactoring an older code base and noticed a pattern I used to follow where a project keeps implementations private and only leaves the interfaces public. The motivation behind this was to force consumers to depend on the interface and not concrete implementations. This is a nice motivation, but it’s only a patch to a deeper design flaw.

I previously compared the tradeoffs of Gherkin-based and TestApi-based behavior tests. Recently, I realized there is a simple in-between solution: TestApi with Gherkin-style names.

My test types diagram sparked concern that mature process focuses on repeated measured improvement, not specific techniques. This is right, but I don’t see the conflict. Tests are a kind of measure, and the diagram identifies common tests (measures) certain actors leverage to meet larger goals. This raises the question, what do the different kinds of tests measure? Consequently, what do they tell us about our system?

I recently put together that multiple verification (the quality technique) is effectively the same and as governance techniques. It’s about managing the level of trust and risk we accept from individual contributors.