Download to read offline
class Acceptance and System Testing.pptx
- 1. SE 412 Acceptance andSystem Testing Fall 2023 Software Engineering 1
- 2. Outline ● Introducing theimportance of acceptance testing especially before development. ● Introducing FIT/FITness.
- 3.
- 4.
- 5. Why Acceptance Testing? Beforedevelopment: • Any concept is best understood with examples. • To develop a common understanding of the system’s black-box behavior.
- 6. Why Acceptance Testing? Beforedevelopment: • Any concept is best understood with examples. • To develop a common understanding of the system’s black-box behavior. • Information provided by the customer contains domain assumptions due to his expertise of the domain. • Uncover usage scenarios that the customer has not thought of. • Sometimes customers just do not exactly know what they want.
- 7. Before development: • Abasis to write down further lower-level tests. • A basis to guide the development process. • A basis to write down the contract. We try to make sure that we will be building the right system Validation Why Acceptance Testing?
- 8.
- 9. Why System Testing? Beforedevelopment: • To cover more usage scenarios, especially unsuccessful ones. • To test against tacit requirements, especially non-functional ones (such as data safety and security concerns). • To cross-check against use cases (or user-stories) to make sure all functionalities are covered. • As a basis to develop further lower-level tests. • As a basis to guide the development process. • As means to track the progress of the project. 9 We try to make sure that we will be building the right system → Validation
- 10. Why Acceptance Testing? 10 Afterdevelopment: • Does the system actually behave the way the customer expected (in case there was ambiguity)? • Is the system’s functionality correct? • Is the system’s performance acceptable? • Is the system’s usability by its end-users acceptable? • Is all the functionality requested there? • To run the system at the customer site. • To sign-off on the contract and end it. We try to make sure that the system we built was built the right way → Verification
- 11. 11 Requirements document (SRS) Use CaseModel Customer End-users Domain Experts Acceptance Tests Robustnes s Diagrams User Stories Executable Acceptance Tests Replaces use case model if in Agile process Source of Acceptance Tests
- 12. Source of SystemTests 12 Acceptance Tests Requirements document (SRS) Use Case Model Robustness Diagrams User Stories System Tests Replaces use case model if in Agile process
- 13. How does itstart? • A brain storming session that includes the customers, domain experts and the product manager.
- 14. FIT (Framework forIntegrated Tests) • A framework that allows non-technical stakeholders to specify system requirements through concrete examples. • A tool that can execute acceptance and system tests. • Using a tabular form – FIT tables
- 15. Creating A SimpleInput/Output table • This represents the customers’ views of what the system needs to do
- 16. Fixtures • FIT tablesare more commonly referred to as fixtures. • Fixtures uses fragments of the actual code that is being tested when the coding is completed. • Before coding is completed, fixtures simply use English words.
- 17. Results • Green: Thesoftware was right. • Red: The software was wrong. • Yellow: An exception was thrown. • Grey background: The cell was ignored for some reason. • Grey text: The cell was blank, so FIT fills in the answer from your software.
- 18. Table Types • ColumnFixture- best for checking rules and calculations • ActionFixture - best for step-by-step processing • RowFixture - best for checking sets of data
- 19.
- 20. ActionFixtures • Checking thata sequence of actions produced the right results • Special keywords • start aClass or a program -- Subsequent commands are directed to an instance of aClass. This is similar to navigating to a particular GUI screen. • enter aValue into a aField. This is similar to entering values into GUI fields. • press aMethod -- Invoke aMethod with no arguments. This is similar to pressing a GUI button. • check aValue -- Compare the returned value with aValue. This is similar to reading values from a GUI screen.
- 21. ActionFixtures - Example fit.ActionFixture startBuyActions check total 00.00 enter price 12.00 press buy check total 12.00 enter price 100.00 press buy check total 112.00 •What if the row “enter price 100.00” was removed? •Then the “buy” action will be performed on the previous “price” and the total would be 24.00.
- 22. RowFixture • RowFixture tablesare designed for testing that the results of a search or a query of the system under test are as expected. • Testing lists
- 23. RowFixture - Example •Trying query a list of users currently in a chat room • Order is unimportant OccupantList user room hassan lotr luke lotr • What if there is more occupants than expected? • What if there is no occupants? Second row has attributes that cab be changing for every record in the data set. In this case the user and room name can be changing. Top row has common attributes amongst the search of the name of data set (the list) OccupantList user room
- 24. RowFixture - Example •What if we want to check the occupants only in a particular room OccupantList lotr user hassan luke OccupantList user room = lotr Top row has common attributes amongst the search of the name of data set (the list). In this case the room “lotr”. Second row has attributes that cab be changing for every record in the data set. In this case the user name can be changing.
- 25. Chapter 4 SE 412Folder bit.ly/se412fall2023