Story Acceptance Criteria

General Story Acceptance Criteria

In addition to meeting PM's requirements for each story, the following additional criteria will be used to verify story completion:

• Unit and Automated Testing - Coverage of new features (higher coverage for commons / pillar code), this can be conducted using junit, web driver, or other automation tools.  We need to investigate SWT and Swing automated testing.  We should also consider stress, performance and load testing as necessary.
• Developer Documentation - Document in code assumptions on input and output, purpose of methods and classes. Create necessary architecture and OEM doc.
• Customer Documentation - Update necessary customer docs based on feature, or minimally create JIRAs for future DOC tasks with notes on which docs are impacted
• Test Plans and Test Cases - Updated test plans to include new stories, considering browser / platform testing matrix -  ie, moz, win, linux, mac, oracle, postgres, mysql
• CI and Nightly Builds - Test cases, unit tests and final reviews are executed based on CI and Nightly builds
• Code Reviews - Based on a clear set of criteria, listed below
• JIRA Management - SVN commits should include JIRA cases, and JIRA cases should be marked in the correct release and contain necessary information for validation
• Usability - All UI related functionality must meet usability expectations

Code Review Acceptance Criteria

• logging
  • no System.out calls
  • debug logging is encouraged in areas that could be useful for support and engineering
  • appropriate use of error / warning / info
• exception handling
• interfaces
• code formatting
• re-use
• dependencies
  • new dependencies, upgrading of existing dependencies, gwt, swt, eclipse versions
• threading
• security
  • multi-tenancy
• caching
• eclipse warnings
• i18n
  • externalizing strings
  • proper use of encoding
• proper use of generics and collections
• javadoc
  • public facing methods and apis
• temp file creation
• architectural considerations
  • determining the correct balance of architecture, avoiding over architecting
• build and packaging impacts
  • new ant targets, etc
• additional best practices

Special Considerations

• Projects that have downstream dependencies (Commons, Pillars)
  • testing should be conducted not only on the current sprint's requirements but on all uses, unless a rigorous test environment is created for the project increasing the confidence of stability for the commons project
  • API changes to these projects should only be made in Major or Minor releases, not patch releases of the project
  • Many times commons projects are not branched for patch releases, we need to be conscious of downstream branch dependencies.
  • Please see the CI dependency report to determine downstream dependencies of projects
• Code Coverage verification
  • coverage verification will be determined on a per story basis initially.  This may be included as part of the ci or nightly builds depending on the projects involved.
• Code Reviews
  • The goal will be to do team oriented code reviews, based on the above criteria.  As we work on creating a more comprehensive detailed list of criteria.  Marc will also participate in code reviews as requested and necessary.
• Handling of bugs during sprint process
  • Product Owner working with Team Leads will determine if the bug is a blocker for story acceptance or if a JIRA case spanning sprints is acceptable for bugs created and discovered during the sprinting process.
• Remote Considerations - making sure these processes are visible to the community and to work-from-home developers