Tuesday, September 26, 2023
HomeManagementWhat is a "test perspective"?

What is a “test perspective”?


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.

test perspective
test perspective

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.

test perspective
test perspective

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”.

So how do you organize your test perspective list?
The author organizes the test viewpoint list into two lists, “functional element + confirmation point” and “evaluation angle + test parameter”. The image is shown below.

Functional elements confirmation point
Confirmation target Confirmation details
Screen display test Layout Arrangement of screen parts (characters, images, icons, scroll bars, etc.)
Perspective display Size, shape, line type, fill, gray out
a letter Wording, garbled characters, broken characters, broken line breaks

Table 1. “Functional element + confirmation point” list image

Test parameters Verification angle
type factor level
factor Level
major classification
data text Character type Basics Half-width, uppercase, alphanumerical Normal variation test
Special Machine-dependent characters Semi-normal test
event Touch panel Touch operation generally Tap Normal variation test
simultaneous Simultaneous tap Semi-normal test
Table 2. “Evaluation angle + test parameter” list image

In this way, by changing the item list according to the meaning of the “test perspective” and listing it, it is easy to organize and browse.

in conclusion

The “testing perspective” is a very important idea, but the word “testing perspective” itself is ambiguous. The ambiguity caused the problem that the test perspective list was difficult to organize and use. We have shown that this problem can be solved by introducing a test perspective model.

The test perspective model was created to make it easier to reuse past insights about testing.

-Which element of the test target is to be tested (functional element)
-What characteristics of the test target are to be tested under what conditions (verification angle)
-What values ​​and events are added to the test target (test ) Parameters)
・ What to observe for the test target (confirmation points)

At the beginning of this article, I mentioned that the purpose of the test perspective list is to improve the efficiency of test design and prevent omissions. However, the test perspective list is not meant to be used simply by copying what is written there.

The test perspective list is meant to be used as a basis for not missing out on the basics of test design and as a guide for a deeper look at what is being tested.

If you ever want to know about similar things, check out the Facebook page Maga Techs.



Please enter your comment!
Please enter your name here

Recent Posts

Most Popular

Recent Comments