John Ferguson Smart’s Post

Automatic test retries? Just say no.

Does BDD Help With Manual Testing? YES...But not in the way you think... If you're a manual tester, or just getting into automation, BDD can feel a bit intimidating. But it turns out, it can be a fast track to more effective agile testing, even if you don't write a line of code! How so? Well, there are two main ways that BDD pratices can help with manual testing. The first benefit is probably the biggest one. The BDD process (not the tools, not the automation, not the Given..When..Then format, but the process) is designed to build a shared understanding of the requirements, and uncover the things you don't know early, rather than later. So when you pracice BDD (properly!), your team take deliberate action and get a much more solid understanding of the requirements they are trying to build, before they start building it. And this is a game changer. Even if you do zero test automation. Even if you only focus on manual and exploratory testing. Why? Let's dig deeper. In BDD, everything starts with a conversation. Teams that practice BDD get together before a sprint starts. They talk about how the user will interact with the application to get their job done, and about the business rules and constraints that apply. And they identify a few key examples that can be used to prove that the feature does what it's supposed to do. But they don't just chat over a coffee - it's a deliberate, structured conversation with well defined methods. There's a bit of an art to doing it, but it's pretty easy once you know how. And automation in all that? Well, the automation side of BDD speeds up the feedback cycle and automates the release evidence - it lets you know when a feature is done, and gives you some evidence that it actually works, automatically. But the real value isn't the automation itself - its knowing what to automate. Because if, as a team, you know what to automate, you also know what to test. And if, as a team, you know what to test, you also know what to build. And you (as a team) are likely to get the job done faster, and make fewer mistakes, because you (as a team) spent time thinking about all those scenarios and edge cases before you started the work. That's one of the biggest benefits of BDD, and it doesn't need a line of automation code. And the second benefit? Well, even if all you do is identify your acceptance criteria and write them in a rigourous, structured testable format, even if you don't automate them straight away, it gives you a powerful basis for your manual and exploratory testing. You start with the acceptance criteria (does the feature do what it's supposed to), and then you fan out from there with your exploratory testing. And this is much more efficient, in my experience at least, than the old-school approach of writing reams of manual test cases in an Excel spreadsheet or some test management tool, then going through them one-by-one like a robot. Give it a try and let me know how you get on!

What with all the UI-focused test automation courses I see, I really get the impression that the majority of testers still think that the Test Pyramid is something the Egyptians used before they made the real one - am I wrong?

Automated tests are just for catching regressions, right? Wrong! Well written automated tests don't just show that the code works; they also show the code does what the business needs it to do. Your tests aren't just tests - they should also act as a form of documentation, that you can refer to when a bug is discovered (what test case would have picked this up?) or when a change is required (what test case needs to be added or updated to cater for the new requirement?). And yes, this is also true for unit tests. Here are three tips that can help make your tests have more impact: 👉 Organise your tests so they read like a user manual - structure the folders in a way that will make sense to whoever needs to read and find them. 👉 Use descriptive test titles, and never use the word "test" (you know they are tests) - instead, describe the example you are illustrating ("Calculating sales tax on a digital product sold in France"), or the expected behaviour or busines rule instead ("email is mandatory") 👉 Test behaviours, not implementations, AT EVERY LEVEL. This is really important - it's the key to being able to maintain and expand your tests in a sustainable manner, and not end up in a situation where your tests feel like they are slowing you down, not speeding you up. Take pride in your tests. A bit more effort in the beginning can save a lot more down the road.

If you are asking “how can I write BDD scenarios for this screen”, you are already stating too late. Acceptance criteria define business goals and rules, not UI implementation, and drive the design, not the other way round. Want to know how BDD 𝘳𝘦𝘢𝘭𝘭𝘺 works? Have a look at https://lnkd.in/eUmGbxiH

These days API testing is important. Critical, even. That’s why everyone wants to learn API testing. But I’m gonna be a bit contrarian here - most API testing should be done by developers, as part of the normal development cycle. NOT as part of a separate automation exercise done by testers (even if they are SDETs). Why so? Simples: - Testing APIs can be done much more easily within the code base itself, where you can mock out external components if you need to - Microservices are self-contained, and they can and should be tested as much as possible before they are deployed. This means testing as part of the build. - API Testing is technical and can require a deep understanding of how the service works in order to test it optimally, and developers are much better placed to know these details. BUT…testers still have an essential role to play - Helping to identify scenarios and edge cases that will need testing. Testers are generally much better at spotting edge cases that might trip you up later on. - Making sure the integration and acceptance tests cover enough of the functionality to be able to release with confidence - Pairing with developers to implement the integration tests - Defining and automating cross-service tests to verify end-to-end user journeys or data flows. - Performing additional non-functional testing such as performance or penetration testing So should testers know how to test APIs, and write API integration tests? Heck yes! This will help them pair more effectively with developers to implement the most effective tests possible. But should they be the only ones doing it? Not so much. It’s a team effort, which is why effective 3-amigos sessions are so important. Collaboration, as always, is key. What do you think? Let me know in the comments! #APITesting #SDET #IntegrationTesting #Microservices #DevOps

This was a fun podcast to do! Thanks Joe Colantonio and Scott Aziz for the great interactions and reflections on a very interesting topic!