Research on software project acceptance test

Good software testing methods ensure that the software project works correctly, however, there is an important but often overlooked role in addition to the software-the customer. Considering customer requirements at every stage of software project development is important to the success of the system.
1 Software Project Acceptance Testing overview
Acceptance testing has always been used in different technologies and methods, sometimes referring to the same concept, sometimes referring to different test forms. Therefore, it is necessary to give a clear definition of the relevant concept of acceptance testing in this paper: ① acceptance test: Including customer acceptance test, user acceptance test and functional test; ② executable specification: The acceptance Test specification, which can run tests to verify that the project implementation matches the defined specification; ③ customer: The end user of the system ④ System: The software project developed, ⑤ Acceptance: Meet the functional and non-functional requirements, ⑥ functional requirements: The system must perform functions and actions, such as display items, user authentication, etc. ⑦ non-functional requirements: System related factors such as performance, scalability and security; ⑧ black box: Test procedure that does not rely on internal details of the system , such as input data, detection output results.
These terms are not sufficient to provide an accurate description of how acceptance testing is applied to the software project development life cycle. Acceptance testing is not a new concept, but it has been a focus and widespread use in recent years, like test driven development, and there are a number of related testing tools and architectures. Next look at how acceptance testing is applied to the software development lifecycle.
Acceptance testing is often used in software projects that are guided by the extreme programming, agile principles, and scrum iteration models. There are two main reasons for this situation. One is that acceptance testing focuses on the value that customers and software implementations deliver to customers, consistent with agile development principles, which are also focused on delivering software that actually meets customer needs. Second, through a set of automated acceptance testing, you can ensure that the software can meet customer needs, to ensure that the implementation of new features without destroying any old features. This means that you can focus on ensuring that the features you are developing are consistent with what you expect them to be.
Acceptance testing is most effective in conjunction with the agile development process. During each iteration, acceptance testing ensures that the entire team is focused on the specific parts of the application, ensuring that the software is complete from design to test in a single iteration.
2 software Project Acceptance test method
Acceptance testing should be written and implemented throughout every iteration of the software project development process. The following is a scrum iterative model that enables a software project iteration process that includes acceptance testing.
At the beginning of a standard scrum iteration process, the development team accepted the highest priority list of product requirements to be completed, which should be decomposed into multiple user stories, each using a scenario to define a system requirement. A user story typically consists of two parts that describe the part of the system that the user needs. A typical user usage scenario can be described as "as a sales administrator, I want to be able to view credit card information so that payments can be processed locally." "This user story describes the actions and actions associated with the user and gives a clear explanation of what is required to be implemented."
Once a user is selected to use the story, the development team should have a good understanding of what they want to achieve, and this phase should be a conversation with the customer and the product owner, identify what is actually needed and extend the initial user usage story, and create the task based on this information and other technical staff discussions within the team. At this stage, acceptance tests should be prepared. Knowing the user stories you're trying to implement makes it clear that the tasks you need to accomplish these implementations are well understood and how you can verify that the application meets the customer's needs. Acceptance testing is not a low-level unit test, but rather a high-levels test that focuses on verifying that customer needs based on user stories are correctly implemented. Once you have identified a user usage story, it is necessary to define the acceptance test before breaking it into a task. When all the acceptance tests are passed, the system is completed. This makes task decomposition more focused on what needs to be done. At this stage, the customer and the product owner should assist the development team in defining the acceptance tests to ensure that the software requirements meet the customer's expectations.
Good acceptance testing allows the customer to clearly know the functionality that the software project will implement in the current phase before starting coding. The customer clearly defines the requirements, and the development team can put forward any requirements-related issues and finalize the details with the customer before the actual coding. Using acceptance test guidance and validation, you can give customers a clear idea of what they want, and they can make the software project development team clearly aware of what they plan to deliver.
However, customers often do not understand the technology and cannot understand any test code developed to validate the requirements. Therefore, in writing, the acceptance test does not present the code to the customer, but rather uses the language to describe the validation test, which is to define high-level views in a few sentences. Acceptance testing has many forms of writing, such as given, when, and then syntax is a more popular acceptance test writing grammar, the specific test case is written as follows:
Suppose you have a new user account (Given)
When it is created in the system (when)
Then the default password should be [email protected] (then)
When testing to solve a specific problem, the test statement can be more complex as needed:
Suppose there is an overrun account (Given) and a valid debit card
When the customer takes cash from the ATM machine (when)
Then an error message (then) is displayed, no cash is returned, and the card is returned to the customer
This form of testing will enable customers to better communicate with the development team and define validation tests, validate and finalize each detail. This type of test definition does not use jargon too much, and customers will be more enthusiastic about testing if the test case is defined in this way. Because customers at the start of the project indicate what they want to deliver the software to achieve, and after the software is delivered, it can be seen that all the tests that were written are effective.
Acceptance testing should focus on business issues and scenarios, using the same language as the business to describe the tests. The advantage is that, first, you can understand the scenario and expected results without a technical background, and secondly, if the software is changed at the bottom, you do not need to return and update the tests to reflect this change. Because acceptance testing is high-level, it may cover many different builds in the code base. Acceptance testing should not depend on specific details, as these details change over time. If the user usage story is no longer valid because of a drop or change in some way, the test should be updated to reflect this.
Idle acceptance tests and tests that are no longer used are harmful to the project and test suites. Test suites should be as streamlined and centralized as possible, with enough testing to provide a higher level of assurance, but should not be redundant and repetitive.
Performing acceptance tests can be manual or automatic. Although manual testing appears to be a faster choice, it can be more time-consuming in the long run, because every time a part of the system is modified, it needs to be rerun. As the system grows, manual testing becomes more time-consuming and leads to more errors, and it is not as simple as you might think to perform these tests manually. In addition to completing the acceptance tests manually, you can also use the tool to automate them.
3 Automated Acceptance Testing tools
Currently, the most popular automated acceptance testing tool is fitnesses. The tool is based on fit (Framework for Integrated). Fitnesses provides a wiki front-end that can be used to manage test cases and scripts, enabling the entire team and customers to collaborate on the creation of acceptance test cases. In addition to the wiki front end, Fitnesses also provides a basic codebase for handling communication between wikis and test systems. This provides an abstract attempt to interact with the system, making it easier to write validation tests.
In addition to fitnesses, you can use cucumber to implement automated acceptance testing. Cucumber is an automated test tool that understands the test cases described in common language, supports behavior-driven development (BDD), is written in Ruby, and supports a variety of development languages such as Java and. Net.
4 Conclusion
The biggest advantage of acceptance testing over unit tests is that it is easier to apply to legacy code. Following the acceptance test method, you can immediately add customer acceptance tests around the project and provide a level of automated testing that does not have to be massively refactored for the project and test methods. Acceptance testing actually provides a value-added benefit to legacy code, and with a solid set of customer acceptance tests, you can refactor the code in the background and add unit tests, and the acceptance test will provide an additional safety net to ensure that no damage is done during the refactoring phase. The acceptance test provides a good end-to-end safety net.
Software Project acceptance testing is important and valuable to ensure that software systems meet the actual needs of customers.

Research on software project acceptance test