: Gherkin , Gherkin ,
少し前に、私の友人の間で、「なぜガーキン？」という質問が起こりました。 さらに、質問はシャベルへの投入ではなく、その適用性を理解するために提起されました。
議論は、G +のkuntashovが次の内容のメモを付けて開始しました（ここでは、私が少し修正した乾燥残留物を持ち込みます）。
Gherkinは、ユースケースを物語（ナレーション）として編集できるように作成されました。 「ほぼ人間の言語」をシンプルで簡潔な形式で、アクセス可能な形式で。 つまり このフォーマットの目的は、主に非技術者に直面することでしたが、同時にそれが自動的に処理されるように、多かれ少なかれ十分な形式を維持します。
同時に、ビジネスアナリストやその他のエンドユーザーは、Gherkinのスクリプトを読み、さらに編集する必要はありません。 したがって、機能ファイルの作成は開発者の肩に渡されます。開発者にとっては、ガーキンは追加の、場合によっては追加の抽象レイヤーです。 私たちが知っているように、「抽象化が流れ」、追加のレイヤーが「漏れ」の可能性を高めるだけです。
プログラマ向けの言語を引き続き使用できますか？
Gherkinの有用性とその対象を共同で理解したい場合は、catの下で歓迎します。
ガーキン= BDDですが、BDD≠ガーキンであることを強調します。
実際、BDDの概念をサポートするツールキットを見ると、2つの専用キャンプがあることがすぐにわかります。
- Gherkinで動作を説明し、開発言語でマッピングを行う人。 たとえば、Cucumber、SpecFlowなど。
- 動作を開発言語ですぐに記述しますが、通常のコードよりも自然な形で記述します。 たとえば、Codeception、mocha.jsなど。
ガーキンは、誰も知らない場合、システムの望ましい動作を記述するための言語です。 自然言語に近いことから、テストを自動化し、「ライブ」プロジェクトドキュメントを作成するために、1石で2羽の鳥を殺す試みを追跡できます。 詳細を知りたい方は、 こちら（eng）またはこちら（rus）をクリックしてください 。
ガーキンとビジネス/分析
当初、ガーキンはアナリストやビジネスの代表者向けのツールとして位置付けられていました。 ビジネス担当者とは、ビジネスの専門家、製品所有者、アナリスト、ドメインの専門家などを意味することを少し説明します。
なぜ彼は行かないのですか？
ガーキンは人間の言語に最も近いにも関わらず、プログラミング言語のままです。 つまり 私たちはビジネスに少しプログラムを依頼します。ほとんどの人は、本当に理解しておらず、一般的には理解すべきでないことをするように求められたとき、どのように行動しますか？ 先延ばしまたは反乱。
ガーキンと開発者
だから、決めた。 原則として、ビジネスの代表者は正式なシナリオを説明することはできません。 さて、これを開発者の肩に投げてください。
なぜここに行かないのですか
実際、開発者の大多数では、コードの前にテストを書くことに対する認知的抵抗をもつように脳が設計されています。 TDDを試し始めたときの気持ちを覚えています。 通常の考え方は完全に崩れ、脳の左右半分が入れ替わっているように感じました... まだ書かれていないものをテストするにはどうすればいいですか！？！？！？ 思考の再構築後初めて、このアプローチは自然なアプローチのように感じ始め、有益になり始めます。
さらに、すべての開発者がテストスクリプトを設計できるわけではありません。 テストスクリプトの設計は特別なプロセスであり、開発者にとっても自然ではありません。 開発者は、検証と検証の問題に関心のない作成者です。
また、ガーキンは開発者にとって追加の抽象化レイヤーであるという絶対に論理的な発言に注意を払う価値があります。 アプリケーション言語ですべてをすぐに実行できるのに、なぜGherkinで何かを書く必要があるのですか？ もちろん、開発者向けのGherkinは完全に冗長なリンクのように見えます。
ガーキンと他の誰か？
まあ、ビジネスの代表者はできない/望まない、開発者はできない/望まない。 このツールは誰のために発明されたのですか？ 誰に役立つのでしょうか？
たぶん問題は、間違ったポジショニングとターゲットオーディエンスの間違った選択にあるのでしょうか？
しかし、ガーキンのターゲットオーディエンスがテスターであると仮定するとどうなりますか？ そして、テスターだけでなく、柔軟なテスター（アジャイルテスター）もあります。 自分の血でテストスクリプトを作成するスキル。 この考え方により、テストに最も重要で必要なシナリオを分離し、簡単に説明できます。 それでも、これらは後に将来のシステムをテストする必要がある人々です。 したがって、彼らは彼らに到達するシステムが仕様と動作シナリオを明確に定義しているという事実に興味を持っています。
はい、通常のロジックを反転します。 はい、テスターは何かが開発される前に作業を開始します。 しかし、実際には、本質的にTDDとBDDはまさにそれについてです...
そして、次の事実に問題はありません。
- テスターは、半分の反復で「天井に座り」、その後すぐにすべてを追い払う必要があります。
- テスターは、自分で「偏った」、たとえば1週間のスプリントで作業します。
反復の最後に、最も興味深く、難しい部分が残ります-通常の開発ではめったに十分な時間ではない研究テスト。
ここで、「ビジネスインテリジェンスを武装したガーキンなどの柔軟なテスターに変更しますか？」という疑問が生じます。
いいえ、変更しません。 テスターの要件ステートメントチームを補完します。 明確にするために、テストマトリックスを参照します。
私の意見では、開発をサポートするビジネス指向のテストの明確な代表であるガーキンです。 つまり、これは2番目の象限（Q2）です。 この象限のテストは、主に要件の収集を目的としています。 Gherkinのテスターがいる場合、要件収集プロセスはどのようになりますか？
現代の開発では、新しい機能は、ビジネスチームが作成したユーザーストーリーの形で生活を開始します。 ストーリーを書くことは、詳細の精緻化を意味しません。 ストーリーは、ビジネスチームと開発チームの間の対話の出発点としてのみ使用することを目的としています。 ここでは、テスターが重要な役割を果たし、各ユーザーストーリーの例とコンテキストの選択を支援します。 この時点で、ガーキンスクリプトが生成され、プロセスのすべての参加者に共通の情報スペースが表示されます。 ビジネスの問題を理解することで、技術スペシャリストは実装においてより実用的な代替手段を提供できるようになります。 結果として生じるユースケースは、ビジネスによって承認されます。 これらのシナリオは、コードを記述するプロセスで開発者をさらにガイドし、コードがビジネス要件を満たし始める時期を見つけるのに役立ちます。
まとめると
ビジネスチームにとって、ガーキンは、技術とプログラマーの知識に精通したチームのスペシャリストがいる場合にのみ有用です。
Gherkinは開発者を支援する可能性が高くなりますが、追加の、場合によっては不要なアクションを実行するように強制します。 開発者にとって、テストマトリックスの第1象限（Q1）では、ユニットテストのレベルでテストの自動化を簡単に実行でき、BDDスタイル（codeception、mocha.jsなど）で簡単に確認できます。
私の意見では、テスターはガーキンにとって最適な対象読者です。 すべてのテスターがプログラムするわけではありませんが、ガーキンを簡単に習得できます。 早い段階で、テスト作業の一部が完了し、他のタイプのテスト、たとえば研究のための時間が残ります。
また、私の意見では、象限1と2（Q1とQ2）からのテストは反対ではなく、お互いに素晴らしい追加であることに注意してください！
第1象限のテストは、プログラムコードの高品質な設計のような素晴らしい成果物を提供します。
2番目の象限のテストは、ビジネスが何が起こったかではなく、期待どおりのものを受け取るという自信を与えます。
これについてどう思いますか？