2

Should I include negative test scenarios in my test automation? As of now, I'm just using positive tests for my test automation. Any ideas from you are pretty much appreciated.

Thanks in advance. Cheers!

3

What does your product manager say?

Your product owner (aka stake holder) will be interested in listening to your reason for having positive tests and negative tests or not. You may need to present the pros and cons to your product owner to help him / her make this decision. Some of aspects you may need to take into account include but not limited to:

  • what values does negative tests bring?
  • how much extra effort / time do you require in order to implement +ve and -ve tests?
  • what are the consequenses of not having -ve tests?
  • To which extend, you will implement negative tests? The number of negative tests is infinite, so you will have to limit the number of -ve tests and you need to show why you have chosen some -ve tests and not others.

Please remember a tester is an integral part of a multi-discipline, cross-fucntional team. Your decision should never be made alone, please coordinate with the rest of your team before making a decision that may impact others and mostly importantly, the overall progress of a project.

1

It depends on your time frame, If you have enough time to cover negative path scenarios it really helps to test all the validation error messages, alert boxes , information messages ....etc.

1

Negative scenarios "expected errors" should be commonly checked as well as positive scenarios. The expected error handling is a part of software and an important part of user guidance in software usage.

E.g. user could enter wrong password or login that could not be saved, but the user should be normally notified by the system what he has done wrong. And keep in mind that boundaries of negative cases are usually much bigger than positive ones, so you should work with values close to boundaries on negative sides or even use randomization in some cases.

Automation of negative cases are highly expected when:

  • high priority of negative cases (loosing data, breaking business process)
  • negative scenarios are done manually as often as automation tests are run (or should be done but there is not enough of time)
  • their implementation will save time for testing team

Here some cases when you should not automate negative cases:

  • positive cases are not covered yet (if the software can not perform expected functions, it far too early to check negative cases). Still there is an exception when "this alert is highly critical!"
  • software for internal usage by users who are instructed about software limitations (they normally know what they should not do)
  • negative scenarios are newly designed (changes are highly expected)
0

Agree with all other answers. I suggest to pitch to include negative scenarios.

  • When one is taking decision to implement automation for any application, it's rare that it would have less time frame which will restrict you from implementing negative tests

  • Using automation we have some boundaries already limited to identify bug/defect[As a result can not automate 100% all manual test cases], So if we exclude negative scenarios also then we might not be able to use max power of automation

  • Yes, surely you need to communicate this to senior team members and stakeholders for clarity if you focused & concerned on ROI[return on investment]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.