Why is software development difficult. An Acceptance Testing Viewpoint

Transcription

1 Why is software development difficult An Acceptance Testing Viewpoint

2 Developers Don t Know. Where to start What to test What not to test How much to test. That testing is about DESIGN and SPECIFICATION

3 Where to start USE CASES describe BUSINESS or CUSTOMER VALUE VALUE implies ACCPEPTABLE to the CUSTOMER VALUE acts as TESTS

4 High level (Use Case) TITLE <Feature Name> As a <ROLE or ACTOR> I want <an ACTION> So that <I receive some BENEFIT or VALUE> TITLE View Account As a Customer with an account and login details I want to be able to login and view my account information So that I can see my balance at any time

5 Use Case (The details or EXAMPLES) Scenario <DESCRIPTIVE TITLE> Given <a CONTEXT> When <an ACTION happens> Then <a VALUE is returned> Scenario Customer views account when logged in Given the Customer is logged in When the Customer attempts to view their account Then the Customer see the account.

6 Acceptance Tests Scenarios become acceptance tests The structure Given. When. Then Becomes testing code. Scenario Customer gets cash from the ATM Given the account has sufficient funds AND the card is valid AND the dispenser contains cash When the Customer requests cash Then ensure that the account is debited AND ensure that the cash is dispensed AND ensure that the card is returned

7 Sounds like a lot of work Yes, but remember we are dealing with a wicked problem. We need a working definition of -- Where to start and finish (construction); What to test and not to test; and How much to test The tests seek to limit the scope of the system. Seek to avoid develops producing the wrong system Remember this problem..

8

9 Still sounds high-level Correct Many details are not known we are still focussing on those interactions and delivering value to the actors For example, what is a valid card? No definition, currently exists that is okay. But we need some working definition to write that test code.

10 Drilling down add Examples We finalise the tests by (user, customer, development team, etc) to define actual examples This allows us the write the tests If the system gets the examples right? We assume that the system is correct and meets the specification. Hence, the EXAMPLES need to be executable! As we keep trying them until we get them right.

11 Let s try an example

12 Title: Choose a pizza shape As a customer of pizzasareus.com I want to be able to define the shape (square, round) of my pizza So that I can build my own custom pizza

13 Scenario: Allow the customer to define the shape of their pizza Given the customer is logged into pizzasareus.com When the customer chooses to build a custom pizza Then the Customer should be able to build a square or a round pizza.

14 Scenario: Allow the customer to go to Step 2 without choosing a shape Given the customer is logged into pizzasareus.com AND the Customer selects to continue to step 2 (choose your size) When the customer selects to continue to step 2 Then the Customer should be asked to select a square or a round pizza.

15 What about special occasions? Valentine s Day and heart-shaped pizzas sounds like a natural But what does that mean for the previous scenarios? Tests like requirements will have to change and evolve!

16 Scenario: Allow the customer to define the shape of their pizza Given the customer is logged into pizzasareus.com AND the date is Valentine s Day When the customer chooses to build a custom pizza Then the Customer should be able to build a heart-shaped pizza.

17 But. What happens if it is not Valentine s Day? No heart-shaped pizzas Yes, we need to test false results as well. Sounds like a lot of work huge amounts.

18 Scenario: Allow the customer to define the shape of their pizza Given the customer is logged into pizzasareus.com AND the date is NOT Valentine s Day When the customer chooses to build a custom pizza Then the Customer should NOT be able to build a heart-shaped pizza.

19 Specification + linking code + system under construction Given a selected shape Then the customer can select a size chooseshape( round ) choosesize( small ) True false IsShapeValid( round ) issizevalid( round, small )

20 Automating Acceptance Tests with Fit / Fitnesse

21 FIT FIT = Framework for Integrated Tests A framework that allows non-technical stakeholders to specify system requirements through concrete examples Using a tabular form FIT tables

22 Creating A Simple Input/Output table This represents the customers view of what the system needs to do

23 Our view The fixture : the actual code being run inputs outputs

24 Fixtures what we write! Fixtures are fragments of the actual code that is being tested inputs output ColumnFixture is a class which interprets the customer s table.

25 Results what we both see! Green: The software was right. Red: The software was wrong. Yellow: An exception was thrown; commonly not declared.

26 Table Types ColumnFixture - for checking rules and calculations ActionFixture - for step-by-step processing RowFixture - for checking sets of data Discussed in the lab.

27 ColumnFixtures Given some input values, do some calculations and evaluate the output

28 ActionFixtures Checking that a sequence of actions has produced the right results. Special keywords start aclass -- Subsequent commands are directed to an instance of aclass. This is similar to navigating to a particular GUI screen. enter amethod anargument -- Invoke amethod with anargument (of type determined by amethod.) 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 amethod avalue -- Invoke amethod with no arguments. Compare the returned value with avalue. This is similar to reading values from a GUI screen.

29 ActionFixtures - Example fit.actionfixture start BuyActions check total enter price press buy check total enter price press buy check total

30 FIT/Fitnesse Making it nicer!

31 FIT limitations in the work place Does not support sharing of acceptance tests Does not support team participation FIT does not provide any means to create acceptance tests Does not display results

32 Fitnesse Fitnesse is and HTML Wiki front end to the FIT framework Fitnesse does not actually run the tests, the heavy work is done by FIT

33 Fitnesse Users can use FIT through the use of the friendly interface provided by Fitnesse

34 Fitnesse provides a software development collaborative environment Create acceptance tests Share acceptance tests Organize acceptance tests Run acceptance tests (through FIT)

35 Wikis The core of Fitnesse is Wiki pages Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser Wiki supports hyperlinks and have a simple text syntax for creating new pages and cross links between internal pages on the fly

36 From a User Point of View

37 Fitnesse Example Ready to run the test Our fixture (or code or System under test) This can be located anywhere! Acceptance Test FIT table

38 After Clicking TEST The results are shown right in the browser.