|
 |
|
|
|
|
|
||||||
 |
|||||||||||
|
The following articles reflect upon my experience while testing software in a “traditional” waterfall-like development environment - and it suggests a project- and team-based approach in order to create software in a more flexible and effective way. It’s the eldest part of this homepage and most ideas aren’t new from today’s point of few, but I still like it. |
|||||||||||
|
While testing system, middleware and business software for several years as a Quality Assurance Engineer (I also spent some time in software development and did implementation projects on customer sites), I frequently wrote down my experience about Quality Assurance in order to understand what I had been doing – and why it sometimes hadn’t worked. This is my recent version. …. For QA engineers are masters in the art of negative thinking, I will start this tiny paper with describing the problems, pitfalls and contradictions of day-to-day Quality Assurance - before I will argue in favour of a comprehensive project-based approach to Quality Assurance for small to medium-size software development projects in the next chapter. .... continue |
|||||||||||
|
Let's assume a new version of your successful product DoSomething should be released. ....Marketing has ideas about new and improved functionality, there are request from some of your major customers, the field people add ideas from projects on customer sites, support is grumbling about old bugs which after all should be fixed now, development has brilliant ideas about improving the software's infrastructure. Furthermore it's a medium-sized project, i.e. some dozen developers, testers, technical writers and support people will join it. ...... the first steps will be: writing the specification, determine what quality means with respect to this new version of the product, analyse field bugs from the previous version, discuss and fix the processes, create the schedule and do some risk management. continue |
|||||||||||
|
Let’s assume all stakeholders (development, QA, writers, support and other field people) agreed on specification, schedule and common processes, field bugs were analysed, quality requirements defined and some risk management was already done. The development team was put together and has started designing and coding. It’s now time to form the QA team and focus - beside reviewing the design - on one of the main tasks of QA: to make a statement about the quality of the product as soon as possible after the first release. continue |
|||||||||||
|
As I mentioned before, I’m addressing small- to mid-size projects, which are difficult to manage because you have to find a way between organisational overkill and chaos. To do so I suggest applying a lean version of Eliyahu Goldratt’s “Critical Chain” project management approach combined with proper Risk Management (which I stole from Tom DeMarco) – both items fit together seamlessly. continue |
|||||||||||
|
|||||||||||