Skip to main content
Software Quality Assurance & Testing

Return to Answer

added 11 characters in body
Source Link
Paul Muir
Paul Muir
  • 3.3k
  • 18
  • 35
  • Automated Regression Suites

Nothing fancy, just to cover your basics

  • Identify Areas of Risk

Do code reviews, understand what changed and how in order to optimize your tests. The test everything mentality will not work.

  • Regression Early

Between tasks being developed you will occasionally have some down time. Regression during this.

  • Easy access to data

Ensure that you have plenty of test data for your scenarios and that there is an easy/efficient way to create this data.

  • Identify and Discuss Risks

Communicate with the team whatwhich areas you are focusing your efforts on. Often times scenarios can not be covered and areas can not be tested. It happens. Break the application down into multiple smaller pieces and then determine a priority level on each piece. If there is no direct impacts to either piece, you'd want to do far more testing in an area that is consistently used than an area that is seldom used.

  • DRY

Don't Repeat Yourself.

This is a common development principle that can roll over into the Agile QA world. Knowing where code is being reused and avoiding massive amounts of tests against identical code.

  • Automated Regression Suites

Nothing fancy, just to cover your basics

  • Identify Areas of Risk

Do code reviews, understand what changed and how in order to optimize your tests. The test everything mentality will not work.

  • Regression Early

Between tasks being developed you will occasionally have some down time. Regression during this.

  • Easy access to data

Ensure that you have plenty of test data for your scenarios and that there is an easy/efficient way to create this data.

  • Identify and Discuss Risks

Communicate with the team what are focusing your efforts on. Often times scenarios can not be covered and areas can not be tested. It happens. Break the application down into multiple smaller pieces and then determine a priority level on each piece. If there is no direct impacts to either piece, you'd want to do far more testing in an area that is consistently used than an area that is seldom used.

  • DRY

Don't Repeat Yourself.

This is a common development principle that can roll over into the Agile QA world. Knowing where code is being reused and avoiding massive amounts of tests against identical code.

  • Automated Regression Suites

Nothing fancy, just to cover your basics

  • Identify Areas of Risk

Do code reviews, understand what changed and how in order to optimize your tests. The test everything mentality will not work.

  • Regression Early

Between tasks being developed you will occasionally have some down time. Regression during this.

  • Easy access to data

Ensure that you have plenty of test data for your scenarios and that there is an easy/efficient way to create this data.

  • Identify and Discuss Risks

Communicate with the team which areas you are focusing your efforts on. Often times scenarios can not be covered and areas can not be tested. It happens. Break the application down into multiple smaller pieces and then determine a priority level on each piece. If there is no direct impacts to either piece, you'd want to do far more testing in an area that is consistently used than an area that is seldom used.

  • DRY

Don't Repeat Yourself.

This is a common development principle that can roll over into the Agile QA world. Knowing where code is being reused and avoiding massive amounts of tests against identical code.

Source Link
Paul Muir
Paul Muir
  • 3.3k
  • 18
  • 35

  • Automated Regression Suites

Nothing fancy, just to cover your basics

  • Identify Areas of Risk

Do code reviews, understand what changed and how in order to optimize your tests. The test everything mentality will not work.

  • Regression Early

Between tasks being developed you will occasionally have some down time. Regression during this.

  • Easy access to data

Ensure that you have plenty of test data for your scenarios and that there is an easy/efficient way to create this data.

  • Identify and Discuss Risks

Communicate with the team what are focusing your efforts on. Often times scenarios can not be covered and areas can not be tested. It happens. Break the application down into multiple smaller pieces and then determine a priority level on each piece. If there is no direct impacts to either piece, you'd want to do far more testing in an area that is consistently used than an area that is seldom used.

  • DRY

Don't Repeat Yourself.

This is a common development principle that can roll over into the Agile QA world. Knowing where code is being reused and avoiding massive amounts of tests against identical code.