During the past few month we pushed all of our projects on with near time testing. As already mentioned, I phased in this method since a project in july and after working the 1st time with tis method, we noticed following pros and cons of near time testing:
» Developers had a faster feedback and therefore less context switches
» The Quality of the feedback was really high, due to my knowledge about the customers expectations
» I was able to improve the application by using it constantly and making it therefore much better usable by the customer then it was planned on the contractual paper
» the only odd thing was that during this time (2 weeks) we had about 200 tix at all, which (when coming in constantly) are not very motivating to the developers
After working, developing, testing in this manner for more than 3 month ,the time has come to talk about our constistent further development of the near time testing and to phrase some rulez for the projectmanager of such kind of projects:
Over the time, we realized: Projectmanagement is not only the coordination and mangement of individuals (developer, customer, executive board of our company) but also a kind of public relation. Testing and debugging is the ubhorrent part of a project by developers. Tickets/bugs are not welcome, so the 1st step to realize a sucsessful near time testing: Overwrite the current opinion! The primary objective of testing is the optimization of the code and the workflows of an application. While testing, the team will come to know the mentality of the customer, his wishes and desires. So you are in the position to make a person happy - this is great! So bring to mind: Testing is not merely finding bugs but rather a part of conception. This point of view makes the importance of testing clearly. The deeper meaning beside finding bugs is to phrase enhancements, which simplifies your work.
To assure the quality of the QA, we build for every project a dedicated Tester team, who are also managed by the projectmanager. The projectmanager introduces the guys in the system and also in the intellectual world or business case of the customer. He writes the testcases which are similar to the use cases of the application and gives the tester a sense of the future user. It is really important to have motivated dedicated testers, who are able to project the customer thoughts and understand the use cases of the application. If you are able to build such a team, you have not only a enormous power in testing and conception, but also a group of qualified persons for heated and output-driven discussions for the UI of the application.
It is clear, that a lot of tickets will be wrote during a project which is driven by near time testing, enhancement will be phrased and defects will be found- and this is stress for the developers, who are sensitive beings. To minimize this stress , we interpole the projectmanager as owner of every ticket. He decides at which time which ticket will be reassigned to every developer and how many defects and how many enhancement will be showed.
With this in mind, we’ll see: It is important to have a well balanced ratio between enhancements and defects – the motivation of a developer team is a fragile property – so be carefully!
Concluding, I’m really happy to see: We were able to improve the system. And by the way, it is really great to suprise the customer with a great UI and easy workflows. So have the courage to try the approach of near time testing
This entry was posted on Wednesday, October 15th, 2008 at 1:53 pm and is filed under Projects. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
[...] will work faultless. and: how we work instead? If the base for an application is set, we start testing the app manual. And if there are bugs, we fix them. So we are much [...]