An Excellent Way of Data Testing Using XML Technologies (White Paper)

In this article, we will learn about a wonderful way of Data Testing Using XML Technologies. Let’s get started.

In the SDLC, if the application uses a waterfall model, testing activities are planned at the end. This poses a risk of rework with respect to requirements, design, code and test cases if QA team identifies defects. It is better to avoid waiting till the end to identify the defects in an application.

Tests that are not based on functional execution of the application can find defects without mandating the release of all the components into the test environment. This can be accomplished by data testing.

The XML and related technologies used for communication between different tiers of an application provide an opportunity to carry out the tests that need not wait for the entire application to be readily available for testing.

An Excellent Way of Data Testing Using XML Technologies

This document outlines one possible way of looking at data testing options early in the life-cycle of a product release.

Assumption

This document assumes the reader is familiar with software testing concepts and fundamental usage of a database and XML Technologies.

Focus group

QA team (QA), data team (DT), developer (DEV)

Purpose

The sample data identified for testing a product defines the extent of testing performed, and adds confidence in the test results and quality of the product. Identifying the data for a test depends on the requirements of the test to be performed.

This document focuses on validating the test data before seeing it on the user interface.

This process requires test data management in order to have effective test results. Data as we all know can be saved in a database or a flat file. But the data transfer from / to a database can be handled using XML. There exists a very close relationship between XML[1], XSD[2], XPATH[3] & XSLT[4]. (See all definitions below).

[1] XML – eXtensible Markup Language. It is a World Wide Web Consortium (W3C) recommendation to describe the data. With a set of correct syntax rules applied, one can ensure a XML document is “well formed”

[2] XSD – Used to denote the structure of a XML document. A “well formed” XML document can be validated against a XSD (XML Schema) to validate it

[3]XPATH – A “valid” and “well formed” XML should be navigated through to pick up appropriate data from XML. XPATH expressions look like a traditional file path in a directory.

[4] XSLT – eXtensible Stylesheet Language Transformations – While representing the data from a XML on a user interface (UI), any style (font, color, size, etc.) can be applied using XSLT. XSLT uses XPath to locate information from XML.

Data presented in the XML is validated against a schema (XSD file). The XML can be output into different formats with XSLT and XPATH.

For the purpose of this discussion we shall use the following example.

Example – A publishing house has a website displaying information about the books it has published. One of the webpages displays a summary about every chapter of a book. Testing should ensure that the content is appropriate on this webpage. The publishing house has by now published millions of books.

Any information related to the published books is saved in a database. Yet, the webpage in question needs a subset of the data (about a new book and its chapters) to be extracted from the database into a XML.

The XML given below represents the metadata about the book.

XML file Book.xml

<?xml version="1.0"?>
<Book xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Book.xsd">
    <Title> A book on test data</Title>
    <Author>Jim</Author>
    <Publication_Year>2015</Publication_Year>
    <Category>Technical</Category>
    <Language>English</Language>
    <Pages>120</Pages>
    <Number_of_Chapters>10</Number_of_Chapters>
    <Chap_1>Acknowledgement</Chap_1>
    <Chap_2>Introduction</Chap_2>
    <Chap_3>What is data</Chap_3>
    <!-- Like this there will be chapters up to 10 in this XML file-->
    <Reference>List of references</Reference>
</Book>

XML Schema Book.xsd

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Book">
<xs:complexType>
<xs:sequence>
<xs:element name="Title" type="xs:string"/>
<xs:element name="Author" type="xs:string" minOccurs="1" maxOccurs="2"/>
<xs:element name="Publication_Year" type="xs:positiveInteger"/>
<xs:element name="Category" type="xs:string"/>
<xs:element name="Language" type="xs:string" default="English"/>
<xs:element name="Pages" type="xs:postiveInteger"/>
<xs:element name="Number_of_Chapters" type="xs: postiveInteger "/>
<xs:element name="Chap_1" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="Chap_2" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="Chap_3" type="xs:string" minOccurs="1" maxOccurs="1"/>
<!-- Similarly the number of chapters can be represented separately-->
<xs:element name="Reference" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Test Data Management Life Cycle

