JaSST '22の2日目のセッションA8 「ソフトウェア開発にかかわる全てのエンジニアの一般教養「ソフトウェアエンジニアリング体系」における品質技術 ～翻訳者が語る「実践ソフトウェアエンジニアリング（第９版）」における品質技術の概観」の資料です。 http://jasst.jp/symposium/jasst22tokyo/details.html#A8
『実践ソフトウェアエンジニアリング(第９版)』の第3部の一部についての超概説です。
Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI“Close portrait of an ostrich” by Tambako The Jaguar is licensed under CC BY 2.0『実践ソフトウェアエンジニアリング』第3部 品質とセキュリティ 超概説Mar. 11th, 2022JaSST ‘22 Tokyo日立製作所 鈴木 一裕@ kz_suzuki
View Slide
2/ 29Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKIこの20分間について◼ 『実践ソフトウェアエンジニアリング 第9版』⚫ 通称: 「プレスマンの白本」⚫ ページ数: 548ページ⚫ 大きさ: 18.2 x 2.7 x 25.7 cm⚫ 重さ: 1,135 g◼ 第3部 品質とセキュリティ⚫ 第15・17章: 品質は大事！⚫ 第16章: レビューは大事！⚫ 第18章: セキュリティは大事！⚫ 第19・20章: テストは大事！⚫ 第21章: ごった煮、逆にいうと一番アツイ⚫ 第22章: 構成管理は大事！⚫ 第23章: メトリクスは大事！
3/ 29Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKIこの20分間について◼ 発表資料の構成⚫ 第3部は、本書全体の25%・144ページ(*1)を占める。⚫ 各部・各節単位で、ポイントとなるキーワードを中心に資料化したところ、約40枚。早口にしても40分オーバー・・・。⚫ 今回は9つの章から5つをピックアップし、「どんなことが書いてあるか」を雰囲気をつかむ1,200秒にしたいと思います。◼ 注意事項⚫ 以下のスライドの章・節番号は、『実践ソフトウェアエンジニアリング (第9版)』（Roger.S.Pressman等、SEPA翻訳プロジェクト、オーム社、2021年）の引用元です。⚫ 本セッションはチュートリアルではなく、紹介レベルの「超概説」です。概要をざっくり把握いただいた後、ぜひ購入をご検討ください。(*1) 重さでいうと約300g。エネルギー換算すると、2.7×1016Jに相当。第17章 品質第18章 セキュリティ第22章 構成管理第23章 メトリクス第16章 レビュー第15章 品質第19章 テスト第20章 テスト第21章 Web・モバイル
"Polargraph line quality" by Euphy is licensed under CC0 1.0第15章品質の概念
5/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第15章 品質の概念◼ 15.1 品質とは何か⚫ David Garvinの主張- 超越的な観点、ユーザの観点、製造者の観点、製品の観点、価値に基づく観点⚫ 設計の品質、適合の品質⚫ Robert Glassの主張- ユーザの満足 = 仕様に準拠した製品 + 良い品質 + 予算とスケジュール内での提供⚫ Weinberg(*1)の「品質は誰かにとっての価値である」は、意外にも引用されていない。◼ 15.2 ソフトウェアの品質⚫ McCallとWalters- 運用・変更・移行という3つの側面に注目⚫ ISO 25010- 製品品質モデル- 利用時の品質モデル(*1) G.M.Weinberg氏は日本のソフトウェア品質業界において、「みんな大好き」という枕詞とともに引用される。なぜならみんな大好きだからである。1第15章2
6/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第15章 品質の概念◼ 15.3 ソフトウェア品質のジレンマ⚫ good enoughなソフトウェアは、よい？(*1)- 「十分によい」？ 「それなり」「ほどほど」「悪くはない」？⚫ 品質コスト- 予防コスト、評価コスト、内部失敗コスト、外部失敗コスト後になるほど、劇的に上昇していく- Meskimenの法則「物事を正しく行う時間はあったためしがないのに、やり直す時間はいつだってある。」◼ 15.4 ソフトウェアの品質を達成する⚫ ソフトウェアエンジニアリング⚫ プロジェクトマネジメント⚫ 機械学習と欠陥予測⚫ 品質コントロール: レビュー、テスト、測定とフィードバック⚫ 品質保証(*1) 右のインフォグラフィック引用元はVisual Capitalist。Goodは7.08で、そこまでポジティブでもない。OKなんて5.83。Not Badの次点でしかない。第15章3 4
"Book review" by Thad Zajdowicz is licensed under CC BY 2.0第16章レビューの推奨方法
8/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第16章 レビューの推奨手法◼ 16.1 ソフトウェア欠陥のコストインパクト⚫ ソフトウェアプロセス中におけるすべてのエラーの50%～65%は、設計時に発生⚫ レビューの技術を用いた場合、設計上の欠陥の発見に最大で75%の効果◼ 16.2 欠陥増幅と除去⚫ 欠陥増幅: 初期に入り込んだ欠陥が、プロセスの後半で複数の欠陥に増殖する⚫ しかしレビューにはコストが・・・ → You can pay now or pay much more later.◼ 16.3 レビューのメトリクスと使い方⚫ 測定・メトリクスはいつでも大事- レビューによる欠陥摘出の実績に基づいて、未レビューのドキュメントの欠陥数を推定- レビュー後、テストによって品質を測定することで、レビューの費用対効果を評価- レビューという初期投資は、テスト工数や修正工数の削減となって返ってきたか？第16章1 2 3
9/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第16章 レビューの推奨手法◼ 16.4 レビュー種別ごとの基準⚫ レビューの形式度- 役割の定義、計画と準備、タスクや成果物の定義、フォローアップ◼ 16.5 非形式的レビュー⚫ 机上チェック、カジュアルミーティング⚫ ペアプログラミング◼ 16.6 形式的(*1)テクニカルレビュー⚫ テクニカルレビューの効果- エラーの発見、トレーニング、バックアップ⚫ レビューガイドライン- 作成者ではなく成果物をレビューする- 議論と反論を制限する- レビューそのものをレビューする ・・・(*1) 「形式的」は”formal”の訳であって、「形だけの」「儀式的な」という意味ではない。第16章654なぜ重大な問題を見逃すのか? 間違いだら けの設計レビュー 改訂版森崎 修司日経SYSTEMS参考文献
10/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第16章 レビューの推奨手法◼ 16.7 ポストモーテム(*1)評価⚫ リリース後、ソフトウェアプロジェクトの結果を評価- ソフトウェアエンジニアリングのプロセスと実践について、何がうまくいき、何がうまくいかなかったか◼ 16.8 アジャイルレビュー⚫ レビューは、アジャイルと相性が悪いのか？- 作り込んだ問題をできるだけ早く見つけ出すというニーズに、むしろ合っている⚫ スクラムイベントもレビューとみなせる- スプリントプランニング ・・・ ユーザーストーリーのレビューと優先順位付け- スプリントレビュー ・・・ 形式的テクニカルレビューの一種とみなせる- 成功を再現し、失敗を繰り返さないようにする(*1) ポストモーテム（postmortem）は「検死」「死体解剖」の意味。なぜこんな言葉を選んだのか・・・。なおこの言葉は、「発生した障害から学びを得るための活動」として使う場合もある。第16章87
"Quartz watch component parts" by explainthatstuff is licensed under CC BY-SA 3.0第19章ソフトウェアテスト – コンポーネントレベル
12/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第19章 ソフトウェアテスト – コンポーネントレベル◼ 19.1 ソフトウェアテストに対する戦略的アプローチ⚫ 品質は、プロセス全体を通してソフトウェアに組み込まれるものであり、プロセスの最後に、手直しのようにテストを適用することはできない。⚫ コンポーネントテスト→統合テスト→妥当性確認→システムテスト⚫ テストはいつ終わるのか？- テストは終わらない。テストを行う主体がエンドユーザに移っただけ- 時間と金を使い切った時点でテストは終わる◼ 19.2 計画と記録保持⚫ 「ビッグバン」アプローチと、インクリメンタルなアプローチ⚫ コンポーネントテスト- 内部的なプロセス論理とデータ構造にフォーカス- スタブとドライバの必要性⚫ テストの投資対効果- 全数テストは不可能(*1)。複雑度が高く、エラーが潜んでいそうなコンポーネントを選ぶ(*1) 「ソフトウェアテストの7原則」 その2第19章1 2
13/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第19章 ソフトウェアテスト – コンポーネントレベル◼ 19.3 テストケース設計⚫ テストプロセス失敗の要素- トレーサビリティの喪失、データの不整合、テストカバレッジの不完全さ⚫ コンポーネントテストにおけるテスト対象- インタフェース、データ、独立パス、境界条件、エラーハンドリング◼ 19.4 ホワイトボックステスト⚫ コンポーネント設計として記述された制御構造を利用してテストケースを導出⚫ 制御フローテスト: プログラムのステートメントや分岐のカバレッジを保証- いわゆる「命令網羅」「分岐網羅」といったコードカバレッジ- サイクロマティック複雑度⚫ データフローテスト: 変数の定義・使用・破棄に着目第19章3 4int blech (int j) {j = j – 1;j = j / 30000;return j;}Binderの例題2行目が正しくは j = j + 1 であったとすると、この誤りを検出できるテストケースはいくつある？
14/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第19章 ソフトウェアテスト – コンポーネントレベル◼ 19.5 ブラックボックステスト⚫ ソフトウェアの機能・ふるまいに着目してテストケースを導出- ホワイトボックステストの代替ではなく、補完⚫ 同値分割: プログラムの入力ドメインをデータのクラスに分割し、テストケースを導出⚫ 境界値分析: エラーを起こしやすい境界値でテストを行う。⚫ インタフェーステスト: 受け取ったデータを適切な順序、データ種別で扱い、また適切な順序、データ形式で返すか- 統合テストの一部と見なされることも◼ 19.6 オブジェクト指向テスト⚫ クラスによってカプセル化された操作と、そのクラスの状態の振る舞いに着目⚫ 状態遷移的なテスト- 例: 銀行口座のクラスは、開設から閉鎖まで、どういう状態遷移を辿っていくかを検証第19章5 6
"Connecting Rod" by Daniel Y. Go is licensed under CC BY-NC-ND 2.0第20章ソフトウェアテスト – 統合レベル
17/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第20章 ソフトウェアテスト – 統合レベル◼ 20.1 ソフトウェアテストの基礎⚫ Kanerの「良いテスト」- 良いテストは、高い確率で欠陥を発見できるテストである- 良いテストは、冗長ではない- 良いテストは、「ベスト・オブ・ブリード」 (*1)である- 良いテストは、単純すぎても、複雑すぎてもいけない◼ 20.2 統合テスト⚫ コンポーネントが正しく動くことは確認済みなのに、なぜ統合テストが必要なのか？(*2)⚫ インタフェースに関係するエラーを発見するためのテストを行いながら、ソフトウェアのアーキテクチャを構築していく⚫ インクリメンタルアプローチによる統合- トップダウン / ボトムアップ- プログラムの構築とテストを、小さい単位で段階的に行う(*1) 時間やリソースに合わせて、テスト群から必要なテストケースが選び抜かれていること。(*2) 右上の画像は「2 unit tests, 0 integration tests」などで見つかるインターネットミーム、出典不明。第20章1 2 ✔✔✔ ✔✔出典不明のため、公開資料では削除
18/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第20章 ソフトウェアテスト – 統合レベル◼ 20.3 人工知能とリグレッションテスト⚫ リグレッションテストの必要性- 統合テストでモジュールが追加される → ソフトウェアは変化する- 変更が意図しない副作用を引き起こしていないかを確認するために、テストを再実行する⚫ 人工知能によるリグレッションテストセットの選定◼ 20.4 オブジェクト指向コンテキスト内の統合テスト⚫ 明確な階層構造をもたないため、トップダウン/ボトムアップなアプローチはしづらい⚫ スレッドベースのテスト- ある入力やイベントに対応するために必要なクラスの集合（スレッド）ごとにテストを行う⚫ フォールトベースのテスト- モデル分析に基づき、フォールトを発見する可能性が高いテストを設計する⚫ シナリオに基づくテストケース設計- 製品が何をするかではなく、ユーザが何をするかに集中し、誤った仕様を見つける第20章3 4
19/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第20章 ソフトウェアテスト – 統合レベル◼ 20.5 妥当性確認⚫ 「顧客が当然と考える期待結果どおりにソフトウェアが機能するとき、妥当性確認は成功したといえる」⚫ ユーザが認識できる動作や、ユーザが認識できるシステムからの出力に焦点を当てる◼ 20.6 テストパターン⚫ デザインパターン: 明確なコンテキスト、問題、解決策の関係を表現するルール⚫ テストパターン: テストに関する問題と、それに対処するための解決策を記述したもの第20章5 6
"mobile phone mast" by osde8info is licensed under CC BY 2.0第21章ソフトウェアテスト – 移動体端末と特定ドﾒｨ…
21/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.1 モバイルアプリにおけるテストのガイドライン⚫ シンクライアント型モバイルアプリの課題- データ転送、動的なネットワーク、端末の種類、リソースの少なさ、・・・- 通信の原理、各モバイルOSプラットフォームの機能や差異の理解が重要⚫ ガイドライン- 制御されていない実世界の条件下でのテスト- 最重要となるハードウェアとプラットフォームの組み合わせの明確化- 現実的な無線トラフィック・ユーザ負荷条件下における性能測定 ・・・◼ 21.2 モバイルアプリにおけるテスト戦略⚫ 認定テスト⚫ 性能テスト- モバイル固有なものとして、ダウンロード時間、データ保存容量、電池のもち⚫ デバイス互換性テスト⚫ UXを考慮したテスト ・・・第21章1 2
22/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.3 UXを考慮したテストの課題⚫ ジェスチャーテスト- ペーパープロトタイプでは妥当性や有効性が十分にレビューできない- ジェスチャーが利用できない人、利用できない環境では？⚫ スクリーンキーボード⚫ 音声入力- 環境条件と個々人の声に起因する入力の差異⚫ アラート- WiFiの切断、メッセージ受信、着信といったイベントをハンドルできているか？⚫ 回復テスト第21章3
23/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.4 Webアプリのテスト⚫ Webアプリのテストにおける戦略は、モバイルアプリにも適用可能⚫ 21.5節の前座的な節。節として分けなくてもよかったのでは・・・◼ 21.5 Webアプリにおけるテスト戦略⚫ コンテンツテスト- データに応じてコンテンツが動的に変わる- 構文や意味(*1)、コンテンツの構成や構造のエラーを見つける- レビューとテストの合わせ技での検証⚫ インタフェーステスト(*2)- 設計ルールへの準拠、見栄え⚫ ナビゲーションテスト- ユーザがWebアプリを巡回するための仕組みがすべて機能するか- リダイレクト、ブックマーク、サイトマップ、サイト内検索・・・、(*1) 「構文と意味」（syntax and semantic）は本書で何度か登場する。文法的な正しさと、内容自体の正しさを指す。(*2) コンポーネントテストにおいて出てきた、モジュールのインタフェーステストとは別のもの。ここではユーザインタフェースを指す。第21章54
24/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.6 国際化⚫ 国際化 (internationalization、i18n)- 開発が必要となる変更なしで、複数の国や言語で使うことができるようにする⚫ 地域化 (localization、l10n)- 地域特有の要求を追加したり、対象となる地域で製品を使用できるように適応させていく- 言語の違い、各国の通貨や文化、税制、技術的・法的標準、・・・⚫ 地域ベンダーへのアウトソーシング、クラウドソーシングでのテスト第21章6
25/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.7 セキュリティテスト⚫ システムを保護する仕組みが、不正な侵入から実際にシステムを守ることができるか⚫ 情報獲得により得られる価値以上に、システムへ侵入するコストを引き上げること◼ 21.8 性能テスト⚫ システムとして統合したソフトウェアの、実行性能を確認- システム要素を統合するまでは、システムの本当の性能は確認できない- ただし、性能テストはテストプロセスにおけるあらゆる段階で実施する⚫ 2つの目的- ユーザ数・トランザクション数・データ容量といった条件下でシステムがどのように応答するかを把握- 性能を改善するための設計修正に役立つメトリクスの収集⚫ 負荷テスト- さまざまな負荷レベルや負荷の組み合わせを実環境で確認する⚫ ストレステスト- ソフトウェアがどの程度の負荷まで処理できるかを判断するために、限界まで負荷を高めていく第21章87
26/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.9 リアルタイムテスト⚫ リアルタイムアプリケーション- 処理や応答が非同期- イベントに対する処理、データの読み書きタイミング、タスクの並列動作への考慮、・・・⚫ 実地テスト- 何が起こるか予測しづらい環境> サポート期限の切れたブラウザやプラグイン、固有のハードウェア、不安定なWiFiやキャリア回線、・・・- 少数のユーザしか関わらないユースケース、マイナーなブラウザ、多様なデバイス、・・・⚫ ネットワークサービスにおける性質- 輻輳、再送、雑音、タイミングの変化、・・・⚫ 重み付きデバイスプラットフォーム表- デバイスとOSの相対的重要度に基づき、サポートの優先度と工数の配分を決める第21章9OS1 OS2 OS3相対的重要度3 4 7デバイス1 7 n/a 28 49デバイス2 3 9 n/a n/aデバイス3 4 12 n/a n/aデバイス4 9 n/a 36 63
27/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.10 AIシステムのテスト⚫ 経験則かデータ分析に基づくアルゴリズム- 膨大なデータ同士の相互作用がテストを難しくする⚫ 静的テスト- 用いられるデータやアルゴリズムにステークホルダが同意しているか- プログラムコードがAIの仕様に沿っているか⚫ 動的テスト(*1)- 専門家により策定された動作仕様どおりか> 専門家にも知られていない新しい関係性を見つけることを目的としているかも- セーフティクリティカルシステムで使っても問題ないか- 倫理的な問題はないか⚫ モデルベースドテスト- ステートマシン図のような要求モデルをテスト設計の軸にする。(*1) AIプロダクト品質保証コンソーシアムから、『AIプロダクト品質保証ガイドライン』が発行されている。第21章10AIソフトウェアのテスト――答のない答え合わせ [4つの手法](AI/Data Science実務選書)佐藤 直人, 小川 秀人他参考文献
28/ 2921 3 421 3 4876521 3 4876521 3 487 96521 3 4 6521 3 487 9 106511 1221 3 4876521 3 4 6521 3 4 5第15章第16章第17章第18章第19章第20章第21章第22章第23章910 1169Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI第21章 ソフトウェアテスト – 移動体端末と特定ドﾒｨ…◼ 21.11 ゲームとシミュレーションのテスト⚫ プレイアビリティテスト- ゲームがプレイヤーにとってどれほど楽しいか- アルファテスト: エンドユーザの代表者を集めて、開発組織の中で行われる- ベータテスト: 1人以上のエンドユーザによって、開発者が管理できない環境で行われる⚫ アクセシビリティテスト- どれほどの人びとがコンピュータシステムを利用できるか⚫ ユーザビリティテスト- ユーザがアプリを活用できるか、アプリがユーザの行動をうまく誘導できるが、アプリからユーザへのフィードバックが適切であるか、そうした相互作用に一貫性があるか- 相互作用性、レイアウト、可読性、・・・◼ 21.12 ドキュメントとヘルプ機能のテスト⚫ マニュアルに沿って操作したのに期待通りの結果にならないのは最大の苦痛⚫ テクニカルレビュー＆動的テスト第21章11 12
Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKI"bird" by Mathias Appel is licensed under CC BY-NC-ND 2.0第3部まとめ
30/ 29Copyright 2022, Hitachi, ltd. Kazuhiro SUZUKIまとめ◼ 「品質とセキュリティ」は、ソフトウェアエンジニアリングの25%(*1)を占める広大な分野である。◼ テスト・レビューを中心に説明したが、それはあくまで品質確保のための仕組みの一部である。◼ 品質保証の分野は決して「体系化済み」ではなく、変化し続けている。◼ 分野の変化についていく、あるいは変化を起こすためには、ベースラインを知ることが大切。◼ベースライン、それが本書です！(*1) 本書比
kzsuzuki
keithyokoma
kumamatsu
.png){kind=avatar}
jisungbin
takmin
yoshidashingo
tsutaj
yoshikieguchi
charmichokshi
shogo452
mixi_engineers
chmikata
hiboma
jlugia
mthomps
malarkey
carmenintech
geeforr
soudai
myddelton
sachag
sugarenia
thekraken
iamctodd
jrom