The Recent development of the frameworks like Cucumber shows the importance of techniques that make technical automated tests more readable to business. But are we able to design BDD test scenarios well? Are the sentences describing test steps always clear and consistent? Is our code fully reusable without any unnecessary duplications? Suppose we have thousands of Gherkin scenarios and a dozen of engineers developing them: aren’t there sometimes phrases like „I click…”, „I press…”, „I activate…”, „I choose…” which are similar in 90% or even fully equivalent (implemented twice by two different developers, in two different classes). How often are there synonyms in your Gherkin scenarios? „Link”, „URL”, „page”, „site” – if they all occur in scenarios and it is not easy to distinguish then be sure that both business and developers are sooner or later confused. Having ambiguous sentences we lose all the benefits of BDD. Fortunately, the given examples are well-known and deeply investigated topics in the area of natural language processing. One of a common solution for this kind of challenges is language ontologies.

3. •
•
•
•
•

4. •
–
–
–

5. •
–
–
–
•

6. •
–
–
–
•
•

7. •
–
–
–
•
•
•

8. •
–
–
–
•
•
•
•

9. •

10. •
•

11. •
•
•

12. •
•
•
•

13. •
•
•
•
•

14. •
•
•
•
•
•

15. •
–
–
–
–

16. •
–
–
–
–
•
–
–
–
–

17. •
–

18. •
–
•
–

19. •
–
•
–
•
–

20. •
–
•
–
•
–
•

21. •
–
•
–
•
–
•
•

23. •
•

24. •
•

25. •
•
•

26. •
–
–
–

27. •
–
–
–
•
–
–

28. •
•
•
•
•
•
•
•

30. •
•
•
•

31. •

32. •

35. •
•

36. •
•
•
•
•

37. •
•
•
•
•
•
•

38. •
•
•

39. •
•
•
•
•

40. •
•
•
•
•
•

41. •
•
•
•
•
•
•