Wednesday, April 22, 2015

Testing is hard

I'm writing test scenarios for a product I own, and I've developed a newfound respect for the people who had this as part of their job description before me. Our previous product development and management model had been that we would read the law or subregulatory guidance, tell IT what to do and IT would do it and tell us how they recommended testing it based on the requirements we gave. Someone else would handle any resulting operational processes. It resulted in a lot of miscommunication and annoyances, but had no idea how good I had it.

Our new model is end-to-end product ownership. In other words, I have to read the law, tell IT what the law says, IT codes it, I tell them how to test it, I approve the results, I put in the operational processes and figure out how to report out afterward and make sure we're actually doing what we said we'd do. I also manage congressional complaints, discussions with the federal government and other fun. In other words, if something gets screwed up, the only person I've got to blame is myself unless IT jacks with the code.

On the upside, I'm forced to actually read what I told IT to do because I have to cross reference all my requirements to make sure they're tested. It makes me identify potentially missed requirements, requirements that need tweaking, items that may have changed, etc. And it makes me respect IT more.

The project I'm putting in place is large - very, very, very large. It's a massive industry change from the way we've been doing things so far and I've written nearly 100 test scenarios on logic in our system alone and I haven't even gotten to the hierarchies and data part yet, let alone putting together the operational processes I will then need to support and monitor on top of my other responsibilities.

Hats off to you, IT and ops. You guys are rock stars. And I'm the poor schlub trying to fill your shoes.

No comments: