{{announcement.body}}
{{announcement.title}}

Accelerate Software Testing by Sharing Test Assets Across Dev and Test Teams

DZone 's Guide to

Accelerate Software Testing by Sharing Test Assets Across Dev and Test Teams

With the right tool, you can accelerate testing across dev and test teams.

· DevOps Zone ·
Free Resource

While the whole shift-left concept is indeed incredibly valuable, you can accelerate testing to keep up with development by simply reducing rework across functional testing and improving collaboration across teams — that is, if you have the right tool.

As 2019 continues, I had to reflect on the thousands of conversations I have had over the last year with QA, test engineers, and managers. Last year, especially the last quarter of it, was dominated by conversations about accelerating testing, especially how to align testing strategies concurrently with development. So I had the distinct pleasure of sharing with many people how to reduce rework across functional and nonfunctional testing with Parasoft SOAtest, simultaneously improving collaboration across teams while accelerating testing to keep up with development.

I can confidently say that SOAtest is the complete solution for functional test creation and automation. It is the blood, sweat, and tears of over 17 years of development, produced by a company whose single, dogged focus is test automation and making testing easier and streamlined for its customers. In terms of end-to-end testing, it reduces the manual effort of test creation for various types of functional testing, such as Service Definition/Contract tests, smoke tests, API component tests, API scenario tests, Web UI tests, database tests, omnichannel tests, microservices tests, performance/load tests, and API security tests, all of which are easily automated and can be tied to your CI/CD pipeline through a command line interface or SOAtest's award-winning REST API.

There is a lot of raving that I can do about SOAtest and its depth of technology, innovations in AI and machine learning, and the success it has had in enabling our customers to achieve their goals for quality and delivery; however, today, I want to talk about the value that is unlocked when an organization uses SOAtest to bridge the gap between development, QA, and performance testing teams, to reach complete synergy in a testing organization.

Development Lays the Groundwork for Testing

So I'm just going to rip the band-aid off and lay it out there: development should test.

And I'm not just saying unit testing (which is obviously valuable). Development should be involved in testing any new or changed APIs. Now, I am not saying development should be building full testing scenarios, and I think when you really dig into it, development is most likely already doing some of the testing. I'm talking about when a new API is being built out, or an API has undergone schema or service change, development typically does minimally create contract tests and smoke tests for each of those APIs to validate that the service contract is written according to specifications and to validate the schema (request and response) and endpoints (HTTP, MQ/JMS Topic/Queue, etc.).

If developers can start using the same functional testing tool to create tests, the QA team can simply leverage these tests to form the more complex test scenarios that they need to validate. So how can developers leverage Parasoft SOAtest to help accelerate testing?

Developers Can Create Service Definition Tests

With Parasoft SOAtest, developers can very easily validate:

  • Is the service definition semantically correct?
  • Is the service described valid?
  • Does the service meet interoperability standards?
  • Has the service recently changes?

Developers using SOAtest easily create tests to validate and enforce policies of a WSDL, Swagger, RAML, etc., through the consumption of that service definition file. SOAtest will perform schema and the sematic validity tests to make sure the definition file is machine readable and consumable. It will validate the interoperability to make sure it adheres to the industry standards of a service definition file, and finally, it will create a regression test to validate that nothing has changed since the last test run.

These tests provide that stable foundation that QA can leverage to efficiently build a solid and resilient testing strategy (more on that in a moment).

Developers Can Create Component Tests (Smoke Tests)

Using Parasoft SOAtest, development can easily create their component tests, to test the individual components of service looking to validate that the:

  • Request/Response payloads are well-formed
  • Response status is as expected
  • Response error payloads have the correct error messages
  • Response is meeting baseline criteria
  • Response is received within an expected timeframe

With SOAtest, creating these functional smoke tests is literally as easy as uploading your definition file to SOAtest and selecting "create functional test." This will parse your API automatically, creating one test for each individual service contained within that API. These tests are immediately runnable, and allow developers to spend minimal time validating that errors they may have received are the correctly-expected error messages and responses.

Accelerating Testing by Improving Collaboration and Leveraging Work Across Teams

Development at this point has done its job — they have validated the basic functionality for each service, and now it's QA's turn. Testers need to create tests that go beyond basic functionality and test the actual business logic and complex scenarios of the API to discover unforeseen and unexpected behavior. Dev does a beautiful job of building it, and QA's job is to create complex scenarios meant to test the stability of the services as they function in concert. I like to look at it like this: when development has utilized SOAtest for their contract and component tests, QA comes to a kitchen already stocked with ingredients laid out ready to be mixed, blended, and assembled into a meal.

It's amazing to me how valuable this reusability of test artifacts is, and how much it can accelerate testing practices, simply by eliminating the rework of QA creating tests that have already been done by development. In the work-smart paradigm, QA starts with the stocked kitchen and can get more done in less time. It's just logical.

Let's look at how this can accelerate testing.

Reusing Developers' Test Artifacts to Efficiently Create Meaningful Scenario Tests

QA can reuse the same component tests that the developers created in Parasoft SOAtest to make sure that everything works in a specified scenario. They can:

  • Ensure the APIs work when combined into a scenario
  • Drive the test with data
  • Use response data to feed into subsequent requests
  • Optionally leverage start up and tear down tests

