Sometimes you don’t manage to do your best testing. Even as you frantically try to test more, to test better, you know that on this occasion you’re not going to walk away feeling like you did a great job.
This was me last week. We were facing down an exciting deadline. Time was short. I had started on the back foot by missing the earliest project conversations. From then on I felt that I was chasing but never quite catching the conversations and decisions. It didn’t help that things were changing, nothing major but just a constant state of flux around the copy, the design, and some confusion over what was going to be changed before the launch and what could wait until afterwards.
The tight timescales meant we couldn’t follow our usual processes, developers were focused on writing code but we couldn’t test as we went. Code was ‘deployed to production but the launch would be a ‘flip of a switch’ at an agreed time. End to end testing gained an unfamiliar significance and obviously exposed a raft of bugs.
Tight deadlines often end up with a tester co-ordinating testing meaning valuable testing time is wasted telling non-testers how to raise bugs or showing them which area of the system to test.
Was the project a success? Yes. We hit the deadline. There were no unexpected reports from users. Everyone was happy. But I knew I could, and should, have done more. Getting bogged down by a project prevents you from thinking clearly. When you don’t think clearly you miss silly, obvious bugs.
So what can I do? I’m going to go away and come up with a plan. A plan to guide me through these short, frantic projects. A blueprint to co-ordinate end-to-end testing with non-testers. A checklist to remind me of the silly bugs that mobile browsers can introduce, or the need to check plain copy emails. Most important of all I’m going to come up with a plan for gathering project information and finding a way to think even when imd is tight.
Next time will be better.