An illustration of the software Test book __ Modeling

A collection of illustrations, testing in one of the books you have seen it. I recommend this book, but also because the author of the book layout, the paintings are personally involved, elegant layout, easy to read and not boring. The illustration of this book is completed by the author, the author's baby and the illustrator.

Pirate Pie Test Analysis Mfq&ppdcs

I want to choose this book layout show:

The illustrations in the screenshot below come from hand-drawn. The Pirate Pie Testers is a group of testers who:

They hold the same test idea
They believe that testers are the core of the test, higher than the test process and test tools
They try their best to hone their test skills and improve their testing skill.

The vision of this book is described as:

for Those who are software testers, or who are interested in analyzing a transaction, are not software testers;

They have the need to (systematically learn software test analysis skills, or to understand the software test analysis);

this "Pirate Pie Test Analysis: Mfq&ppdcs" is a (with test analysis as the core content, Mfq&ppdcs as the implementation of the framework of the book).

This book (a systematic description of the testing skills involved in all aspects of the test analysis, supplemented by a large number of practice cases),

Unlike most of the books on the market that explain test design,

The main point of this book is not to explain an existing test design method, but the idea of "starting from the actual problem, not from the method", from the point of test analysis and test designers, when taking over a new system or tested characteristics, how to use a variety of test skills, Analyze the object step by step and finish the test task successfully. before reading the book, learn about the following six questions that will tell you if you want to choose

Question 1: Why the appropriate readership is "Software testing practitioner".
For (those software testers, or non-software testers who are interested in how to analyze a transaction),

They have the need to (systematically learn software test analysis skills, or to learn about software testing and analysis of this matter).

There are two reasons why readers are positioned as "software testers" rather than "software test analyst [4]".

Reason one: The software testing skills mentioned in the book are universal.

Universal testing skills are not only beneficial to those involved in software testing and analysis. Alternatively, learning to analyze a subject from a test point of view is an essential skill for every Test practitioner.

Reason two: I do not agree with the creation of a "software test analyst" such a dedicated post

The division between the "Software Test analyst" and "Test executor" is more likely to lead to a separation between the test analysis design and the test execution. Software Test analysts "rarely do test execution because it is not part of their work, and software test executives have fewer opportunities to do test analysis and test design."

"Test analysis and Test design" and "Test Execution" are the basic activities of software testing, but no one is required to perform these activities serially, sequentially, and in a phased manner, much less as "some people can only engage in a certain type of test activity." In fact, these two types of activities are so closely related that only they can complement each other with frequent feedback and synergy to achieve the best results, as James Bach said: "It is difficult to try to divide a comprehensive cognitive activity into two parts and work well alone." [6] "

The reader of the book "Software Testers", not only does it need to be divided from test positions, nor does it need to be differentiated from the way tests are executed, whether you're a manual tester or an automated tester, it's also useful to believe that many of the test skills mentioned in the book will work for you, not to mention the number of test experiences. Whether you're a novice in the testing industry or a veteran who has been in software testing for more than 10 years, the book has a more or less perspective that has been validated several times in my "Mfq&ppdcs: Software test analysis and test Design" offline training course. Of course, different people read this book's Harvest and inspiration will be different, this book footnotes listed a lot of relevant reference learning resources, if you are willing to explore, follow, you can maximize the value of the book.

Question 2: Why it is also appropriate for "non-testers who are interested in parsing a transaction".
For (those software testers, or non-software testers who are interested in how to analyze a transaction),

They have the need to (systematically learn software test analysis skills, or to learn about software testing and analysis of this matter).

If you are not a software testing practitioner, such as a software developer, a product requirement analyst, or you are not an IT practitioner, you can also flip through the book if you are interested in how to analyze a transaction.

In the current world of information diversification, many innovative ideas come from the "cross-border" behavior. Steven Johnson[7] has studied the common features and development patterns of a series of recurring innovations, "innovation is an open door", and one of the most important innovative models he puts forward is "neighboring possible (adjacent possible)". When we often take the courage to step across the boundaries of our familiar domain, it is often found that in another adjacent field, there are many problems, ideas, ideas and knowledge are interlinked, as if the initiative opened a door, to explore the new "adjacent possible" provided the conditions.

In fact, there are a lot of small creative ideas in this book that I was inspired to read in the non-test theory books.

For example, the 5 main chapters of this book "Kym" "TCO" [8] "Modeling (modeling)" "TD (Test design test)" "TE (Test Execution testing execution)" is divided by the adventures in experience Design [9] The effect of this book is that the author uses the process of designing the user experience in 5 s to represent (sponge, Spark, Splatter, Sculpt, Storytell), while the 5 s are subject to the software development Lifecycle 5 D (Discover, Inspired by Define, design, develop, Deploy).

For example, the book "Curation and subtraction heuristic (filtering and culling heuristics)" is a book from the field of graffiti "The Doodle Revolution" [10], for a infodoodler, It is often necessary to extract critical information quickly, or even in real time, from a large stack of text or live lectures or discussions, and then visualize it, which is similar to the quick extraction and presentation of the information that testers have to offer.

