1 / 27

Automated Acceptance Testing as an Agile Requirements Engineering Practice

Automated Acceptance Testing as an Agile Requirements Engineering Practice. HICSS 2012 : 5289-5298. Tor Stålhane. Børge Haugset. Hawaii International Conference on System Sciences . 100525002 王浚懿. Outline. Introduction Requirements Engineering Agile RE

sveta
Télécharger la présentation

Automated Acceptance Testing as an Agile Requirements Engineering Practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automated Acceptance Testing as an Agile Requirements Engineering Practice HICSS 2012: 5289-5298 Tor Stålhane Børge Haugset Hawaii International Conference on System Sciences 100525002王浚懿

  2. Outline • Introduction • Requirements Engineering • Agile RE • Existing comparisons of RE and agile RE • Acceptance test-driven development • Results from the case study • Discussion • Conclusion

  3. Introduction • How to use • Automated acceptance test-driven development (ATDD) • Impacts requirements engineering

  4. ATDD documentation communication RE agile RE

  5. Framework for Integrated Test

  6. Requirements Engineering • Requirements engineering (RE) is a large domain • focus on functional requirements • leave non-functional requirements (NFRs) out of scope.

  7. Goal – what do they want to achieve? • Main activities – what do they do when they “do their job”? • Main goals – what do they want to achieve when they “do their job”?

  8. Agile RE • Adaptive rather than predictive • People oriented rather than process oriented. • Face-to-face communication • Customer involvement

  9. Existing comparisons of RE and agile RE • Lack of requirements existence and stability • Issues with users’ ability and concurrent among users • Inadequate user-developer interaction • Presenting requirements in the form of designs: • Not inspecting requirements

  10. Acceptance test-driven development • Framework for Integrated Test(Fit) • Fit tests may be needed to convey understanding of a requirement.

  11. The case study • Theyinterviewed four developers from a consultancy company (Konsult). • The project group, now a total of ten developers and two interaction designers are working on-site at a customer office . • All projects are run in a test-driven fashion . • The project with the most extensive use of FIT currently has 1100 lines of tests, the average test being 15-20 lines long.

  12. Results from the case study • Business requirements are discussed in bi-weekly meetings with the customer. • The communication of requirements has been focused around the Fit tests. • Not all requirements ended up as Fit tables. • In the specification phase ATDD was used to help communicate requirements .

  13. Discussion • Lack of requirements existence and stability • Issues with users’ ability and concurrent among users • Inadequate user-developer interaction • Presenting requirements in the form of designs: • Not inspecting requirements

  14. Agile RE mitigated this risk. • ATDD has the same iterative interactivity, and should give the same benefits. • ATDD has a focus on the customer and developer agreeing on the existing requirements • If the requirements change the tests must reflect this, adding a larger cost than regular agile development.

  15. Discussion • Lack of requirements existence and stability • Issues with users’ ability and concurrent among users • Overlooking crucial requirements • Presenting requirements in the form of designs: • Not inspecting requirements

  16. Agile and ATDD both depend on communication with customers. • Different customers specialize in different topics. • The developers need to communicate with different key personnel when they have questions about the various sorts of requirements

  17. Discussion • Lack of requirements existence and stability • Issues with users’ ability and concurrent among users • Overlooking crucial requirements • Presenting requirements in the form of designs: • Not inspecting requirements

  18. Agile RE has a positive impact on this risk . • ATDD has an even larger positive effect here. • The tests to improve their communication with the customer, guiding the conversation.

  19. Discussion • Lack of requirements existence and stability • Issues with users’ ability and concurrent among users • Overlooking crucial requirements • Presenting requirements in the form of designs: • Not inspecting requirements

  20. In ATDD, requirements are described • tables that act as both documentation • runnable tests • This leads to mitigating the risk that the agile process exacerbates.

  21. Discussion • Lack of requirements existence and stability • Issues with users’ ability and concurrent among users • Overlooking crucial requirements • Presenting requirements in the form of designs. • Not inspecting requirements

  22. Agile RE worsens this risk. • This is perhaps a risk where the practice of ATDD .

  23. Conclusion • ATDD gives detailed documentation of all requirements • This documentation,built as runnable tests, is founded on close communication with the customer. • It is not necessarily easy to use ATDD if you want to gain all its advantages. • it requires more customer cooperation than regular agile development • not all requirements can be described in this fashion.

  24. ATDDcan help with uncovering the correct requirements. • ATDD focuses on detailing requirements in an automatically testable way.

  25. Q&A

More Related