ogawaeri commented 4 years ago

受託開発におけるハイアジリティのとりくみ

概要

ITビジネスが中心となっている昨今、開発における意思決定/課題の早期発見の重要性は高まっている。特に課題の発見には設計～試験までを短期間で繰り返す（イテレーション）ことが有効である。イテレーションとテスト駆動開発の事例について紹介。

このセッションに関連するキーワード

テスト駆動開発
自動テスト
BDD(自然言語)
Spock
sitimi

セッションの内容

開発に入る前の仮説検証プロセス

開発に入る前にどういうことが起こるか早く知りたい、というのをラーメンから説明（@￣ω￣@）

ミニマムなスコープ管理によるプロジェクト運営

課題の発見にはウォーターフォールの開発より、設計～試験までを短期間で繰り返す（イテレーション）ことが有効である。

仕様の見える化とテストファーストによる品質保証

"テスト駆動開発"は、先に結合/受入試験レベルの項目書を作成して開始するスタイル。

【メリット】
- 開発の早い段階で仕様が明確になる
- 実装とドキュメントの不整合というありがちなことを減らせる →自動テストとプログラムで整合性をとるという考え
【困難な点】
- 結合テストのデータバリエーションが膨大に。一部はUT(JUnit)で確認したとのこと
- 自動テストは結合/受入試験レベルのためDB接続があり、試験のたびにDB状態が変わるため工夫が必要。 →DBの状態を決まったところに戻すようにしたり、シナリオの組み立て方を工夫して対応したそうです。

どんなテストをおこなったのか？（Spring Boot と Spring Test）

振舞駆動開発(BDD)
- テストのやり方テスト対象がどうふるまうか確認するシナリオ作成する。従来の3APattern(Arrenge/Action/Assert。JUnit4のイメージ)から、BDD(GTW:Given/When/Then)で試験を実施。BDDはテストケースを自然言語（人が話すような自然な言葉）で記述する方式。
- 使ったツール結合試験：Selenium + Cypress、Spock + Geb、Spock + sitimi
BDDの実例より
- BDDのメリット自然言語に近いテストコードのため、新人/Javaを知らない人でもすぐにシナリオを作成できるようになった
- 困ったこと画面試験で使ったsitimiはまだアイコンの判定が得意ではないそうで、誤操作がありキャプチャを取るのが難しかったとのこと。ちなみに話者の寺田さん作成！ →sitimiを使っていた新人さんは、ツールが認識しづらいUIコンポーネントは人にも分かりづらいのでは…と思うこともあったそうです。
受入テスト駆動開発テスト仕様が受入テスト相当のシナリオ受入試験（皮下テスト）：Spock + Spring Test

考察したこと

ドキュメントは成果物として重視しないという考え方に、思い切った考え方だなと感じました。
正直、結合/受入試験レベルの自動テストのための環境設定/データ準備/証跡の残し方（特に画面試験）を考慮すると難易度が高く、あまりやりたくないです。ただ、自動テストは何度も同じテストの実行/結果確認ができる事がメリットのため、一度苦労して作成すると後から報われるとも分かりました。また、このテスト駆動開発の考え方は、仕様の検討・コーディングに必要であり、こういう開発方法がある、ということを知ることができてよかったです。
テスト駆動開発では、いつ仕様を検討するのか分からなかったため聞いてみたところ、テスト仕様書は、製造をする前のスプリントに作成するそうです。仕様書がテスト仕様書に完全にとって代わられています。派生しますが、スプリントも分け方は大きく分けると２つあるとのことです。
- スプリント役割 ①作りたいものがはっきりしており、納期までの期間を分けたスプリント ②スプリント内で作りたいものの仕様検討からスタートする

①と②のどちらかによって回答が変わり、私は①だったので上記の回答でした。 ②だと恐らくスプリントの開始時に検討（テスト仕様作成）をするのだと思います。イテレーションの仕方によって、最適な手法/成果物を考えることは大切だと感じました。

疑問点

Spock

講義資料URL

https://t.co/VKvXHsYqqD?amp=1

fukumotom commented 4 years ago

知らないキーワード多数。。仮説検証プロセスというのは、プロトタイプ作成に似ているのかな？アジャイル開発とはまた別もの？

ドキュメントは成果物として重視しないという考え方

長期メンテナンスするときは何を持って仕様を確認するんだろう？開発スピード、とにかく検証するから、今動いてる成果物を正とする、ということなのかな。

スプリント役割

移行ツールは①でやったけれど、②の考え方もあるんですね。仕様検討からとなると、M/UTだけのスキルでは足りないんだなぁと思いました。

ghost commented 4 years ago

実装とドキュメントの不整合というありがちなことを減らせる

ドキュメントとプログラムの挙動に差異が生まれないのは良さそうだと感じました。ただプログラムの質がテストコードに依存する(という認識)ので、テスト項目を洗い出すのが大変そうです。

ogawaeri commented 4 years ago

スライドのURLが見つかったので貼りました。聞きなれない言葉だらけの中、コメントありがとうございます！

仮説検証プロセスというのは、プロトタイプ...

ここでは今までの仮説検証プロセスでは、"意思決定が遅れていること"、課題が開発工程が進んでから見つかることを説明し、迅速化が必要なことをお話していました。

長期メンテナンスするときは何を持って仕様を確認...

ここでは"テスト仕様書"になります。アジャイル開発だったので"必要なものがあれば作る"かもしれないですが、確認できなかったです。"テスト仕様書"に沿って作ったテストケースがＯＫになることが正しい状態でした。

仕様検討からとなると、M/UTだけのスキルでは

少数精鋭という言葉を思い出しました。

ogawaeri commented 4 years ago

ドキュメントとプログラムの挙動に差異が生まれないのは良さそうだと感じました。ただプログラムの質がテストコードに依存する(という認識)ので、テスト項目を洗い出すのが大変そうです。

聞きなれない言葉だらけの中、コメントありがとうございます！開発スタイルに合った成果物を選んでつくることは大切ですが、テスト項目を洗い出すのは仕様を考えることになるため難しそうだね。（最終形態は決まるけどどうやってやるかは決まっていない。）小規模システムだといいのかもしれない。

applepie-umai / SpringFest2019