Integrated, “Integration Testing”

As a software development company, what is your goal? What is the one thing you feel you need to do to ensure you have a job at the beginning of each wonderful work week? The answer is actually quite simple; You need to deliver a quality product. Like how I used the word simple? Although the answer I gave was simple, the process to make that answer possible can sometimes be a frightening, unclear, and glooming reality. But then one day you wake up and ask the question, what can I do to make this better? Well, for those who have woke up and asked themselves that question, this should help clarify at least one step in the process to a smoother and more collaborative product delivery.

At the core of every great product, is a great team that has the ability to ensure a product delivery that puts a smile on everyone’s face. We all want to push a product to production and make sure it happens with the least amount of flaws as possible. We also want to do that as fast and efficient as possible. That is where continuous integration becomes a key aspect in your software development mindset. When you look at the grand scheme of things, what scares you about continuous integration? It usually involves a lot of testing, and if you don’t have the proper test automation in place, how will you receive that feedback in a timely manner?

 Well, continuous integration requires continuous feedback. What better way to get continuous feedback then a list of test results that solidify stability of an application? With DevOps at the forefront of every innovative software application these days, the need for solid test automation is critical. It’s so critical that I would go as far to say that you cannot call yourselves a true DevOps shop without some form of test automation built around the application. You have unit testing, integration testing, UI regression testing, and the list goes on and on. So you ask yourself, what kind of test automation is out there? How much do I really need to automate, and where is my value? Well, as many within our company know, I like to break it down into a simplistic format.

Traditionally, you had your three levels of test automation and they were tiered in a fashion that represented a triangle. A whole bunch of unit tests, a good chunk of integration tests, and a few UI smoke tests. Kind of like such…

Many software development shops use this test automation triangle and it serves them quite well. Tests are still automated and the end result is pretty successful. Why argue with something that works, right? Well, I began to ponder on the efficiency of this model after having numerous discussions with some of my very knowledgeable co-workers. Why not tweak that triangle a little bit, and in the spirit of DevOps, get the whole team involved with the process? Wouldn’t it be neat to live in a world where a developer and QA actually worked together to build an automated test? An “integrated”, integration test. Sounds pretty cool doesn’t it? In a nutshell, that is exactly what we did at my company. Now, before I get into explaining the process, let me do a quick explanation of what our test automation triangle looks like now, and why it looks like it does…

Funny looking triangle right? As our team began to develop and improve our testing processes, we found that the traditional triangle reference quickly shifted to a diamond reference. We began to write fewer, but higher quality unit tests around our code. The integration testing became the bulk of our testing because we were able to test our business logic, separate from the actual UI, in a much timelier fashion. And of course, we still had our UI smoke tests that really confirmed that our site was looking the way it should and functioning appropriately. In the past, a developer would write a unit test or integration test, leaving a large portion of the testing effort on them. With a large portion of the testing effort falling on a developer, that leaves less time to actually develop.

 The trickle-down effect starts to show its wear and tear on the unit tests. They become stale, unmaintainable, and irrelevant after a few iterations of work simply because the developer just doesn’t have the time to do it all. Not to mention, the QA were completely hands off from our code and left in the dark with many questions when an ugly bug would arise. In reality, our QA also had a lot of good scenario-based input that was valuable to a developer, but often times that got lost in translation. So what did we do? We brainstormed, we kicked it around, and we finally found an awesome solution for getting the team integrated from a testing perspective.

That is where the wonderful tool of TestArchitect came into play. We were able to utilize TestArchitect as a source for data storage when writing automated integration tests with the help of a developer. The way it works is pretty slick. First off, you have a QA who creates a test module within the TestArchitect tool, this is where the test data or test scenarios lived. Next, a developer would code up a test harness that connects the communication from the data in the test module to the data being returned from a service or API. The cool thing was, when you execute the test, you are left with a combined effort to make that test successful. The developer didn’t do it all, and the QA provided valuable input on the data scenarios that needed to be tested. We “NEEDED” both the developer, and the QA, to work hand in hand which created a natural collaboration between the two of them.

 With the help of TFS, you can then associate all of those tests to run daily, hourly, at check-in, or whenever you feel they are needed to verify that the software being built is being thoroughly tested. I like to explain it in a simple process flow like this; A QA creates a test module that houses scenarios of data within it. The developer creates the harness that links the test data to the service or API that is being tested. And in result, the test executes and shows the quality of your application under test. It turned out to be a really collaborative effort and something that benefited our team tremendously.

