More Artful Testing

In the software development world we have a whole cabinet full of testing tasks that can contribute to quality work; here is a list of those most commonly used, in an approximate order of where they happen along the development cycle:

Impact Analysis
Usability testing
Code Review
Risk assessment
Stress testing
Test bed preparation
Test case creation
Test driver development
Functional testing
Regression testing
Boundary Value Analysis
Branch coverage
Error seeding
System Test
Parallel testing
Documentation Review
Integration testing
Acceptance testing
Post implementation validation

Therefore all of our software should be perfect and bug free. Right? In the real world our ability to spend time and money on software testing gets constrained however by the dynamics of staffing, skills, and delivery schedules. So much as I described in this earlier post about appropriate balance, we must carefully choose which test tools to remove from our cabinet to apply to each project. And that my friend, is why software still has bugs.

An Artful Environs

In an earlier post I discussed the vagaries of herding the cats of developers. Here I want to chat a bit about motivation of creative developers in a more diffuse sense -- about how to create the environment that allows for quality and valuable software to "materialize."

This is nearly a diametrically opposite approach to the conservative management of a formally enforced SDLC. And it only tangentially has to do with software. First, consider in general what motivates an artist: a desire to be creative, a desire for recognition, a desire to be challenged, and a desire to stand out amongst their peers. Maybe they seek glamour, or grunge, or just to make an aesthetic statement. Maybe they want to promote a socially redeeming view.

Considering the amount of demanding self-discipline, focus, sensitivity, and work that this requires, how do you create a comfortable supportive space in a world of abrupt changes, insecurities, hidden stakeholders, control freaks, and conflicting priorities?

Mostly it helps to be honest and open in your approach. You don't have to necessarily build a consensus, but it does help to lay all of your cards on the table: acknowledge both the staff needs and the strategic challenges as well as how you plan to enable the former through the onslaught of the latter.

Yeah that by itself seems like a considerable undertaking, but the mere process of discussing it with your staff and your superiors will get you on the same page. At least it will settle the expectations toward how much of the developers art you can bear under the freedom of the muses versus how much of their work must yield to the dogma of the Methodology.

The Art in Pseudo

Most new development work starts with ideas or directives or change orders or functional specifications. From this comes diagrams and wireframes and state diagrams and use cases and UML. From all of this documentary scaffolding one would think a person could just sit down and start coding. But for design work that is more involved than just the standard form-based update to a database, one more step will be helpful: the pseudocode.

In carpentry there's an old maxim "measure twice, cut once." Pseudocode does this same pre-measurement for you when you are programming.

Consider for example this recent change order I received: "Send the file Monday through Friday night at the time specified in the parameter unless the Stop flag is set in the database. Allow an override flag in the database to send the file immediately without otherwise affecting the schedule."

It looks simple enough to describe, but once you start programming you will trip yourself up without some pseudocode that considers the last time the file was sent and the actual time of day. Don't be shy to create the pseudocode if you have any doubts about any boundary conditions. And review the pseudocode with the user to help prevent any unintended misunderstandings.