Seamless Integration: Testing 2.0!!

End-to-end seamless integration of tools is important in every domain, especially ALM. iTKO seem to have understood the concept and is delivering a Test Automation Platform (LISA) which not only allows automation of customer scenarios (spanning across various technologies), but also provides integration APIs to integrate with rest of the ALM tools.

For example:

A test can register a user on a web-portal, download a software, installs the bits on a local or remote system, runs commands to finish & verify installation, calls a web-service to confirm product registration and in the end queries the database to make sure all tables are correctly populated - all from within the context of the same test case!

There are even APIs available to expand the core functionality of LISA - like filters, assertions, companions, etc.

There is more... Once the test is automated, it can be automatically kicked off as part of cruise control, or other Ant integration, post result into a central database or TestDirector or homegrown test management system, automatically file a bug or integrate with requirement management system. Use of pure java, xml, open architecture and public APIs makes the seamless integration possible across the entire ALM domian.

The tool allows all data strategies I discussed in my August blog. The data driven testing is the key to leverage test scripts, lower maintenance and improve ROI.

Checkout Test Automation Tools blog. It nicely captures the automation framework requirements and the battle of build vs. buy. Remember, understanding the requirements and ability to clearly articulate the question is the first step in finding the answer!

Like Paris Hilton is Marketing 2.0, LISA seems to be Testing 2.0 for Web 2.0 :-)

Understanding SOA

SOA is the buzz word these days. Gartner reports predict that more than 80% of applications will be based on SOA by year 2009. So, what is SOA and why is it picking up so fast?

SOA means different things to different people. Different parts of organizations have different motives behind adopting SOA. It has something for everyone!

We all know SOA is "Service Oriented Architecture", but what does it really mean? And more importantly what does it mean to an engineer? What does it mean to an IT organization? What does it mean to the top management? And what does it mean to a company as a whole?

Distributed Computing

Distributed computing is not new. Over the past 2 decades, we have seen it grown from simple 2-tier client-server architecture to 3-tier and then N-tier and p-2-p architectures. The goal of a distributed system has always been scalability, availability, and flexibility. Moreover, distributed architectures have helped companies to better align their resources (both human and hardware)

SOA evolution

Distributed computing allowed companies to break their systems into smaller components. This helped companies to realize the fact that a majority of these smaller components are not related to their core business and, in fact, are common across different companies and even industries. For example, entitlement and billing systems, payment systems, catalogue management, application infrastructure layers and even middle wares.

With the bust of dot-com era, companies started thinking about ways to lower costs. One of the most obvious was to out-source the non-core aspects of the business. The outsourcing and consulting companies find this really interesting, as they started leveraging their experience across companies and industries. The need for openness and ability to consume third party services led to the advent of web-services and Service Oriented Architecture (SOA).

Software as a Service (SaaS) and SOA

Software delivery as a service has grown rapidly as more and more companies have realized that they can keep the customer relationship active by delivering software as a service, rather than delivering one-time products. I see SOA as a SaaS enabler.

What does SOA mean to an Architect?

SOA provides loosely coupled components. Each component is implemented using open standards for flexibility and future expandability. Architects need to make sure that there is no Single Point of Failure (SPOF) in the end-to-end system and, in some cases, are forced to implement extra caching mechanisms to improve availability and reliability. SOA brings simplicity back to architectures.

What does SOA mean to Development?

To developers, SOA means smaller teams and shorter development cycles. However, SOA also means more coordination across different teams and requires developers to follow standards.

What does SOA mean to an IT organization?

SOA enables faster release trains. With SOA, not all components needs to be upgraded at once. That means Bug fixes can be delivered faster, safer and easier. Less downtime and happy customer. SOA provides business agility. SOA enables continuous change!

What does SOA mean to Management?

SOA means large number of smaller projects rather than one monolithic project. Till date, it has been a nightmare for management, as they have not been able to grasp the power of SOA and the concept of smaller projects. To management, it only means more projects. Since Software development has been famous for not following discipline and processes, SOA has caused more harm than good. SOA requires engineering discipline and standardization.

A lot of organizations have been caught in the messy middle - the market environmental pressures are forcing them to enable SaaS and adopt faster release trains, Technology office and architects are pushing SOA, and the managers are stuck with their dogmatic viewpoints around waterfall methodologies. Engineers are confused, not knowing what to do, and quality is the last thing on anyone's mind.

The irony is that SOA goes hand-in-hand with agile development methodologies like Scrum. If and only if the management can be trained in SOA and newer development mythologies like Scrum, the companies can dream of coming out of this messy middle.

Changing market environment and industry pressures have forced companies to adopt SOA, but not everyone in management is even aware of the change. Management needs to be trained with new ALM tools to be successful.

What does SOA mean to a Company?

SOA enabled applications live longer and the ROI curve becomes very lucrative very fast. For companies, SOA is a blessing (if only they can deliver it right).

Final Thought:
SOA requires better ALM tools and integration of processes. The dependency among different components of SOA is not trivial. Sophisticated tools are required to orchestrate the whole application life-cycle management.

Trackback URL: Understanding SOA

Data Driven Testing (DDT)

We all have heard about data driven testing and how it can improve our ROI exponentially and at the same time reduce maintenance costs. We all believe in it, but we still don't practice it to the extent we should. This blog describes the concepts using a pictorial notation in an effort to bringforth the structural thinking that one needs to implement DDT.

A picture is worth thousand words:-



Step 1:

You start your automation activity with some test procedures in hand. Refer to column 1. A test step is reflected by a donut, hexagon, triangle, etc. These different building blocks combine togather to form a structure, which depicts a test case. Different shapes and their combinations reflect various test cases in the test suite. As you can see, a test case can have many different steps as part of its procedure.

Step 2:

In next step, you start automating one test case at a time. When you encounter a second test case which contains the similar step that you automated before, you move that particular step into what we call "Test Library". You must filter out all common functionality into test libraries over time. Refer to column 2. It shows how you can take common shapes and make library out of them.

Step 3:

As part of Step 3, you separate variability from static functionality. This is the most important step in DDT. Most of the times the variability is the data input; but you may have more variability in your system that you may also want to identify and manage it as data. More the static functionality you can identify, more you'll be able to leverage your automated scripts across datasets. Refer to column 3. All colors depict data. In this step you also make your test libraries data driven.

Step 4:

Once you separate the variability from the core (static) functionality, you'll be able to identify opportunities for more test libraries or leverage existing libraries. Go through this iteration to make sure that you are leveraging your test case libraries to the fullest. Convert more common functionalities into libraries, if required. Refer to column 4.

The more you will think in terms of DDT and leveraging libraries, the easier it will get to automate more in less time. Apart from achieving higher productivity, you will realize that your automated test cases are a lot easier to maintain. Whenever some common functionality changes, you just need to update the corresponding test library. Just imagine updating hundreds of test cases, in case you are not using libraries. Similarly, when some data requirements changes, you will not have to change your automated scripts - just update your datasets and you will be done.

Final Thought:
Tools only provide mechanisms to accomplish DDT or create test libraries, but if we choose not to practice these concepts, we end up creating large autmation code which is both hard to maintain and sustain.