One of the things I've really been enjoying about my job here at Kroll is how we're structured to run software development projects. As I interviewed here, I made it a point to give examples of projects I'd been involved in that had come in on time and on budget. Because, in general, I had found at my old place that that was an exceptional result.
Not so in my new work life. There is a dedication to process and excellence in work output that I've not previously encountered in my career in IT and software development. Granted, points of brilliance can always generate good results, but here it's wired in. If I bring a project in on time and on budget, it's not all that exceptional really. The system drives the result.
However, in some ways my role here as a development manager is a little different from some of the other development managers here. Our team is charged with developing an internal tool that can respond quickly to changing needs. To do that, we've done some hybridizing of the Kroll OnTrack software process. We shorten our cycles and work with more of an agile mindset, although to be fair, we're not actually following the agile process to the letter.
How is it different and better?
A lot of companies understand the need to do requirement gathering. Some even do it adequately. The role of the testing here, I think, is the critical component that most companies miss. Testing is something a lot of companies have their developers do, or their end users. It's a mistake.
Developers who test their code, test their code for mistakes that they expect. The inputs they don't expect and haven't coded for aren't going to be tested. If they had expected the input, they would have already coded for it. Sure, developers should test their code, but it's only going to scratch the surface on how your users will actually use the application.
End users, in general, make lousy testers. A couple of reasons for that. One, they already have a day job to do. Running multiple scenarios through your test system isn't on their list of important things to do today. They are much more likely to not even test some of the things you need tested until it's in production. By then, it's a fire drill to fix it, AND you have the added publicity of a bad launch.
Having a dedicated group of testers who work with your development team to unit test the application code, build test cases, and develop user scenarios catches bugs early in the process. They can be fixed as part of the normal development cycle and then released working and whole to your end users.
The problem is that it's not always easy for the people who manage your budgets to understand the value. But that's a subject for another entry.
Posts
1 comments:
Sounds like a great environment John. I suspect you fit in perfectly...
Having spent most of my career in the medical device industry (with brief sojourns in various other development environments) I have a lot of first hand experience with development processes that involve a rigorous testing phase and huge teams of testers. I agree 100% with your assessment that testing is a "critical component that most companies miss." In fact, in practically every position I held that wasn't in the medical industry a part of my job description was to help implement a better software test process, often as a part of improving the overall software development processes that were in use.
All that said, I do think you have to be careful. There's a sweet spot where just the right amount of testing - of just the right requirements - happens. I've seen many projects blow through deadlines because testing got bogged down and side tracked chasing inconsequential details while serious issues were glossed over or ignored. Of course, this certainly can be caused by requirements issues as well - but that's a whole other comment...
Post a Comment