The InfoBeans engagement life cycle – part 2

So once we go into the development part of a project, we look to validate what we have done and make sure that the quality is within acceptable limits.

The quality measures and the relative emphasis that we lay on are different for different projects and are really a requirement. For some deliverables, sub second response time is extremely critical, while for others, clients are looking to do a lot of number crunching which again is performance optimization. Yet another aspect is the visual appeal. Some web applications lay a lot of emphasis on visual appeal when the users of that application are say, retail consumers. We factor in these requirements are an early stage of development and that is really what it means when we say that QA is involved in the very beginning of the project life cycle. We like to have our QA team or at least some representation of it, involved in the development process right from the business understanding phase.

Apart from quality testing the application, we also rely on our QA team to be our consultants. We have found that the QA team is extremely useful as a sounding board of ideas and their feedback on various issues, including usability is important to the project. They also have probably the most holistic view of the application and are quick to identify impacts on areas for any changes. I personally rely a lot on feedback from such quarters. In complex implementations, such feedback becomes critical.

We also have a keen emphasis on just reducing the number of defects created in the first place by the development team. A lot of testing goes into the development at the time of development. We understand that a single defect increases costs a lot and therefore the most more we rein in the number of bugs in the first place, the better off we all will be. You as a client would be better off with lower number of issues and higher turn around time. We as a vendor will be better off with lower costs, lower developer fatigue and higher margins. A true win-win!

A user acceptance testing phase is something that we bank on a great deal to get the final issues ironed out and make sure that we have met expectations of the user who is actually going to be using the system. Many a times, the folks who think about the app, ones who develop it and the ones who actually use it are different people. And different in many senses of the word. Different in capabilities, knowledge spheres and domains. The UAT phase helps us in making sure we have gotten most of the application right and there aren’t any surprises to the end users before the application is released to production.

Releasing to production is not the end of our relationship with our clients. It is the start of a new one. We constantly help our clients monitor the health of the implementation and give support proactively. We understand that our task merely moves to the next phase of the project where we have to provide support to our clients after they have implemented the system, rather than the end of an engagement at that point, like many other vendors like to put it.

This two part series tries to shed some light party on the actual engagement life cycle and partly on the philosophy with which we try to approach the engagement. Please feel free to post any questions or write to me at siddharth.sethi@infobeans.com