I've blogged before about how I've found it difficult to hire Java quality assurance engineers. Because our Flux and Flux BPM software products are targeted at Java software development teams, we need Java QA engineers to do lots of programming to the Flux APIs in order to properly test them. We can't hire someone with the standard set of IT skills.



With this experience in mind, this is what I've done.

1. I've folded our existing QA team into the development team.

2. The development team will perform all QA work, from unit testing all the way through to integration testing, load testing, system testing, and so forth.

3. Performance benchmarks will be posted online with the Flux and Flux BPM technical specifications as well as in the Flux software manuals. These benchmarks will be updated with each major and minor software release. In conjunction with this
effort, Eric and the development team have been improving Flux's performance significantly in the last two weeks. Eric will blog about what the development team has done.

4. Known bugs are posted online in the Flux bug list and the Flux BPM bug list. As I write this blog entry today, there are 20 bugs on the Flux bug list and one bug on the Flux BPM list.

###

I take our customers' success very, very seriously. Their success is the only reason I have a job today. I like my job; I want to keep it.

I have never intended for our users to be our QA team. We are our own QA team. Logic bugs, performance bugs, and excessive database deadlocks are unacceptable. They lead to bad feelings all around, starting with our customers' own users. And that's very, very bad.

With these changes, we are redoubling our efforts to find and fix all of these bugs, both with the current Flux and Flux BPM releases and all future releases.