Before the agile process, testers used to start testing the software once the development cycle is completed. In the agile process, testers started involving early in the cycle.
When we have multiple developers in the team they do code reviews. In this code review, they mainly concentrate on coding standards, code quality, never ending loops and deadlocks. Sometimes the software may not full fill the requirements.In this case, we require acceptance testing. If it passes the acceptance testing the will do the full round of testing.
This kind of situations we can handle by introducing "Rubber Duck Sessions". The name “rubber ducking” is a reference to a story in the book The Pragmatic Programmer , in which a programmer would carry around a rubber duck and debug his code by forcing himself to explain it, line by line, to the duck.
In these sessions, the tester will understand the software whether we had built the right thing or not before we start testing. These sessions some people call "Rubber Duck Sessions".
Tester can add value earlier in the Lifecycle
A tester will have a different view if we compare with the developer. This will help to build the right software. If we involve tester in earlier life cycle he can work with the developer and understand the software well, so that he can prepare the checklist or test scripts. It is good to deliver the software to testers in workable pieces. In "Rubber Duck Sessions" tester can detect anomalies if they exist.
With checklist or test scripts tester can write unit tests and as he knows the business requirements he can prepare some end to end scenarios and before delivery we can make sure that expected things work fine.
In the waterfall model, testers were not interacting with developers much. In Agile process speaking with developers and knowing them will not add direct business value, but it does open up space for conversation about what the developers are doing.
No comments:
Post a Comment