Use this simple, creative technique to break down acceptance criteria and reveal missed scenarios

Taking a break between talks before it fills back up again, Emily recommends getting up on stage to take it all in. Something we welcome everyone to try at TestBash. Can you find Bug, Space Duc...

Discover hidden features, celebrate real stories, and hear how the testing community is connecting in surprising ways

Upcoming event? Here's my tips to encourage top tier networking that goes beyond the usual "who are you and what do you do?" Before you head out the door, wear something you'll WANT to be photog...

Pair Programming is a development approach where two engineers collaborate on a single development effort at a single setup (virtual or not). Pairing implies that the responsibilities are equally shared, not split. This might mean two people take different roles or that they alternate between "driving". Pair Programming following Llewellyn’s strong-style pairing This style mirrors that of a driver with a navigator in a car, where the high level instructions come from the navigator and the implementation being done by driver. This style of programming is all about increasing communication and collaboration, building the ability to verbally communicate code and editor commands. The driver needs to ensure the solution is out of the navigators head by facilitating code input and challenging design decisions after the solution has been codified or when the navigator is confused and unable to navigate. The navigator has two main jobs to manage the big picture details so the driver can stay focused on the code they are typing: Giving the next instruction to the driver the instant they are ready to implement it, and talk in the highest level of abstraction the driver can understand. Pair Programming following Test Driven Development Pair Programming can also lead itself to test driven development where two developers (A and B) work such that;  A writes a new test and sees that it fails.  B implements the code needed to pass the test.  B writes the next test and sees that it fails.  A implements the code needed to pass the test.  Using this approach, refactoring is done whenever the need arises by whoever is driving. Pairing using these methods can be done by anybody in the dev / test teams.

Good times were had. Here with Gwen Diagram, Kat Obring, Emily O'Connor and Ady Stokes.

On Thursday 19th June, the British Computing Society (BCS) held their annual conference in London for the "Special Interest Group in Software Testing" (SIGiST), well personally I don't much like th...

Does your phone have that feature where it highlights your photo memories? Here's one of mine! In June 2024 at Ministry of Testing York, Sophie Weston presented her talk - Going Beyond DORA. ...

I love podcasts. I've had the privilege of being on a few of them. Today was my first day co-hosting one! I was nervous, for sure, but once I settled in, made sure I had coffee in hand, and remembe...