Tips & Tricks – Overview of Test Automation with testRigor
 |
This session will show you how you can automate your tests and spend very little time on maintenance. The best part is that no coding is required. testRigor uses plain English and will help you accomplish a higher test coverage than you thought possible.
Here’s the transcript for your convenience:
Connie Lund: Thanks for joining our first Tips and Tricks session for testRigor. Session from testRigor, and we’re excited that you joined us. We are going to show you how to automate tests. And in terms of using no code written in plain English, it will reduce your maintenance costs to nothing. Our presenter today is Artem Golubev, the CEO and founder of testRigor. Please ask your questions, and we’ll answer questions in the last half
Artem Golubev: Hello everyone, and I will try to make it as short as possible to get enough time for your questions. Okay, so testRigor is, as Connie mentioned, a functional end-to-end testing system, which allows you to write tests, and those tests are from the end end user’s perspective. So let me share my screen. So this is basically how it would compare to Selenium. There is a lot of coding Selenium has to write, and there’s very minimum in testRigor, but that’s not the point. The point is to execute purely from an end user’s perspective, not waiting the need to deal with implementation details. And you have things like IDs, data test IDs, like names, Xpath, anything like that. The components of implementation can change at any moment. And like we’re for breaking the test for no reason. At testRigor, you don’t have that. You write from an end user’s perspective.
So that’s your tip number one; testRigor, fortunately or unfortunately, actually is very powerful, and you can write the test the wrong way. So your best bet is to try and write the test as much as possible, as close as possible to how you would do it in English from the end-users perspective. For example, if you use our recorder, it will give you some suggestions. If that is not the kind of the point and the single source of truth is just a suggestion, you should review it and maybe rephrase certain things. For example, if I were to click on this second update button here. What you probably want to do is you want to say click on update and change your password section. However, the recorder will tell you it is critical updated, robust numbers because phone numbers text is technically closer to his update button than this one. So for our recorder system, there is not necessarily a way to guess the right way to express steps. You need to review those and fix those.
This session will be helpful even though you are already an advanced user of testRigors. I’ll show you some settings that can dramatically affect your tests. And that is how stuff is being executed if you go to settings. And where there’s a load of actual settings in the speed optimization section, as you can see, is quite a number. Your primary focus, of course, is the leading life timeout is how long this testRigor will wait until the element is whether or not he wants higher stability. You might increase it in the case of a staging environment because the staging environment might not be optimized for performance the same way as production is, as higher numbers of variety if you’re looking specifically for lower numbers and intentionally want to fail. If your font is not there, here’s the place to change it. Another interesting point of testRigor, which has a massive impact on how testRigor works, is getting visibility of the elements approach. We have to introduce it at some point to help our customers achieve higher performance, and the default right now is visible first two options and batched. What does that mean? So if you go to the page Safeway.com. What visible first will do is it will just get elements visible on the screen and assume that everything else is non-existent. And this is the default approach for performance reasons. Because there are many cases, the first page is enormous; if you try to get all the elements, it just takes longer. However, testRigor does have a way of dealing with all elements on the page, even though they may not necessarily be visible on this current view front. That is to use an evident batched approach. Here back to here, so it’s batched system, which hadn’t been selected here means likely to work with all of them. It’s called batch, to rename it probably. Because the number of elements frequently is so ginormous. It’s even impossible to get at one goal. So we talked to the browser in batches many, many times to get all the elements on the screen that were potentially visible. That affects how tests are run. If you’re seeking the visual first approach, which is the default right now, if you were to create a new test suite, then if something is not visible, you would need to scroll to it first. And notice what you can do: scroll down until the page contains certain things to ensure it doesn’t have enough scrolls. So not a problem. In case if you select batched, then if an element would be reasonable if he were to scroll, it will be available. Therefore, that’s the difference. And it’s a big deal. And we suggest people stick to this visual-first approach for performance reasons because it better reflects how the human sees the page.
All right, I can see there’s a question here. What’s the benefit of using the testRigor compared to the BDD frameworks like JBehave or Cucumber? Great question. So testRigor is out of the box and is also a BDD framework. However, BDD is a process, and not every company necessarily follows the process to implement BDD. Most companies don’t because it’s frequently challenging to change whatever procedures are in your organization to watch your BDD. However, like if you do use BDD, what we see across the board with companies that use BDD is that it is a three-step process. Right? For UI testing, mind you, API is separate. Let’s say you’re doing UI testing for UI. It is three steps first. Like they have JBehave and cucumber, best case scenario, product, product managers or whatever like it’s called quote unquote business would write the specification.
Product owners will write specifications of what needs to be done. I like the length. They would write it in gherkin you can, which is sometimes the case. People are willing to write a specification in gherkin, then engineers would write the code matching that gherkin specification and then create will come in, and they will write the code in Selenium to match gherkin can specification. So it’s a three-step process. And there are two issues with this number one, QA engineers hooking up into implementation details. That’s a number one issue we help our customers avoid, and that’s basically like it’s a problem of situation point.
So at some point, the test maintenance is so ginormous you can’t build tests anymore. And with testRigor, you don’t have to rely on implementation details. So this is one. However, that’s not only that the QA engineers can’t build tests earlier in an ATDD style until engineers are done, but they also are not enough details to construct an implementation of your gherkin specifications. For example, it’s unclear what XPath will be or if further would be ideal for database study. Of course, sometimes exceptions, but as a rule, like it is impossible, it’s a three-step process. Now, the second issue is a three-step process itself. And that is if product managers have written gherkin specifications such that engineers misunderstood and understood it differently. Because they misunderstood it or for whatever reason, maybe it was a mistake. This will only pop up later after engineers have done and QA engineers are building and writing the tests. And then it will pop up, but there is a mismatch. With what product managers had in mind and what engineers coded, the QA engineers usually have a way of thinking similar to how product managers do it as opposed to how engineering feels about it. But because there’s, like, context.
In different contexts, there might be this misunderstanding. This seems like we’re not necessarily the issue, but it occasionally does. With testRigor, you can write the specification, which is executable out of the box, before engineers write the code. Then what engineers need to do is, again, an ATDD had been
possible with API. It just has never been possible with UI like that. However, with testRigor, it is possible to do the UI where engineers would execute this executable specification and see if it’s working. And this way, it will help to engineer a vast misunderstanding between what product managers mean when we write the specification and how engineers understand that when they call it.
Moreover, engineers cannot do things like that if engineers see some issues. So this issue will pop up earlier and be communicated back to Product Managers as soon as possible, not after that fact. Then it will make a more efficient process with less back and forth, and engineers rewrite the code to match what product managers meant. So it’s a two-step process. Product Managers, mainly with the help of QA engineers, could just QA write the specification, and engineers write the code to match that specification closer to what TDD looks like. As opposed to like three-step. And finally, if this is English, remember, it is not only low-level steps, which testRigor provides out of the box as I’m highlighting, but also you can extract your own rules, or you might cover functions in your language. As such, let me show you an example. Let’s say go to registration and go to those reusable rules. This is going to roll. Those are the steps here.
The trick is that you can give the arbitrary name to those steps and the best practice is to provide a name that matches the specification the way people in product managers talk about it themselves in [unintelligible] in actual ordinary English language, not gherkin. I mean, testRigor can use gherkin, but you don’t have to. It is a superset of gherkin. So you can give those phrases precisely the same name, as product managers have in their specification is the way they talk about it. It encourages collaboration and makes your test cases easier to read and understand, and if those phrases are available, the third difference compared to Cucumber and JBehave is that Cucumber and JBehave require QA automation engineers to write code, literally. So somebody would have to register a code usually. Selenium might be something else. It doesn’t matter. But there’s an engineering effort involved, and in testRigor, you don’t have to have engineers. Manual testers can do that. Product Managers can do it. Engineers can do it. Anybody can do it. Literally. As long as you can read and write English. You’re good to go. Especially if somebody in QA would build all those phrases in advance, it makes it even more accessible to create tests because it matches how you describe your product, in your own words, in the terminology you use your company. So those are the three most enormous differences. So to go for it again. So number one is no reliance on details of implementation. Number two, it’s a two-step process instead of a three-step process, and number three, product managers or manual QA helping product managers can do that. You do not necessarily need to involve engineering. All right.
Connie Lund: So there’s another question, Artem. How does testRigor identify the locator, and does the engineer have the ability to correct it?
Artem Golubev: Good question. And the answer is the testRigor does not use locators. This is yet another point here. So the whole point of testRigor being an order of magnitude more stable and requiring order of importance, two orders of magnitude still 100 times less time on this maintenance is exactly because testRigor does not use locators. Any locator whatsoever. TestRigor is this executable specification in plain English. So as you can see, you are expressing stuff from the end-users perspective. And the advantage being is if as a problem we have Selenium is that it forces people to use as filters and very for hook up into how engineers implemented the page and therefore once implementation changes, sometimes unintentionally, because engineers let’s say, upgraded a library, which renders certain elements or the patient now is, is doing differently.
Selenium code would fail because it relied on those details of implementation. It relied on how things are in HTML. In testRigor, we don’t do that. You’re specifying specification purely from the end user’s perspective, and because it’s from an end user’s perspective, it doesn’t matter what implementation changes. As soon as from the end-users perspective, it is the same thing testRigor record will be executed the same way. And this is the server code. It’s plain text, as you very well know. Most of you are on this call, and you can even keep ten gifts if you choose. There is no hidden data. You see, whereas there are like a lot of other tools. Like if you, if you do record and say and all this kind of stuff, he store the ginormous amount of data about elements on the page you clicked on, including XPath and other locators, as I mentioned. However, it is the wrong way of doing that because you’re looking up details of how things are implemented and testRigor. There’s none of that. Literally. You can copy-paste this text which is executable specifications, somewhere else, and it will be executed from scratch again and executed precisely because it behaves the same way humans will. You can think of this testRigor as manual tests or emulators to give instructions to a very unsophisticated manual tester, so your education must be exact. But doesn’t that precisely how a manual tester would do? So you basically, testRigor does, indeed, emulate the way humans would execute the steps instead of hooking up like heaters, details, limitations, and stuff like that. Yeah,
Connie Lund: All right. There’s another question. How does testRigor help to reduce time spent on test maintenance?
Speaker Artem: The number one reason is precisely that. You just because you’re not dealing with details of implementations, like, hey, there’s IDs, data test IDs. So, therefore, as soon as those details of implementation change, you don’t have to do anything because, in testRigor, we’re just not relying on at all whatsoever. So that is the number one reason our customers spend 200 times less than maintaining their test code compared to Selenium. This is mostly how you do it. However, they’re also tools where there’s the only company on the planet that provides you with tools to reduce maintenance. For example, testRigor extracts unique issues affecting, potentially more than fantastic, as many of your customers have already seen that in action. If a particular issue affects multiple tests, you will see one point affecting numerous test cases instead of just many broken tests. That way, you are improving on dealing with unique issues instead of dealing with a considerable number of broken tests.
Connie Lund: Okay. Next question, can we use an API for testing?
Artem Golubev: You can use API for testing for that. You can go to Resources, click on documentation or go to documentation. Google testRigor documentation should be able to walk us through the language support. You should be able to find this page. It’s also available as a link from the testRigor.com landing page. And here on the left is the menu, and you can go to API testing here, which shows us many examples. Different ways how you can deal with different types of API. And more is coming.
Connie Lund: All right. Last question. Is this web-based only, or can we automate testing on mobile apps?
Artem Golubev: You definitely can automate both web and mobile with testRigor. This is an example. I heard hands in here because many people are asked. So an example of a mobile test on Android is the same language here. Moreover, using the same vocabulary, you can switch between the web and mobile in the same test. So yet again, this is an example. In this example, we start with a mobile test clicking something on violence. Here I say tap to distinguish it from click, then the startup browser and switch where open URL and proceed the signup process for Twitter and that even open up the email. So definitely, you can do all of that in one test very quickly. And that’s the point of this testRigor. It has been designed for end-to-end tests.
Connie Lund: All right. Well, that’s all of our questions. We are going to start offering these every Wednesday at this time. And so the next session next week is on data sets. If you have any questions about yourself, know what items talked about? Please email us at [email protected]. Visit the website. You can get access to our free version, or you can request a demo. So there’s a question here. Is there a sandbox where I can try it? So on the website, you can go and use the free version, or you can request a demo. So there’s a sandbox there. I’d let Artem you talk about the difference between the free and the trial if we offered a person to trial.
Artem Golubev: You can go to testRigor.com, click start free, and a free version is available. Although please keep in mind that it is open source. Whatever you are writing, as the code is public, everything is shared. All screenshots and public videos of your test executions are mandatory, recorded, and published or as public videos on YouTube and then created in the theater. So this is great for people who are learning QA and want to brag about their skills, but that is not applicable if you want to try something related to professional life or you’re about your company. For it, you might want to kick off a free trial of a private version.
Connie Lund: Yeah. And if you talk to us, we can help you get going with that free trial. The very last question and then we’ll wait till next week. What is the first step to writing a test case?
Artem Golubev: The first step in writing a test case is to create a test suite. Let me do it here. So once you start, testRigor, let’s do it on Safeway. You copy the URL and create the test suite here. Then you can go to Resources and install our Chrome extension. And then you can start to create speed up a little bit. We are creating test cases. Let’s open were like by recording stuff. Let’s click and run. Go back. This is our test case, and that’s it; then, you can modify and extract. You can do it post hoc extract stuff like that. We’ll probably talk about it in the next session.
