Judges’ feedback

Judges' feedback

The following are comments gathered from the 2015 Judging Panel after they had reviewed all entries. It may help you in deciding on what information to include in your entries.

 

As a whole the entries did not take into account user experience as much as the Judging Panel would have liked.

 

Additionally, the entrants should remember that they are being judged by a panel of industry peers and so would do well to pitch the entry to the target audience. A few entries were considered “overly simplistic.”

 

Entries that fared 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
• 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
• 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

 

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)