Entries that faired better tended to:

  • give explicit evidence of project success (time/money saved, etc.)
  • show empirical evidence on what the problem was, what they changed and the what they measured to show the success
  • show willingness to adopt more modern test practices and show some initiative to research how others are improving
  • include voices of customers/clients, which was helpful in showing successful outcomes
  • include a strong introduction summarising the project (timelines/scope) and what the expected outcomes were/what the business stakeholders were looking for
  • give strong evidence of communication skills in the ‘best individual’ categories
  • give strong evidence of work/involvement outside of their main organisation in the ‘best individual’ categories
  • emphasise the role of testing and QA throughout the SDLC
  • demonstrate holistic approach to testing and upskilling of team members
  • show commercial awareness
  • not be overly perfect – there is no such thing as a perfect project – it was interesting to hear about the occasional blip in the road and how the team worked to overcome it
  • clearly discuss project challenges and how they were overcome
  • give context to metrics to fully justify their inclusion
  • not attempt to use metrics, which are broadly regarded as bogus (e.g. simply quote test case numbers) but provide a range of metrics which demonstrated success

Weaker entries tended to:

  • not focus on a project or come across too much like a sales pitch
  • not give evidence of the project’s purpose/scope/timeline/success
  • not consider the larger picture
  • not justify the reasoning behind including metrics
  • list a large number of acronyms, tools or technology (this just distracted from the original problem and the eventual outcome)
Menu