Lewis Prescott
Lewis Prescott
QA Lead
I'm an experienced Test Consultant at Hippo Digital, book author of Contract Testing in Action with Manning Publications. I am also a course author of ATDD for Front End on Test Automation University.
🎂 MoTaBirthday | April 24, 2018
Open To
CV Reviews
Mentor
Teach
Write
Speak
Podcasting
Free course by one of our MoT members, Lewis Prescott How to use AI in your daily SDET workflow: a practical ATDD guide | ShiftSync Community
19 Jul
Share your tools / frameworks as well. There is no right or wrong answer, what would be particularly interesting is the reasons a tool was chosen due to your context and environment.
22 Mar
In recent years I've steered to using the Honeycomb model (made popular from Spotify). Integration testing has become much faster to execute and easier to maintain.What is your preferred testing mo...
22 Mar
A new portrait photo of Lewis Prescott taken at MoT London
6 Mar
Lewis shares his experience of working with a Zero Bug policy. What is it, how does it work and how can it help?
16 Mar
What could be at risk when you only have a week to get a website tested?
31 May
How to engineer situations to develop your people management skills
19 Jul
Often qualitative metrics are more powerful in relation to risk and feelings of confidence.
22 Sep
Denial of Service (DoS)
A Denial of Service attack, or DoS, is when someone from outside your system tries to overload it by sending a large number of requests, often targeting public APIs. The goal is to stop real users from being able to access your service. This is where rate limiting becomes important. If your endpoints are open and don’t have any limits, attackers can keep hitting them again and again. You can also use tools to block traffic from certain IPs or regions if you start to see suspicious activity.
Zero bug policy
The premise of zero bug policy is to redefine what is classified as a bug. Peter Hilton explains that the aim of the zero bug policy is to fix bugs before adding any new code. Switching gears frequently to fix bugs and test the new code can lead to unpredictable development timelines, which a zero bug policy can help to address. Within my company, bugs are called “live issues” and are immediately documented as user stories. This means that they get prioritised alongside all other user stories, so they carry the same value (in theory). So bugs are categorised as follows:
Bug found in production -> “Live issue” created as user story
Bug found during feature testing
Must be fixed before release -> User story, prioritised for development and testing
Feature will be released with bug present -> User story for that feature is updated to account for bug
Bug found during regression
Must be fixed -> User story created and added to backlog
Satisfied with existing workaround -> No new user story created
Bugs found during regression testing can point to a gap in testing: for example, tests were not updated when some requirements were changed. These, too, are categorised as user stories and can be prioritised accordingly.
Comments
(1)
Back to the basics: Rethinking how we use AI in testing
Absolutely agree. This is a must read!
How AI can help teams build quality into software earlier
(hippodigital.co.uk)
24 Jul
How to use AI in your daily SDET workflow: a practical ATDD guide
(shiftsync.tricentis.com)
19 Jul
Insights from the MoT London Chapter: Advancing quality engineering
(hippodigital.co.uk)
09 Apr
QA Test Automation Engineer Interview Questions from a QA Lead in London
(www.pactman.co.uk)
29 May 25
Contract Testing in Action: With Pact, PactFlow, and GitHub Actions
(www.manning.com)
13 Apr 25
Learner completed your lesson
6.5.0 of MoT Software Quality Engineering Certificate
Community Star
1 day ago
