During the development of custom software applications I am often confronted by the question of when to demonstrate software that is still under development.
The fear of every developer is to allow individuals to interact with the software before it is "ready." Of course, defining "ready" is the challenge--but so is defining who is giving the demo, its purpose and the composition of the audience.
In the early stage of development, as a developer or technical lead, I am the one pushing for a demo intended to uncover questionable areas of the requirements definition or technology issues as early in the development process as possible. (The actual software may very well be throwaway code.) For this to be effective, the test application should be created rapidly with a single focus (e.g. illustrate performance, screen layout, work-flow, or even error handling). The main idea is to eliminate as many unknowns as possible and to throw light upon aspects of a complex system as early as possible. We want to avoid going down a path too far, only to find we are proceeding in the wrong direction. These demos are typically oriented for technical people on the team as well as stakeholders.
The next opportunity for a demo is the more traditional usage. At this stage of development, the application is not complete but major functions are implemented and tested. The purpose is to measure the applications performance against requirements in a controlled setting. One example is to gain feedback observing typical users, where feasible, interacting with the application. Are there confusing areas? What happens when a mistake is made?
Another effective demo is to stress-test the application. This can be done by scripting data entry or transactions for example. Allow the application to run for an extended period of time and measure performance. Now I am looking to expose areas of weakness and potential bottlenecks that must be addressed.
Finally the software is code complete, tested and ready for release. It is safe to demo at a trade show and in front of potential customers. In fact, at this stage, the software is ready for beta site deployment.
-Gary
When it comes to technological solutions, you want a firm that has a proven track record of excellence. As one of the first software and hardware consulting firms in the Northeastern United States, Advanced Decisions is a leader in the industry. Our strength is not only in the experience that we bring, but also in our approach to developing solutions.
Showing posts with label development. Show all posts
Showing posts with label development. Show all posts
Friday, March 15, 2013
Monday, May 7, 2012
Who's Testing Your Code?
I often talk with software executives about the structure of their software development teams.
Some of their common questions are
I believe strongly in the last question's answer. There needs to be someone else besides the developer to test the product.
Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.
Who tests your code? Are they doing a good job at it? Let me know.
-Judi
Some of their common questions are
- Should developers interact with users? (Yes)
- Can developers write their own requirements? (Sometimes)
- Can developers test their own code? (No!)
I believe strongly in the last question's answer. There needs to be someone else besides the developer to test the product.
Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.
Who tests your code? Are they doing a good job at it? Let me know.
-Judi
Subscribe to:
Posts (Atom)