Don't test cases which users in practice won't execute?
we are working in an agile context where we use Gherkin and Specification by Example to describe tests for our user stories. I often here the argument: Don't test the case, because a user in practice will not do this.
From my point of view this is an invalid argument, because I should know how the system behaves even if the user will probably not do it in practice. As long as the system does not prevent the user to execute this "invalid path" I want to test it, in order to see how the system reacts. If I don't test it and later on user in production will perform these "invalid steps", we might spent a lot of time analysing what has happened if a bug occurs in that scenario.
What do you think?
My opinion is Gherkin is great for integration tests. Unit tests you want to go straight for code coverage, but integration tests, you want to test business rules and logic, but you are not testing a full flow.
When you write test cases for manual testing, you want to zoom into use case examples. Generally in an agile story you have your "Story", under your story you have "Rules", then under rules you have "Use Cases". Gherkin are a great way of consistently expressing rules, but you want to use Use cases to drive how you write test cases.
Thanks for your answear dlai, but my question is not about gherkin or how to write test cases. I want to know in general if you test a software, do you also test test cases where you know that a real user of a system will probably not use the system in the way the test case does?
In honestly.. I just quickly glance at the first sentence and skim. Just a FYI since most of use are professionals who just read this on our break.
Originally Posted by mwoody007
To answer your question.. Of course they put positive examples, a good product manager would think of negative scenarios too. But as a QA Professional, the specs isn't just about what the product CAN do, it's also about what the product SHOULD NOT do, that is equally as important.
I get it why a developer might push back. he or she may or may not know it. You see a bug ticket with that nice little bug icon, etc... they get offended. At a past company I worked with, we changed "Bug" to "Change Request" to create a more neutral tone in the organization. And along with writing the bug steps, we were also required to write why the change was necessary so the developers had a greater understanding. "We would like the form to not accept negative numbers to avoid confusion". "Not able to process invalid characters could lead to a potential security vulnerability". That helps take the edge off.
Ultimately is avoid attachment. Developer or Product pushes back, my attitude is, I've tested the core requirements, and these change requests are my professional opinion. You're perfectly entitled to reject or defer the ticket. My perspective is I'm creating suggestions to improving the product.
no problem at all, I just wanted to give some context to my question.
To your reply. It's exactly my opinion on this topic. My job is to find examples which may break the given rules and to give my feedback in order to create a better product.
Thank you very much for your reply
I am working as senior tester in a software testing company. So, when we regress any Story or an Enhancement, then itís our responsibility to first create the functionality test cases which are as per the product and then create its negative test cases which can be faced by the user in the real time environment. But the chances where user can face negative issue are very rare.
So, now if I come to your question, then my answer based on my prior experience would be Yes, we should execute all the test cases but according to the release priority:
1. If there is no release, then a simple smoke suite having only basic functionality test cases should be executed.
2. If there is a major release, then complete regression suite, covering both functionality and negative test cases should be executed.
I hope my answer gives you more clarity to your question and also let me know if you have any other queries.