QAing your QA
Work has been tough lately. I’ve been overworked and requests for help have been mostly ignored. It is up to me to fix it ultimately which is pretty great, all things considered, because I am trusted to handle myself and my growing team.
Much of my overwork is self-inflicted because I assign myself too much to do and it reduces my ability to focus on the quality of my job. And quality is the entire point.
I am Quality Assurance.
It’s, like, right there.
But it’s hard to see that whn there’s a crush of development to test, unhappy customer calls, company wide initiarives to rescue.
Now though? I’m post deadline and I have had a chance to breath, step back, and look at what I’ve been doing and how I’ve been doing it. Which ives me time to think and when I think, I philosophize about goodness of things. Of quality, if you will.
I”ve written up what I think are guiding principles for any quality assurance engineer.
Seven Principles for Quality QA
- Quality first, excuses never.
- Why is your strongest asset.
- Where there’s one bug, there are more.
- Find bugs sooner, get them fixed faster.
- Write it down or it didn’t happen.
- Break the code, respect your developers.
- Advocate for your end user.
I am not sure if that is complete or the right wording. I initially had “love your developers” but people look at me weirdly enough when I say normal things.
What am I missing? What matters for quality software testing?