By Jeffrey Palermo, Blake Caraway, Eric Hexter:One of the activities that is always involved in software is quality assurance. What does that mean to Headspring and is that a focus that Headspring would ever cut time from to ensure a timely delivery?
First and foremost, quality should be supreme and prioritized above quantity. Here at Headspring we are all about quality, even to the point where every project comes with a comprehensive warranty that is included with a project's price from start to finish and after an initial project finishes we offer an additional warranty that may continue year over year warranting against any software failure that is encountered as a result of a defect. (We will fix defects at no charge.)
During projects, we don't charge by the hour our rent talent. We only charge from results. Our clients need software of a certain quality capacity. We are going to deliver results. If we mess up and there are quite a few defects and the software fails, per our warranties, it is our problem and we will resolve it. We're selling end results hands down. That's it. The way we're structured as a business centers in quality and requires quality in order to operate.
In fact, we do not have anyone on staff with the title of "tester." Now let that sink in a little bit. How do we have such high quality requirements, yet not have anyone on staff with the title of "tester?"
Then the remaining gap to fill in development may be summarized by asking: "Now that the software is working, is it exactly as the approved specification?"
Pervasive in the entire process is automated testing at every level of the software, and the full system testing is the most important.
There is a fad going on within the industry with unit testing, and, yes, unit testing is important, but full system testing is where the rubber meets the road. While all of your unit tests may pass your software may still fail if a file format is wrong. The system tests are going to fail when there is a problem. The unit tests help developers narrow in on problems quickly.
We recommend automated testing in general along with frequent builds and frequent deployments to UAT environments to be put in front of a client so that they may do the final inspection and close the long loop that has all the checkpoints along the way. You have to sew the process together with frequent UAT checkpoints, frequent milestone deliveries, and lots and lots of communication.
On average we like to close the loop every two weeks. For our larger and more risky projects we do it every week to mitigate risk. On smaller projects, interestingly enough, it has even gone out to three weeks and four weeks. In this, we find that there is an inverse proportion between the size of a project and the length of the iteration.
for the requirements process and automation of software. If there are no software testers on staff, how does the automated testing happen?
Remember Me
a@href@title, b, em, i, strike, strong, sub, sup