Tales from the AntiTestingSide - My Process vs. Typical Corporate America

Automated Testing and Test-Driven Development are wonderful concepts. They are time savers in the LONG RUN. That's the hardest part to grasp. What I want to get across is that in order to even GET to Automated Testing and TDD, the project has to have these methodologies in mind when gathering requirements and designing the system! This is where my process differs from most big corporate shops.

Typical development shop development process:

• Business unit says they "need" a piece of software developed
• Development shop talks to business unit and says, "Yes we can do that" (doesn't matter if they can't, cause answer is always yes)
• Business Analyst's are sent for a few months to gather requirements
  
• Over-formalized Use case's are created and sent to developers (not easily readable)
  
• Programmers look at use cases and go back and forth with Business analysts about what needs to be done (waste of time)
• Programmers start coding
  

....... 6 months later

• Programmers still coding, no testing yet
• Development of application is "finished" and is sent to QA
• QA tests for a month or 2
• QA finds bugs, sends defect list back to Developers
  
• Developer spends weeks fixing defect list (waste of time and money)
• Application sent back to QA to check one last time
• QA finds defects, but they aren't show stoppers
• Application is released and now falls into maintenance mode
• Programmer starts working on first BugFix Release
• Programmer makes changes, releases code as fix
• Fix breaks already existing production code
• Now a mess insues
  
• ... and the process continues

Screw that. WAY too many things going on that could have been caught beforehand with a little better and easier planning along with automated regression tests.

How do we get there if we don't know where to begin? Easy.

Read my Use Case post first, before continuing.

My process:

• Contact business that needs application
• Find out who's going to be using it (think of this as "roles" within the application)
• Ask HOW each of those people are going to be using it (i.e. ReservationSpecialist will search for an existing reservation)
• Find out HOW a ReservationSpecialist searches for an existing reservation -- what do they usually search by?
• By breaking down these simple business tasks (Elementary Business Process [Larman]) you can wrap an easier time estimation around it or have a really good idea of the difficulty for each task.
• By using the SIMPLE use case format, that is your test case for code
• Invoke TDD metholody for this use case
• Rinse and Repeat -- it's that easy

The overall goal in my process is to get something working as soon as possible. The reason for this is to make sure it all works within the customer's infrastructure. It's better to catch issues in the beginning than at the end -- even if it's in a test environment. Sometimes you can develop and application and by the time it's LIVE, you find out that the user credentials aren't working or something of that nature. Catch it early!

Using the example above of a ReservationSpecialist... I would aim for requirements that would get me to an end product with limited features. This requires thinking on your part. Yes, it's difficult. Yes, it's your job. Yes, you have to use your brain more than you do now opening a bag of Fritos.

The application would probably be able to do the following:

• Log a user in , if they don't exist have them create a login
• Have an option to "search existing reservations"
• Have a Search form for Existing Reservations that had options to search by and some way to submit the search
• Have the Search form list the results
• Deploy the application to the test server
• Make sure everything is gravy

That would provide a "pipeline" to start making feature additions. As developers and programmers, if theres something we can "update" or "add features" to.. It's more enjoyable and more productive since we're ADDING to and not ALWAYS IN DEVELOPMENT.

...until next time.