(これは 6/6 に書きました)
アジャイルプロセス協議会主催の「ソフトウェア技術者サミット in 長野」というイベントに参加してきました。
アジャイルプロセス協議会は、こういうイベントを年に2回くらい地方で開催しているらしいです。
ソフトウェアにまつわる３つの疑問
上田出身の湯本さん(@yumotsuyo)がゲスト講師でした。
以下メモ。
- テストはどこまでやれば十分か
- テストを設計するってどういう事か
- テストを開発するとは何か
- TDDはテスト？
- 開発をドライブする手段だから品質保証しなくてよい？
- 品質保証の人たち、うざい
- 品質はどうでもよい？
- 品質保証が最後にシステムを確認するのはテスト？
- 品質保証の手段だから開発のことは知らなくて良い？
- 開発者は言うこと聞かない！
- 「造り」を無視して品質が保証できる？
- SWEBOK2004より
- ソフトウェアテスティングとは、通常は無限に大きいと考えられる「プログラムの振る舞いの実行領域」から、最適だと考えられる有限な「テストケースの集合」を選定し、所期の通りかどうかを実際に動かして検証すること
- テストは単なる「行為」の総称
- 「何か」をしたら確認するだけの話
- いつも同じものを作るわけではないし、作る必要もない
- 製造業はいつも同じ物を作るために頑張るが、ソフトウェア開発は違う
- ほんとに同じものはコピーできる
- 必ず何かがちょっと違うから作らないといけない
- テストするのも製造業と違い「いつも同じになっていることをテストする」わけではない
- 同じ作業だとしても目的が違う
- 製造業のやり方は使えない
- 品質保証に対する誤解はここからきてる
- ソフトウェア開発の品質保証では、批評（良い、もしくはどこが良くないか）が必要
- 信頼度成長曲線、ISO9000 は使えない、無意味
- 製造業に学ぶところも多い
- 検証しやすく作る
- IT化を推し進める
- どこまでやれば十分か
- コードを実行してエラーにならなければよい?
- 仕様に書いてあるとおりに動けばよい?
- 「いつでもどんな時でも」仕様に書いてあるとおりに動けばよい?
- 「いつでもどんな時でも」「所定の速度で」仕様に書いてあるとおりに動けばよい?
- 仕様に書いてあるとおりに動いた時に変な副作用しなければよい?
- 仕様に書いてないことも「利用シーンを想定し」うまく動いてくれればよい?
- ソフトウェアを使う当初のもくろみを達成すればよい?
- 「最適」を確認することがテスト
- 知らず知らずに考えている「最適」をあらためて整理し共有する→「テスト目的」
- テスト目的の典型例
- 開発を進めるための重要な項目の評価確認のためのテスティング→TDD
- 仕様・要件への充足性を確認するためのテスティング
- 信頼度の向上及び評価のためのテスティング→品質保証
- テストの目的は具体的にすること！
- テスト目的を２つの「観点」で具体的にする
- 見方（網羅的、ピンポイント的）
- 見る位置（外観、中身など）
- プログラムコード →ホワイトボックス
- 仕様に書いてある通り →ブラックボックス
- いつでもどんな時でも →非機能テスト
- 十分かはどう測る？
- どう「目的」と「対象」を選択したかで決まる
- 目的と対象を組み合わせる
- テスト目的とテスト対象の選択と組み合わせを考えるのがテスト計画
- 複数の組み合わせでシステム全体がテストされたことを保証する
- テストしきれないところはレビューも組み合わせて良い
- アジャイル開発での組み合わせ方法
アジャイルの４象限
ビジネス面
2 ↑ 3
チームの支援← → 製品の批評
1 ↓ 4
技術面
第1象限 TDD
第2象限 機能テスト
第3象限 シナリオテスト/探索的テスト
第4象限 非機能テスト
- テストの目的を一言で言うと
- ジャネット・グレゴリー
- テスターに「あなたの仕事はなんですか？」と質問してどのような答えがよいか
- 「バグを見つけること」「要件とマッチしていることを確認すること」→イマイチ
- best answer is "To get feedback!"
- 組み合わせの配置
- 組み合わせた「目的と対象」をスケジュールの中でどう配置するか？
- 方針に沿って、テスト結果からのフィードバックがもっとも適切な時期になるようにテストを設定する
- バインディング・タイム
- アジャイルにするほど目的と対象の配置以外の工夫が必要
- テストだけWFにするとめちゃくちゃ
- 配置したテストに対する「目的」をプロジェクトの状況にあわせて具体的にする
- フィードバック→信頼性→ダウン時のデータ保護
- 目的を明らかにするためには以下に対する十分な文責が必要
- プロダクト/開発プロセス/開発におけるリスク(品質リスク、計画リスク)
- 目的を完遂するための工夫
- 自動テストと手動テストの使い分け
- テストを設計するってどういう事か？
- テスト目的とテスト対象を決めたらテストケースが書けるか？
- テスト対象に関することは、仕様書にすべて書かれているか？
- 仕様書に書かれたこと全てをテストした方がよいか？
- 時間が足りるか？ 十分か？
- テストを設計すること＝テストケースを目的に沿って抽出すること
- 目的を具体化した観点を絞り、技法を選択し、技法に合うようテスト対象をモデル化してテストケースを書く
- 全パターンテストは発散する→無限
- 設計技法 →同地分割、デシジョンテーブル
- テストを開発するってなにか？
- 教科書では、小さい問題、低位レベルの問題を扱っている
- 現実には、テストケース設計技法は現実的なテストアイテム/テスト対象のごく一部しか扱えない
- テストケースを作るためには技法が適用できるサイズまでシステムを分解しなければならない
- 分解して理解する行為＝「分析」
- →設計には分析が必要「テスト分析」
- 十分なテスト、目的に沿ったテストをするためにテストを開発する
- 目的や対象を明らかにする（計画する）
- テストを抽出できるように分解する（分析する）
- 目的に沿ったテストを抽出する（設計する）
- テストを実行できるようにする（実装する）
- 手動なら手順を考える・自動ならテストコードを作る
- まとめ
- どこまでやれば十分か
- 目的を明らかにしてどこまでやればよいかを決めてそれを満たせば十分
- テストを設計するとはどういうことか
- 十分であることを効率的に満たすテストケースを作るため
- テストを開発するとは何か？
- 十分に目的を満たすテストをやり遂げるため
アジャイルマインド
VOYAGE GROUP の 水越さんが講師でした。
- アジャイルプラクティス
- TDD
- ペアプログラミング
- 朝会
- ふりかえり
- 計画ゲーム
- リファクタリング
- 継続的インテグレーション
- アジャイルマインド
- 納期
- 素早く
- 無駄なく
- 正確に
- いいものを
- つらくなく
- 喜ばれる
- 失敗なく
- 迷惑かけない
- 楽しく
- 着実に
- 各自のアジャイルマインド
- 一言では言い表せない
- マインドは存在するか
- mixiアプリ みんなのヘアカタログ
- 理由を説明しなくても直感で判断できる
- 問題を出されたらついちゃんと答えようとするのもマインドの一種かも
- マインドとプラクティス
- マインドがプラクティスを支える
- お互いに支えあっている
- マインド→はっきりするとプラクティスになる
- マインドが必要なプラクティス
- ペアプログラミング
- TDD
- 朝会
- 計画ゲーム
- 共同所有
- など
- マインドを育てるプラクティス
- ペアプログラミング
- ふりかえり
- マインドからプラクティスになる
- 「素早く決断しよう」
- →疑問点は付箋に残して毎朝確認する（モリゾー）
- SW開発と言っても、種類によって持っているマインドが異なる
- 組み込みソフト
- パッケージソフト
- 受託開発
- サービスの運営
- ゲーム開発
- 業界とマインド
- 自分の業界、チームのマインドを把握しておく
パネル
メモってなかったので、印象に残った言葉
某社の@kotyさんの質問で出た「ハンコ駆動開発」とか、顧客に渡すわけでもないのに「コードと１対１の詳細な設計書」を中間ドキュメントとして必要とかって話がすごかったです。詳しく聞きたい!
