Key Points on Communication from Test Design

Introduction

Hello! I am mmm from the QA team.

I am mainly involved in the QA of KINTO web systems. The systems we handle include the frontend visible to customers, the back-office area used by dealerships, and several systems for internal operations. Between these systems, various types of data are linked.

Recently, we have adding been more apps such as "KINTO Unlimited" and "KINTO Easy Application". As new features and requirements are added, organizing their relationship to and impact on existing systems is essential. Therefore, it is necessary to understand not only the specifications for each system unit, but also the series of operations in KINTO services to grasp the flow of data.  I personally consider organizing QA work challenging and crucial, especially as each new system or functional requirement increases the complexity and impact on QA as well.

In this article, I would like to focus on test design, discussing challenges from my past projects and considerations when interacting with the development team.

Common Challenges

Specifications for the same function exist in multiple documents

Since a project may involve multiple development teams, each team can have documentation for the same function. Therefore, the following are likely to occur.

• There are differences in content between documents, and the correct specifications are unknown.
• There are wording fluctuations between documents, leading to miscommunication.
• Specifications that should be considered on the development side are buried, leading to bugs.

A specification for the status under review exists.

While reading documents, you may find specifications listed with expressions such as "under confirmation" or "?" as it had points not yet finalized. These have the following effects on test design and implementation.

• Test design: The number of test cases is tentative (may increase or decrease), as we proceed with a tentative testing perspective.
• Test implementation: Testing of undefined ranges cannot proceed, and when specifications change, case modification work will be required.

No documentation that provides a bird's eye view of the status of each system.

While the actual front-end area that is visible to users may display status, on the back-office, level, behind the scenes may retain detailed status, but there is not always documentation that can be seen at a glance.

For example, when purchasing a product on an e-commerce site, a store's status is more (actually, probably more) detailed than the information seen on the customer's side

In the absence of documentation that provides a bird's eye view of both, the QA side needs to organize test design in terms of data linkage between systems.

The specification of the calculation system is described in code.

If there is a test that requires the calculation of amounts or days, we check the development specifications, but they are sometimes written in code. In such cases, there are the following effects.

• Deciphering the code takes time.
• If specifications are not summarized so that a third party can understand its contents, by the time a test is implemented the QA work becomes a silo that depends on the knowledge of specific people.

Considerations When Interacting with the Development Team

Get an overview of the project

Given that the above-mentioned issues are inevitable due to the nature of the project. I believe that first inquiring about the background of the project's inception and understanding its purpose and history can help the QA side better comprehend the specifications. This, in turn, enables questions about potential excesses or deficiencies in the specifications.

Request an outline of scenario operations.

Although the specifications for each system are available and you can understand if you read documentation, receiving explanations directly from the development side who understands the system has the following advantages. (The QA side often makes its own materials to understand the specifications and gain a bird's-eye view.)

• Easier to understand the operation of the intended actor/user
• Easier to visualize data flow
• Timely questioning promotes a deeper understanding

Check the segregation of documents

We will simply check to see which documents contain the correct specifications for this functional requirement and screen design, and whether other documents exist but are outdated notes, as it cannot be determined.  As the content of the area in which each development team is in charge is often up-to-date and correct, we aim to minimize the burden on the developer side by asking closed questions.

<Example> "Is it correct that Document A accurately reflects the specifications for ●●? May I confirm that Document B also contained the same information, but slightly differently? "

Review the Restrictions

If there are currently known restrictions in QA work, asking for sharing in advance will make it easier for the QA side to consider how to respond.

Request a separate briefing for complex specifications such as calculation systems.

Since various prices and plans exist, there are multiple formulas for calculating them. Even with similar formulas, the values obtained may differ slightly. To prevent mistakes in advance, we are conscious of clarifying the following when asking for explanations from developers.

• The original meaning of the amount
• The meaning of values used in the formula and where they are referenced
• How to count the number of days
• Considerations to keep in mind when testing
• Existence of calculation tools

For calculation systems, the QA side often creates its own calculation tools for efficient testing. Specifications are compiled and finally reflected in the tools through discussions with developers.  In addition, although I mentioned the calculation system this time, if a specification proves challenging to understand, direct consultation with the developer is often sought.

Conclusion

When I was struggling with the content of this writing request, a member of the development team who is also in charge of this blog said, "It would be helpful to know what kind of information the QA team wants when requesting QA."  Despite not directly aligning with this content, I wrote it with the hope that it will be useful for awareness of QA work other than testing by sharing information on the challenges in test design, which is the starting point of QA work.

In addition, the development team has already given consideration to the challenges mentioned above, and I feel that the work environment is quite organized compared to when the QA team was first formed.

Nevertheless, I believe that one of QA work is to organize information that cannot be seen from documents alone, so I will continue to exert effort not only to read the specifications but also to seek and organize the impact on other specifications.