Agile software development is a new software development method which has attracted wide attention since 1990’s. It is a software development ability which can cope with the rapidly changing demand. As a new development mode, agile software development has been applied more and more to software projects.

Agile software testing in agile software development process is related to the quality of a series of activities, and traditional software testing have a lot of difference, because the concept of agile software testing has been blurred, so often someone into the erroneous zone, I was under the waterfall model of software development did a few years of testing personnel, As a result, I had some misunderstandings when I first started working on Agile projects. However, after nearly five years of working on agile software development teams, I have gained a new understanding of many problems. Here are some common misunderstandings I would like to share with you.

No testing strategy is required

Test strategy focused on the goal and method, that is, how to in a limited amount of time the effective use of limited resources to achieve goals ahead of time, to develop the test strategy when they first generally clear test target, and then determine which tests need to type, various test types of proportion, probably choose the test framework, final planning prior to the release of the software need to experience what test phase.

Many people think that agile software development is built around user stories. Is it enough to focus on user story testing? Is there no need to think about a test strategy at all?

In fact this is a big misunderstanding, because of agile software development is often an iterative, cycle short, limited resources, it is more need us to make overall plans, small to a user story, big to a complete user features, all need to consider how to reasonable use of test resources, so agile projects is very need to test strategy.

Specific to the actual project, the team would usually at the beginning of the project (iteration 0) to develop the test strategy, clear objectives, including functional requirements of goals and the goals of the non-functional requirements), and then determine which test automation in the development stage need to add (including unit testing, interface testing, contract testing, integration testing, system level UI user scenario testing), Specify the approximate ratio of these tests (consistent with the test pyramid), select automated testing frameworks (such as XUnit) and which manual tests are required (including exploratory testing, usability testing, etc.), and plan the testing phases (such as new functional testing, regression testing, etc.) for each release cycle. The testing strategy will guide the development and testing of agile teams, although it will vary from team to team depending on the project.

Here is a simple agile testing strategy:

There is no need to test the documentation

Test documents usually include test plans, test cases, test reports, test defects, and corresponding requirements documents that can guide testing.

Many people think that agile software testing doesn’t need documentation. The Agile Manifesto says, “Working software is better than detailed documentation.” Even though the agile Manifesto says at the end, “The right has value, and we value the left more,” people tend to ignore the right. This has led to a complete denial of the usefulness of test documentation in many teams just starting out with Agile development.

First of all, it is undeniable that in actual Agile projects, there are few formal and specialized requirements documents and test documents in the traditional sense, but this does not mean that agile projects do not have documents. For example, user stories themselves are the carrier of requirements, and acceptance conditions in user stories are part of agile test documents. In addition, many agile software projects will adopt the way of BDD for development. The test cases will be described in natural language that business personnel can understand, combined with automatic implementation, forming a document integrating requirements and testing. In order to cope with the problems caused by the rapid change of agile software testing and the delay in updating of documents, Many Agile projects are using Living Document.

Pure automated test or pure manual test

Some people new to Agile believe that agile software development releases are so short that testers don’t have time to do manual testing, so purely automated testing should be used.

There are also some people who believe that agile development emphasizes rapid response to change, and if the investment in automated testing costs, then it will surely lead to the waste of resources in maintaining automated tests, so pure manual testing should be adopted.

These are two extreme misconceptions, although the difficulty with both views does exist, because in agile software development, iterations are usually short and there really isn’t enough time left for manual testing, so there must be enough automated testing to ensure that.

However, agile testing is also dependent on manual testing because the test code itself may be flawed and there are many parts that are difficult to be covered by automated testing (interface testing, usability testing, exploratory testing, etc.).

As for concerns about test automation maintenance cost, the characteristics of agile projects also exist change more, but usually are close to the user’s part, it is desirable to minimize user level depends on the interface of automated testing, and add some more is not easy to change at the bottom of the unit test interface testing, etc.

It is recommended that agile testing be primarily automated and supplemented by manual testing.

Agile QA = Agile Tester

On many teams that are new to Agile practices, agile QA is still considered to be in the Tester phase, as long as the user story is developed and QA is dedicated to testing and finding defects.

