継続的デリバリー読書会 4 参加してきた #CDStudy
9月22日に継続的デリバリー№4が行われましたので、参加してきました。
募集ページ
Twitterのまとめ
タイムテーブル
13:30 - 14:00 アイスブレイク & 7章説明(@kyon_mm)14:00 - 15:15 Chapter7(コミットステージ
15:15 - 15:30 8章説明(@kyon_mm)
15:30 - 16:45 Chapter8(自動受け入れテスト)
16:45 - 17:00 9章説明(@kyon_mm)
17:00 - 18:15 Chapter9(非機能要件をテストする)
18:15 - 18:30 クロージング
今回は、全体的に@kyon_mmさんによる開発やテストに関する解説を多くしていただきましたよ。相変わらずすごいですね@kyon_mmさんは^^
7章 コミットステージ
コミットステージでは、開発時のソースコードのコミット時に何を行うべきか?というお話でした。ここで関わってくる重要な要素としては、 ユニットテストがあるでしょう。私たちのテーブルの議論は以下のようになりました。テーブルメンバーは私と@kyon_mmさん、@mau0824さんです。また、@kyon_mmさんにテストの分類について詳しく説明してもらいました。
上のホワイトボードはまだ書きかけの状態の図なんですが、私自身が非常にためになったのは、 開発したコードのメインブランチへのマージは、既存システムを網羅したユニットテスト群を通過した後に行うという事です。作成したコードのユニットテストに関しては作成者の責任において行われるべきであり、それをメインブランチへマージする前には、他のシステムへの影響を踏まえて、あらかじめ作成してあるユニットテスト群をくぐらせるという事ですね。
8章 自動受け入れテスト
受け入れテストは最も顧客に近いところで、最も変更の多い所です。また、 見積りとの兼ね合いも難しい所です。私たちのテーブルの議論は以下の様になりました。私は特に見積りとテストの兼ね合いが気になっていたので、その辺を重点的に話を聞いていました。例えば、「客先から予算の関係でテストを削ること」を求めらた場合、その説明の難しさという事を感じました。 品質とコストと納期、その全てが揃ってこそ価値ある製品が納入できるとは思っていても、人と人(企業と企業)の考え方の違いによって差が生まれてしまい、自分たちの品質方針が守れなくなってしまう事もあるかもしれません。
また、@kyon_mmさんにまたホワイトボードで熱く語っていただきました。
ユーザーストーリーとか ハッピーパスは、アジャイルやXP界隈で出てくる単語ですね。ここでは、右上に書いてあるピラミッド型のテストの重点度の図が、私にとってツボでした。ユニットテストが一番下にあって、上のテストを支えているように見えるこの図は、 開発者目線の図であると、@kyon_mmさんは言っていました。加えて客先が求めているのは、 一番上の受け入れテストを重点に考えるはずだから、形状はまったく逆になると。なるほど。忘れがちですが 真理ですね。こういう点からも受け入れテスト、大事ですね。ここまで自動化する価値があるという事ですね。
9章 非機能要件をテストする
これも難しい問題ですね。私が気になったのは、 非機能要件は標準化されているか?という点です。最近私は仕事上BIとかデータベースに触れることが多く、パフォーマンスチューニングという点でも今後関わっていく可能性があります。私達のテーブルの討論結果は以下の様になりました。ここでも、いいお話が聞けました。ユニットテストをうまく使ってDAOのレスポンスタイムを計測するテストプログラムを組み、極端にレスポンスが悪いプログラムを確認しておくと。なるほど!そうすれば継続的デリバリープロセスにも組み込めますね。昨今、DBMSが充実していてデータベースエンジニアとしてSQLの処理速度を確認する事は容易でも、統合自動化プロセスの一環として使用できるようにするには、これもありかなと思いました。