Common Sense in Test Automation

Let's think about test automation from the perspective of first principles.

Why do we want to automate testing? We want to automate because we want to make sure less bugs will make it to production, and, therefore, the company will lose less revenue.

What do we want to validate? We want to validate that the most important flows work for our end-users.

How the most important flows are described? Usually using plain English in test cases of feature specification documents.

Therefore, based on the above, our best bet is to build automation using our own language in plain English where it is executed the same way as user would do it.

Something like this:
login
go to leads page
create new lead
click "pencil" on the right of stored value "Lead Last Name"
enter "New Last Name" into "Last name"
click "Submit"
check that page contains "New Last Name"
check that page doesn't contain stored value "Lead Last Name"

Now, let's get into a bit more details on how it should be done.

When we are validating that certain flow works we care that it works from end-user's perspective. For example, if we are testing a purchase on an e-commerce website then we care that a user using this website will be able to actually finish the purchase. In particular, your customers do not care which UI framework did you use, what are the elements names, and how tables are rendered. However, if you look into frameworks like Selenium today, this is exactly what you would use to refer to the elements: names, ids, XPaths, etc.

Wouldn't it make more sense if your testing framework would do things the same way as your user's would, instead of relying on details of implementation?

Next, let's talk about how it is done.

I believe the following properties are what people are looking for in a good testing framework matching their needs:
  1. Testing from end-user's perspective as the above
  2. Ability to express scenarios in a readable way like in BDD
  3. Ability for manual testers to be able to build automation and understand test failures
  4. Ability for the code of tests to be versioned alongside the code (in Git or other VCS)
  5. Ability to run tests in parallel and on multiple browsers/OSes/mobiles without modifying the code to do it explicitly

Let's see what we usually get. If we are going for coding frameworks like Selenium, then we only get 4. If we go for some of record-and-play systems, we might get 3 and 5. None of it matches the ideal scenario.

This is why we came up with testRigor, where anyone can create tests just writing them in plain English (and making any sequences of steps a "function" with any arbitrary name). The example of the code you can see above and it will fit all 5 of your ideal framework requirements:
  1. testRigor matches the way end users go through your application, with no reliance on details of implementations what so ever
  2. All "code" is in plain English, so anyone can chime in. Including PMs, Engineers, QA, etc.
  3. As soon as manual tester you've hired can read and write English - it should be sufficient for her/him to be able to create tests of any complexity in testRigor
  4. testRigor test are pure plain text, versioning works wonders
  5. testRigor will run all of your tests in parallel (given that you are purchasing enough parallelizations) and it will run it on 3,000 combinations of OSes/Devices/Browsers. No modifications required at all as soon as your application will function the same way.
Join the next wave of functional testing now.
A testRigor specialist will walk you through our platform with a custom demo.