Similar to other processes, test data management has its own life cycle (LC) stages.

1. Identify data requirements
2. Plan the data collection
3. Build the data
4. Test the data
5. Data maintenance (not detailed in this document because it is not relevant)

#1. Identify data requirements

In the above example, the database stores millions of records. If the content of all the books is extracted into a XML file, it requires detailed validation. As and when new information has to be output into the webpage, the XML and schema might undergo changes.

The changes to the XML, XSD, XPATH and XSLT require proper validation. However, this testing need not wait for presentations, middleware and data tier releases. QA team can analyze XSD to prepare a data requirement plan.

The process of identifying all the data requirements for a product should address the following:

a) Coverage and completeness – Do the identified requirements cover all use cases?

Example – It is very important to test the data combinations for title, author, category, language in the above XML sample; since the schema mandates these fields.

This can be easily handled by looking at the XML schema that describes the presence of an element / attribute and their order in the XML

b) Quality – Is the data collected of best possible quality? The test data used determines the quality of the testing performed on the application.

• Positive and negative scenarios – Testing should check how the application behaves with valid / invalid input data.

The test data requirements document lists the data needed across all tiers of the application. Data from the database can be used directly in UI and/or manipulated (calculations, concatenation, etc.). Hence, it is required to capture all the data requirements.

The table below represents a sample data table:

In the above example, use of string data type for Author field can be avoided. Instead, a pattern can be enforced.

E.g. alphabets only, start with an uppercase letter, no special characters etc. A pattern (restricting an element value defined in XSD) can be defined as <xs:pattern value=”[a-zA-Z0-9]{12}”/>.

If this is set for the author element in the above example, it means, the author element should have the value with a combination of uppercase, lowercase alphabets and positive integers only.

#2. Plan data collection

#3. Build the data

#4. Test the data

As listed in the above tables, QA validates the XML against the schema to check if the data is available as expected. Once the schema matches, the content and its structure can be confirmed to be fine. Yet this does not confirm that the data is picked up accurately by the system.

As we know XML shows a tree structure with parent-child-sibling-ancestor-descendent relationship between the nodes.

Look at the table below to understand the simplest XPATH conventions:

In order to represent the fields from the XML on a screen (as HTML for example) XSLT – XPATH combination is used.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 
<xsl:template match="/">
<html>
<body>
<h2>Latest Book</h2>
<table border="6">
<tr bgcolor="#9cad32">
<th style="text-align:left">Title</th>
<th style="text-align:left">Author</th>
<th style="text-align:left">Publication_Year</th>
<th style="text-align:left">Category</th>
<th style="text-align:left">Language</th>
<th style="text-align:left">Pages</th>
</tr>
<xsl:for-each select="Book">
<tr>
<td><xsl:value-of select="Title"/></td>
<td><xsl:value-of select="Author"/></td>
<td><xsl:value-of select="Publication_Year"/></td>
<td><xsl:value-of select="Category"/></td>
<td><xsl:value-of select="Language"/></td>
<td><xsl:value-of select="Pages"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

On a browser finally the resultant XML is represented as below. Since the data has already been verified, the focus of testing can be more on the look and feel of the screen.

Conclusion

• Data testing performed early in the development-testing life-cycle saves money as the cost of fixing a bug during the functional test execution is much more than fixing it early in the life-cycle
• The effort spent initially in validating the XML file, XPath and XSLT with XSD documents helps avoid multiple iterations of the release
• QA team can work closely with the development team and provide a value added service
• QA team can help mock up various combinations of data to ensure coverage and correctness

I am sure you will find this technique useful. Feel free to write to us in the comments section if you have any doubts or queries. We would love to hear from you.