 for coming so early to a 9 a.m. No, it's not that you can. I appreciate it. So yeah, first I wanna ask a question for you guys. Who in this room considers themselves a developer? Okay, it's like half the room. It's just helpful to know as we go through everything. Another question for everyone. Who has ever had anything ever break on their website? Okay, everyone, everyone. Okay, not surprising. Now let's go a little more specific. Who's ever had a contact form or a checkout break? Okay, still good amount. All right, perfect. And who is now either terrified or tests their checkout and form all the time manually? No one. Okay, that's what I expected. Don't blame you. I don't think I do either, right? So that's what we're gonna talk about a little bit today is how can we do certain testing called Indian testing to, sorry guys, I thought it wouldn't. Michael, can you grab my power cable? Thank you. Indian testing to essentially go through, test your contact forms, test your checkout and do this in a way you don't have to manually do it and you don't have to worry and you can sleep at night, right? So that's the goal. But before we get into that, a little bit about myself, my name is Matt, I run a agency here in Atlanta and we're a web dev, WordPress agency and the only reason that's at all relevant is probably like a lot of you, we have a lot of client sites. They can have different configurations. We sometimes inherit those sites. You learn the good and the bad of all those different sites and over the years, something that has come up kind of time and time again is how do you handle websites in a way to prevent them from breaking and then if they break, how do you know if they break? Ideally without your customer telling you or calling you, yes. So that came all into fruition as an agency because we started looking into how can we test our contact forms, our checkout, really anything from the perspective of a user experience or user story through the whole process and so we started kind of building our own called CheckView. I'm not even gonna talk about that one today but really today's talk is to just tell you guys what I've learned. I'm not gonna pretend I'm a QA engineer. If you are a QA engineer, I'm so sorry you're here. You'll either be telling me I'm wrong which is very, could be true or you're gonna be bored out of your mind. This is really meant for either developers who hate dealing with QA or agency owners, managers of websites that you want to start to learn a little bit about just how you can test your site and make sure it's performing. All right, sound good? Cool. Let's go not to that one. I'm learning this remote I believe. Looks like, all right so starting with just a little list of what can break on your website? What can cause it to break that sort of thing? I don't think any of this is probably surprising to anyone of all the different things that can break your website. Obviously any sort of theme, plugin, anything with your hosts, you might say I never wanna update my site ever again. It's gonna run perfectly but as you probably know your host will have PHP updates, et cetera, MySQL updates, that sort of thing and you'll have to essentially deal with that eventually. Now on top of that you can have just more updates from your developers or content managers can break things, changing settings, that sort of thing. So there's a lot of things that can break on your website and this is just kind of a short list and that's not I think a bad thing from WordPress's perspective. For example, we use a lot of third-party code, not everyone does but a lot of people do. Either you're extending WordPress with your own code or you might be using third-party code which could be a commercial plugin or you pay a developer and that's the beauty of WordPress is you can extend and we have a huge community. But the other side of it is that we're using a lot of third-party code which means it couldn't really all be tested. There's only so far the developers can test that code. They can't test every single plugin combination that you're necessarily going to use on your website. And so that's why things like this can happen, unintentional breaks and that sort of thing. And you might be saying, okay, well I do a ton of stuff to actually make sure we know if the site's breaking and this is just like a short little list like how many people in here do uptime monitoring of their websites? So most people and how many people do any sort of visual regression testing? Has anyone heard of that? Visual regression? It's just basically where you take a screenshot and you compare has the site changed and that sometimes just shows if something breaks. You might be doing things like that. Page speed, security scans. You might even be using reporting tools to tell you if your SMTP for email is down, that sort of thing if you're going really fancy. But one thing that's often not brought up is what we're gonna get into which is really testing kind of the whole shebang of what is that whole process because this leaves gaps in what is actually the fundamental reason for most websites which comes down to some sort of contact form or a checkout. It might be a learning management system login or a course, something like that. So essentially that's why there's other things that you typically wanna look into. So I've got like one pretty typical fire scenario you could say and this is just a good example. This is a good example but obviously it can vary. So one I've got here at 8 AM it's a little hard to read but at 8 AM developers may make updates to live. They might have even done some testing but they maybe didn't test through the whole process. They just said, hey, the site's up, it looks good. Seems reasonable, right? So then around 8 30, customers start reporting that they have checkout errors. And of course, it goes through customer service and customer service like I don't know, I can't get screenshots from these people. They aren't technical. So then the developers are struggling. They're trying to figure out what to do. It gets passed to them. Maybe around 9 30 they actually figure out this is what maybe is going on. We're shooting in the dark but this is probably a good start. So then 10 they might patch it on staging and then by 11 which I think this is a pretty reasonable timeline. They actually get it live and that's if they're working that day, the right people. So you can see you've got a pretty big gap here and this is where when we talk about end-to-end testing a lot of this could have actually been prevented and even later in the process if it's not prevented a lot of times the developers can replicate the issue quicker because they could actually run a test based on what the customer feedback is. So that's kind of what the benefit is. And this is a good example of you might say well that's a lot of money and obviously it's gonna depend on your website size and your risk. What are you willing to risk? If you're not making any money on a website relatively or it's just not a very important website in your opinion, you may not be willing to do end-to-end testing. But this is a good example. Let's say you get 10 orders per hour average order value is $122.82. You multiply that just based on that very simple example that we kind of gave you can kind of and you have to obviously do that based on the 10 orders that gives you a good idea of what it's costing you. And that's obviously doesn't include your reputation just as a website or your reputation with a client plus the developer time scrambling customer service all that sort of thing. So in this way you can probably justify some amount of additional testing. And that's what we're gonna talk about even further is what's a reasonable way we could go about this that's not gonna cost $50,000 to do, right? So that's just again an example of how you could be burning money if you've ever experienced a site going down. And I mean I'll tell you personally I've had that happen. I had a client that they, it's a little different than this one but they were doing a TV episode and we didn't load tests where we test, stress test the server and they went down and I had to deal with those consequences of, they're like, well we've calculated what we lost. How are you gonna handle that? So this is actually good for you too because you can help reduce your risk and liability around that because you can kind of prevent this at least you have something to back up we did some amount of testing. But before we go into the actual examples of how this relates to WordPress we'll talk a little bit about the types of testing that you can do. And there's really three main types. There's unit tests, integration tests, and end-in tests. So typically depends but typically the unit tests and the integration tests are going to be done by the developers that are developing your software. Not always the case but majority of the time. The reason being is they need to basically go through and they can test certain things as a writing functions and code and make sure it's getting the correct output that they expect. So for example with unit tests these are usually very quick tests that they do when they write, let's say a plugin or something, a specific function you're just literally checking to see is this giving me exactly the value I expected. It's really good for bug testing but typically this isn't really going to look at the whole picture. It's really just like we're not going to release something that breaks a very specific function. And then they may go a step further and do integration testing and depending on the semantics of WordPress versus not WordPress because WordPress is kind of different with how they do some testing. They may be testing it against core, they may be testing against core WordPress plus other plugins in their ecosystem. So they're doing some amount of integration with other software essentially to make sure it doesn't break. Again, core is kind of a good example. They want to make sure it works in core WordPress. Let's say they build a plugin, right? They've done all their unit testing but they need to test through all of that. But that kind of leaves the last one which is end-to-end testing which is typically the hardest to do. It's the most expensive to do but this is almost always the one that falls on the website owner or the agency or whoever is actually working on the website after all those plugins get installed. And that's where you essentially test through the entire process. So you're going to go through and you're going to take like a user story or user experience and say, hey, this is exactly what happens from the beginning to the end, hence end-to-end testing, right? And again, there's no way that you can really rely on let's say commercial developers or you pay someone to custom build a plugin that they can plan for your entire experience unless they have access to all of that. And I think this is a point that often is lost in the community just because developers do an awesome job at this, the first two specifically. And that's why the software's gotten better over the years. The plugins are high quality and you don't see as many things breaking. But with that being said, the reason that end-to-end testing is important to do is, I mean, we're all running updates all the time, right? With 300 vulnerabilities typically a month, you then have the whole, well, do I run the update and hope it doesn't break or do I have this potential security risk on my website, right? And it's not an easy answer, but at the end of the day, a tool like end-to-end testing can at least give you some confidence compared to essentially just hoping that the developers are doing the best they can to test it. And this is just to illustrate essentially that typically end-to-end testing is going to be the smallest amount of tests ran. It's at the top. For that reason, that's not always true. But again, with something like WordPress, my opinion, we probably should be doing more end-to-end testing because we use so much additional code, especially again, if you're using an in commercial code because there's only so much they can test. Now, outside of the loss revenue I kind of already mentioned in your reputation. As I mentioned, it will allow you to be able to run updates faster. So you can actually set up tests, and I'll show you, you can set up tests like you could be running them and staging and going through the process of checking your user experience, making sure it works before you push it live. You can even do things like, hey, when I push it live, automatically run a test. So we'll talk a little bit about that. So it does give you some confidence. Now, with that being said, keep in mind that it's reducing your risk, it's not a perfect solution. It doesn't mean it's always going to catch every situation. You're just trying to kind of pick up typically the baseline examples of whatever your business critical functions really are. You can have more like a very basic smoke test, which is where you're just, hey, does it look like there's an issue and it's a very basic test, but you can make a more complicated one. It just takes longer. And then it can have benefits for even developers building plugins because typically when you're building plugins, you have to build specific tests for, or test classes to actually test your code. And you can use end-in testing in that process. And that just gives you a little more confidence to test new functionality out and just see overall if it's working. Pretty obvious, but it basically benefits everyone to use this. For example, developers I talked about, but a couple other ones are content managers and stakeholders because from the perspective, it often falls on them that they need to make sure the site's doing what it's supposed to be doing, right? The developer is busy coding. They don't have time to be making sure the website's doing what it's supposed to be doing. So it ends up being that customers complain and then they basically are like the ones that get blamed for that saying, hey, why didn't you catch this? So this is a way even as a content manager or like I said, a manager of a website or stakeholder, you could do some basic tests like this. Obviously end users, it's huge too because their user experience is gonna get better and they're less likely to have bugs. So you might be like, okay, so you keep talking about end-in tests, but what is this really? What is an end-in test? So all that really means is that you're going through the user experience, whatever story you wanna define that as, that your application should be doing. And typically you're going to use some sort of browser to do that. So technically I could do an end-in test where I just fire up my browser locally and I go to my website and I type everything in and I make sure it works. And you could set up like an assumption where if I get the thank you message on my contact form that's where I decide that it's validated. Or you might take it a step further and be like, I want it to say it's successful once I get the email as an admin or the customer gets their confirmation email, right? So you kind of have to write up what that story is gonna be, but essentially then you're just going through with the browser to do that. And we're gonna talk about how you can essentially write tests to do that and then later you can actually just automate them so they run all the time and it's spinning up a browser for you. So this is a really simple example. I'm going to our agency site, I'm going to the contact form at the top, I'm entering in some sample dummy data essentially, I'm submitting that contact form and I'm just validating the text value here. Most of you have probably done a very basic end-in test yourself at least once, not knowing what it was. But the goal here is that we're gonna try to standardize it and make it actually part of our routine. As far as end-in frameworks go, there's a lot of them out there as we start to look into, again, building these tests and writing software that does this. So you can first kind of start with what requirements you need. So do you want to test with Chrome or Firefox, et cetera? Most of them will support different browser engines, not all of them do. The argument being that you're not doing browser compatibility testing here, you're just really doing a full end-in test. So you might decide the majority of our clients use Chrome, that's what we're gonna focus on. Again, all of this, the goal is to do a practical application for end-in test. If you're running a $1 billion company, you may have a much more robust solution. But the goal here is, again, to give you guys something that you can actually use. A lot of them do use different code stacks. All I'm saying there is there's different, basically frameworks that provide all the tools that you need to write tests. They can, for example, take visual screenshots. They can do visual regression testing. They can validate that it's running, all these sort of things. And they will also let you decide like what browser engine and plug-in to that browser to do it. So you can do it locally on your computer. You can also use like a cloud-based system where they fire up the browser for you. And with those, most of the time, the code's gonna be in something specific like a JavaScript framework, for example, or a Java framework. I know that sounds weird. If anyone knows Java, it's kind of strange, but Selenium is a good example. But most of the more modern ones will then let you write the test in whatever code you want. So you could write it in PHP. You could write it in JavaScript. You could write on Python, really whatever you want. You're just writing out steps. And the way, so everyone understands, I'll show it in a minute, is if you're familiar with CSS and ID selectors, that's all it's really typically doing is you're saying go to this page in this input value with an ID of name, type in this value. That's all it's doing is really selecting those and that's how it does it. And it can be more complicated, but that's how majority of it works. And you can set up things like conditions, like if this happens, test this, so you can create a little more extensive logic. You can set delays like wait for this pop up to load or to go away before you actually test my contact form for an example. And you can set up baselines and assumptions. For example, again, you could say if either this happens or this is validated, this essentially is either a successful test or move on to the next step. Most of them, the modern ones can take screenshots, even record that video for you. A lot of them will record your console. So if you're familiar with the browser console, it will record like any JavaScript errors that you have, any network data that's being passed because a lot of times if you find an issue, that's how you maybe are gonna have to fix. You're gonna either fix yourself or send it to your developer and be like, hey, the end-in test is getting this error. Can you figure out what's going on here? And you'll hand that to them essentially. And then you can do automated testing. That's essentially just where you schedule these tests to run automatically on their own, which we'll talk about. And then some of them can also do API testing with even mocks where you essentially get data back from like a fake API to get the data you need to run through the rest of the test. There are some limits to what these can do though. So for example, it's really hard for them to test anti-bot and spam protection because essentially if you're not running it yourself, you're using a bot, whether you know it or not, right? And we have all this software to prevent bots from running. For example, if you use recapture, there are ways that can get around recapture. One, like for Google recapture version three, you can tweak it where you can start to get a high enough score that may not trigger it all the time, but it's just not very reliable, at least for most people. You can also just bypass, you know, you could set it up in your software where if it comes from this server, this IP, just bypass this and allow it through stuff like that. So you kind of have to decide based on your situation. But that is one of the harder ones. Another example is payments. If you're doing like a checkout, it's really hard to test payments with a bot. Technically, you could do it before, but it's getting really hard because if I set a bunch of automated tests, my credit card processor is going to realize what I'm doing if it sees a pattern because it costs them money. And so doing real payments is a little harder, but you might use like a sandbox to do that. Like a sandbox payment, if you've ever used the Stripe payment gateway and put in test mode, stuff like that, you could do during in-din tests. That's an easy way. Couple other things that become a concern when you're doing this is it obviously creates data on your website, especially if you're doing on a live site, it may submit a contact form, which may affect your conversions and it may, you know, send it to your customer or to you when you don't intend it to. So you have to kind of consider those things. And then of course, if you're hooking it into like a CRM, it may send it off there. So there are some things you have to think practically what's the best way to do that. And then if you are working and you're using a browser-based setup with this, it's going to typically cost money because when you fire up a browser, that requires a computer, which means it's running all the time and you're paying for that. So it's like a whole nother server you basically have to pay for. And then because it's a headless browser typically, which means it's just the browser without the UI. So for example, you might be using Chrome. A lot of them, you can't set up like extensions. So if there is an issue with like an ad blocker or there's an issue with an antivirus, like I've had a good example where it took us forever to figure out an antivirus was breaking PayPal. And it wouldn't pick up on that. So there are some limitations there. Okay, so you might say, well, there's a lot that sounds nice about this, but this seems like a lot of work, right? A lot of money, a lot of time. So we're gonna try to go over some practical examples today of how you can use no code testing to do some of these. No code testing, you may be like, I hate no code. It's very limited. I've looked at it in other applications, not great. So, yep, thank you. No, that's legit. I think actually when I created it, see it doesn't look like this on that, but that's good to know. Thank you. Yeah, Michael, can you get the light? So with no code testing, essentially, these are just some examples of ones out there, but it really has opened up. Is that a little better? Hopefully, okay. And really these names don't matter that much. I mean, you can write them down. These are just, if you just look up low code testing, these are some examples. It's a pretty big industry now, but essentially if you're a QA engineer, you're probably, if that's a professional job, you probably hate these tools because they have limitations like all no code software. You're not writing, they can't do as much logic. You don't have access to the actual code. They're more just going to let you click through and you can say what steps you wanna run. But for a very basic end-in test, they're actually really neat. So for example, the first one on the list, Ghost Inspector, we're gonna talk about and watch a quick video of how it works. But some of these other ones do give you access to the code. They just tend to be much more expensive. So with no code, there's some primary advantages. Obviously if you don't have a technical background or you have other things essentially to work on, it will allow you to write end-in tests without being a developer essentially or a QA engineer. Even if you are one, you can quickly duplicate and set up fairly intense tasks without writing as much code. And again, some people would argue they could write code faster and that's totally fine. There's nothing wrong with using straight-up Cypress or an end-in framework like that, Playwright to actually do that. But most of these no-code platforms do actually use Selenium or Cypress or Playwright. They are using end-in testing frameworks. They're just putting it in a cloud essentially for you with a nice GUI so they'll write all the tests and everything in the background for you. So overall, it can save a lot of time. Again, they'll do visual regression testing. So it's another way to validate that things aren't breaking on the site. And the other key thing, which I'll talk about right at the end, is that machine learning and AI has made these tools a lot better than they used to be so they're not as fragile because most people that are very professional engineers will tell you that they're gonna go down this path, right? And if your CSS selector changes, your ID changes, it's just gonna break the test because you're constantly making changes. Maybe someone updates an ID on the contact form and then it just breaks. And you know it didn't really break the form. It shouldn't have, but it does. So some of the newer tools actually can see the intent of the test and they may note that, hey, this changed, but they're gonna run it through and realize that, oh, this was the purpose of the test, not the ID. I already kind of talked about the fragility of it, but if you're setting up really complex sites with very complicated functionality, it doesn't always make sense to use no code tools. Just because, again, I gave that example, if you're hooking to third-party APIs and you actually want to test those, most of these tools aren't gonna let you create like mock API data where you're getting back data like that. They're just not meant for that. They have a little more limited access. Again, you can't write the same amount of logic. It's a very procedural. You're really just writing out steps for the most part. Some of them have some cool things though. Another thing is if you don't actually know about how your website works at all, it's kind of hard to write a test. You could do it with a basic contact form, but you do need to have some idea of how your plugins are configured and what sort of issues could crop up because you have to kind of keep that in mind as you're writing the test. A lot of these are cloud-based, which means they're going to be, vendor lock-in is a real concern because if you're using something again, I'd recommend Cypress or Playwright probably if you're gonna write your own tests from scratch or you're going to spin up a server yourself to do it, you can actually often move those tests between different frameworks. A lot of times they even use like a wrapper, but they're using the same base framework. But with these tools, you're kind of locked in essentially. You'd have to rebuild those tests. I already mentioned the code access. And then if you have a very custom dev-op environment, it's sometimes not gonna be able, you're not gonna be able to get the access because it's not on your server. All right, so I've blabbed on about a bunch of stuff. So let's try to talk about how can I actually use this in WordPress, right? Because that's why we're here and that's what we're gonna get into. So I'm gonna go over three different platforms today where they're often used for WordPress. The first one's gonna be more of a general platform, not WordPress specific. And the other two are actually built for WordPress sites only to do end-in testing. So if you haven't gotten anything out of it, this is probably the time to wake up for a minute. So the first one is Ghost Inspector. Has anyone ever heard of Ghost Inspector? No? Well, okay, cool. So Ghost Inspector is a cloud-based, you pay them basically monthly. They spin up, they use something called Selenium. That's their framework. They spin this up for you essentially. They host it. They're the ones loading those browsers up and they let you essentially go through and record steps. And this one's one of the easier ones to use. And it's not super expensive, it's not super cheap, but this one's often used a lot in Ghost Inspector. So I just made a little quick video here to show you guys. So I've got a contact form here. So right up there, you might have seen before I clicked it, there's a little, where my arrow is, there's a Chrome extension that I've installed where I'm literally just saying record. And it's recording and now at this point, I'm essentially just going to reload the page so it knows that's a step. I'm just typing it in as if I was a normal user and it's actually recording it from the Chrome extension for me. So I don't have to write any tests if that makes sense. So all I did was install the browser extension, hit record and it's creating a new test that's gonna go to their system where it will generate the test for me, which I'll show you, I submit it and I get a thank you message essentially, right? And I basically finished that test, I give it a name and you can create suites where you combine multiple tests if they're related. That's not a Ghost Inspector specific thing, that's just how end-in testing might work. You may wanna set it one up for like checkout versus adding to a cart or you might wanna combine them, it just kinda depends on how you set up your tests. And then now I'm actually in Ghost Inspector here and I can see I've got my contact form and there's just basically a test set up and then right here, I can stop this for you guys. Nope, give me one second because I think this is at least important to show you all. Sorry guys, videos are always dicey, there we go. So right here, I don't know if you can read that but these are just different steps and mostly this is a ninja form so it's just doing like NF-field-1. That's just the ID Ninja Forms creates by default with their plugin essentially. And it's saying assign a value of test name, all that really is is the name field. So it's just writing those steps essentially for me using the IDs and it's typically gonna use IDs because it's less likely to break than if you're using a class that might break more often or may not be unique. So it's just going to the site and it's basically just filling the stuff out and you can add conditions, you can copy steps, all that sort of stuff so you can see it's a really simple gooey. If you just want to set up a test on a site that you think is really critical to be running tests on, this is like a really easy tool that you could set up like today. It really doesn't take too much work, little learning curve but like you can see it's not too bad. And then I think I just kind of click through and now I'm running that test so I'm manually running the test because I haven't actually scheduled as an automated test so it's actually run through now and you can see it's just checking off saying I did all these steps, none of them are read. So it's basically working, right? And it's making a video, it's got a little video you can watch, it shows it's past and this is a really simple example so that's actually a remote browser essentially that's filling out that test. You'll notice it's doing it really, really fast compared to how quickly we would do it but because it requires again extra servers they wanna run that thing as fast as possible and it's headless which means it's not loading all the stuff Chrome normally loads. So with that you can help slow down or you can speed up the test a little bit and then it takes a validation so there's a little contact right here so it's actually screenshotting the last step so if that failed it does a visual regression test or if it's just different and it will fail the test automatically so they usually do it on the last step. And then one important thing on this test that I did knew and it's even telling me is you haven't set up an assertion step and what that basically means is you're not really validating anything you're just going through the contact form but for all I know I could submit it and then it throws an error because it had to have filled out all the steps, right? So you can actually add in essentially a validation to say hey if I get like specific text then go ahead and say this pass maybe it's my thank you message, right? Instead of an error message or something like that. So I'm basically copying over or you can see that's the thank you message I really want to see and I'm obviously mirroring around trying to get to the steps so now I'm actually editing that test that it generated for me and I can basically say I want to do a validation well first I'm going to pause it because I want to give it enough time just in case the network takes a second to pick that up so I put three seconds on it and then I'm going to say is this basically element equal to? And so in this case I'm actually going to use a CSS you could also use XPath if you're familiar with that I'm just using the NF response message from Ninja Forms to essentially go ahead and put in that value and now it's running it again and you might say well I don't understand CSS I don't know how to do that you could just rerun the test to actually let you add more steps using the Chrome extension I was just showing you guys an example of how you can edit it and add your own CSS selector and it will basically find that element and validate it and there's a lot of other things you can do like I said you can schedule tests you can run them daily, weekly and I would just do that based on how important this is because you do pay typically per test so if you're running something that's really important you might want to run it every hour or every day you can also set where the tests are ran which is pretty neat you can even put in your own sample data so let's say you're not going to reset up which I'll show you in a minute you don't want to deal with having the form not go to your clients you're just going to tell them I'm running these tests just put a filter on your email but you could go ahead and give this system custom data essentially so when it fills it out they know what that is instead of just generic and they can make it dynamic even like test, da-da-da so it knows which test basically fails based on the submission and let's say ninja forms or gravity or whatever you're using so I'm going to skip forward a little bit here just to show you guys so that actually right there is where I say if the enough response message equals thank you for contacting us we will be in touch shortly if that's valid then cool that means that validation worked I'm not going to spend a ton of time for sake of time but I did add some extra steps here and this is just so you guys are aware where you can actually create a temporary inbox in Ghost Inspector in their system and again this probably only took me 15 minutes no code I just had to follow some documentation and essentially it will generate a inbox so when it gets filled out it will go to them instead of us and then essentially they will actually use their browser login to their inbox and validate that the data is correct now the only thing you have to keep in mind is because this was not actually meant for WordPress specifically and I don't think I put the example just for sake of time well actually I did so I'm filling all this out it's just generating an ID but this is a ninja forms so what I had to do though is I had to say that don't send this email confirmation essentially if it includes Ghost Inspector in the email so it's not going to go to my customers you could do the same thing with the submission I don't want to save it in our database so you do have to use some sort of conditional logic like on whatever plugin you're using if you don't want that to happen and you might argue well then it's not a real test but again this is about practicality you know you have to limit how far you go with things but that's one of the only real limitations in Ghost Inspector's side is it wasn't built for WordPress which means you do have to write some extra logic if you don't want it mucking up the data and you would have to do the same thing if it's triggering a CRM integration or something you'd have to write that logic that says if it's a Ghost Inspector email does that value don't send it to you know Zapier or CRM whatever you're using all right so that's Ghost Inspector what are we doing on time Michael how much okay cool so I'm gonna quickly go through this one Shop Warden is a WordPress specific SAS and a plugin so it's different than Ghost Inspector because it actually talks to your WordPress plugins specifically what they focus on is WooCommerce when you want to test check out so what's nice about using this compared to something like Ghost Inspector is that you can actually connect it and assuming you have just a basic WooCommerce site you haven't basically created a custom checkout with your own CSS selectors you can just turn it on and it will just start working it's also gonna delete the data automatically from after it validates it in your WooCommerce order tables it's gonna delete that data automatically it's not gonna send the order confirmation to your you know whoever your admin set to it's basically doing all the things you'd have to do manually Ghost Inspector it's just doing it in the plugin because they have a plugin on your website to do all of that and they do some other stuff too but that's essentially the biggest benefit of that is you can just set it up and you might say well you know we did create a custom page for checkout or what have you so at that point you can actually still customize that just like in Ghost Inspector you can tell it we use these CSS electors for first name, last name you know whatever fields you have and with their example this is just like setting up a really simple site I put in my e-commerce website here it basically I install the plugin it's gonna go ahead and get that set up and I can just set up a new check as they call it you can do like a full checkout so it will actually actually run through that or you can decide what you want to you can manually record kinda like Ghost Inspector as well but in this case I'm picking a full checkout and for time I'm just kinda showing it off but I can pick what products I wanna test so you might wanna pick you know a very configurable product if that's a product you're always worried about you might use multiple products it will crawl through the site and similar to Ghost Inspector you can tell it what data it's gonna use at checkout for first name, last name, shipping address that sort of stuff so if you even had different shipping options you might wanna set up a different test for each of them because that's something that often can break right shipping you may wanna test a variety of you know wherever you're shipping to that sort of thing so now it's basically running through getting it ready and you can see this looks very familiar to Ghost Inspector right it's just running through these tests essentially all the steps that are involved and it does this one's a little fancy cause it does have some nice things like they remove the cookie banners they'll work around pop-ups cause that's a common issue that you'd have to manually do in Ghost Inspector you'd have to give it extra code to do that and even then it can be tricky because you don't have access to the code like you would with a non-hosted solution essentially so I'm just gonna show you guys so now it's basically filling out that form it's just going through it and one thing you'll notice is it says shop right at the top right corner it says shop warden payments because it's using its own sandbox payment gateway because you can't use a real credit card easily right but they also support like Stripe sandbox so you know you could again do any of this kind of yourself if you wanted to but it is nice they've built all this in they do testing da da da da and then a little different but I think it's good for you guys to know is if unlike Ghost Inspector this will actually let you record steps in a browser inside your browser so they basically boot up a copy of your site and then I'm filling it out here and it's recording it instead so some tools you'll find do that Ghost Inspector is actually a little more old school it uses a Chrome extension because most tools have switched to this because people don't wanna install another extension or they don't want their customer to have to install one so here I'm just setting up an example of a contact form and showing I can still do the same thing I just didn't go to Inspector in this tool the downside is this wasn't meant for forms either which means the data I'm gonna still have to write that conditional logic to keep it from getting deleted all right last one this is Form 365 Form Tester 365 this is basically the other equivalent for contact forms for WordPress you install their plugin which I've already installed it automatically picks up that I have this gravity form ready and it tries to find the URL that it's on because again there's a plugin now installed talking to their system and one thing to note is this only works with gravity forms currently but it will essentially go through and I can just turn that on and it will run the test itself I don't have to set up the steps at all and it supports multi-page forms it supports conditional logic out of the box it just does that now certain things it doesn't do for example payment forms it doesn't do user registration it doesn't do it can do a pretty complicated form with a lot of different field variables and that's where you might test it you might check with them and this is one of those limitations of using a no code is it may not work in every situation that's where you'd have to use another test to do it and they have this setup where you can basically run it every day and their platform doesn't do the same visual regression testing although it does make a screenshot so I know I had to kind of breeze through that but this cool but that kind of has a little bit of how you can do that you can set up end-in-testing without having to write code or really spend a ton of time and money just figuring out if this is worth your time you can also put this in your maintenance services so for example that's an added value you could add you could even hook it onto your SLA and say we have a critical thing if you're of contact form your checkout goes down this is covered everything else is a tier two and you're laying that out for them so they understand it but the benefit is everyone uses this the user experience is going to get better and I think WordPress's reputation will get better too not a lot of time for this AI just want to mention they are setting up some cool tools now where as I mentioned if the IDs and stuff change it will not break the tests it can help you scan your site some of the newer tools and just say hey these are the things you should be testing based on all the millions of sites we've tested you need to be testing all these forms these specific things that break you can even write like a prompt of what you want to test and it will write the script for you so a bunch of cool stuff that they're doing so I know how to breeze through that questions or did I just overwhelm everyone or it was just boring can you do another example of smoke testing oh yeah like so a smoke test could technically be it's kind of subjective because it can really be whatever you consider is like the basic test that needs to be done so for example there's a there's a website that does a smoke test of WordPress plugins to make sure it just works on core that's technically a smoke test because they're just activating and does it trigger any errors so that's usually it's going to be something basic but you could technically argue filling out a basic contact form is a smoke test so it just depends how far you kind of go with it there's a lot of semantics with it so I don't know if that helps but other questions no? oh cool so some of these tools do the three I show do not but because there's some overlap there some of them I think that I had in that original list of no code they actually will do accessibility testing as well because they're already basically crawling the site like a bot so it makes sense that they can do accessibility testing they can even test things like I had in the example they can like download let's say generate a document let's say you're creating a PDF with gravity forms could actually validate that that download let's say it's a warranty registration is actually working properly so it's they can do quite a bit so Ghost Inspector, yes most of the ones I put in that original list that was not very accessible that they most of them can do it because they're just on the outside really but the last two I showed are just word per specific and that's why they just work turnkey because they're actually connected to your website to do that and one thing I'll mention is that you can use let's say you wanted to do a contact form you can use something like Zapier to find out when your plugins get updated and you could use something like Ghost Inspector to just go shop or to trigger these tests every time you run updates and you wouldn't have to write in code to do that so it's pre-named any questions, cool, all right I think that's it, thanks guys