Almost invariably, your software development schedules slip. If your release dates cannot be moved, something has to give. Testing is often put at the end of the release cycle, so the temptation is to reduce testing and hope it doesn't hurt quality too much. A better idea is short-term software testing assistance.
As part of my own research work, I have developed a best-in-class white-box "test as you build" methodology for compute-intensive software. The goal is to test every line of code as it is compiled, but the methodology can be adapted to obtain core feature coverage with a robust regression test suite to ensure that bugs stay dead.
This methodology helps you isolate bugs and test fixes quickly. Unlike standard methods which require running the entire application, individual driver programs provide test setup, execution, and checking. A quarter million lines of code can be tested this way in minutes on a single processor core.
I can teach this methodology to your development team, show how best to apply it, and demonstrate how it will save them debug time. I can also develop a custom test framework for your project, either as the code is developed or as it approaches final release.
If your code does not have the visibility required for 100% statement coverage, or if you prefer a more conventional application-level testing system, I can develop driver scripts and output checking systems for you. I have tested applications that lacked a test-friendly architecture and have also refactored code to improve testability.
If testing is well underway, or if you don't have staff to deal with a critical bug, or if a key developer leads suddenly, I can help. Finding the most difficult bugs is a specialty: memory leaks, dangling pointers, and memory corruption. It's not enough to know where leaked memory was allocated, or when memory is overwritten - it is necessary to know why, and to find all of the places where the problem can occur.
I am persistent enough to track down everything and focused enough to chase problems down in priority order. I can set problems aside and return to them easily. I've used both Purify and Valgrind, though I can debug without them if their performance overhead is too high to be practical.
I can be productive on day one - after writing (and debugging) 1,300,000 lines of code, I've seen it all.