There are always more points to consider. Here are a few of the cherry-picked ones:
- Blurring the team boundary: Tools such as FitNesse and Selenium IDE make it easier for non-Java programmers to write tests. The easier it is to write tests, the more likely it is that the relevant tests capture the quintessential details of user expectations. Look for new Jenkins plugins that support tools, which lower the learning curve.
- Deliberately adding defects: By rotating through Jenkins builds and then deliberately adding code that fails, you can test the alertness and response time of the team.
- Increasing code coverage with link crawlers and security scanners: A fuzzer discovers the inputs of the application it is attacking and then fires off unexpected input. Not only is this good for security testing, but also for boundary testing. If your server returns...
