『実践アジャイルテスト』第11章のコメント・疑問
第11章 技術面のテストを使った製品の批評（P217）
11.1 第4象限の紹介 （P218）
製品を批評する技術面のテストとは、要するに非機能要求に対するテストという理解でOK?（ヤマモト）
P219 「非機能要求や機能をまたがった~説明する責任があります。」の部分は痛いところをついています。
特に非機能要求のトレードオフにまつわる制約などをきちんと説明する必要があります。（例：性能を確保するために拡張性を犠牲にする・・・）（岩井）
P.219 リサの話「テスターがアジャイルチームに大いに貢献していることは、質問することです。」アジャイルサムライのインセプションデッキにもある、手ごわい質問/核心を突く質問ですね。(You&I)
11.2 誰がやるのか？ （P220）
チームメンバーができればいいけれど、外部の専門家を利用してもいい、その場合でもチームが主体性を持つこと、ということ？（ヤマモト）
外部の専門家に支援を仰ぐ場合は事前にネゴっておく必要があるので、早めに非機能要件を確認しておかなければなりませんね。
ウォーターフォールであれば、要件定義で非機能要件を確定して、開発フェーズ中にそうした専門家をアサインする時間的余裕があったのですが。。。（岩井）
「チームの中のスキル」／開発の段階でPSR（パフォーマンス、スタビリティ、信頼性、拡張性）を作りこむことは可能、と言ってますね。（岩井）
P.221 チームの中のスキル「チームがすでに持っているスキルをもう一度みて、現在の要員でできる「～性」テストのタイプを検討してみましょう。」アジャイルって何か新しい事をしなくても良い。今のチームで最大限出来る事を見つける事も大事ですね。新しい事に取り組むにはチームはもとより自分自身も変化が必要だと思います。(You&I)
11.3 いつやるのか？ （P222）
できるかぎり早めに。すべてが揃わないとテストできないと考えるのではなく、早期にテストできるように工夫しよう、ということかな。（ヤマモト）
⇒パフォーマンステストもインクリメンタルに、ということですかね。（岩井）
リリース計画時やテーマ計画時に非機能要求について考える、というのは同感です。
そうでなければ、早期に専門家を外部からアサインすることもできません。（岩井）
11.4 「～性」テスト （P223）
カタカナ表記がここまで読み辛いと思ったのは初めかも。って位に後半は読みにくい記述だった。(You&I)
11.4.1 セキュリティ（P223）
P.223 「セキュリティは「-ility」で終わりませんが、「～性」の仲間に含めます。」面白い発想だ。(You&I)
P224 権限付与機能は業務機能の一部であり、それとは別の非機能要件としてのセキュリティ観点が必要ということでしょうか。（岩井）
P224 セキュリティのテストにはリスクベースのテストが適している。
リスクベーステストとは、欠陥を作りこんでしまう可能性と欠陥が発露したときの損害をリスクとして計上し、高いものからテストを行う手法。（ヤマモト）
P225 セキュリティテストにも探索的テストが・・・（岩井）
P225 「セキィリティテストの考え方」
インサイドアウト（ホワイトボックステスト）：ツールを使う。テスタープログラミングの知識が必要？
アウトサイドイン（ブラックボックステスト）：アタッカーと同じ気持ちで。最新情報を知ってる必要がある。
※秋に開催されたOSC2011Nagoyaに「セキュアコーディングノススメ（Java編）」というセッションがありました。
主催のJPCERTコーディネーションセンターのサイト（http://www.jpcert.or.jp/）に色んな情報があります。（岩井）
P.226 セキュリティテストの考え方「80/20ルール」セキュリティ予算の20%がツールの予算で一般的なセキュリティバグの80%を見つける事が出来る。残りの20%のセキュリティバグを見つける為に、予算の80%を使って専門家を雇う。(You&I)
11.4.2 保守容易性（メンテナビリティ）（P227）
P227 従来の開発ではコードレビューで、アジャイルではペアプログラミングで担保。（ヤマモト）
P227 標準やガイドラインを作成するのは良いとして、それが守られているかをどう担保するのかがモヤっとしています。（岩井）
私も守らせるという、5S(整理・整頓・清掃・清潔・躾)の中の躾の部分はどう理解してもらうか悩んでますね。(You&I)
P227 コード共有や自動化も、よいコードであることを推進する。と言っているのかな？（ヤマモト）
P228 データベースにも保守容易性が求められる。（岩井）
P.228 リサの話：相変わらず内容が不明瞭。テストで見つかるはずの不具合が見つからなかった。原因はスキーマを手動でメンテしていたから。スキーマの修正スクリプトを修正するのは諦めて、新規に作成して解決したって事でしょうか。(You&I)
11.4.3 インターオペラビリティ（P228）
（インターオペラビリティ：相互運用性）要は他システムやデバイスとの連携をテストすること。非機能要件ではない気がします。
相手側システム、デバイス、テスト環境といったリソースに関するスケジュール調整の方に、むしろ苦労することが多いです。（岩井）
11.4.4 互換性（コンパチビリティ）（P229）
互換性の要求を見落とさないように。同じスクリプトの実行で済ますことができないか考えよう。かな？（ヤマモト）
11.4.5 信頼性（リライアビリティ）（P230）
平均故障時間や平均故障間隔といった指標。単純に同じテストを繰返し行うことで可能。
これはテストを徹底的に自動化するアジャイルに合ってますね。（ヤマモト）
単体テストや受入れテストで実施した自動化テストを利用して信頼性テストが可能。（岩井）
「何をもって信頼性OKと判断するかを顧客に尋ねる」←これは大事ですね。（岩井）
11.4.6 導入容易性（インストーラビリティ）（P231）
継続的インテグレーションとデプロイの自動化によって向上させることができる、と。（ヤマモト）
本文には触れられていませんが、デプロイ以外の付帯作業についても導入容易性が必要かと。（岩井）
（例：マスタデータのセットアップ、M/Wの設定 etc）
11.4.7 「～性」のまとめ（P232）
「~性」テストは他にも沢山あるなぁ、という印象。いずれにしても、インクリメンタルなアプローチと顧客から品質目標を引き出すことが重要。（岩井）
個人的には、フェールオーバーテストの話が軽く流されていたのが少し残念でした。（岩井）
11.5 パフォーマンステスト、負荷テスト、ストレステスト、拡張性テスト（P233）
11.5.1 拡張性（スケーラビリティ）（P233）
アジャイルチーム単独では解決できない。対策としては「チームを外から見る」ことと「早めに計画する」こと。（岩井）
11.5.2 パフォーマンステストと負荷テスト（P233）
11.5.3 パフォーマンステストツールと負荷テストツール（P234）
11.5.4 ベースライン（P235）
P.235 「ベースラインとは、パフォーマンスについてソフトウェアの新バージョンに対して比較できるもののことです。」意味不明な説明。(You&I)
ベースラインを定めることと用語を定義して全員で共有することが重要。（岩井）
P236 後の方で性能問題が出ると致命的になる場合があります。だから反復の中に性能テストを入れるべき。（岩井）
11.5.5 テスト環境（P237）
11.5.6 メモリ管理（P237）
P237 「ストーリに関して、プログラマと一緒に働いている時には~尋ねてください。」の主体はテスターということでしょうか？
逆に言うと、メモリに関する問題が残っている以上は、リスク管理の観点でもプログラマをリリースしてはいけないということ。（岩井）
11.6 まとめ （P238）