First of all. Happy new Year!
Explain how to write good Gherkin, beyond just the syntax Like I'm five.
For those who may not know, Gherkin is a language that makes it easy for businesses to write down requirements for a system that fulfills business needs. This reduces the chances of wasting time in development where there is a disconnect between the tech team and the product owner or business team.
However, while trying to actually implement the actual Gherkin. I have found it difficult to establish the following things:
- What counts as a Feature?
- What counts as a Scenario? When should you pull out a scenario and make it a feature and when should you make a feature a scenario?
- What makes good Given statements?
- Why not split individual And sections into their own scenarios in most cases?
I speak from naivety and would like to understand what makes for good Gherkin and good requirements specification
Soft skills are as critical as technical skills for a software engineer. No one works in isolation. Each person has to deal with teammates, colleagues, managers, etc. Therefore team interpersonal skills are essential too. Soft skills include things like good communication, honesty, teamwork, integrity, organization, empathy, etc.