Why is there a need to work with QA in integrations deliveries?
Testing can be looked upon as a subset of QA (Quality Assurance). It is important that we include testing in customers' expectations. It is often the overall process that quality risks are introduced. Important aspects are definitions of testing, roles, scope of commitment, separation of duties, and stakeholder management in general. The importance is often stressed by senior developers, architects and QA's.
When we work with system integration, we find ourselves in the borderlands between modules, components and applications. In your everyday life where and when can things heat up? Where do things change, what is it that we say recurring in our lessons learned and project evaluations?
"Communication is important"
- System integration concerns changes
- System integration is about data
- System integration is communication
It's all about integration! And despite this, so many of us have been too bad at focusing on overall quality assurance in integration deliveries, an extremely important area!
What is what and who does what?
Let us get started with some basics. One of mankind's basic needs is certainty. We feel safe when we can sense some stability around us. In a project for instance, it would be good to know who does what and what do we mean by, let’s say "integration testing”. I come to think of Martin Fowler’s quote “The term [Integration testing] has become blurred even by the diffuse standards of the software industry, so I've been wary of using it in my writing”. He also suggests that if you get stuck in your project, just come up with a terminology that you all can agree on.
However, let’s at least try to look at ISTQB (International Software Testing Qualifications Board) and the test pyramid to decide on some basics – and start using it in our line of work, to increase certainty and raise quality.
For a software project to succeed, a testing strategy is required. One way of achieving success is to use the Test Pyramid. The Test Pyramid tells us to group software tests into buckets of different granularity. It also gives an idea of how separate responsibilities can be organized to clarify who does what.
Level/type - Responsible/driver
Unit and Component testing - (Integration) Developers
System integration testing - (Integration) QA/Testers
E2E, system and UAT testing - UAT team/Project team/Customer
There you have it. Some basics in quality assurance. Diminish uncertainty by using standards. Communicate, increase certainty, and raise quality.
Other important QA aspects of Integration deliveries
- Determine expectations and separations of duties.
- Find conflicting information in different specifications and discuss it with the integration architect and solution architect.
- Be nice - act communicatively. Get hold of the end-users, don’t just talk to your usual “tech buddies”.
- Question specification details.
- Provide time-boxed, easy-to-understand handovers, including “how to use” instructions.
- Make sure that the integration specification, endpoints and authorization is up to date.
- Make it easy for the next person – tech or business side – to do their level of testing.
- Bring up with PM or PO when you see that UAT team isn’t pushing data through the integrations in their testing. We don't want to find those bugs in production!
To sum up: With quality assurance we try our best to supply a smooth journey for the next person in line and for the entire customer project.
For any questions feel free to contact me:
Integration QA Manager