April 30th, 2010


To My President/CEO

weather: clear
outside: 11°C
mood: ...
Collapse )

[Update - Saturday, May 01, 2010]

I was too drained to write any more yesterday. All I can manage even this morning is this token lament on the quality of my penmanship spiralling quickly downwards.

And yes, it's been five years at Work. That's the longest I've ever been at one company. Work is undergoing a sudden and large shift right now. It's a large shift in size, culture and scope. It's made everything very very trying.

My title is still "QA Analyst". I figure if one day, I have enough white hair, they'll put "Senior" in front of it. Or not. I don't really care.

It sounds like I'm something between a QA Analyst and a Business Analyst these days. I'm still not convinced I know what the difference between the two roles is. Honestly, I don't care what I'm called or even what my role is.

I just want to do the best I can to help my team produce the best quality software we can in the time that we have. And I want to make it "no extra work" to compile statistics and higher level reports for managers and others who are not involved in our day-to-day activities, who neither know nor care about the nitty-gritty.

Requirements, in whatever form they're given to a Development team, is only a starting point. A Functional Spec is rarely ever followed to the letter or kept up. User Stories are just "a promise for further conversation".

The TRUE Requirements and Acceptance Criteria are in the test cases. They are always kept up to date, always tell you exactly what the software will and will not do, in the most granular detail.

I had always thought that, but I thought it was because I was QA and I believed that the world revolved around me. =D But my previous CIO also said it many times in our big department meetings. So, I've kind of taken that to heart.

I had always felt a huge responsibility to understand the business context in which the requirement came to us. Every day, I make small decisions and small judgements on the "correctness" of my team's work that are not covered anywhere, written or verbal. I have to guide the system's behaviour towards what the business needs and not away from it. I wouldn't want bugs to be fixed the wrong way.

I have evolved the way my team tracks User Stories. I've changed the way our User Stories are written, for the better. I have evolved the way my team tracks Test Cases and Testing Coverage. It's been a gradual process of getting something that is light weight enough that people can do the day-to-day upkeep and capture useful enough information for future reference.