SLIDE 31 5
Pre-Check in tools
Another good idea is to build the product and then run automated tests before the developer’s changes get into the product build system. Basically, if your team can afford some machines and more test code development, you should be able to have automated tests that would run for every check in into the product source code tree before it really occurs – in case any test fails, the check in is aborted, so the developer either has to fix his code
- r the automated test. A possible alternative, in case you can’t afford it, would be to convince your development
team to do it☺. This will actually benefit them more than you.
Automated daily builds and Code Coverage builds
But, in case the idea above is not feasible, I still got few more for you. One big serious problem is when there is a build break, when there is no product to be tested, what makes the whole team go into waiting mode. Also, you should make every effort to have recent product builds, this way you would be maximizing the results of your test team, as they would be testing the most recent version of the product, not outdated ones. So what I am suggesting is to have as often builds as possible, like daily builds. And if you implement this idea, why not do the same for Code Coverage builds? This way your test team can have them easily available whenever they want to perform code coverage analysis..
Automated tests execution and code validation tools
And if you want to take another extra step: produce the build automatically at night, like at midnight or so, and then also run all or some of automated tests you might have, including development ones. You could also run some tools that will verify your source code for bugs and bad practices, like FXCOP. This way, the next day when you arrive at work, you will not only have a new product build to test, but results from the automation, which will indicate how good or bad it is. If you are able to deploy any (or all, hopefully) of these ideas, you will be taking few steps towards a higher quality product; and your test team will become more efficient and less frustrated too.
Looking for bugs in different ways
It is common to have product features assigned to individual testers, who conduct spec reviews, write the test spec, execute it and provide support to the feature developer. But if you have just the same group of people looking at the feature, they could get “too” used to the feature, ignoring problems and bugs that someone with fresh eyes would not let slip through. The techniques below focus in this concept, and normally produce significant results when deployed in working groups.
Bug hunts, Focus and Adhoc days
There is a chance that some testers end up spending too much time developing test automation, ignoring adhoc and/or manual testing – it is important to keep a good balance, and because of this we used bug hunts and adhoc days while testing past MS products. This practice would set some specific time where test team members would simply play, test and have fun testing the product, focusing on specific areas or picking random areas, depending on the need and stage of the product: let’s say there is a big check in that occurred recently, and the feature tester is worried about possible regressions – this could become the focus of a bug hunt.
Bug Bashes
Similar to the bug hunt, the major difference in the bug bash is that it involves the whole team, not just testers – you should get developers, program managers, documentation writers, product support folks, etc. to participate in the bug bash. Again, depending on the situation, it could be focused or free for all. But to maximize its results,
