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

In the SDLC’s waterfall model, testing tasks are often planned towards the conclusion, potentially causing rework if the QA team discovers defects. Discovering defects in an application sooner rather than later can prove to be more advantageous.

Without releasing all components into the testing environment, it is possible to identify defects by employing tests unrelated to the app’s functional execution. Data validation stands as the means to achieve this.

The utilization of XML and related apparatuses for interaction amidst an app’s diverse tiers enables the execution of tests without the need for the entire application to be ready for testing.

This paper details a possible strategy for contemplating data testing solutions early in the product deployment life cycle.

Presumption:

This document presumes that the reader has knowledge of percepts relevant to software testing and a fundamental understanding of database and XML technologies.

Target group:

The target group comprises the QA team (QA), data team (DT), and programmers (DEV).

Objective:

The chosen data for product testing delineates the scope of testing conducted, reinforces confidence in the test results, and evaluates the quality of the product. The data for a test is selected based on the requirements of the test to be conducted.

This document particularly focuses on the verification of the test data before it’s showcased on the user interface.

For achieving precise test results, effective test data management is required. Data can be housed in a database or a flat file, but XML can be employed to manage the transfer of data to and from a database. XML, XSD, XPATH, and XSLT are interrelated technologies. (Definitions given below.)

[1] XML – Extensible Markup Language. It’s a World Wide Web Consortium (W3C) recommendation for data description. Adhering to a set of correct syntax rules ensures that an XML document is “well-formed”.

[2] XSD – It’s used to establish the structure of an XML document. A “well-formed” XML document can be validated against an XSD (XML Schema) to guarantee its validity.

[3]XPATH – To traverse through a “valid” and “well-formed” XML and extract the required data. XPATH expressions mimic traditional file paths in a directory.

[4] XSLT – Extensible Stylesheet Language Transformations – XSLT can be used to introduce styles (like font, color, size, etc.) to represent data from an XML on a user interface (UI). XSLT employs XPath to locate information in the XML.

Data exhibited in the XML is validated against a schema (XSD file). The XML can be transmuted into various formats using XSLT and XPATH.

The following example serves the purpose of our discussion.

Example – A publishing group has a website that displays details about its published books. One webpage exhibits a synopsis of each chapter of a book. Testing should validate that the data on this webpage is correct. The publishing group has already published millions of books.

All information related to the published books is stored in a database. However, the webpage in question requires a subset of the information (about a new book and its chapters) to be extracted from the database into an XML file.

The XML below symbolizes 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:positiveInteger"/>
<xs:element name="Number_of_Chapters" type="xs:positiveInteger"/>
<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 supervision life cycle

Comparable to other proceedings, test data management consists of its original life cycle stages.

1. Determine data necessities
2. Strategize data accumulation
3. Construct the data
4. Verify the data
5. Data maintenance (not elaborated in this document as it is irrelevant)

#1. Determine data necessities

In the example provided, the database retains millions of logs. Transferring the content of all books into an XML file would need comprehensive validation. Whenever new information needs to be exhibited on the webpage, the XML and schema might require updates.

Correct validation is needed for modifications to the XML, XSD, XPATH, and XSLT. However, this testing does not necessitate waiting for the launch of the presentation, middleware, and data tiers. The QA team can scrutinize the XSD to devise a data requirements strategy.

<

div id=”tablepress-61-scroll-wrapper” class=”tablepress-scroll-wrapper”>

<

table id=”tablepress-61″ class=”tablepress tablepress-id-61 tablepress-responsive”>

Lifecycle phase Entry Criterion Tasks / Accountability Exit Criterion

<tbody class=”