1

I often get requests from developers and others to test some scenarios to check if a web app functions correctly. Generally, these scenarios don't have enough details and I have to waste a lot of time in getting information that should have already been given to me. So, I was thinking of forcing the entire organization to communicate such scenarios in Gherkin format, as shown below.

GIVEN the conditions condition-1, condition-2, condition-3 etc.,
WHEN these actions action-1, action-2, action-3 etc. are performed,
THEN these events occur event-1, event-2, event-3 etc.

This format seems very helpful in that it will make scenarios clear and reduce the need for unnecessary communication to find out the GIVEN, WHENS and THENS that one needs to know before they test something.

But, since I have limited experience in using Gherkin, I am not sure if Gherkin is the best way to communicate scenarios in all kinds of situations. I don't know if there are any better methods out there. So, what is the best way to write testing scenarios ?

  • 1
    Humans are different from computers in a way that humans can (and do) handle unsaid assumptions or custom domain-specific languages with no problems. One neurosurgeon can explain to another in 5 minutes a specific procedure what will take an hour to describe to a smart layman in details in plain English. – Peter M. Oct 5 '17 at 21:38
  • @PeterMasiar - I think you are saying that not all conditions must be mentioned, because some can be inferred by humans. That makes sense to me. We expect people to know the basics of the app and not mention every condition in the scenarios, unless really needed. For example, GIVEN that I am on any Facebook post, WHEN I enter some text and press post, THEN the text must appear in the post. Here, we don't need to mention GIVEN that the user is logged in etc. because its understood. Did I understand you correctly ? – MasterJoe2 Oct 5 '17 at 22:10
  • Correct. But of course in real life, those unsaid assumptions are more complex and less obvious. Imagine how many unsaid assumptions you have when you deal with problem area which takes years to become expert, like flying a plane, medicine, logistical support for an army operation, or our own: software design. We have layers of abstraction on top of layers: binary, assembly, programming languages, OOP, file systems, databases, networks, frameworks, design patterns. Every one of them has different unsaid assumptions. – Peter M. Oct 6 '17 at 13:07
  • 1
    So unless you and your audience share those unsaid assumptions, communication will inevitably fail. Also, different specializations use the same word for different meaning. For a biologist, "buffer" is a solution that resists a change in pH when acids or bases are added. So you don't ever "flush the buffer" like we do when we want to save the data in CompSci. When you do, your experiment is over, gone down the drain. – Peter M. Oct 6 '17 at 13:12
1

Regardless of to Gerkin or not to Gerkin, the point is communication. You need to help communication and rework be decreased for the project as a whole. If that format will accomplish that then good, if it needs to be modified or something else done, then do that. I have found it's best to work as a team to fix the communication and the first step is getting everyone to acknowledge it's an issue and then come to a unified decision on fixing the issue. If you just say "do x" and noone wants to do it or believes it's helpful then you might as well just talk to yourself and do what you want.

  1. Get the team as a whole to see the issue and the need for a solution.
  2. Come up with a list of ideas, not just 1, and present them to the team and indicate which idea you think would work best and why.
  3. Take any other suggestions that people might have and compare/contrast.
  4. Take a vote and go for a team trial run and see if it improves. If future improvements are needed repeat the process.

This will help include everyone and also help the team as a whole be more team oriented and working together. Just enforcing something on everyone to benefit one part usually does not do anything but aggravate everyone and breed dis-unity.

0

I am a manual tester in an organization where we do not get much of written requirements. What helps me is I follow basic functionality checking with the format you have shared in your question. For more details, I focus on DON'Ts and Negative aspects of requirements, where I try to break the developer's code. or A scenarios that developer has not handled or have forgotten to. Play with dependencies, if there are requirements that have pre-requisites and post behaviors.

Try, if they can help you increasing your test scenarios.

-1

Basically there are 3 methods of Test Scenario

  1. Functionality Breakdown: Break the main or top level functionality.
  2. Use case Diagram: Find what are the possible functionality an Actor performed.
  3. State Transition Diagram: try to make state of the functionality like

Add to cart--> Checkout process--> Order details

  • This really doesn't answer the question. Please work on putting more time and thought into understanding questions rather than just posting lots of short simple answers. – c32hedge Oct 9 '17 at 19:40
  • Can you Please answer the question as you have – iamsankalp89 Oct 10 '17 at 4:54
  • Not sure what you mean, but I also realized I didn't give you much to help you improve your answers. Sorry about that. Perhaps you could add more detail about the pros and cons of each method you mentioned--sometimes it's better to answer the question the OP should have asked than the one they actually asked. They're looking to improve communication across their organization so detail on how each of these would help or hinder that, or which would be easier to adopt, would be much more helpful than simply listing techniques. – c32hedge Oct 10 '17 at 14:02

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.