Day 4 – Summary of the Agile Course so far (Part 1)

Below are my notes from the Agile course so far – covering introduction to Agile projects , why it makes business sense, the use of FIT and other acceptance testing tools what Agile means for customers , managers and teams.

These notes are a good complement to the Agile presentation I gave.

Introduction to Agile

  • Requirements
    Change on project – it’s going to happen , clients (paying for the code) have the right to change their mind , accept it and get on with it.

  • Agile Family Includes

    • XP (Extreme Programming)

    • Scrum

    • Adaptive Software
      Development

    • Lean Software
      development

    • Feature Driven
      Development

    • Crystal

    • DSDM

  • Values
    wrap Principles wrap Practices

  • Values
    (from the Agile manifesto)

    • Individuals and interactions over processes and tools.

    • Working software over comprehensive documentation.

    • Customer collaboration over contract negotiation.

    • Responding to change over following a plan.

  • Principles
    (Customer Focused)

  • Deliver early, deliver often.

  • Deliver valuable software.

  • Welcome change.

  • One
    Big team (business people and developers)

  • Principles (for Management)

    • motivated individuals give better results

    • face 2 face is the best way to communicate (although accept need to
      communicate across location and across time as good 2nd
      best).

    • Remember : working software that meets business needs is the primary measure
      of progress

    • Promote sustainable development (or you’re just going into Technical Debt)

  • Principles(for Teams)

    • use technical excellence and good design to promote agility but

    • simplicity is essential

    • the best architectures, requirements, and designs emerge from
      self-organizing teams (rather than imposed from above)

    • do continual improvements to the process

  • Practices

    • Continual Improvement

    • Technical Excellence

    • ProjectManagement

    • Business Practices

    • Community and Collaboration

  • Why Agile

    • Waterfall projects : we’re most likely to find bugs in testing phase at the
      end , when (a) we’re most likely to be under time pressure and (b)
      when they’re most expensive to fix.

    • Waterfall projects: Hard to know how far through we are , as each step is
      different from the last (design has gone well , but will coding do
      better or worse?)

    • Agile:Testing is continuous, so likely to get early feedback and
      resolution of bugs. Testing = Unit Tests and Acceptance Tests.

    • Agile: Progress is steady and measurable , as we carry out all
      tasks as part of a regular cycle.

    • Productity = doing less but producing more value. e.g. Customer can prioritize
      highest value tasks and we deliver these first.

    • Standish group stats showing small projects are more successful.

    • Deploy early and often gets usable software into the hands of users sooner
      where it can start to payback it'[s investment earlier.

    • Success factors for Agile projects:

  • Enthusiastic development team/ Committed customer / Knowledgeable on-site QA
    resource / Didn’t cherry pick practices / Open workspace / Regular
    retrospectives.

  • Still hard work to do:

    • Good people give good software

    • Can be faked , so people really need to buy in

    • Practices are learnable / a lot are common sense

    • Recognize reality

Informative
Workspace

  • Person walking into ‘normal’ coding office has no idea of what is going on, nor what status it is at. Most of the stuff is in people’s heads.

  • Informative workspace seeks to communicate this information (via simple methods)in the office e.g. Notice boards, coder of the week hat , printed graphs of velocity , iterations etc.

  • Kent
    Beck :
    "An interested observer should be able to walk into the team space and get a general idea of how the project is going in 15 seconds. "

  • Similarto Kanban idea – while going for Just in Time / continual improvement , visual representations are displayed to demonstrate
    progress.

  • Information Radiators : anything that gives out info (example given of monitor running , showing latest build progress).- jokey examples of Lava
    Lamps / notes in toilet

  • Toyota (Toyota production system – recognise their edge is in how they build their cars, and not just the cars that they build).

    • Human face to automation.

    • Board giving current
      production status

    • Audible Cues

    • Ability for anybody to stop the line.

