Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Step 2 of 2:
databases. Both architectures can become quite complex, comprising multiple components, servers and physical locations. Can changes in one tier or component cause problems in the others? The answer is a resounding maybe.
First, one should test the individual components of business logic, user interface, services and data access layers. This testing isn't really about evaluating the dependencies among systems, but nevertheless is vitally important. For example, if a change to component A makes component B stop working, maybe component A is broken. But before getting into the complications in their interactions, make sure A and B are both functioning as expected.
Passing data from one system to the other may be the weak link in the chain.
Gerie Owen
Enterprise architectures often have complex interactions, which means that passing data from one layer to the other may be the weak link in the chain. How does one test these interactions? In most cases, this is done either through SOAP testing or API testing. Assuming that the services have been fully tested, you'll need to ensure that a similar quality exists at the interfaces. Companies and other services utilizing your components have to have a high level of confidence that the quality and performance of those components meet their standards.
Additionally, you have to test not only your software, but also the SOAP or API interfaces. There are specialized tools for this kind of testing, including SmartBear's Ready! API and Parasoft's SOAPTest. Although you may not need these specialized tools, making sure that the interfaces are sufficiently robust and high performing so as to add immediate value to any solution you propose.
Finally, if you are using a legacy component architecture such as Common Object Request Broker Architecture (CORBA), convince your organization to get out of it as soon as you can and use either traditional Web services or APIs. CORBA was both highly complex and difficult to test, and so most software teams have since moved on to more modern architectures.
I've been a tester for many years and want to progress professionally. Yet, I'm struggling to find chances for advancement and a career path in ...
Continue Reading
There are numerous DevOps tools, so as a tester, is it necessary to know all of them? Gerie Owen explains why tools might come secondary to the goal ...
Continue Reading
As a junior tester, I think learning scripting languages could make me more valuable to my team and enhance my career. But how do I pick the ...
Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.
What solution(s) to this problem is your article answering, exactly? There are so many of these things published by TechTarget, I rarely take the time to look through them. I made an exception for this one, because it's a great topic and a continuing source of challenge, time, resources and a significant inflection point in a project/program's success (or not) in getting over the finish line. I was disappointed in what I read; as the old Wendy's commercial expressed, "where's the beef"? This article could have provided so much more value, for anyone (and that's pretty much everyone) that manages projects with complex system integration, multiple-layer/-tier components in any given Service being delivered. How about adding a suggested/proposed process flow diagram, showing the sequencing and suggested order for testing the various pieces, once unit testing is completed? Are all the individual components integration tested at once, or is there a specific order/sequence that should be followed for optimum efficiency and/or quality? What about overall End-to-End (E2E) testing, at the end of the individual component integration testing effort - to test the overall flow of requests and responses that are flowing through the layers/tiers? When's that done? Who's responsible/accountable for each piece of the integration testing chain? What about environment constraints/considerations - should integration testing be done in the Development (unit testing) environment), should it be done in the System Testing environment, where? How about communication and coordination - important? Any suggestions/strategies/tactics for planning out, then executing the communication/coordination strategy for the various service-to-service integration testing? How about a typical/template project plan - what would one look like for the integration testing effort? What about Test Planning for integration testing - is it the same, or different than unit testing? SIT? UAT? Who should be responsible/accountable for pulling together this plan? for contributing to it? What do the test cases look like, and the test data to support the test cases? Over what timeline/schedule should integration testing typically be done? These are the burning issues that we as project and program managers face every day in these complex development and delivery efforts. The article, as it stands, doesn't answer any of these questions/concerns... Would love to see a follow-up that digs into these questions, and more, in more depth that provide someone with an actionable and implementable solution.
"A simple approach to system integration testing" Yep, the title is totally misleading. The articles does mention important aspects in bits in pieces. Should also have included risk assessment.
Join the conversation
2 comments
Yep, the title is totally misleading. The articles does mention important aspects in bits in pieces. Should also have included risk assessment.