It's All About The User: Product Lifecycle - Implementation

Now it's milestone time. Regardless of whether your milestones last for two weeks, two months, or two years, (someone on) your team somehow decides what all will fit into the milestone. Once the milestone's features are decided each feature must be described in a specification. The exact form these specs take again depends on your environment, but you always have a spec. User actions come into their own here as you convert each spec into a set of user actions. Can't decide what the user actions for a feature are? Is the team unable to agree on what the user actions are? Clearly the specification needs further clarification.

As (portions of) the feature definition stabilizes your developers will start implementing it. At the very same time you can start writing your test libraries and automated test cases - the user actions you helped your team define become your test APIs. You probably don't know how you will implement them yet, but simply stubbing them out is sufficient for you to start writing test cases against them. Since the user actions don't have anything to say about UI, it doesn't matter if you don't know what the user interface will look like or how it will work. You don't have to know how you will verify the actions either. Your test cases won't run, but just thinking them through at this high level will help you find areas where you don't understand things as well as you thought you did.

Dev implements, implements, implements. They can use your stubbed-out test cases and the user actions on which they are built as a remembery for how the feature is expected to work. As the user interface becomes defined you can implement your test libraries in terms of an object model around that UI - so again you don't need to know exactly where the various bits of UI will be, or even whether a particular widget will be a check box or a push button. As parts of the feature come online you - or your dev! - implement the corresponding part of your test libraries. The dev code and test code can be complete at virtually the same time and checked in to version control in the same checkin. Test can actually be in sync with Dev! And because Dev has been using the tests throughout, those tests are very likely to pass.

Posted by The Braidy Tester at 07:30 AM  Permalink