So when I titled this article, “Integrated, Integration Testing”, it was intentional. It truly was an effort that integrated our team. With that integrated effort came challenges and experiences that provided so much value to the team in the long run. For the first time, our QA were able to understand the logic within the services of our site, and the developer was able to understand testing from a QA perspective based on the constant exposure to the test scenarios. The more we sat back and watched all of this collaboration happen before our eyes, the more we realized that we have something that really benefits the team. It was really neat to see a team work together to deliver a product that everyone truly cares about. At the end of the day, we all want to build software that pleases our customers. Doing it as an integrated team, just made it that much more enjoyable.

Jake Wallingford   Senior Technical Lead, specializing in Quality Assurance. Experience, and background in Agile software development, Continuous Integration, Continuous Testing practices, and Test Automation. Passion for testing software and providing the best possible online shopping experience for our customers.
Jake Wallingford
Senior Technical Lead, specializing in Quality Assurance. Experience, and background in Agile software development, Continuous Integration, Continuous Testing practices, and Test Automation. Passion for testing software and providing the best possible online shopping experience for our customers.

The Related Post

Having the right skills and experience, even if you have to go outside, is essential for designing tests for large-scale cloud deployments. Moving existing applications to a cloud environment adds new dimensions to testing. One of the primary reasons for moving to the cloud is scalability. Capacity to handle traffic and data transfer can be ...
It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps–not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor, ...
Cloud computing has been the buzzword in the world of Information Technology for quite some time and it is likely to retain that status in the coming years. Cloud computing has been helping business enterprises deliver services faster and cheaper compared to all other existing delivery models. Small and medium business enterprises have changed their ...
DevOps may be the next big buzzword, but Test teams really need to focus on its little sister, Continuous Delivery If you pay attention to trends in software development—from the perspective of what some sophisticated teams are doing, what articles and books are being written, to conference topics, you may have noticed the tools being ...
LogiGear University announces the launch of a new, free video series on Testing in DevOps and Continuous Testing which is available today.
For this month’s book review, I read Continuous Testing for DevOps Professionals: A Practical Guide from Industry Experts, by various authors and edited by Eran Kinsbruner. The book is divided into 4 sections: Fundamentals of Continuous Testing, Continuous Testing for Web Apps, Continuous Testing for Mobile Apps, and The Future of Continuous Testing. The Fundamentals ...
It’s no secret that the cloud is growing at an exponential rate. By 2016, two-thirds of the world’s server workloads will exist in the cloud. But according to Cisco’s 2012 Cloud Index, less than half of server workloads currently run in the cloud. Closing the gap between current capabilities and future requirements is a mission-critical ...
How to ensure a successful test-driven environment In order to ensure a higher quality product is released in the end, many teams have turned to test-driven development. Under this scenario, quality assurance metrics professionals first create various QA tests, and then software engineers code based on these tests, typically while using a robust enterprise test management ...
This post is part of the Pride & Paradev series With continuous deployment, it is common to release new software into production multiple times a day. A regression test suite, no matter how well designed, may still take over 10 minutes to run, which can lead to bottlenecks in releasing changes to production. So, do ...
…On what you need to know before making the transition to EaaS 1. What are the main differences between cloud-based environments and cloud infrastructure? An environment is a collection of infrastructure elements working in conjunction to enable an application stack to work. For example, a simple 3-tier application, with a web front-end component, a business logic ...
  LogiGear_Magazine_June 2016_Testing in the New World of DevOps  
Continuous Testing and Continuous Monitoring What is the goal of Continuous Integration? Is it to enable Continuous Delivery of the code developers’ produce out to users? Yes, eventually. But first and foremost it is to enable ongoing test and verification of the code. It is to validate that the code produced and integrated with that ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe