QA best Practices in Agile world!

We all know testing is vital for quality assurance, and best practices in software testing can yield high-end software at the end. Here are commons fine clue listing about prevailing best practices in software testing projects:

  • Learning is the key. Learn your product, business logic, testing type, automation with new technology.
  • Never assume, always check/verify/validate and communicate the Actual vs Expected results. Otherwise it may end up as a production defect.
  • Communicate and collaborate freely and openly with all the steak holders including your team.
  • Quality is not about only testing and detecting bugs. It’s more to do with creating a usable solution for end-users.
  • Replicate/Reproduce the issue before you file a bug or start testing
  • Keep acceptance Criteria well define, clear, simple and understandable.
  • Plan but not over Plan to avoid manage risk.
  • Test Early, Test Often- Find issues as early as possible. Communicate, report and share it. Reduce the cost significantly and save development time.
  • Enable QA Members to maintain their own testing environment including test data which should be more closer to production environment.
  • Create and maintain clear, lean documentation to keep records as well to have everyone on the same page.
  • Pesticide Paradox: No new defects will discover if you run the same test cases again and again after a certain period. So need to keep reviewing and updating our test suites.
  • Think like a user first specially when you do front-end testing. Any activity which doesn’t add value to customer should be eliminated.
  • Think out side of the box to cover not only happy path but also negative scenarios including different devices, OS and user profiles. Ensure defect reported is reproducible and well documented.
  • Adopt agile methodology, build quality culture and deploy quality product.

Once requirements have been created and approved, while coding is in process, it is time to create test cases. The idea is to have a complete list of test cases completed before coding is complete, that way you do not waste time during the QA process. Use the Test Type field (choice list) to identify the type of test:

Functional/Sprint Testing : Negative & Positive

 Regression

 Unit and Integration Testing

 Smoke/Sanity Testing

Positive Testing: Positive testing is testing the software in the exact way it was designed. To create these test cases, you will want to follow the requirements document to ensure that all features of the software are tested. In positive testing, you are not trying to “trick” the system; you are simply testing all the features per the design.

Negative Testing: Negative testing is used to try to break the software in ways that a typical user might, by entering erroneous data. Here are some examples of negative testing:  Date formats – Try entering invalid dates (like 02/30/2006). Try entering alphabetic dates (like Jan 1,2006), try entering in totally bogus information (xxxxxxx).  Numeric formats – If you know a field must allow only numeric entry, try entering character data (abcdefg). Try entering commas, decimals, hyphens, dollar signs.  Field Sizes – If you know the size of a field (let’s say up to 20 characters), try entering a large amount of data (like 100 X’s), it should handle that gracefully. Many times this will cause a crash. I like to go to every field and just enter tons of xxxxxxxxxxxxxxxxxx and see what happens.

Release Preparation / Regression Test Cases: Each new release has the potential to break existing features of your software. It is a great idea to have a list of regression test cases that are run to ensure that all the existing features work as originally designed. Prior to the testing process for the release, the existing test cases should be updated to ensure a high quality test process for the release.

Unit and integration tests: Unit tests will isolate each component of your app, while integration tests will assess how well each subsystem works. Run unit tests in parallel to save time, but don’t move onto integration tests until you have ensured that individual components work like they should.

Smoke/Sanity Testing: Could be use as very high level production testing on the same release day. It can also perform if you do a minor code change due to injecting the new changes did not break the system.

Share the Knowledge

You May Also Like

About the Author: codenbox

Leave a Reply

Your email address will not be published. Required fields are marked *