When starting to build a new Alyvix test case, it can make a significant difference in the quality and speed of the resulting monitoring check depending on whether you just do "what works", or use established best practices. In this blog post we look at the correct way to prepare a test case and to mark up components on the interface so that you will consistently get the best results.
Building a new test case
So it's time to build a new monitoring check for one of your critical applications. You've already stepped through a specific task you want Alyvix to reproduce, so you know where and when Alyvix needs to click and type.
Let's get building then! Wait a second though... are we missing something?
Preparing to build the test case
There's more to an Alyvix test case than just the steps. What machine will this check be running on? What's its screen resolution? Do you need to log in first?
Unlike a traditional monitoring check like a CPU check, which is practically instantaneous, a typical Alyvix check can take a minute or longer.
That's because it represents an entire user task, not just the calculation of some value. It's like a check that instead of asking "Is the CPU busy?" asks "Can you add a new client right now?"
Okay then, let's go through the best practices you need BEFORE Alyvix runs even the first step in your test case.
Best Practice #1: As little GUI interference as possible
Our computer systems are multitasking, which means it's possible that other users could be active and their applications might be running. So our Alyvix window might get covered up by another window, or the mouse might not always be in our control, or a system dialog could pop up on top.
All of these can make an Alyvix task step fail because it won't be able to see the application GUI if it's covered up by another window.
So the first best practice is to make sure there's as little outside interference as possible: Run your critical checks on a dedicated machine.
Best Practice #2: Launching the app is part of the test case
We also don't want to start with the app already open: launching it and shutting it down are parts of the test case, so the user should be logged out of the application. We also need deterministic consistency in the sense that the system should react in the exact same way every time a test case is run.
So here the best practice is to make the first step launch our application.
Best Practice #3: At the end, we return to the initial state
Correspondingly, we have to remember that at the end of the test case, we need to be sure everything is logged out and restored to the initial state, especially if something went wrong during the check.
Thus the last step must log out our test user and closes the app.
Best Practice #4: Screen grab format must match live GUI
Many Alyvix checks run on remote servers, so it's important to be sure that the screen resolutions and Windows Scaling Factor of those servers matches the resolution and scaling of the screen where the test case was created.
So be careful if you're using something like Remote Desktop that has a different resolution and scaling factor than the device where you built the test case, and ensure that you have the highest level of compression quality.
Best Practice #5: Passing parameters to apps for simplicity and easy reuse
Optimizing your test case isn't the most important criteria when you're building one. But reducing the number of steps in a test case is one way keep things simpler and more organized, while helping you reuse steps in that test case or in others.
For example if you're using a browser-based service, you can reduce the number of test case steps by passing parameters like the URL to the browser when it launches. That page is then automatically loaded and you can still use the current step to look for elements after page loading is complete.
So pass a page URL to the browser, a filename to a batch script, a language flag, etc.
Best Practice #6: Browsers store credentials and insert them
A problem specific to browsers is that they try to help you out by autofilling your credentials to save you time, and even automatically logging you in. But then what happens when the time limit expires and you have to enter them by hand?
It's better not to let the browser autofill at all, so another best practice is to use private mode to stop that from happening. Just like in the previous best practice, pass the browser startup parameter for private mode.
Best Practice #7: Windows can appear anywhere on screen
In our Alyvix test cases we don't want windows to be different sizes or in different places at each run if we can help it, since it may break a test case that expects an image, box or some text to be in a particular place.
The easiest solution is to ensure the app window is always full screen size, and there are several ways to do that. You could have Alyvix do this actively in the step by double clicking on the window's title bar, locating it in a menu somewhere, or using a keyboard shortcut.
But remember that many apps like browsers have those good ol' command line options again, one of which may be to maximize the screen on startup. So maximize the window to full screen as part of the first step.
Building a single step
Whew, we've followed the best practices, and now everything is set up and ready for our very first test case step. So we can relax now, right?
Nope, not yet. There are also some best practices to help you correctly build that first step. Or any step in the test case for that matter.
It's more accurate though to say these best practices are for how to mark up the screen. There are of course other aspects of building a test case that we'll get into in a later video and blog post.
But for now, let's look at how we should mark up the onscreen graphic and text elements given a particular interface's screen. If this is the point where you're starting to think you need some more background information to follow along, read up here and then come back.
Best Practice #8: When first marking up a screen
When starting with an empty screen grab, the first task is to set an anchor, the main selection for the first group of components. The anchor should be a large graphic near the top left if possible.
It should also be something that is basically guaranteed to always be there, like a logo on a web page, or if not, a window control.
Since Alyvix scans for components from left-right, top-down, this type of graphic will be quickly and easily found, speeding up recognition time for the interface.
You'll have to start with an image or rectangle component though, because text components can only be subselections, never a main selection, as there are too many potential font faces and sizes for OCR to handle quickly enough.
So choose an appropriate anchor like one of these.
Best Practice #9: When creating a selection or subselection
When marking up a selection or subselection, your first decision is whether to mark it by hand or autocontour it.
Autocontour is faster to create, but you have to take what the algorithm gives you. It's also more reliable at run time because autocontour is guaranteed to give you the minimum height and width.
Marking up by hand gives you more choice though, since autocontour won't always give you the rectangle you want.
Best Practice #10: Autocontour for contiguous graphics like icons
Autocontour works best when it's a single, connected graphic. If the graphic is disconnected, autocontour will only select a part of it.
So if a graphic matches the criteria, give Autocontour a try.
Best Practice #11: If autocontour doesn't work at first
If autocontour in fact doesn't match the criteria and only selects a limited part of the image, first undo it, and then try to autocontour again at a different nearby position (i.e., right click somewhere else on the graphic).
If it still doesn't work out right, press the space bar to "see" what Alyvix sees. The screen grab turns to grayscale and you can see boxes showing you what autocontour would select if you right click inside that box.
Press the space bar a second time to go back to regular mode.
Best Practice #12: If components have problems matching
There are other ways Alyvix can help you if a component you create doesn't match during a run when you think it should.
The component parameters include what is considered during the matching process. By default, an image component matches both the colors and the shape of the selection.
But you can also match them independently: just color, or just shape. An exact match means 90% of colored pixels are the same, a color match means 70% of colored pixels are the same, and a shape match means that 50% of grayscale pixels are the same.
Rectangle components that match structures like buttons and text fields are more reliable, especially when someone changes an interface.
If for instance a website designer later changes the size or color of an image like a logo, you'll have to update the test case by hand to account for the change.
Buttons and text fields are recognized by outlines of a certain height and width. If these objects change but stay within their Region of Interest (R.o.I.), you won't have to update them.
You can use the Monitor tab to see the special R.o.I. for the Button and Box parameters:
Text components only need to be updated if the content changes, because the text recognizer ignores color, size, and font type.
Also, note that the quality of text recognition improves with the amount of text in the R.o.I., the size of the font, and increased screen resolution.
But for text that never changes, like the words that are part of a logo, it's probably better to use an image component than a text component.
Best Practice #13: Dynamically placed GUI elements
It's especially important to properly size components when GUI elements "float". For example if a window can be resized, or if there are a dynamic number of elements in a row, the components might be in the wrong place and won't match where the intended target is in the live interface.
If you're working on a dynamic-length list of graphic or text elements, or a GUI with a tile approach, you should expand the component's Region of Interest the entire length of where items might appear, even if that's to the edge of the screen.
Best Practice #14: Dynamically resized GUI elements
All components in all groups have to match the interface for the current transaction to be successful. But why do we need multiple groups at all? Why not a single, large group?
That's because the selections are positionally independent of each other, and so their subselections don't have to depend on a single position in the GUI.
This is especially necessary for modern U.I.s where multiple parts can change position dynamically, such as multiple subpanels, resizable windows, dynamic column and row sizes, and separation of controls from content.
So when UI elements can be dynamically resized, use a separate group for each set of those resizable elements.
Conclusion
So at this point you've seen the best practices for preparing for an Alyvix test case and how to mark up the components on an interface.
Try to apply them the next time you build a test case, and even over the next several test cases to see if you can be more effective
If you'd like to go further into the details, or you're a visual person, check out the following two videos that explain the concepts above.