Building an automation project, some error handling

As I mentioned, I write automation code in phases, the same process that is done for editing photos in Photoshop or writing a novel. Photos are edited in layers. Each layer adds a small change to the overall image.

Novels start with an outline. The outline is then turned into chapters. The chapters are broken down into scenes. A scene may only be a few paragraphs. Those are then connected to the next scene, which might only be a couple of paragraphs.

Automation follows a similar process. I pick a set of pages I want to work with. They might be relevant for a production smoke test. Or they might be the more important or more frequently used sections. Either way, my goal isn't to write automation for the entire site. The goal is to pick important or high traffic areas and focus on those first.

Once inside Katalon, the goal of the first phase is to map out the objects I want to work with. Which input fields and buttons will I use, and where will the results display? If that's in a table, I get that definition and try to parametrize it, such as using ({row} and ){column}.

I then write some proof concept code that confirms these definitions are correct. If I enter some criteria, do I get a result back? If I search for Bill Smith, is Bill Smith in my list? If I search for Arizona as a state, do my results contain AZ?

Writing this small, quick code, lets me get through multiple pages in a short amount of time. Writing automation code is not my full time job. It's not even part of the sprint.

I still have to work on other tasks, most of which are testing manually. My goal is to make as much progress across the site as I can in the short time I have allotted. At the end of the day, literally, I want code that I can use.

This also lets me touch multiple pages and see commonalities. Once I write a section to enter text and verify the results, I can use that same code on multiple pages. And in fact I did.

I created a basic structure for entering search criteria and validating it in a table. Since many of the pages followed a similar pattern, from one small block of code, I was able to generate half a dozens tests with minimum code change.

Now that this phase is complete, the focus becomes more code centric. The first order of business is to add some error handling, improved timing, marking errors, logging information, and additional validation points.

For example:

What should happen if a value is blank? Is that a failure? Is that an error? Can the test move on?
What happens if an object doesn't appear?
What happens if the page doesn't load?
What should happen if there are no results?
Do errors merely need to be logged or should the test be marked as failed?
What happens if data takes longer to appear than expected?

This starts to give the tests more usability. Yes, they are still rather static, as variables have hardcoded values. That will change soon. But, once this portion has been done, I have an improved test suite that can be used to confirm some basic data points, and it has some ability to adjust to conditions and note errors. For example, if the first name is missing, that's bad. If the phone number is missing, that may not be an issue.

Once this phase is complete, it will be then be time to move into reading and validating data. That will also be the point where Keywords are developed and the tests are made more dynamic.