Development Done Checklist - IntegratedBreedingPlatform/Documentation GitHub Wiki

Why Checklists?

The volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably... Checklists seem able to defend anyone, even the experienced, against failure in many more tasks than we realized.

Development is Done when...

  • Followed all standards (no new Sonar rule violations introduced)
  • Automated Unit and integration tests (JUnit) have been written and passed
  • Acceptance tests (Cucumber + Stepdefs Impl) have been written where possible/applicable e.g. for new features
  • Deployed on Standalone Server ideally a BMS install
  • Database script changes tested on clean install and update install using Groovy scripts
  • Tested in all supported browsers
  • Tested UI changes at minimum resolution
  • Code has been reviewed (or pair programmed)
  • Is the code cleaner than when you started? The BSR.
  • Code has been committed and CI build has passed
  • Exploratory and acceptance testing has been completed
  • Branch has been merged and deleted

JIRA Format

|| Task || (/) / (x) ||
| Followed all standards (no new Sonar rule violations introduced) | |
| Automated Unit and integration tests (JUnit) have been written and passed | |
| Deployed on Standalone Server ideally a BMS install | |
| Ensured that all tests are passing in branch (local and remote) | |
| Database script changes tested on clean install using Groovy scripts | |
| Liquibase change logs tested | |
| Tested in all supported browsers | |
| Tested UI changes at minimum resolution | |
| **Reviewer** Code has been reviewed | |
| **Reviewer** Code has been committed and CI build has passed | |
| **Reviewer** Branch has been merged and deleted | |
| **Reviewer** Pushed to QA | |

*Risk Assessment*: 

*Testing Instructions*
|| Type of Change || (/) / (x) || Comments ||
| Front-end Change | | |
| Liquibase scripts | | |
| Regression Testing Needed | | |
| Performance Testing Needed | | |
| Affected REST service(s) | | |

Bookmarklet

For old JIRA version. TODO: new JIRA html format

javascript:(function(){document.getElementById('comment-wiki-edit').getElementsByTagName('textarea')[0].value = '|| Task || (/) / (x) ||\n| Followed all standards (no new Sonar rule violations introduced) | |\n| Automated Unit and integration tests (JUnit) have been written and passed | |\n| Deployed on Standalone Server ideally a BMS install | |\n| Ensured that all tests are passing in branch (local and remote) | |\n| Database script changes tested on clean install using Groovy scripts | |\n| Liquibase change logs tested | |\n| Tested in all supported browsers | |\n| Tested UI changes at minimum resolution | |\n| **Reviewer** Code has been reviewed | |\n| **Reviewer** Code has been committed and CI build has passed | |\n| **Reviewer** Branch has been merged and deleted | |\n| **Reviewer** Pushed to QA | |\n\n*Risk Assessment*: \n\n*Testing Instructions*\n|| Type of Change || (/) / (x) || Comments ||\n| Front-end Change | | |\n| Liquibase scripts | | |\n| Regression Testing Needed | | |\n| Performance Testing Needed | | |\n| Affected REST service(s) | | | '}());

"Testing instructions only" format

*Risk Assessment*:

*Testing Instructions*
|| Type of Change || (/) / (x) || Comments ||
| Front-end Change | | |
| Liquibase scripts | | |
| Regression Testing Needed | | |
| Performance Testing Needed | | |
| Affected REST service(s) | | | 

javascript:(function(){document.getElementById('comment-wiki-edit').getElementsByTagName('textarea')[0].value = '*Risk Assessment*:\n\n*Testing Instructions*\n|| Type of Change || (/) / (x) || Comments ||\n| Front-end Change | | |\n| Liquibase scripts | | |\n| Regression Testing Needed | | |\n| Performance Testing Needed | | |\n| Affected REST service(s) | | |'}());

Detailed explanations and FAQs about checklist items

This section is intended for capturing FAQs and details about some of the checklist items when more explanation is necessary.

Deployed on Standalone Server

Changes have been compiled, built, packaged using maven command line and deployed to standalone server outside Eclipse and tested with Workbench

Acceptance Tests

How do you know if you have to write an acceptance test or not?

  • If you are writing a new feature, you must start with a feature file and core scenarios for it.
  • When you are working in an area of existing features, look at the smoke test suit in Test Link. See what smoke test is manually carried out for this feature when smoke testing. Start a feature file for this feature capturing the high level feature and scenario that is manually repeated with TestLink every time we smoke test. Try and automate with stepdefs and selenium. Start with a very very basic feature description and the most common simple scenario. Do not try to cover all the scenario at once.

Developer Testing

As a developer, how do I document the scenarios I handled during developer testing?

  • You can put Developer Notes in the JIRA ticket description to give special instructions, notes to dev or QA (eg. affected modules)
  • As for documenting the actual test scenarios, dev is expected to create a test session in JIRA with the prefix "DEV: " and document the developer testing done

Code Review

As a code reviewer, what are the key things I should check for?

  • Inspect the new Junit tests (if applicable). Are all relevant scenarios covered?
  • Have the developer run the module’s (or modules') unit tests to be more confident that nothing was broken elsewhere.
  • Have the developer run SonarQube analysis on Java files changed to make sure no new violations were introduced.
  • Have the developer run JSHint on Javascript files changed to make sure no new violations were introduced.
  • Review the commit message. Have the developer change it if not descriptive enough.
  • Oversee the developer actually pushing the commit(s) to master.
  • Do the commit messages describe the changes clearly? See operational ground rules on Git Workflow page.