Briefly describe the importance of testing in agile projects

This is a response from a test expert to the paper.

Just as the dead royal family (the king is gone, but the Queen will live on), our software development is sending a similar cry: "The test has died, we no longer need testers!" "But then you will find that, alas, the customer is dissatisfied and finally goes back to the" Long live test, "but this time it is better, more complete, more effective testing. As with many of the Restoration Dynasties in history (I like Queen Elizabeth 1 Best), tests will powerfully help redefine how things are done and how they work.

I bet you're thinking now it's just a boast, but that's how it happened:

Let's discuss the concept of testing: What is a test? A test is a process that considers what is "right" and defines a method to determine whether the object being tested is "right", identify metrics to determine what the "right" looks like, understand what the "right" level means for other people's tasks and activities, and assist the team in making good decisions based on useful information to meet the "right" The required level.

Testing is much more than randomly tapping the keyboard to find the problem; The test needs to really understand the required solution, participate in the methodology plan used to deliver the product, understand the risks involved in the delivery method, and identify these risks as early as possible to take appropriate remedial action. Testing also requires driving the project to a successful direction and helping everyone understand the appropriate level of success required.

Why do we need to focus on testing, and everyone on the agile team is not testing? In fact, this is not the case.

All disputes begin with the concept of quality. Perhaps you will say to yourself: "It's easy." "If that's what you really think, push it to the next step ... Define it. Define quality for your development team, customers, product owners, project managers, and CIOs and CEOs in your organization to be well defined and defined to the extent that they are good enough. Will they agree? If you don't agree, then that's your first question. The task of testing is to help the team define and understand the impact of quality.

"The impact of quality??" What is it? "That's your next question. In fact: Quality is required cost! What's worse: true high quality requires a higher cost! To really build quality, we first have to define it, and then we need to find it. Quality solutions are not possible without building quality into processes and technologies and not building complete levels of testing into our work.

"Ah, finally caught you," the developer said, "we define the quality by defining completion in agile." Garbage "That's my answer." The most exciting concept I've heard all the time I've been in it is to define "finish"-all the components, centralize all the knowledge, pass all the information ... The complexity of the solution is predefined, and all teams (development and customer teams) know what needs to be done to achieve "completion." The definition of "finish" reminds me of all the testing related. But the bad news is we didn't do it! Yes, we didn't do that! Just as we don't define quality ... We're just pretending we've defined it. Wow, did you get a sore spot?

Why do I say that? First, defining "finish" is as difficult as defining quality. Because quality is like "beauty", it is a question of the beholder. The content of the test includes the definition of training to focus on quality, followed by a search for quality (or quality defects), and communication in the project process, according to the process, risk and the remaining work of the clear quality level means. This is also true for the definition of "finish", which is not the same for each "performer" (non-bystander), which allows us to understand the multiple levels of "completion" ... My completion, our completion, the completion of the story, the completion of the iteration, the completion of the feature, the completion of the release, the completion of the product, the completion of the project.

"It doesn't matter, we can redefine it when it's done." "This is your witty answer to this question. Now the real challenge is coming! Defining "Finish" is completely different from defining "well done". "Well done" is not just about completing the work required in the current product, but also about how we know that it meets the required standards. Each level of "completion" has different completion criteria, and a very different "good" quality standard. There is a group of people who are not only well suited to helping define "well done", but also to help define processes and techniques for finding "well done" levels.

Step one, define "finish" ... Well, it looks simple--ensure that the performer completes all the components that need to be delivered at the "Finish" level. Well, so far it sounds good. But then the difficulty comes ... If the customer is not satisfied, then nothing is "done". This is one of the basic attributes of the Agile manifesto. I quote the phrase "working software is better than all documents". For some unknown reason, people tend to confuse the definition of "working" with "completion," while confusing the concept of "exhaustive documentation" with the definition of "good test". And then it goes against the principle "our highest goal is to make our customers happy by delivering valuable software as early as possible." So what makes software valuable? Is the delivery of the product? Of course not! But the software can do a good job of it!! So this is my "finish", our "finish", or what the "completion" ...?

How are we going to do that? First, we need to recognize that testing is not just about development and what users are concerned about. function to achieve what is a very simple part (it is simply easy-I swear). Features are easy to define, build, and evaluate. Features tend to binary, similar to the "completed" or not! "Done" has two levels ... "complete" and "unfinished" ..... There is no such thing as "almost complete". function similar to cooking food ... Only can and can not work the say ... Binary system! But then we went into the "finish" and then the "Well done" field, and even went further "for who is well done?" ”。

Testing focuses on understanding what makes a solution or method valuable to the person who uses it. Values are context-independent and must be defined within the context of the project and the customer. Using standards such as ISO9126, based on its 6 quality features (functionality, reliability, practicality, availability, maintainability and portability) and its child characteristics, can inspire testers to discuss what is good, appropriate, and valuable. But what's better is that we need real tests to find these values. Such tests also require time and planning to perform well, which can take longer if you want to do it better.

All of the non-functional features in a solution are design-layer attributes and typically cannot evolve in iterations. It needs to be discussed in advance, and it needs to be discussed as soon as the solution is identified, yes ... discussed as soon as the solution design is determined. If these features are not embedded correctly at the beginning, they will never be found in the test. Unit test can you do this? Of course not!

"Oh ~ ~ ~, that's why we do acceptance test drive development Ah!" "You said. I agree, but we tend not to do the ATDD well, we focus on what the customer knows and ask, without paying attention to what needs to be considered and captured in the upfront.

"Then let's focus on the function," he said. "This is a word I often hear, and it often bores me ... It means it's hard to think of other things and we have to move on and pray that it's right. Have you ever heard the "ignore" agile? Agile is about getting things right from the start.

The test helps build the right solution from the start by static testing. The static test is "do not test the solution by executing code." The beauty of static testing is that it can be performed at any time and in any place. Static tests should be performed when the first idea of a solution arises. Ideally, there should be a tester who raises the question: "It's a good feature ... But how do you make sure it's valuable? "Testing the concept through problems, graphs, and plans for the solution to see if it really delivers the solution that is needed is a critical part of the product's life."

We can also test delivery plans, focus on risk, time, and dependencies between components, and how to use different levels of "completion" to prove that we are moving towards the right solution. Defining completion in the "Well done" direction requires that the right person be involved at the beginning of the work, not after the code has started. Test plans are critical-do you define the right environment, team, resources, and methods to deliver value? This is a problem, but often it is not answered before coding. The existence of this wonderful new test system has caused the problem, and everyone has answered it before heading to the next step.

The completion of the test plan can be defined by the use of test design technology to predefined acceptance criteria. You might shout: "What??" The test has already begun??? "Yes, absolutely right. What's the point of training and certification that testers get if you don't do it ahead of time? You see most of the test execution activities that testers do are the result of their test design activities based on risk and test design specifications. Concepts, features, long stories, and user examples are all just rules that translate under different names. Better, in the ideal agile World, testers will be involved in the requirements definition so they can test them statically and then apply dynamic technology to anyone before attempting to implement a line of code.

Next, we start the real work (chuckle ...). If anyone feels that the work before coding is not work, then he doesn't understand the concept of work, we start coding, do unit testing, improve code, do integration testing, release code to test environment (boom, boom, thump ...) The drums are ringing) ... We are beginning to do our best to find urgent action!