So, look forward to this book on software testing analysis of some of the non-software testing practitioners also have some reference to the role:

If you are doing "software analysis", you can focus on the previous chapters "Kym" "TCO" and "Modeling (modeling)";
If you are the manager of a software project, you can focus on the "Kym" TCO and the Test Execution (TE) chapters for other chapters.
If you are engaged in an industry that needs to quickly extract critical information and perform structured rendering, the "Kym" and "TCO" chapters are available for your reference;
If you are interested in "expressing a complex logical idea with a simple graphical model", you can refer to the chapter "Modeling".

what the problem 3:mfq&ppdcs.
This "Pirate Pie Test Analysis: Mfq&ppdcs" is a (with test analysis as the core content, to Mfq&ppdcs as the implementation of the framework of the book);

The book (a systematic description of the testing skills involved in all aspects of the test analysis, supplemented by a large number of practice cases).

The MFQ embodies the 3 main dimensions when analyzing a measured object from a test point of view: The measured objects consist of which single functional (MD), functional interaction points between functions are worth testing (FI), and what non-functional quality attributes are required to be tested (QC) [11].

For the M section, Ppdcs provides a way to "choose the right model for single function modeling", each letter representing a model feature.

To mention the origins of Mfq&ppdcs, the story dates back to 2008 years.

I was in the 8th year of software testing at  and was involved in a test process improvement project the following day after the transition from "functional testing for a specific feature" to "responsible for testing skills upgrading across the department". The so-called test process improvement, in simple terms, is to find the current test work in the weak points, to seek improvement measures, to carry out improved implementation and tracking. I was acutely aware that the design of the test was a worthwhile direction to improve (not knowing the difference between the test analysis and the test design at the time), and volunteered to embark on an exploratory trip to test design improvements.

I analyze the existing characteristics of the test design documents, interview developers, testers and project managers, collect all the questions and problems encountered in the test design, learn the industry test design methods, read the test design books and articles, and finally wrote a "test designs Problems Investigation "(Test design Problem survey) [12] investigation report. It talks about the two outstanding problems in the test design: One problem is that the weak single function test analysis, the tester did not divide a measured object into different parts of a separate test, but for the object of the test of the whole of some functional and non-functional properties tested, MFQ is proposed to solve this problem Another problem is that the existing test design techniques have not been used systematically, and Ppdcs's proposal is to solve the problem.

Any object being tested, whether it is an attribute or a system, are structured (structured), each "whole" object can be divided into "parts", each "part" to assume a certain function, I put this can be tested independently of the "part" called " Single function (discrete function) ", because the model for a single function modeling to carry out test analysis, so, also known as" model-based single function (model based discrete function), you can use MD simplified representation, People who are familiar with MFQ are simply represented by a letter m; In addition, there may be points of interaction between a single function and a single function, the entire feature/system and other features/systems that need to be tested, called functional interaction (function interaction), which can be represented by FI, To put it simply, a letter f is used to indicate that, for a single function or for the entire feature/system, some non-functional quality attributes (Quality characteristic) need to be tested, as well as a simplified representation of QC with a letter Q.

When I was doing a test design survey, I found that many features take into account the test of some functional points on the whole (f), the interaction between the feature and other features (f), and some non-functional tests (Q), but rarely consider M's test, that is, not dividing the feature into multiple single functions, Then test for each single function. It is as if there is a building, everyone is concerned about the appearance of the building is elegant, the overall quality of the building is safe and reliable, the structure of each floor is reasonable, but few people pay attention to the quality of each room, or even the quality of each piece of brick. Of course, the concepts of M and F, part and whole are relative, and you can get more information about this in the TCO chapter.

The survey also found that a lot of test ideas[13] came through the "head" approach, and the test industry for more than half a century, more than 10 kinds, or even dozens of kinds of test design technology has not been widely used in the system. What is the reason. It is these technologies that remain at the theoretical level and are not useful in practice. Or our products are too special, these technologies are not suitable. Or testers have not heard or learned these methods, will not use. There are other reasons.

I have selected more than 10 commonly used test design techniques, including equivalence classes, the boundary value, the judgment table, the causal diagram and so on, each method carries on the study, the practice, the analysis its characteristic, then randomly selected some characteristics in the product, attempts to use 2 kinds of to 3 kinds of test design technology to analyze and modelling to it, compares the superior which is inferior. After months of groping, a thought loomed in my mind, the object and test design technology, like two meshing gears, choose which test design technology for a specific object to be tested for modeling analysis, there must be a certain factor played a key role, so that two gears can be very good to bite together, What is the key factor.

In the attempt and the thought, something of a certain regularity has gradually surfaced. [14]: Careful study of these basic test design techniques reveals that they can generally be categorized into several categories, each with its own unique "characteristics", while the specification of the object being tested is described It is found that the internal logic of the measured object can be expressed by abstracting some kind of "characteristic". Then, when the two "features" coincide, this test design technology can be used to analyze the object, Ppdcs idea thus came into being, each letter represents a "feature" of the English acronym. You can learn more about Ppdcs in this chapter of modeling (modeling).

Question 4: The relationship between test analysis and test design.
This "Pirate Pie Test Analysis: Mfq&ppdcs" is a (with test analysis as the core content, to Mfq&ppdcs as the implementation of the framework of the book);

The book (a systematic description of the testing skills involved in all aspects of the test analysis, supplemented by a large number of practice cases).

In the years that have just been tested, there is no difference between "test analysis" and "Test design". Even rarely mentions the term "test analysis", more about "test design", the sense of test design is a relatively vague process: input is the demand, and then after testing the design of such a magical black box, The test instance comes out. In fact, just as developers don't get the need to write code directly, instead of a series of requirements analysis, functional design, technical design processes (in agile projects, these processes are short and rapid), and then write specific code, testers also need to go through a "systematic, incremental, analytical process," Then carry out the test and design a concrete test example [15].

What we usually call "test analysis and Design", to some extent, is to confuse "test analysis" with "Test Design", to blur the difference between the two, or not to emphasize the important position of "test analysis". When I was doing the test design question, I happened to read an article by Mike Smith [16] and found our point of view to coincide. Mike Smith wants people not to say "test analysis and design" in general terms, but rather to express it as "Test analysis and Test design", since "Test analysis" and "Test design" are two different test activities. He considered "Test analysis" to be a "What Issue"-What are the measures & targets of success for testing. (Test the goals and criteria for success.) "Test Design" is a "how Issue"-how would those measures and targets be achieved. (How these goals and standards are achieved.) ）。

Similar to this view and Torbjörn Ryber, I was fortunate in early 2008 to participate in the Torbjörn Ryber test analysis and Test Design course, the course greatly felt his attention to the test analysis process. Torbjörn Ryber likes to think of the process of testing as a problem [17], specifically, "test analysis" can correspond to "how Issue"-How does I ask questions? (How do I ask questions?) , the "Test design" can correspond to "What Issue"-What questions do I ask? ）。

"Kym" "TCO" "Modeling" is all about "test analysis", "TD (Test Design)" This chapter focuses on "Test design."

Question 5: What is the idea of "starting from the actual problem, not from the method"?
Unlike most of the books on the market that explain test design,

The main point of this book is not to explain an existing test design method, but the idea of "starting from the actual problem, not from the method", from the point of test analysis and test designers, when taking over a new system or the characteristics of the test, how to use a variety of testing skills, step-by-step analysis of the measured objects, Finally successfully complete the test task).

In addition to participating in the Torbjörn Ryber test Design course, I was fortunate enough to have attended Lee Copeland[18 's Test design course. Discover these test design courses or their main body parts of the test design work are elaborating on a test design approach in detail. The design of this book is different, this book will not explain a specific test design technology, if the reader is not familiar with these basic test design technology, can be from the Internet and a variety of books to obtain relevant knowledge. This book will be a virtual project "monopoly" game as an example throughout, from the point of view of test analysis and Test designer, when taking over a new system or the object being tested, how to make better use of the existing test design methods and combine the testing skills of testers to analyze the object step by step. Complete the test task in the final victory.

It is easier to read this book for those who understand the common test design techniques and experience in actual combat projects. For those who do not understand these test design techniques, before reading the chapter "modeling", we recommend that you first have a general idea of these basic test design techniques such as "equivalence class", "Boundary value", "state diagram", and so on. Although this book will not elaborate on these basic test design techniques, it will explain how to use these sophisticated test design techniques to model them with concrete examples.

From the practical point of view, also embodies an important idea: the test is based on the context of [a] (testing is contextual driven.). When everyone receives a test mission, the problem is different, that is, the test context is different, so you should adopt different test strategies to deal with, and test analysis and test design for the test strategy services, so the specific test analysis and test design activities are also different. Due to the need for writing, this book will follow a certain step in order to test the "monopoly" in all aspects of the activities, Kym, TCO, modeling, get test Condition, come to test ideas, but this does not mean that you have to deal with the test problems encountered when you have to do so , I really encourage you to apply that content based on your current test context. In other words, although the core of the book in the "Analysis modeling" 4 words, but there are 4 words is also very important, that is "free and easy."

Question 6: What test skills would this book talk about?
Unlike most of the books on the market that explain test design, the focus of this book is not to explain the existing test design methods, but rather the idea of "starting from the actual problem, rather than from the method", from the test analysis and Test Designer's point of view, when taking over a new test system or measured characteristics, How to use a variety of test skills, step-by-step analysis of the object tested, and finally successfully completed the test task.

It takes a lot of skill to do a test analysis, and the following figure lists some of the test skills that this book will talk about.

"Buy access" Pirate Pie Test Analysis Mfq&ppdcs