This is a big misunderstanding. First, QA(Quality Assurance/Analyst) is not a tester in the pure sense. From the name of this role, we can see that Agile QA emphasizes Quality Assurance and analysis rather than testing products.

In the actual project, agile QA usually from requirements analysis phase began to participate in the entire software development process, through the different role in different stages and the team cooperation, agreed to help the whole team for quality, and through the different stages of qualification and validation do defect prevention, rather than wait until after the completion of the software development to find defects, so for agile QA, The goal is to find as few defects as possible after software development is complete, and for Tester, the more defects found, the better the job done.

Non-functional testing is not important

Non-functional testing refers to the testing of non-functional requirements (some features other than the functional requirements required by the software itself to meet user requirements, such as security, performance, availability, compatibility, etc.), usually including security testing, performance testing, availability testing, compatibility testing, etc.

In agile software projects, the requirements are cut into small units, in the process of cutting, non-functional requirements is the easiest part of being ignored, and this problem is caused by functional test is often overlooked by team, over time, can form such a misunderstanding, think that NFT is not important.

This view is wrong, first of all, the importance of non-functional testing are not varies according to the software development model, especially the importance of safety testing and performance testing are increasingly pay attention to, because a lot of products must consider the safety of the user’s sensitive information and performance leads to customer satisfaction, in agile projects due to the software will be released as soon as possible, If these non-functional requirements fail, the impact will be felt earlier, possibly losing the majority of users as soon as the software enters the market.

So non-functional testing is just as important as functional testing, and in a real world project, it would be better to add these non-functional requirements to the acceptance criteria of the user story and validate them throughout the agile development process.

Quality is QA’s business

Because of the conventional wisdom, many people still think that quality is QA’s business, and if the quality of the product is not good after launch, QA is QA’s problem, and other roles have little to do with quality.

First of all, this view overestimates the role of QA on quality. Software quality is gradually formed in the software development process, from the requirements analysis stage to the customer really understand the function, to the development stage to add enough automatic test guarantee, whether to write robust enough production code, In the final testing phase, whether the usability of the whole system after the introduction of functions is tested, whether the different user paths can work properly, etc., are all components of software quality.

Can see, in the whole process, the quality of the software without agile teams of various roles, including the business analyst to demand accurately, with developers to achieve the same high standards of product code, for the security of the automated test coverage, and QA on quality related activities in the process of implementation and guarantee, This includes the replenishment of the business from the QA perspective in the requirements analysis stage, the review of automated testing in the development stage, and the further assurance of product quality such as exploratory testing availability testing.

So in Agile testing we tend to downplay the concept of roles and emphasize that everyone on the team is responsible for quality, which makes it easier for everyone on the team to make quality a very important part of it, rather than relying on one person or one role.

Development can write tests, no need for QA

Because agile teams emphasize that everyone is responsible for quality, and developers write a lot of automated tests using TDD and so on, is QA not needed?

There has been a lot of heated discussion in the community about this idea, such as this article “Do We Need full-time QA?” In fact, I think the QA mentioned in this article refers to Tester. Please refer to the previous point of view for the difference between the two. Despite this, some of the author’s points are valuable, such as the last point that quality is not measured, but is guaranteed through activities at all stages of the software life cycle, all of which involve QA.

First of all, in the requirement analysis stage, QA can question, supplement and modify requirements from different perspectives. Because of its unique technical background, QA has a deeper understanding of software availability, so it can often put forward opinions different from those of business analysts and developers. In the development stage, QA will also review the automated tests written by developers and help developers write more valuable tests through QA’s professional testing background. For example, we once found that developers wrote many tests with no business value in the project. Testing, exploratory testing, usability testing, security testing, performance testing are all things QA does.

Of course, if the business analyst has perfected the business analysis from a variety of perspectives, and developers can write very valuable tests, as well as do various types of manual testing, then it is not impossible to eliminate full-time QA, so that QA is not not needed, but everyone is QA.

conclusion

Listed above at seven o ‘clock is easily when they are new to agile testing into myth, and even some views on some has imposed agile still existed in a long time team, these views are very easy to cause the agile testing on detours, above are some of the thinking, combined with actual project experience personally hope to be of help.