Serenity Dojo’s Post

Transcript

In the next 5 minutes, I'm going to show you the fastest way to identify and document the most valuable scenarios and test cases that you need to automate and need to test in an agile context. My name's John Ferguson Smart and I help test this, become brilliant agile test automation engineers so that they can have more satisfying jobs and make a real difference in their teams and in their companies. And in every video on this channel, I'm going to be. Giving you concrete tips about how to implement agile test automation, agile testing practices in your own work so that you can grow as an agile to sort automation engineer. And in this short video today, I'll be showing you the fastest and most effective way that I know to identify and document the most valuable test scenarios that you'll need to test or automate in an agile project. So let's have a look. Let's have a look at how this would work with a really simple example. The simplest 1 I can think of, in fact. Logging on to an application. How would we model that using a traditional test scripting approach? Now typical test script might look like this. We have a list of the detailed steps we need to do to in order to verify this piece of functionality. So we launch our application, we enter the correct e-mail in the correct password. We click on login and login should be successful. Then we might have some edge cases in other different test group documents where we launch the application and to correct e-mail, enter the wrong password, click login and get an error message. We might have a third case where we end launching application into correct e-mail, wrong password or wrong. No wrong e-mail to passwords and the wrong password we're getting invalid credentials. So we have different test groups with. Some cases now when I look at this, it feels to me like I'm filling in an admin form for a bureaucracy, and I hate admit forms, so I don't really like this format very much. But more importantly, how much effort does it take to write a test script like that? Takes a great deal of effort, especially when it's a more complex phase where you've got actual real business requirements. It takes a lot of effort to get this done. And how much value are you getting out of this effort in modern? Application approaches. The answer is not a great deal. We can get the same value from much simpler approaches, which I'll show shortly. Because the reason we do all this detail is this approach comes from a bygone age. This approach comes from a time when testing was done by a separate team, even a separate organization, by testers who are not familiar with the domain or the application had to be taught step-by-step what they need to test, and that had to be written down and. Documented in great detail. Very bureaucratic, slow, cumbersome approach. Suitable for waterfall when you've got months to do your testing. Not suitable for agile at all. In an agile approach, we need to be much more nimble about how we go about this whole testing business. So let's see a better approach. In an agile project, in an agile approach, I would approach things very differently. And there are much more efficient, much more collaborative ways of defining your test scripts and your test cases. You see, in a traditional approach, testing is very much an isolated, siloed approach. And those test cases are written by the tester, derived from the requirements separately. But it's basically the testers business. It's by the testers for the testers. That that is not the sort of collaborative approach that gets things done effectively in an agile context that actually slows down your team. What you really want to be trying to do is collaborating more, getting into the earlier stages of requirements discovery. When you first get the user story, when you first get the feature that you need to implement, you start to have conversations about how you're going to implement that, what the conditions are, what the acceptance criteria. And they are the heart of your test cases. Now if we look at this example, we go back to our login example, login securely, that's our user story in order to allow customers to access their data securely and to prevent unauthorized access. And customers need to be able to provide valid credentials. Now any user story is going to have some acceptance criteria and that is where we are going to start. So our first acceptance criteria might be simply that. Customers need to provide valid credentials to access the site. And when we do example mapping, we have a conversation, we try to identify the positive and negative examples for these acceptance criteria. So for example, for this particular acceptance criteria, customers need to provide valid credentials. These are our acceptance, our examples. So one we're colon provides valid credentials, but the one where is password is wrong, the one where he is. Username or password is blank. We might have another continue like this one where his his username is wrong and so forth. So we'd list the different examples. We can do this really, really quickly and we don't need a whole page of Word document with lots of fields to fill it out. We can document this really, really quickly. And generally speaking, that is sufficient for most testing purposes. That is sufficient if you're testing within a team within a Sprint, that is largely enough. You don't need to do all the extra. Effort of writing out detailed test scripts at rest. All that details, all that bureaucracy is generally waste in an agile project. But the other advantage of this approach is when you have these conversations, you can start to identify other requirements and go further. So all that time we were spending writing out those details, test cases, we could have been having conversations say, OK, well, what else can happen? What other acceptance criteria are there? We might have, well, what happens if our customers are using an authentication app? So we might say, OK, well we need an example of Facebook, the Facebook Authenticator, Google Authenticator. Or whatever other authenticators we need. And we might say, well, hold on, what if they're using something like a Face ID on an iPhone? And so we might come up with some examples and counterexamples there with the one where Isabelle authenticates using Face ID, the one where she can't use Face ID. So there has to be some sort of backup system. And we might even take that requirement a little bit further and say, well, valid credentials to access their account. What does that actually mean, Ken? What happens if you use it gets blocked. So we might have the. Now another edge case when we're Bobs account is blocked, so we can get a lot more coverage done, a lot more test cases done in a much smaller amount of time and much more focused, highly productive, high value effort getting all these test cases done. And that is generally enough. That's all you need for your coverage in an agile context. So it is by far a much a far better method than writing all these test scripts. So I never write test scripts. You can ditch the test groups, don't worry about the test scripts. I would strongly recommend having a go at this. It is a much smoother, faster, more effective way of discovering and identifying and documenting test cases than what most people are doing at the moment. Hey, if you found this video helpful, there's a lot more material where that came from. Don't forget to subscribe to the YouTube channel if you're on YouTube and check out the Agile Test Automation Secrets group if you're on LinkedIn. And if you like this particular topic about coming up with test cases much more effectively, much more quickly, and with a lot more impact than make sure you check out the links underneath the video. Where there's a course on Ajo requirements discovery, that is the go to course you want to do if you want to understand this stuff in more detail or check out the BDC in Action book those if you prefer to read. There's a lot more material on all of this stuff and a lot more in there. So yeah, I hope you got some value out of this. Thanks for watching.