Testing and Design by Contract

  • Started by Bertrand Meyer in the Eifel Language

  • Frameworks available to add these (fully) to the Java Language – over and above the functionality available in Java 1.4 (the assert keyword)

  • Already have a contract that is enforced by the compiler in Java (e.g. Method signatures , return types)

  • Adds to this , to be a finer grained level .e.g method should return not only an Integer , but an Integer of value 0 to 100

  • Like every contract both sides (Caller and Callee) have responsibilities

  • Pre Conditions : Condition that must be true when the method is called.

  • PostConditions: Condition that the method guarantees when it returns

  • Class Invariants state what will be true at a class level (once all pre-conditions at method level / constructor level satisified)

  • Both pre and post provide additional specifiication (.ie. It is clearer to people using the code what is required / what it does). As such
    provides clearer design and additional documentation.

  • Can make code more succient by replacing ‘boilerplate’ code with standard check (e.g. Precondition param must not be null).

  • Java
    Example :

    • Pre
      Condition /**
      @require !empty() */ – as
      javadoc on method (multiple checks allowed) –

    • Post
      Condition : /** @ensure !full()*/

    • Class Level invarient: /** @invariant 0 <= count()*/

  • Exceptions

    • Pre Condition violation should give RuntimeException – provide method to test before call (e.g. IsEmpty() before doing remove)

    • Post conditions: supplier should be every effort to fulfill these : so if it can’t , it is normally due to an Exception (callee should be prepared for this failure)

  • Junit

    • Codein Junit verifies the contact of the class (and provides documented example of code use)

    • assert methods = post condition testing

    • test invarient by checks at class and not just method level (e.g. Check overall status of class, not just return value of method under
      test)

    • Pre conditions by be tested by violating these in setup (code before call to method/ class under test) and ensuring exception is thrown.

  • Think about Test as a contract.

Acceptance Testing

  • Acceptance Tests – defined (or agreed by customer) , states thatfunctionality is complete

  • Differ from unit tests in that they are system wide rather than at class/unit level.

    • Sometimes people used high level / coarse level Junit tests.

  • Unlike unit tests don’t need to be a 100% all the time (but once passed , should alway pass)

  • Automation is nice (for developer and customer)

    • Own note: Not everything in acceptance testing is automatable. e.g. UI testing.In this case automating the acceptance testing of the calculations (the 80%) means that the UI testing is a lot easier.

  • Sample Frameworks for Automated acceptance testing

    • FIT – see notes below

    • Exactor – see notes below

    • Fitnesse – FIT but wiki based (easier to do multiple tests , easier to communicate these to a team.

    • WinFIT runner

  • Inputto all these tools is close to a spec (close in that typicaluser , after one walkthrough should be able to understand what the documents mean).

  • Tests can be written before application is build (again, the notion of the tests forming a spec). A lot of the commerical tools ,
    especialy those that record against a ‘live’application, do not allow this.

Automated Acceptance Testing with FIT

  • Allows Customer s to review (if not write) the acceptance tests.

  • Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the user point of view).

  • Data (unlike in Exactor) is specified as a HTML table. All non-tables are ignored (so safe to created tests documents using MS Word).

  • Fixture (connects this HTML Data) to run test against ‘production’ code.Fixtures are written by programmers (as part of proving code meets
    the spec). Three types of fixtures.

    • Column

      • One class for each table

      • Fit works through on a line by line basis – good for repeating the same action over and over again.

      • 1st Line of Table : Class Name to be tested

      • 2nd Line of Table : class variable or methodName() to be set / called

      • 3rd
        Xth lines of table: values to set or expected values to be returned

      • Good for testing Domain (Business) Logic parts of an application

    • Action

      • mulitiple class for
        each table

      • start – the class to be tested

      • enter – value to be passed into method (no return value)

      • press – call method (no input or output)

      • check – check value on method (no input)

      • Good for stimulating interaction with the user interface (or more accurately either the controller that sits just behind the user interface).

    • Row

      • Like Column , but interprets all at once (rather than one at a time)

      • extend RowFixture ,
        provide query[] and getTargetClass() methods – allows Fit to see what data structure

      • good for testing coding in the service / persistence / db layer of code.

Automated
Acceptance Testing with Exactor

  • Exactor (http://exactor.sourceforge.net)

  • Allows Customer s to review (if not write) the acceptance tests.

  • Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the userpoint of view).

  • Comprises (like fit) of

    • Script – a text file thatyou could show the customer.

    • Commands : what the script calls , extends Exactor classes. These commands then call the code beingtested.

    • Command extends Junit assert –
      so usual capabilities available.

    • Command provides access to test wide map to allow storing / exchange of values.

    • Allows composites to reuse scripts.

    • Scripts allow placeholder parameters

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s