Archive for August 2009
Most development is moving the agile way, when it comes to product development and it does make sense. Considering the previous statement is true, you have to be wary about the automation tool that you use, for most traditional tools would fail in an agile environment. Some of the reasons are, you cannot test last in an agile environment; scripts developed using proprietary tool vendor languages become unmaintainable; and installing them on every workstation becomes prohibitively expensive.
The way traditional test automation works, it just cannot support agile development. Take for instance the workflow - developers develop the code, test analysts design the tests, testers exectute the tests, developers fix the bugs, testers again execute the tests, a few more cycles of this and then automation experts automate the regresssions tests using test documents as specs. This in no way will be feasible to be done in an agile environment and can only be possible with large release cycles.
I am planning to cover this topic in two parts:
Part I will deal with the challenges of a testing organization and the solution for the challenges.
Part II will specifically talk about the solution in detail and how to implement the solution.
The challenges of the testing organization can be categorized as follows:
Business Analyst Challenges
- Product does not meet user requirements. Business requirements are not properly transformed into functionality
- Time spent to support different teams for requirements clarifications is too high
- Customer is facing lots of issues after ‘Go Live’
- Cost and effort spent are increasing exponentially
- Availability of software, to market on time are always a question mark
- Requirements keep on changing and we don’t get clarification on time
Software companies need to take concepts to products quickly so that they can reach the market faster. However, in this process, sometimes they end up building a monster application, which upon maturity, companies have to spend tons of time and money in scaling.
Let me explain this in detail. In your development efforts, doing it right the first time is always costly and time consuming. A workaround will take less time and will probably save a whole load of money from the budget. The general attitude is that we will fix it as we go along when we have the resources. As the time moves on, the workaround never gets done, more and more of the code starts to depend on the workaround. Not only that, users also depend on the workaround. The amount of fixing that needs to be done now begins to multiply and your core product starts losing its significance. Foresight here really pays in the long-term and makes life easier in the future.