The team of the 17th MoT Athens Meetup- December 2025. Meetup with Lewis Prescott and Contract Testing

Taking a selfie before starting the workshop! Full house as well 😱

Glad to be in this learning opportunity around Contract Testing with Marie Cruz and Lewis Prescott.

What a brilliant turn up at 7am for a social run by Brighton beach. I am so happy we did it. We talked, we aligned, we met new people, we discussed work, kids. We showed up for each other. Love it....

About Me: I’m coming from: London, UK My role is: QA Lead I’d love to meet others who are into: API Testing, Contract Testing I'm coming to TestBash 2025 as a: Speaker I’ve been to TestBash: T...

Eighteen months, 19 modules, and 59 amazing contributors later, the MoT Software Testing Essentials Certification is complete! Looking back, my favourite part has been seeing so many community m...

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.

Happy times gathering again at MoT London with these quality people.

Here is Lewis Prescott, recording a lesson for his upcoming course, "Modern integration testing: Tools, techniques, and strategies for continuous quality." In this lesson, Lewis walks you throug...

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.

I tuned into a conversation on testing debt for STEC with Veerle Verhagen and Lewis Prescott What a wonderful conversation covering so many aspects of testing debt: - What factors influence how...