Since I have recently been accused of not being “nice” I figured it was time to write something “positive”. As I have stated here too many times to count – I’m no fan of “A”. There are parts I really like. Other parts – not so much. My position is, and always has been, that software testing is not something we can apply a standard (or for the Context Driven school) a “best practice” to. This includes A. In the early days, that is what A was all about – flexibility! Sadly, those days are over. But back on track. Many A practices use Test Driven Development (TDD) as one of the key components. I whole-heartedly agree!
When I was in the Air Force, I spent a number of years in Technical Training as an Instructor, Instructional Designer/Developer and Curriculum/Course Supervisor. By far my favorite position was Instructional Designer/Developer. As an Instructional Designer/Developers we analyzed the training needs of active duty U.S. Air Force, Air Force Reserve, Air National Guard, and foreign military services on complex F-16 avionics systems.We then built the courses, both initial skills and advanced, to support all the various customers. Back then we used the Instructional Systems Design (ISD) process to create the curriculum.
A major piece of the ISD process is writing objectives and tests. We would write an objective to define an expected training out come and then write the test or measurement to validate that the student successfully met the objective. All other training materials or “content” – lectures, workbooks, student texts, practical exercises, etc., were then written to prepare the students to be able to “pass the test”. The tests may be written tests or practical “hands-on” tests of a given process – like testing a Flight Control Computer. Each course had hundreds of objectives and individual test items. All in all it was a great process. Universal? No. We sometimes had to tweak a few things here and there – but it worked! It was a standard, but allowed flexibility. Like A, many tried to make the rules extremely rigid. It rarely worked. They may still use the process today but I retired from the Air Force 10 years ago so I don’t know.
OK – I told you that to tell you this…
When I was first thrown into Software Test Development (yes, thrown) I quickly found that there is little to no training available. So I applied what I already knew. I had my team write test objectives and then write the test case or test script needed to validate it. The only piece we had no direct control over was the development (content). After a while we learned that if we gave the developers the test objectives and test cases before the code was written we were much more successful. The best part – we could review, verify, and approve the objectives and tests as a team (customers, managers, developers, etc.) before the first line of code was written. We found literally hundreds of areas where blocks of code or tests could be either reused multiple times or simply modified rather than written from scratch. We ended up writing libraries of code blocks and test cases that we could call or reuse as needed. We were doing TDD and didn’t even know it!
The result – the project was delivered on time, within budget, and virtually error free. More importantly – the customer loved it!
Now – we didn’t have 2 week “sprints” or a lot of the other A stuff. We actually did 3 “iterations”. No pigs or chickens – or whatever they’re called. No burn-down charts. None of that stuff. We did have daily 15 minute stand-ups – another practice I love and use universally. We were highly collaborative. It was by far the best project I ever worked on! Were we an “A” team? I think so, but the A purists will tell you no!
Was there a down side? Yep. We did daily builds and ran a daily smoke test. If the smoke test failed, the developer that broke the build bought donuts the next day. If it passed, QA bought the donuts. I gained 20 pounds!