Because QA already has the building blocks it needs (courtesy of development), they can scriptlessly pick and choose, with simple copy-and-paste commands, the individual components that are going to be used to test their scenario. These components can be dragged and dropped into the right order and restructured to create each scenario. The responses and information from the first test can be parameterized with a few clicks, and used to drive the second test's request data, and so on and so forth down the line.

These scenario tests are created more efficiently, benefiting from the components provided already by the development team. With SOAtest, you can take this efficiency a step further, reducing, even more, rework by "templatizing" business logic (i.e. assertions, validations, authentication) into rules, with machine learning. Reusing test logic improves the consistency of API testing while accelerating testing by eliminating work that has previously been completed by another team member.

Reducing the Ping Pong Between Dev and Test to Accelerate Defect Remediation Times

One consistent struggle that arises due to the gap between Development and QA is the ping pong in communication that occurs when a defect is found by QA. It is a time-consuming task to document that defect, take the screenshots, write out the exact test steps taken that revealed the defect, and then communicate this to development, who will often come back with the frustrating reply that it works fine in their environment.

This ping-pong between Dev and QA slows down defect remediation times and takes valuable time away from both the developer (as they struggle to recreate the test environment) and the tester (who gets caught up in a broken documentation and communication cycle rather than spending their time creating more tests).

Instead, when both teams are using Parasoft SOAtest, this communication/collaboration gap is filled by the creation of re-runnable testing scenarios, dramatically speeding up the knowledge-sharing between testers and development. When a QA member finds an issue they can quickly create a test scenario (.tst file), showcasing the behavior, which can then be shared with the development team. Development can then run the test scenario on their machine to see the behavior and can see the exact steps and calls that lead to the incorrect behavior shortening the defect remediation time.

Managing API Schema and Service Change to Reduce the Debt of Test Maintenance

QA is now working smart. They have created a consistent strategy for testing their APIs that is built upon the existing component tests created by Development, that reduces rework by templatizing the application of business logic so that it can be reused and leveraged across the testing team. But what happens when change is introduced to your applications?

Change can take many forms such as:

  • Protocol message format change
  • Elements added or removed from the API
  • Code changes affecting the data format
  • Services undergoing re-architecture to microservices

Usually, a giant headache to QA organizations is understanding those changes, identifying the test cases impacted by the change, and updating and rerunning those test cases to validate that the changes have not broken anything. Without SOAtest, these things require a heavy amount of study of the two versions of an API definition file along with a herculean effort to understand the tests impacted and how to either edit or rewrite each impacted test to validate that change.

SOAtest gives QA an easy way to manage and mitigate the impact of change through its Change Advisor module. Remember those Service Definition or Contract Tests that were so important for stocking QA's kitchen? Those Service Definition files come back to help with change management.

When a change occurs within your API schema or services, Development will update that definition file and provide QA with the newest version. SOAtest's Change Advisor module comes in and automatically compares the new version of the definition file with the old version, creates two maps that graphically lay out the operations and the schemas between the old and new definition files, and then QA can come in, easily identify what needs to be changed, and with a few simple clicks, review and update based on the changes. And once all changes have been reviewed, that change template can easily be applied to automatically bulk refactor all existing tests impacted by those changes.

Reusing Existing Test Artifacts in Performance

QA has now done its job. Testers have created multiple complex testing scenarios meant to test the business logic of the API and validate the functionality of the services in concert with each other. The business logic is sound, and each use case has been tested and validated. Any defects found have been easily communicated back to development in the form of a .tst file for quick reproduction and remediation. There is a comprehensive and minimally-manual strategy in place for maintaining those API tests and updating tests when a change occurs. Now it's time to break the application — it's time for the performance testers to test the behavior of the API when it has 100, 500, 1000+ users trying to perform the same scenarios at the same time from varying locations around the world.

In many cases, a performance tester would need to create his or her own testing scenarios specifically under these conditions. Fortunately, by leveraging Parasoft SOAtest, the performance team again doesn't need to reinvent the wheel. They can utilize the combination of component tests created by Development and the Scenario tests created by QA to validate their SLAs and the timely performance of the application, all within the SOAtest's Load Test module.

Within the Load Test module, existing SOAtest component or scenario tests can be easily leveraged and driven with any possible number of virtual users and spread across any number of slave machines to test scenarios under different load types such as bell, buffer, linear, and stead load, allowing you to validate that the application can behave as expected under the various types of stress.

Conclusion

"Work smart, not hard" should be the end goal with your functional testing strategy, but doing the same actions, again and again, has instead been the norm for testing teams when it comes to API testing. So often, I speak to QA Managers and DevOp Coaches who are tasked with identifying ways to accelerate their testing velocity and increase collaboration, and what I've described here is the answer.

Teams can reduce rework and increase efficiency by leveraging the capabilities of SOAtest. It is easy to adopt at both the enterprise and single project or startup level, as it has been created to deftly scale, and it requires a low level of technical expertise for test creation and automation. Having one unified tool for functional testing used by Development, QA, and Performance allows for a groundbreaking level of collaboration and a reduction in rework that can impact the bottom line, reducing overall testing efforts, time, and costs.



If you enjoyed this article and want to learn more about Automated Testing, check out this collection of tutorials and articles on all things Automated Testing.

Topics:
testing ,performance ,test artifacts ,qa ,devops

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}