Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Validating Modified Data in Test Automation

DZone's Guide to

Validating Modified Data in Test Automation

Why validating data in test automation is important to arrive at correct conclusions about the behavior of an application.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

In test automation of any kind, we end up automatically simulating (with a tool or with a fragment of code) the action that a user would execute on the system (in the broadest meaning of the word “user”).

Therefore, a very important validation is to make sure that our automation, that is, our testing artifact, actually does what it is supposed to do in simulating the user’s actions. As we always say: testware is software, and as such, we must test it as well.

Something that has proven quite important in one of our recent performance testing projects relates to this: we must validate test scripts at the data level, more specifically, at the database level. This is particularly important when we don’t execute at the graphic interface level.

When we execute a test at the graphic interface level of the system subject to testing, such as with GXtest, Selenium, or WatiN, we are certain to a degree that we will do the same thing that a user would do by clicking buttons, entering data in inputs, and so on. This is quite different in performance tests, where, for example, we attack the application at the protocol level. So, in the case of a web system, we will be sending invocations at the http protocol level. In this case, it is most important to verify that a script does what it is expected to do and that there are no differences with what is done manually.

Validating modified data is quite easy to do with the aid of a developer. When we show an expert on the application that we are executing a script that uses certain data, such as: A specific user enters an invoice with products issued to a specific customer. The developer will easily know which tables to check in the database to verify that the data is consistent and correctly updated, so that the difference between that data being processed by an actual user or by a test script will not be noticed. It is important to validate that the different variables and attributes used in each event have been parameterized. Having the system’s KB or requesting this information from the developer can be helpful for that.

What’s important here is that, if the script is parameterized incorrectly and we send wrong data, we could be generating erroneous situations, and the simulation of reality would not be the right one. Imagine that we record a script where we indicate the creation of an invoice. This will surely require that we parameterize the client and the products. But, what happens if there was an error made in parameterizing the script and the product was not parameterized, so the same product is used every time that an invoice is processed? We would first think that it is not such a big deal, and that in simulating hundreds of users processing invoices, we will just have numerous invoices with the same product. However, this could have negative consequences in the test: if the system must verify the existence of stock and update it after every purchase, we will be generating more locks at the database level than the locks there would be in reality. So, we would not be simulating the user behavior as we planned, but rather a situation that is much worse.

It is clear, that, if we’re not careful with validating modified data, we could arrive at incorrect conclusions, showing the importance of tests and of testing artifacts as well!

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
validation ,test automation ,quality assurance ,development

Published at DZone with permission of Federico Toledo, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}