What is a “test perspective”?

Introduction

The “test perspective” is very important in designing a test. However, there are some cases where the “test viewpoint list” that summarizes the “test viewpoints” has become a mere ghost and is not used in practice. In this article, we reorganize what the test perspectives are in the “test perspective model” and show the basic structure of the test perspective list.

What is a “test perspective”?

“What is a testing perspective?” Is explained in various places, but most of them are as follows.

“It’s like a” cut “in testing, such as items to check whether the software works properly, points of view, and ways of thinking.”

In this paper, the summary of test viewpoints is called the “test viewpoint list”.
The purpose of the test viewpoint list is as follows.
・ Reuse the knowledge gained in the past to improve the efficiency of test design.
・ Reuse the knowledge gained in the past to prevent omissions in both test design and test execution
. It is a tool for knowledge management for design and implementation and is created by many organizations.

“Test Perspective List” Problems and Causes

I can’t use the test viewpoint list I made!

As mentioned above, the test perspective list is a very important tool for preventing test omissions and streamlining test design.

However, there are cases where a test perspective list is created and read once, but it is not reread and is not used during the essential test design. With this, the test perspective list is no more than a timely “material” and is not a tool or asset for sharing test knowledge.

Knowledge and tools that are not used are, of course, unimproved.
Even if you make a test viewpoint list at once, it will not be used. In such a situation, you may add or update new items to the test perspective list. In that case, the viewpoint list created with great care will become a mere ghost, and the improvement of tests such as efficiency improvement and prevention of omissions will not progress, and the skill improvement of individual test engineers will not progress.

Why is the test perspective list not used?

So why isn’t the test perspective list we created used? There are several causes, but it seems that there are many cases where there is a big problem in how to make a test viewpoint list and how to organize each test viewpoint.

Specifically, there is a problem with the itemization of the test design list.
The test viewpoint list that you often see is organized in a hierarchical structure such as “major item”, “medium item”, and “minor item”. The rules are unclear and disjointed.

If the test perspective list isn’t too much and you can get a bird’s eye view of the whole thing, it shouldn’t be a big problem if it’s a little poorly organized. However, as the number of items in the test perspective list increases, readability becomes very important. Looking at a list of hundreds of poorly organized test perspectives and telling them to use it is unmanageable.
A poorly organized, or poorly readable, test perspective list can be very difficult to use, even if the individual content in the list is good.
In the field of testing, it is a race against time, so it is faster to design a test by yourself from Hana than to have a hard time reading the test viewpoint list where the necessary information cannot be obtained immediately.

Even if the large, medium and small items in the test viewpoint list are unified, it cannot be solved.

The following is a summary of the problems raised so far.

Organizing the test viewpoint list The usage of “major item”, “medium item” and “minor item” is not designed
↓ The
test viewpoint list is difficult to browse 　　　↓ The test viewpoint list is not used when working on the test design
↓ Test Knowledge is not shared, and test improvement/skill improvement does not progress

Then, it is not such a problem if we should unify the proper use of large, medium, and small items.
I’ve tried it, but I couldn’t organize it well.

The test perspective list I’ve seen wasn’t entirely random. From the list of test viewpoints, which seemed to be cluttered and disorganized at first glance, when I extracted a certain group and looked inside that part, the large, medium, and small items were classified reasonably.
However, when I looked at another group in the same test perspective list, there was another rule, and within that part, the large, medium, and small items were divided reasonably.
In this way, although the test viewpoint list is partially controlled, when viewed as a whole, there are many rules for how to use large, medium, and small items in one test viewpoint list, and as a result, the whole. It was in a state of disorganization.

Gathering and simply merging the perspective lists organized around the corner results in a huge, chaotic, unusable list of perspectives. If so, I tried to sort out that the problem could be solved by unifying the definitions of “major item”, “medium item”, and “minor item” in the test viewpoint list, but there are various test viewpoints. Because there are things, it was difficult to unify the rules for itemization.

In short, what I want to do is “make it easier to organize the test viewpoint list” and “make it easier to browse and use the test viewpoint list”, but to achieve this, once again “what is the test viewpoint?” I had to go back to the point of “Is it?”

In the next chapter, we will move away from the test perspective list and continue to explain what the test perspective is in the first place.

Test perspective model

At the beginning of this section, we have defined the test perspective. Once again, quote below.

“It’s like a” cut “in testing, such as items to check whether the software works properly, points of view, and ways of thinking.”

In the above, it says “like a test cut”, but there are various cuts. However, it’s ambiguous what the cut is, which causes the test perspective list to be cluttered and unorganized.

Therefore, I took the approach of reorganizing what the “test perspective” is and reconstructing the structure of the test perspective list based on it.

First of all, to reorganize what the “test perspective” is, we list what is commonly called the “test perspective” and what meaning and position they have. It is analyzed and related to each item, and summarized as a ” test viewpoint model”. The conceptual diagram is shown below.

As mentioned above, the test viewpoint model is roughly divided into four components.
(1) Functional element
(2) Verification angle
(3) Test parameter
(4) Confirmation point
* There are other components of the test viewpoint model, but they are omitted in this article
because they are unnecessary to explain the contents of the test viewpoint list

Below, I will explain the contents in order.

① Functional elements

For example, screen display test, screen transition test, input confirmation test, connection operation test, playback operation test, and security test.
In this way, the functions to be tested are decomposed and symbolically represented.

② Verification angle

For example, normal variation test (normal system test), normal limit value test, quasi-normal system test, abnormal system test, functional compound/competition test (combination test), configuration test (compatibility test), localization test, stress test, aging. Tests, performance tests, usability tests, etc.
In this way, it represents what characteristics are verified under what conditions for the function to be tested.

③ Test parameters

For example, what kind of character should be given to the character to be input? (Full-width, half-width, alphanumerical, Chinese characters, symbols, etc. Also, their bias (uppercase only, lowercase only, etc.), mixed (mixed uppercase and lowercase letters)
. For
example, an event such as sending a song immediately after playing music or sending a song just before the end of playing music.
In this way, what value or state is given to the function to be tested, what kind of event is generated, and so on. In addition, it represents what to “input” to the test target.

④ Confirmation point

For example, in the case of a screen display test, is there a part where the wording of the components of the screen display does not match the specifications, and is there any character breakage or garbled characters?
For example, in the case of a video playback operation test on a smartphone, etc., is there a synchronization gap between the video and audio?
In this way, observe the behavior (output) of the test target, such as whether the test target is operating normally, whether there is anything that does not match the specifications, and what kind of symptom is exhibited if it operates abnormally. It shows whether to do it.

Structure of test viewpoint list based on test viewpoint model

There are various “test perspectives”, that is, “test cuts”, but based on the test perspective model shown above, they can be organized into the following four categories.
(1) Functional element
(2) Verification angle
(3) Test parameter
(4) Confirmation point

Since each of these points to something different, it was impossible to simply organize the test viewpoint list by “major item”, “medium item”, and “minor item”.