Hi. Everyone I've never come under stage to music before that, makes me very very happy I also. Can't see a lot of people because the lights are in the way so. I feel very much like a rock star which was what I was always supposed to be, anyway. Yes. So thank, you for all dragging, yourself away from the fish and chips to come and hear me talk about, the. Automation breakup I don't know why they keep let, me come to speak here at sea comp because I spend. Most of my time trying to convince you all to stop using selenium-webdriver But Here I am again so. I'm, going to be exploring. Two different, questions. The. First theis is that how, do we know that the, checks, that we've created are, valuable. And useful to us and then. The second question that saw comes that sort of stems from that is. If. Our checks are not valuable, how. Do we go about, identifying. Valuable. Checks. What. I'm going to do is, I'm going to share some some ideas, some. Techniques show, their code maybe, even get it running who knows. But. Essentially, all of this comes out of a. Mindset. A namespace, that myself, and Richard Bradshaw, who speak it's morning. Called. Automation, in testing and we. Believe that in, automation and testing we should use testing. Automation to support our, testing, so. Part. Of this is this, analysis. Of our checks to see whether or not they're, of use to us. So. Yeah first question how do we know if. A check is valuable, I. Thought. The best way to kind. Of demonstrate, this, and, also I struggle. Sometimes with talking, about full stack tests, and to end tests, they kind of mean different things to different people so. What, I'm going to do is I'm actually going to demonstrate, what. I see, is the sort of common pattern. Of. Tests. That will checks that are written in, webdriver. So. My. Check is going to focus on a, specific risk it's. Going to focus on the, fact that user can log into an application. This. Risk is quite sort of abstract, quite high level. But. Will sort of dig into that a little bit D in more detail little, bit later yeah. I'm, basically. Written something that, focuses, on whether. Or not a user can log into an application now, I'm. Working, with. An. Application, that I've built called. Restful, Booker platform. That's. A sort of free to use open source project, where you can practice test, automation against, there's. A version of it on automation in testing, online but. I'm cheating, and I'm gonna use mine locally, because I don't trust conference, wi-fi's, sorry. Okay. So let's, talk very briefly about what this does so, to, start off with, we're. Using webdriver. To navigate. To our home page. Once. We've got to the home page it's gonna click on an admin, link it's, gonna find it click on it which, takes me to a login page and, then, I'm gonna fill in the username and, password click Submit, and then. I'm doing just like a final, assertion. Here, just to say do, I see the room listing, page, which. Means that I've logged in now. For. Those of you who can see the threat sleeps, please. Don't, panic, they're just here so you can see the script running. This. Is not something I would normally do, but. Let's give that a run so we can see what it is they're actually trying to test I think across this works the demo gods, are good to me. Cool. So it loads up the home page clicks. On the admin link. Fills. The details in checks. That the room, listing, pages there and it passes lovely, fantastic. So. As I say this is a common. Pattern common. Approach I, see. To how. A. Lot, of those do test, automation or. Automated, checking. Now. I want, to take. A step back and I actually want to sort of ask that question is this, cheque valuable, is. It, something that I want to be running regularly, and to. Help me determine that in. Automation in testing we've created this, series of characteristics, like quality characteristics. Ways, in which we can judge, whether. Or not a cheque is of value so. The. First characteristic. Is targeted. So. I want to ask myself is this cheque, targeted, so. Bring it back to that risk the, user can lock in that. Risk. Is actually quite abstract, it's quite high level it's, very much focused on the flow of, being able to log in it's. Not necessarily. Targeted, at specific things that occur inside the product, so. Say for example. During. That user login flow there's. Stuff going on in the back end but. I'm actually driving everything through the browser level so. It's not necessarily, the most targeted, thing because if, I'm doing everything on the UI layer and something happens in the backend I'm. Not necessarily gonna get the best feedback. And. Also talk about that more in a minute. So. The next thing is is it reliable. So. We want our checks to, be non. Flaky, we don't want them to be flaky at all and we want them to be deterministic, until. The product changes. That's. The value there that's you know if a product changes, and that check fails that's.
Sort Of triggering us to sort of explore. The system to find out more so. If I end up in a situation where my check fails and I roll my eyes and, I go oh for, god sake the checks failed for the millionth time I better go and fix it only, spend hour and a half trying to fix it to go oh wait. No, the products. Broken, the, check was fine it's the products broken or if. I use that awful. Plugin for Jenkins that makes me run the, test three times and, then pass on the third time if the other two failed I'm, sorry if you've got that in your tool set you need to remove it now. But. That, sort of stuff states to me I don't trust my checks. They are not reliable, to me if I don't trust them they don't have a lot of value because they, should be there to help me trigger other testing, activities, and. Then. We have informative. Is this, check that I created informative, so let's go back to that issue with the not. With a check not being very targeted, so. I'm. Running my run. In that check it's. Interacting. With the login form it clicks, submit and. Back. Ends not working for some reason now, I could tell you for a fact because, I developed, that application, that, I did not develop it very well, so. When you click that login link and the backend failed back-end fails nothing. Happens you just get stuck with the login form that's. Not necessarily, telling me anything about what's. Going on in the backend so. It's. Not very informative so. We want to mean making sure that we give. Our robots. Or automate checks of voice we want them to, give. Us as much detail as possible so, that we can you, know get started, with our other activities so. Whilst. It might not be targeted I could still think about like throwing some logs in there some screenshots that sort of stuff but, not, massively informative. Then. Is it maintainable. And. This is this tends, to be the topic that we talk a lot about in the industry about making, sure that our code is not brittle, that we use. Things like dry principal, you, know name our methods and our functions, well and, the. Fact is that it's clear it's readable it's legible and. I. Would say that. The. Code that I've created I've, sort of followed this or typical. Page objects, pattern. Half. And half I'd say I think it is maintainable. But. It could certainly be improved upon and, then. There's finally the speedy. Now. Speedy is an interesting one because again.
When We talk about speed we tend to talk about it in the context of how fast to our checks run you. Know should we paralyze, them so we throw more resources at, them but. Speed really, should factor in the whole cycle. So Richard and I like to say a failed check is an invitation to explore, and. The. Check that fails is the starter that exploration, is telling, me that something's not right in that part of the product and I need to go and look over there now. Imagine. That scenario in, which the login forms just stuck, there it. May take me an hour, two. Hours, to. Actually, to. Actually, find. Where. The. Problem lies in, the product that's, just two hours of finding the problem before even trying to solve what the issue is so. When we factor that aspect, in the speed is actually quite slow they, don't have if they don't have very good feedback that, I can't react very quickly to them, so. This makes up for an, acronym called trims. We. Were gonna go with Stremme but, we thought that was a bit aggressive and it might you know, encourage. A few consultants, to come in with weed whackers or something like that so a little. Gardening joke there for you, yeah. So trims targeted, reliable, informative maintainable. And speedy so it's. Not very targeted it's. Kind. Of reliable, the system's not changing, in this demonstration, but. It is dealing with a complex system with lots of different things that move and change if. I'm only focused, on a specific part, of the application but I have to turn everything else on those. Are all things, that can contribute, to the. Failing of my check is. It informative nope. Is, it, maintainable, I'm gonna go with yes but I'm sure you probably will all end up looking at my code at some point and have some things to say and it. Is it's speedy it's, not, so. This, pattern, that we see typically, that's creative, with our automated checks. That. We try and do everything all, in one go this sort Big Bang approach full stack check test.
Everything At the same time it's. Not necessarily. Going to give you the value that you're expecting, to get. So. If it's not necessarily, the right thing. For us how, do we go about implementing. Valuable. Checks how do we identify there. Up the opportunities, for them and then, how do we go back implementing, them. Well this is where task analysis, comes in, so. Task, analysis. Richard. Put me on to task analysis, and from, some work by a chap called Rob Sabourin, who, talks, about the task analysis within, the context. Of testing, in, general but we sort of we, realized, that an. Activity that we were doing. By. Ourselves was a sort of a form of task analysis, so. I'm going to demonstrate it's like a model. Of how. We might approach this typically. Once you've done this a few times you start to internalize it in your head because, you start looking at how the system works, and throughout. The layers and throughout the different components, but. For. This demonstration. We're going to show you a visual I'm going to show you a visualization, of how it works, so. What is task analysis, it's, essentially, it's the taking, and, act a tile. Script sort of abstract task and breaking, it down to its different, parts so for example, we could look at the sort of process, of making a cup of tea and breaking. It down into its different parts so we've got the section where we're focusing, on. Boiling. The water, we've. Got the section where we put, the tea bag into the mug and if you're wrong, wrong. You put sugar into it you do not put sugar into tea this, should be your main takeaway, of this talk do, not put sugar into your tea. But. Yeah we can see we can break down the different actions, that we do to make a cup of tea, we. Also could, go even further we can get quite granular, with this we could look at the point in which we turn, on the kettle what. Different apps what, different tasks, are occurring inside that, kettle, so. There's always this balance of trying. To hit, the right level of granularity, and. You. Know you don't want to go to too much detail sometimes, because, you'll, end up with reams and reams and reams of different tasks, and which, become, hard to process but. You don't want to come so abstract, that you end up back in that original position, that you're in. Also. They. Add the milk after, after. The hot waters gone in so that, argument settles, as well. Again. The. Important things to take away is how to make a cup of tea. Okay. So like I said we. Created a model to try and sort of represent, how this task analysis works, in our head so, rather than making a cup of tea we're thinking about how our products, work we. Can look at something like that successful. Login flow like. What did that user do what actually, occurred in the system, and. We could start mapping it out so.
There's A lot to sort of capture in this model here first. Of all I should talk about the bit of May the left-hand side see. My left. But. On the left-hand side there's. An act there's, an act that we would do before this or a couple of different, exercises that we would run before this if. We're to create, valuable. Automated. Checks if we are to be, strategic with, our automation we need to understand how our systems, work we, need to understand the testability of these applications. As well we need to explore. That information. Gather, it all together and try and make sense of it and we. Could do things like modeling, to help model, the system architecture to. Take like a snapshot to see how this system works, how, these different pieces connect, to one another. So. From, those acts and, I've. Resulted. In these four, blue squares on the left-hand side and they, each represent, a different component. Part of, the. Application, that I ran that test against earlier so. We have the UI which, is the. Stuff in the browser that the user can see we. Have the JavaScript, and. We've. Added that in because this application uses react so. React, is doing quite a lot of the heavy lifting in terms of building the actual the, visual components, we. Then have the API so we're moving to the backend we've got a web api, but. Then inside that web api we have service, code because. The web api i, like to sort of sometimes think is than there's like the bouncer, you. Can come in with those shoes you can't come in with those shoes that. Sets the parameters of, what. Information can come in what information, can come out but. When that API is triggered it's actually going to defer, some of that work to. A service, layer this, is why we have the concept of like controllers, and, and service. Layers within our API to the controller triggers, the, service code so. These are the main. Component. Parts of my tech stack within. The context, of the successful, login flow if I had multiple api's I might list, multiple api's, down that left hand side if ID databases. I'd list those so. If you were to do this you, have to spend some time understanding, how your products work and how, they hang together before, we could capture this then. You'll notice there's the blue lines in between and, these are the seams, the layers the. Interfaces. In which data. Information. Triggers. Flow. Across so. A common, one that we all tend, to know about is HTTP. Because that's something that happens over, the network but. We could have ones in which when, we press a button in, the browser that. Triggers, something in JavaScript, there's, a. Unseen. Layer or an unseen divide there between how. We, trigger. Something in the DOM and how that will actually fire some code off for us and, then. The same like on the Java side a lot of the the, unit checking stuff we do we're trying to emulate, how Java. Objects, trigger other Java objects or methods. Again. It doesn't really matter what language this is in so, the fact is is that we have these small individual, parts that talk to each other and then. Finally at the top is the user so there is an interface, between the. Person's, eyes and, the. Screen they're looking at as well. So. A lot of information to take in there but, what. We can do once we have this all in place is that we can then start to map, how. The actual, flow works in our system of, login. So. We start with an initial State so that little green dot there is just telling me some, initial states that I want to be in because I don't necessarily want to capture everything. Within, this task analysis, but you could do and you'll. Be surprised, how how. Long they get so. This is more of a stylistic choice that I was trying to fit everything into one slide it was getting quite compressed, at one point but. Yet the green dot talks about sort of initial States so single page app code located, and loaded. Into browser. Poorly. Worded but really should be the home page is loaded.
And. Then the current state is I'm not logged in, so. From those points let's take, those different triggers, let's look take those different steps through, the login flow, so. First of all the. User is going to click that login, link or that admin link at the bottom of the page which is really hard to find and I should do, a better job than making that more visible but there we go but. You click on that link and that actually triggers react so, react does some. Magic. I think, I. Think that's how react works it's magic isn't it it's like they'll pick see elves in you yeah yeah good I'm getting some nods definitely, magic it's been confirmed but. Yes I click that link and that triggers, react to build the component, login page so that's building all the HTML run, in a bunch of other functions if it needs to run them and that, presents, us with a login form so the user now interacts. With that login form fills. It in hopefully, puts the right credentials in, this. Application, is two three years old and I still put the wrong credentials, in it's quite shocking. And. Submits. The, credentials. Admin and password because, this application is also very super secure and. Click. Submit, submit. Triggers some JavaScript, Java Script sends, an HTTP, request with, the credentials to. The earth API earth, API. Says oh thank you for those details. Passes. Them turns them into a Java object that. Can then be consumed, by, the, service layer so, the service layer is triggered off the, function takes you, know oh it's, admin password, they're, the correct credentials. And. I'm going to create you a token that you're going to use later on in the application, so. We've got all the way down we've got a bubble back up now and so. Once, the APR is complete got that token created. It's. Going to send a response back with, that token inside it sending an HTTP, response back which, Java Script goes hey thank, you I got a token that's fantastic, I'm gonna login I'm gonna flank, myself, as logged in and being. Flagged as logged in call. Some other react, magic, to occur and that. Causes the broom component, to render. And. Once that room component, is rendered, the. User can see the room. It's. Quite a bit to cover, so. When. I created this task analysis, this was the simplest, thing I could do. If. You were to carry out this task analysis, and some of your systems it would be much, more up and down lots. More things. Happening. Now let's, go back to that original check, that we were running that's. Supposed to be checking for all those different points those different triggers, that. Occur. So. As I say if something like check credentials, create token fails it's, going to take me a while to work out what's actually going on and react to it. But. By. Mapping. Out the different, activities, the, different triggers that occur we. Can then actually start to dig into our system more, so. We can now start thinking, about risk, again, so. Rather than that big, abstract. Risk which is the user can log in we. Could start targeting, those individual. Dots we, can start thinking well, you know what, risks, could affect those specific, dots. And. That's where we start to identify valuable. Checks. And. What I want to do is I want to demonstrate. Four. Different checks so I could take from, this visualization, and then I'll show you how they're implemented, and we'll. Give them a run and fingers. Crossed the. Internet still holding up and. Ok, so. You. Notice there's a bit of changed out to this model first. Of all and I'm, thinking, about a very, specific risk, now not thinking about the whole successful, login flow I'm, talking about one specific risk.
That Could affect the login flow and that, would be something, like the, login form is not rendered correctly, so. All I care, about is that when. I'm presented. That mocking form as a user that I can see in the browser. It's. All correct, and it. Works in a way that allows me to sort of in. Release look visually appealing. So. From. There I'm, thinking about visual check, and. The reason why I'm thinking about visual check is you'll notice now I've added in two, new icons we got robots, and a little magnifying, glass. So. When, we automate, we are replacing, that person, or that thing that is interacting. With that part of the system with. Some sort of robot so. When we use Liam, webdriver we're typically. Removing. The user out of that and getting getting, that tool to interact with the broke browser instead so. We put this little robot in there because that's impersonating. The user, created. A new actor. So. That, robot is going to do. The absolute sort, of bare minimum, here it's just gonna open. Up the login page to trigger off that build login, page component. And then. That's. Going to give. Us a rendered, form view in the browser and, then. The little magnifying glass is at the top there is because because I'm focused, on how the user would interact with the system I probably. Want to assert on that level as well so. A user has eyes they're, going to look at it so, this is where something like visual testing or visual checking can come in. So. Oh. And. One other thing is well I should probably add before I start showing you the toys is that. Notice, how all those other points are grayed out and, that's. Because I'm focused. On one specific area, of the application I don't necessarily need. The rest of the application up and running I don't necessarily need the backend up and running I could. You know talk, about things like mocking in dependency, but, for now all i care about is is that this, specific area is tested and the rest of it we can deal with at a later date and we'll sort of cover that as we start to build all these different checks up so. I'm just, focused, on. Spoilers. I'm. Just. Focused, on how, the. Page renders, so. Let's look our second example. For. This I'm using applitools. Because. It's something I've used commonly. In the passed and I'm. Not trying to endorse any specific tools and stuff these are just things that I feel comfortable with and the. Point is is that. The. The. Point at the point on which I was trying to build that check the area the risk that I'm focused on helps dictate which, tools I want to use so. I chose applitools. The. Webdriver script or the webdriver code Slean web trader code there is just that line I just need to open that page because, the application, is all up and running so, I just focus on that page and then the rest of it is applitools. Doing, it's, definitely. Doing magic, to. Do some screenshot. Comparisons. Okay. So let's give that a run. Here. We go. So. We're still working in that space where we're, interacting. With the browser but. I'm not necessarily manipulating. Lots of form fields, or, adding. In any data or doing any state. Setup or anything all I'm doing here is loading. That page up and doing, a screenshot comparison, so, we can see that it's failed that's. Good I was hoping for that this, is all going very well. Now. If we go back to my, dashboard in applitools we can see that we have a unresolved. Test. And. In here, did. He did he. Little. Highlight buttons because it might be quite hard to see out the back see, if I can zoom in a little bit but we can see these little marks here that, show me that there. Are spin some changes, between the different, visual. Comparisons. So. That. Doesn't necessarily tell. Me how the API is behaving, it doesn't tell me, whether. Or not the front-end is talking to the backend potentially. Depends which API you're interacting with I'm just, focused. Specifically. On how, the form is rendered. So. That brings us to our next one so. This time we're going to go down, a layer we're going to go down into the backend so. Now I'm focus on a risk that the, off API, process. These requests, properly, and sends, the right, months back.
And. This is what we sort of typically see with API checking. Now. Now, it's the robot and the magnifying, glass have moved down to that HTTP. Layer so. The actor, or the, the person, I'm the person or the thing I mean personating. Has, changed, it's no longer the user is, actually JavaScript, because, javascript, is normally, responsible for, sending that HTTP, request so. I'm going to build a tool that, impersonates. Chase it personally. It's JavaScript by, sending an HTTP, request and. Again. I'm, going to send something via the HTTP, layer something. Else is going to bubble up and that's where I'm going to do my assertion, that's where my magnifying, glass is going to be it's going to be what comes out from that layer as well, so. Let's see, that one in action as well. Oh. It's quite. Ok. So this. Time I'm using a tool called rest, assured. Again. No preference just it was something that we could quickly and easily put together to. Show how I would implement this check so, the first thing I'm doing is, I'm creating that payload, with that super, secure username. And password. And. Then I'm doing I'm. Using rest, assured to set, content, type ad. For that payload in and then I'm sending a post request to the, login endpoint, and then, that stores me some details back in a response object and then, I'm just going to say did. I get a status code of 200, and does. It also contain, the string token. In there, normally. I'd do something a bit more sophisticated with. This to make sure that the actual payload. Matches. What I what I would expect but. I was, feeling a little lazy and it was late a couple, of nights ago writing, this code up so, you. Know don't. Crucify me, for the for, the bad assertion. The. Point here is is now that when. I run this. No. UI no, browser setup. Nothing, just. Focused. Specifically. On the API, so. For, those two examples I've created checks, that are much more targeted. So. If one of those fails I know now, that specifically. Some things either failed in the front-end or something's failed in the backend. There's, an acronym I like to use which is - - where. You ask the question are you testing, the UI or testing, through the UI, because. If you're testing, risks. If you're interested, in testing or checking risks that exist in the, backend. And you're doing it through the UI you're. Adding complexity, in there, which. May affect, reliability. And you're. Also not necessarily, making them the most informative, with. These two checks that I have now they are much more targeted they're. More reliable, because I don't have complex. Bits of system being set up they're. Informative. Because if. They fail I know. Clearly. I know. Clearly where to look. They're. Maintainable, as well because what we're going to notice is we go through these examples as well it's the amount of code that needs to be written is getting, less and less less, code, should. Equal, more. Maintainable but not always the case it depends how well you've abstracted, you're awful code. But. The key is their speedy because, if these do fail I know specifically. What has failed and I know how to react, to that I can start focusing on the problem straightaway. So. I'm going to wrap this up with two, more examples where. We're. Going even further we're going into the, unit level so, we're starting to identify the potential, for unit checks so, for this one I'm just focused, on whether or not the. Token is created correctly. And. This time I'm actually the actor or the thing I'm simulating, is the service, layer of my API that's, that, service, sorry the controller, layer of the API the controller, typically, triggers, the, service, code but. What I'm going to do is I'm going to use something like j-unit to, create, a unit check that's going to trigger that, process, for me, so, go. Back to our. Code again. And. We're down to four lines of code let's, see if we can get this lower but. With, this one we're, just, instantiating. The, an. Object. From. The class that it, handles the, whole checking, of the credentials, and generating. The token so we can see here decide. On token generation, sitting. In these, awful. Credentials, and it. Returns. As a decision, object and, I'm, just asserting that it, has, a result, of true so true it you, know it's, valid, credentials and that it also includes. A token, that I. Can send later on. So. Let's give that a run as well. So. That took 10 milliseconds, to run so. Fast, to run faster. Quickly react to as well if that fails, I know specifically. That method, and has. Failed or something.
Within That method is felt and I can react to that. And. What we've done here is we've we've sort of. Douve. Divin. Never. Never know we know what the right. Word is for that we went lower. Into. The application, we went further into the backend but we can apply the same sort of rules to. Front-end. As well so. As I said we're using react, react. Is a highly, testable, application. Or code. Base api, sdk but. It's highly testable, so as, we saw demonstrated in the accessibility. Talk that we saw this morning if something, you saw, that we. Can actually isolate these. React, components. We can render them headless lee and we, can then. View, the output of that as if it was HTML, and make some decisions here so. If, I'd have had time I would have loved to put that accessibility, example, in here about how it would work in in the in the wider strategy, but. For now my risk is that I just want to check the lock in hTML, is correct, so. When we were looking at it on the render level we had complained, around not just the HTML but the styling as well whereas, this time I'm just like is the semantic, structure of the HTML correct. So. This is a unit check but this is something that's done in the UI layer. So. For. Our final check. Let's, move over to here. Although. I've got it down to two lines of code I think I would, be taking, the mick if I got it down to one line of code I think you'd probably all chase, me out of here with pitchforks, and flames, or something like that but, all I'm doing here is. Admittedly. Some, setup, is in a different different. File. That's being imported, in but, essentially what I'm doing is I'm using a tool called enzyme, and gest is my runner I'm. Using, enzyme, so I import, my reactor, component whose enzyme, to load the component, in and load. It up well. It loads in into. A small little Dom which, triggers, that whole react process, to turn into HTML, that. HTML is dumped into my login component. And then, I'm using an assertion here where I'm saying expect, the. HTML. To, match a previously, accepted, snapshot, that HTML, so it's similar, to what we saw in applitools, but this time we're doing it on a. In. Terms of sort of some code or some you. Know some string data, so. Let's give that final, one a run, I don't know how well we're gonna be able to see this because it's a dark screen oh. Thank. You thank you lights will make it all much, more intimate okay, so there. We go that's our final check there so. Now we've seen it. Checking. That the HTML is correct and just to, sort of add, a bit to that because that's just basically. A, screen. Rendering. Some staff if, we go to snapshots. We, can actually see the HTML here, on the right-hand, side that's, all being captured. Okay. We've taken, one. Big. Check and we've broken it out into two into, four small ones and, some. Of you might have that what I like to call this sort of software tester, spidey-sense. The. Fact is is that if, we're focusing on specific, areas we're ignoring, other areas, and we. Need to be wary of that, and. That's, good that's good to have that spidey sense because that's telling you that there's potential, checks that could be, identified. In creating other parts of the application that are still targeted, on specific, areas, but. What we can do is we can actually combine all of these things to create a collage, of different checks, and we. Can actually build. Like an create a build pipeline, or. You. Know just a batch script or a bash script that just runs these different, checks in a specific order. And. What this does is this can create a chain of trust, so. If I'm to run my API, check to make sure that the request and the, response is. Behaving. Correctly that's. Not necessarily, the most targeted. Thing if something. Fails within, the service layer but. If I've run a previous, or I executed, a previous, run of unit checks that tell me that the service layer is behaving properly.
In. Its individual, parts when. I come to running the API check and it fails, I've. Already got some information there that says to me well it's not necessarily, how the codes written it's maybe how, the code interacts, with other component, parts maybe there's some miss, configuration. In the integration, or maybe the app isn't up and. We can do the same thing with on, the JavaScript. Layer so I could, say. Does. The HTML, is the HTML rendered, correctly you can run that check yeah brilliant, but, the visual check failed. Well. It's not necessarily, that the hTML is wrong it's that maybe the styling, is wrong, so. We're. Creating targeted. Informative. Checks. That, can make a speedy because we can react to them quickly because. They're actually building on one, another in terms of their trust which. Means I could bring, that first original, check back into the mix and that could become a full tax smokecheck so. Rather than it being something that says the. User logs in successfully. The, risk of that original. Check that I created is the front-end can talk to the backend and, that's all I care about, but. I'd only ever have one of them because, I just need to make sure that the the, UI can, talk to that author API. So. To, wrap, up I encourage. You to all go back and ask, yourself are your checks trims are they targeted, reliable. Informative, maintainable. Speedy if. They're not then. Try, this task analysis technique. Try. And understand, how your products work what, are the different component, parts how do they connect to one another if, you can't, answer that because it turns out your app is really complex or. No one wants to talk to you you have bigger problems than, whether, or not you can design code checks yeah. You, have organizational. Things that you need to get to therapy, about quickly. But. Yeah learn. About your systems then, put, them in this sort of grid based system or model, them in some way you, know draw your finger around the model and try and understand how they, how this flow this, user flow hits all these different points, once. You have these points use, that as an opportunity to identify targeted. Checks the. Fact that you've chosen, these points will dictate, to you or lead you towards specific toolings, like it has for me but, it'll also result. In much more valuable checks and. Then. Finally. Once you've started to create. All these different checks I like to think that a successful. Regression. Checking strategy for me is not. One big monolithic, tool but lots of different little tools they're all connected, to one another all prodding. And probing their application, in different ways but. All of them come together to give me the full picture and they, rely on one another to give us feedback so. That's. It I have. 40, seconds left. Which. Is 40. Seconds more, than I had last night so, I'm. Happy with that and I, will be at the office. Thing. What it's called but I'll be there if you want to unsend your questions but, if you want to learn more about automation, in testing check out automation in testing calm and. Examples. Of the code that I have here, they. Exist, within the, restful book a platform repo I encourage, you to have a look at them there's, much more in there as well it's a rich. Bed of stuff, to tell me that I'm doing wrong but, thank, you Cheers thank. You Mark.
2019-10-25