初級ソフトウェア品質技術者 受験メモ

2020年11月14日、初級ソフトウェア品質技術者の資格試験を受けてきました。

ちょっと時間がたってしまいましたが所感などメモです。

受験前の学習について

• 問題集↓だけでは合格は難しいと思います。

• www.amazon.co.jp

• 問題集は、幅広い範囲を網羅すべく60問用意してあり、解説も丁寧なので、その知識の範囲で質問の仕方が少し変わるだけなら対応できると思いますが、さすがにあの広いシラバスの範囲を60問だけでカバーできるわけがなく、はずれると全く歯が立ちません。
• そういうことで合格率がまぁまぁ低いんでしょうな・・初級で合格率4割とか2割って、自分の感覚的には難易度高いと思いました。

• 試験実施結果 | JCSQE ソフトウェア品質技術者資格認定

• 今回受験してみて、問題集の60問の範囲で答えられそうだと思ったのは、自分の感覚では半分くらいかなと思いました。
• ですので、品質知識体系ガイドもよく見ておきましょう↓

• www.amazon.co.jp

• ご想像の通り、辞書というかガイドですので、範囲広く網羅していて、よくまとめたなこれだけ、、といった書籍です（そしてところどころすごく熱いのが著者の個性を感じる）。ちょうどその分野に悩んでいて、いいヒントないのかいなって参照するにはピッタリ。順番に素直に読むだけだといつのまにかアタマが他の世界に飛んで行ってしまうので、第2章からシラバスにあった単語を拾って転記するぞ！とか、何かタスクにすることをおすすめします。そうやって内容を把握すると試験対策として効果的です。

• その他にはこの本も読みました。とっかかりとしてはアリだったと思いますが、ちょうどそのころはソフトウェアのテストに悩んでいてGoogleの本の方が印象に残りすぎたためあまり記憶に残ってはいません。

• www.amazon.co.jp

• その他、e-ラーニングも受講しました。

• www.juse.or.jp

• 集合研修と違って、時間や場所の拘束がなく、各章異なる講師が説明してくれるのが飽きなくてよいです、また動画再生スピードがコントロールできたのがよかったです。なお、各章に理解度チェックテストがありましたが、その内容はソフトウェア品質技術者の試験の設問とは全然粒度が違いますので、模擬試験にはなりません。
• あと、試験のシラバスに比べると、範囲が限定的です。その限定的なポイントを実務に寄せて深堀しています。集合研修だと、バグ連関図作成演習があるようですね。実務に即使えそうです。（e-ラーニングでは聞き流していると演習はやらないわけで。。）
• 他に、過去問。

  www.juse.jp

• こうして振り返ると直前週だけで合計15時間くらいは勉強したかと思います。その前数か月の間はeラーニングや読書で合計15時間くらいは勉強したことになりそうなので、全体合計で30時間くらい。
• 昔資格をとったITILもプラスに働きました。
• と、偉そうに言ってますが、合格発表は2021年の1月なので、今は祈るしかないですね（汗

会場関連

• 会場は東高円寺の日本科学技術連盟のビルでした。

• コロナで中止にならないか心配していました（現に2020年の6月の回は中止になっていた）が、感染対策に力を入れている印象でした。例えば、会場入りする前に、手指の消毒（スタッフさんがスプレーしてくれる）＆検温。3人テーブルを一人に一つ。座る位置はテーブルの一番左、一番右、を互い違いにしてソーシャルディスタンス。マスク着用。退出時も時間差。というわけでなかなか安心して受験できるんじゃないでしょうか。リモートで試験させてくれると移動しなくて済むので嬉しいですけどねー・・
• 会場前方に大きな時計を置いてくれていたので、時間は見やすかったです。
• 会場じゃないけど、申込後の試験料は銀行振り込みでした。クレジットカードでの決済もできると嬉しいですよねー・・・

試験関連

• 40問を60分で、今回は計算問題は1問しかなかったと思います。なので、知識があって、文章を読むスピードがそれなりにあれば時間は余ると思います。知識がないと、憶測して悩みますのでそこだけ時間を食って焦ります。
• 問題は4択問題で、「XXについて記述が誤っている選択肢はどれか」「XXについて記述が正しい選択肢はどれか」や、文章穴あき問題（空欄①～④に当てはまる用語を正しく記述している選択肢を選べ）です。
• 前述した問題集と完全に文言が同じ問題は、でません（残念）。ただ、問題集は4択型に慣れるという意味で問題形式としては完璧です。
• 回答はマークシートです（初級なので。中級は記述）。問題は持って帰ることはできません。
• 試験中に顔写真を貼った受験票を監督官が回収されるのですが、その時だけマスクをはずして顔を見せます。
• 途中退出はできません。
• 咳が止まらないなど体調不良とおぼしき場合、検温します、体温が基準値を超えていたら退場・失格になります。・・・ってそんな該当者はいなかったのですが、開始前の説明で上記のような内容を言われるんです。これまでの受験にはない新しい緊張感。咳が心配な人は咳止め薬を飲むとか、飴でも口の中に入れておくとよいかもしれません。

所感

• 品質とは何ぞや、から始まって、認証の話や、技法の話、某企業ではこんなやり方をしている、、など幅広い知識に触れられるので、勉強してみてよかったと思います。知識体系ガイドを困ったときにぱらぱらっと見て、この技法使えそう！と思ったものをググる、というのが有効だと思いました。

参考になれば幸いです。

初級ソフトウェア品質技術者のシラバスから用語まとめ（3章）

初級ソフトウェア品質技術者の資格試験のシラバスVer2.0から第3章分のメモです。

第1章はこちらです。

初級ソフトウェア品質技術者のシラバスから用語まとめ（1章） - 拾って落とすエンジニア活動ログ

 第2章はこちらです。

初級ソフトウェア品質技術者のシラバスから用語まとめ（2章） - 拾って落とすエンジニア活動ログ

SQuBOKを見ていると、この技法は仕事でつかえそうじゃないか？ググるか・・と思う瞬間もありつつ、今週末試験だしメモだけして次行くぞ、やたら分厚い3章に進みます。

3ソフトウェア品質技術

＜工程に共通なソフトウェア品質技術＞

3.1メトリクス

3.1.1測定理論

• メトリクス：定義された測定方法及び測定量
• 測定理論：ソフトウェアの品質測定として、種々の国際規格で整理されている測定と評価に関する主要な概念や理論のこと。
• 測定量：測定の結果として値が割り当てられる変数。
• 基本測定量：単一の属性とそれを定量化するための方法とで定義した測定量
• 導出測定量：複数の基本測定量の値の関数として定義した測定量
• 指標：定義された情報ニーズに関するモデルから導出した特定の属性の見積もりまたは評価を示す測定量。
• 尺度：連続的もしくは離散的な値の順序集合または分類の集合で、それに属性を対応付けるもの
• 名義尺度：順序のない質的変数の測定値を分類するための尺度。OSの種類など
• 順序尺度：順序のある質的変数の測定値を分類するための尺度。障害の重大度の度合いなど。
• 間隔尺度：数値間の等間隔性が保証された量的変数の測定値に対応する尺度。加減算を適用できる。気温、テストの点数など
• 比率尺度：数値間の等間隔性が保証された量的変数で、ゼロという値が属性の量がないことを表す尺度。四則演算が適用できる。身長、体重など
• 評定水準：順序尺度上の点のことで、測定尺度を分類するために使用される。あるメトリクスを用いて得られた測定値を優良可に分類するなど。
• 測定プロセス：メトリクスを実際に計測するプロセス。
• GQM手法：Goal－Question－Metrics手法。ある対象項目に関する任意のメトリクスを、トップダウン方式で決定するための手法。方法（１）組織の方針や戦略に基づき具体的な目標を設定する。（２）目標に対する現在の状況や変化などについて定量的に回答可能な質問を決定する。（３）質問に答えるメトリックを導出する。

3.1.2プロダクトメトリクス

• プロダクトメトリクス：ソフトウェア製品そのものやソフトウェアの振る舞いなどにおける属性を測定する方法の集合
• 内部メトリクス：ソフトウェア製品を動作させずにそのものの属性を静的に測定するメトリクス。内部を見て初めてわかる属性のメトリクス。仕様書など製品の中間生産物の測定に利用する。
• 外部メトリクス：製品を試験実行して振る舞いを測定するメトリクス。テストまたは運用期間中に、実行可能なソフトウェアまたはシステムを実行し、操作し、観察することによって測定する。
• 利用時の品質メトリクス：特定の利用者が特定の利用状況において、有効性、効率性、リスク回避性および満足性に関して特定の目標を達成するためのニーズを満たすために、製品またはシステムを利用できる度合い。
• 複雑度のメトリクス：開発・理解・保守がどの程度困難かを数値で示し、品質を予測するメトリクス。規模が大きい、アルゴリズムが複雑、条件分岐が多い、構造が複雑などだと複雑度が上がる。
• LOC（Lines of Code）：ソースコード行数。品質評価に用いる場合は、コメント行を含まない新規に追加した行数＋改変した行数を規模として扱う場合が多い。
• ファンクションポイント：ソフトウェアの機能を点数付けした規模のメトリクス。ファンクションポイントを用いてソフトウェアの規模を測定する方法をファンクションポイント法と呼び、IFPUG法は最も多く使われている。IFPUG法では、ファンクション（機能）として計測する要素ごとに機能を抽出する。外部入力、外部出力、外部照会、内部論理ファイル、外部インターフェースファイルの5種類の機能種別がある。それぞれの機能について複雑さをもとに重みづけを行って合計するとファンクションポイントが出る。

3.1.3プロセスメトリクス

• プロセスメトリクス：開発プロセスの主に品質にかかわる属性を測定する方法の集合。プロセスの効率性や生産性、安定性などはソフトウェア品質に大きな影響を及ぼす。またプロセスメトリクスからプロダクトの品質をある程度予測することができる。

3.2モデル化の技法

3.2.1離散系のモデル化技法

• UML：ソフトウェアのオブジェクト指向モデリングのための表記法。構造と振る舞いの各側面を目的に応じてかき分けるための複数の図から構成される（構造図（クラス図、パッケージ図、オブジェクト図、コンポジット構造図、配置図、コンポーネント図）、振る舞い図（ユースケース図、アクティビティ図、ステートマシン図、シーケンス図、コミュニケーション図、相互作業概要図、タイミング図）。UMLでモデルを作ることで、コミュニケーションの効率化、レビュー効果の向上、シミュレーション・アニメーションの導入による障害の早期発見の効果がある。
• SysML：システム全体のモデル化のための表記法であり、要求、構造、振る舞いの各側面について目的に応じてかき分けるための複数の図から構成される。UMLとは異なり、システムをハードウェアやソフトウェアに分割する前の全体的な検討を行うシステムズエンジニアリング領域を対象とする。要求図、構造図（パッケージ図、ブロック定義図、内部ブロック図、パラメトリック図）、振る舞い図（ユースケース図、アクティビティ図、ステートマシン図、シーケンス図）を通じて表現。システムエンジニアリング工程でのコミュニケーション改善、障害の早期発見および手戻りの削減の効果がある。
• 構造化チャート（PAD）：構造化プログラミングの理論に基づいてプログラムのアルゴリズムを構造化するための表記法。プログラムの構造を見えるようにする、製造と検査を系統的にできるようにする、処理するデータの構造をプログラムの構造と同じ記法で表現できるようにする という３つの目的がある。なお、問題分析図ProblemDialogDiagramとは、フローチャートにかわり構造的・階層的な表現ができる構造化チャートのこと。
• モデル駆動開発（MDD）：UMLに基づくモデル化や、モデル変換、あるいはコード生成を実施するツールを利用した開発形態。OMG（Object Management Group）の商標。
• MBSE（Model-Based System Engineering）：要求定義や設計の段階ではSysMLを使い、それ以降の工程ではハード、ソフトの開発領域にあわせた技法を使う。このようなモデルを活用したシステムズエンジニアリングのこと。

3.2.2連続系のモデル化技法

• MBD（Model-Based　Development）：対象の振る舞いについて連続的な変化をモデルとして表現し検証やシミュレーション解析を通じて性質を明らかにする、連続系のモデル化およびそれをサポートしたツールを利用した開発形態。
• MDD（Model-Driven Development）：対象の振る舞いを離散的なイベントまたはそれに伴う状態の連なりとしてモデル化する開発形態。

3.2.3ドメイン特化技法

• ドメイン特化言語：ある特定の問題領域(ドメイン）を記述するために開発されたプログラム言語や仕様記述言語およびその処理環境の総称。SimulinkやLabVIEW、VHDLなど。

3.3形式手法

• 形式手法：数理論理学に基づいて仕様記述や検証を行うアプローチ方法の総称。

3.3.1形式仕様記述の技法

• 形式仕様記述の技法：要求仕様や設計を厳密に記述し、系統的な方法で一定の品質保証を目指す技法。要求仕様や設計を、文法・意味論が厳密に定められた形式言語でモデル化して記述する。形式技法の代表的な技法として、VDM、Event-B、Alloyなどがある。

3.3.2形式検証の技法

• 形式検証の技法：テストや人手でレビューできないケースに対し、検証すべき性質を与えて検証を行い、高信頼性を保証する技法。特定の状況でのみ顕在化する障害の自動検出や、対象範囲において障害が発生しないことの保証を行う。
• 不変条件、事前条件、事後条件：システムが状態として保持するデータについて常に成り立つべき条件が不変条件。各関数・操作の実行前に前提として成り立つべき条件が事前条件。実行後に成り立つべき条件が事後条件。

＜工程に個別なソフトウェア品質技術＞

3.4品質計画の技法

• 品質計画の技法：品質計画には、品質目標、開発プロセスやアーキテクチャ・基準や規約などの計画、レビュー計画・テスト計画・検査計画・監査計画などの個別の計画、評価のための判断基準や収集する指標、それぞれの活動の合否基準、結果として製品が要求事項を満たしていることを実証するために必要な記録を含むとよい。また、潜在的な品質不良のリスクおよびその緩和策について言及するとよい。
• 費用便益分析：プロジェクトを評価する際に、経済的指標を用いて有形および向けの費用と便益を見積分析する技法。両者のトレードオフを考慮し品質計画を立てる。
• 品質計画書：品質目標を設定すること、ならびにその品質目標を達成するために必要な運用プロセス及び関連する資源を規定するために作成する計画書。

3.5要求分析の技法

• 要求分析の技法：要求分析には要求の抽出、分析、仕様化、妥当性確認と評価のそれぞれの活動に技法がある。
• プロセスパラメータ：使用するプログラミング言語が指定されるなどシステム開発における制約条件のこと。プロセス要求とも呼ばれる。

3.5.1要求抽出

• 要求抽出：ステークホルダーが意識している要求を獲得して収集するだけでなく、意識していない要求を発見し引き出す活動または技法。
• ステークホルダー識別：ソフトウェアおよびシステムに関係を持つステークホルダーを識別すること。
• 要求開発（Openthology）：要求は元からクライアントにあるものではなく、一緒に開発するものである を合言葉にうみだされた日本発の体系。

3.5.2要求分析

• 要求分析：抽出した要求に対して、分類やモデル化を通じてシステムとその外の境界を明確にし、システム要求からソフトウェア要求へと詳細化及び明確化し、要求の妥当性や完全性、一貫性を確認すること。
• ユーティリティ・ツリー：特定の品質要件を満たすためのサブ要求と管理指標のシナリオをツリー状に階層表記する方法。
• NFRフレームワーク：品質要求をソフトゴールとその依存関係にあるサブゴールという形で可視化を試み、それら個々の品質要求間の相関関係をSynergyとConflictの関係で表すフレームワーク。
• Planguage：仕様言語。システムの品質特性を明確に評価可能な形で定義するための記述方法を示している。
• 品質機能展開（Quality Function Deployment）：製品に対する品質目標を実現するためにさまざまな変換及び展開を用いる方法論。品質展開、（技術展開、コスト展開、信頼性展開、）業務機能展開の総称。品質の展開とは顧客が要求する品質を明らかにして、その品質を製造する製品に組み入れるために必要な事柄を分析する作業。業務機能の展開とは、必要とされる品質を作り込むために実施される業務を機能別に明らかにする作業。つまり、要求される品質を明らかにして、その品質を満たす製品を作り上げるための業務の仕組を構築するためのツール。
• 要求可変性分析：共通のコア資産の再利用を通じて多品種の製品群を体系的に導出するプロダクトライン開発において、多品種製品間のシステム要求における可変性を識別する作業。

3.5.3要求仕様化

• USDM（要求仕様記述法、Universal Specification Describing Manner）：要求仕様を記述するための表記法。要求仕様書を、要求とそれを実現するためのいくつかの仕様のセットで書く。要求は、要求と理由と説明のセットで書く。仕様は、要求で表現された振る舞いに対する具体的な制約条件や処理内容、選択肢など。要求の仕様化では、要求の動詞表現に着目して要求を満たす具体的な仕様を抽出する。

3.5.4要求の妥当性確認と評価

• 要求の妥当性確認と評価：要求やモデルのレビュー、プロトタイピング、受け入れテストの設計などを通じて、ステークホルダーのニーズや上位の要求に照らしてソフトウェア要求が妥当であることを確認し、さらに、要求そのものの記述の品質を評価すること。

3.6設計の技法

• 設計の技法：ソフトウェア方式設計とソフトウェア詳細設計に適用する技法。

3.6.1方式設計の技法

• DSM(依存関係マトリクス）：大規模で複雑なシステムのシステム要素（タスクやモジュールなど）の依存関係を、容易に明らかにするための2次元の表を用いる設計の技法。システム要素を洗い出し、システム要素が実施される順に上から並べ、同じように列名として記述。行に並べたシステム要素が依存するシステム要素を列名から探して×印を記入。

3.6.2詳細設計の技法

• コンポーネント：内容を隠ぺいするシステムのモジュール化部品で、その表明は環境内で置き換え可能である。コンポーネントはその振る舞いを提供インターフェース、および要求インターフェースと要求インターフェース(動的、および静的セマンティクスを含む）によって定義する。
• 設計原則：過去のソフトウェア開発の知見から生まれた、設計の基本思想や作法を示したもの。SWEBOK2004では、設計の推奨技法として、「抽象化」、「相互結合と凝集度」、「分割とモジュール化」、「カプセル化/情報隠蔽」、「インターフェースと実現の分離」、「十分性、完全性、および基本性」の6つの基本思想を取り上げている。

3.7実装の技法

• リファクタリング：外部から見たときの振る舞いを保ちつつ、理解や習性が簡単になるようにソフトウェアの内部構造を変化させること。
• 契約による設計（Design by Contract、DbC）：ここのモジュールの責務を明確にしてソフトウェアの複雑性を下げ、保守性を向上する技法。

3.8レビューの技法

3.8.1レビュー方法

• ピアデスクチェック：成果物の作成者に、机上での障害の発見に長けたレビューア1名を加えて実施するレビュー。
• パスアラウンド：レビュー対象となる開発成果物を複数のレビューアへ配布、または回覧を行うことで障害の指摘を行う形態のレビュー
• ラウンドロビンレビュー：レビュー参加者全員が順に司会者とレビューアの役を持ち回りでつとめるレビュー。
• ウォークスルー：仕様書やソースコードなどの成果物に対し、作成者を含め複数人が内容を確認することで実施するレビュー。インスペクションでは参加者の役割が明確で、形式的なチェックリストを用いるが、ウォークスルーにはそれがないのが違い。

3.8.2仕様・コードに基づいた技法

• パストレース：処理の中のパス（処理の実行経路）と、条件によるそのパスの組み合わせとしてのロジックを確認するレビュー技法。
• ラン・スルー：要求仕様から想定される具体的な入力データをもとに、レビューアが机上で内部仕様やプログラムを追跡するレビュー技法。パストレース技法の一種。
• モジュール展開：分割されているモジュールを一つの図などに展開し、モジュール分けの妥当性、インターフェース設定の適切性をレビューする技法。大規模なプログラムでは量が多くなりすぎて全体の見通しが悪くなるため、他の技法を用いるとよい。

3.8.3フォールトに基づいた技法

• FTA（フォールトの木解析）：その製品がフォールトなどの定義された状態に至る、単独または組み合わせの要因を識別して構造化するための技法
• EMEA（エラーモード故障解析）：ヒューマンエラーによる障害の削減のために、考えられる間違いや人的過誤とその影響、および知名度を系統的に分析するために使用する。FMEA(故障モード影響解析、あるアイテムの故障モードに着目し、原因調査、影響評価を行うこと）の適用対象がヒューマンエラーになったもの。
• CFIA（構成要素障害影響分析）：ハードウェア構成の脆弱性を発見し、障害時にとるべきアクションを明確化するためにIBMで開発された技法。
• PQ（パタン・キュー）デザインレビュー：軽微な一時的障害や一般的に想定されるべき部分的な障害でシステム全体がダウンする、あるいは主機能が使えなくなるようなシステム障害の未然防止のために実施するシステム的なレビューの技法。

3.9テストの技法

3.9.1経験及び直感に基づいた技法

3.9.2仕様に基づいた技法

• グレーボックステスト：機能に対する入力と出量という外部に見える現象から判断するブラックボックステストに対し、仕様が明示されない（暗黙の仕様など）ものは、機能がプログラムのロジックに依存することがあることや、インターフェース仕様の確認のためには内部状態まで踏み込む必要があることから、場合によりプログラムロジックやメモリーの内容を参照する形で行われるテスト。
• 同値分割：テスト対象が同じ振る舞いをすると仮定できる入力や出力などの値の集合や範囲を「同値クラス」としてまとめ、同値クラス内の代表値のみをテストすることによりテストの数を削減する技法。
• デシジョンテーブルによるテスト：テスト対象の仕様をデシジョンテーブルと呼ばれる表にまとめ、これに基づいてテストケースを作成する技法。プログラムへの入力を「条件」実行結果を「動作」として抽出し、表の左端列、条件記述部と動作記述部に記入する。その後、条件指定部と動作指定部に規則を記入する。
• 原因結果グラフ：プログラムの仕様を入力と出力の論理関係、原因間の関係を原因結果グラフと呼ばれるグラフで表現し、それに基づいてテストケースを作成する技法。
• モデルベースドテスト：テスト対象システムの振る舞いをモデル化し、そのモデルに基づいてテストケース、テストスイート、テストスクリプトなどを自動生成する技法。
• 要因分析技法：ソフトウェアの外部市王を要因とその要因がとりえる状態の形式で整理して「要因分析表」を作成し、それに基づいてテストケースを設計する。
• CFD技法（Cause Flow Diagram）：テスト対象の入力（原因）と出力（結果）を同値に分割した同値分割図をもとに原因と結果を流れ線でつないだ原因流れ図（CFD）を作成し、これに基づいてデシジョンテーブルを作成してテストケースを抽出する技法。CFD作成時には実装情報を用いて合理的にテストケース数を削減するグレーボックステストのアプローチがとられている。

3.9.3コードに基づいた技法

3.9.4フォールトに基づいた技法

• ミューテーションテスト：テスト対象のプログラムを一定の規則に基づいて変更あるは変異させたときに、その変異をテストで検出できるかどうかにより、テストケースの集合であるテストセットの十分性（障害発見能力）を測る技法で、ホワイトボックステストの一つ。

3.9.5利用に基づいた技法

• 運用プロファイルによるテスト：ソフトウェアが実際に運用される際にどのように利用されるかを確率分布により表現した利用パターン（運用プロファイル）をもとに運用時と同じ条件下でテスト対象を動作させ、ソフトウェアの信頼性を評価する技法。

3.9.6ソフトウェアの形態に基づいた技法

3.9.7組み合わせの技法

3.9.8リスクに基づいた技法

3.9.9テスト技法の選択と組み合わせ

3.9.10テスト自動化技法

• TABOK：米国ATIが策定した自動テストに関する知識体系。７つの自動化リーダー向けスキルカテゴリと、5つの自動化技術者向けスキルカテゴリが定義され、立場・役割ごとに必要となる知識が体系化されている。

3.10品質分析・評価の技法

3.10.1信頼性予測に関する技法

• ソフトウェア信頼性モデル：ソフトウェアの信頼性を定量的に評価するための数理モデル。動的モデル（ソフトウェア信頼度成長モデル）と静的モデルに分かれる。動的モデルはソフトウェアを実行した履歴から信頼性を計測・評価する。静的モデルでは開発プロセスの特性要因やソフトウェアの特徴と信頼性との関係を過去の実績などから経験的に関係づけたモデル。
• フォールト発見数モデル：テスト時間と発見した障害数の関係に着目して構築した数理モデルから総障害数や潜在障害数を予測する。NHPPモデルや統計的データ解析モデルがある。
• 統計的データ解析モデル：累積障害数データに傾向曲線を当てはめることで飽和状態を予測し、残存障害数を推定するもの。
• Fault-Prone分析：モジュール集合などの要素集合のうちで、フォールトを含んでいる可能性の高いモジュールを特定する技法。
• 欠陥除去モデル：開発作業において混入した欠陥数とその除去数からある工程終了時の残存欠陥数を予測するモデル。

3.10.2品質進捗管理に関する技法

• 異常値管理：目標値や標準値の上限・下限の管理限界を定めて、管理限界を超えたものを異常値として分析して対策を講じる管理手法。
• 工数・成果モデル：プロセス品質を評価するためのモデルで、工数指標と発見障害などの成果を組み合わせたマトリクスを作成し、座標位置によりプロセス品質を把握する技法。開発プロセスのどの工程に対しても用いることができる。縦軸が工数指標の高低（テスト効率など）、横軸が成果の高低(欠陥率など）の2x2マトリクス。(工数・成果マトリクス。工数が高い効率で、成果（発見欠陥）が低がベスト）
• コード統合パターン：横軸に出荷までの時間、縦軸に完成予定のコード量をとった計画コード曲線の形状。S字形曲線なら正常な健全パターン。
• PTR（問題追跡報告Problem Tracking Report）サブモデル：テスト工程で期待できる障害除去数を時系列で展開した曲線。時間軸に沿ってコード統合量に応じた予測PTR率とPTR展開パターンを使用することにより、ある時点のテストの障害率を分析・評価できる。
• Rayleighモデル：PTRサブモデルと近いが、開発プロセスのすべての工程をカバーしている点が違い。PTRサブモデルはテスト工程のみ。
• PTR発生およびバックログ予測モデル：開発プロセスの終了時点でPTRの数とバックログの数を予測するモデル。問題追跡報告とは障害報告書を指し、バックログと歯未解決の障害を指す。分析的なモデルではなく、経験的なモデル。

3.10.3障害分析に関する技法

• ODC(直交欠陥分類）：障害の性質をとらえたまま定量的に分析を行うことを目的とする。プロジェクト状態の診断を早期から少ない実施コストで行うことが可能。１）ODC属性による障害の分類 ２）蓄積された障害データの分析の2つのステップで構成する。 ODC属性には、報告者にによる視点3つと修正者による6つの視点がある。蓄積して分析することで、どの分類に障害が集中しているか分布を調べることにより開発プロセスのどこで障害が発生しやすいかを分析できる。
• バグ分析：バグを分析することで傾向を把握し、同一原因のバグの摘出を測るとともに類似バグの混入を防止することで信頼性の向上を図る。分析には2種類の方法がある。１）作り込み原因をなぜなぜ分析などで追及し、根本的原因に対策を立てる。２）バグの属性から分類し統計的に解析することで、解析対象のウィークポイントをつかむ。

3.10.4データ解析・表現に関する技法

• QC七つ道具：数値データを整理解析し、現象を定量的に分析するために用いる技法。視覚的に表現することで問題点がわかりやすくなる。特性要因図（フィッシュボーン）、パレート図、チェックシート、ヒストグラム、散布図、管理図、層別。層別とは、ばらつきの原因になる要因ごとにデータを分けて考えること。
• 新QC七つ道具：言語データを品質管理に生かす技法。言語データを整理して図で表現する。親和図法、連関図法、系統図法、マトリクス図法、アロー・ダイアグラム法(日程計画図）、PDPC法、マトリクス・データ解析法。
• EDA（探索的データ解析）手法：モデルを前提の解析するのではなく、データの示唆する情報を多面的にとらえて解析する手法。
• p管理図・u管理図：工程が安定した状態にあるか管理する。p管理図は障害の確率、u管理図は単位当たりの障害数を管理する。

3.11運用の技法

• ソフトウェア若化：経年劣化による稼働中システムの性能低下、異常停止やハングアップなどの障害を未然防止するための保全技法。予防的な再起動など。プロアクティブな技法。

3.12保守の技法

＜専門的品質特性のソフトウェア品質技術＞

3.13使用性の技法

• ユーザビリティテスト：ユーザーに使ってもらい、その際の行動や発話から製品・サービスの使用性の問題点を発見する技法。
• CIF（Common Industory Format for Usability）：人間中心設計活動からの成果物の表現形式を規定している。
• ヒューリスティック法：使用性に関する知見を集めたガイドライン（チェックリスト）に基づいて評価するインスペクション法の一種。

3.14セーフティの技法

• フォールト・アボイダンス：リスク低減の設計技法のひとつ。高信頼性部品を使用したり、故障の生じにくい設計や構造を採用することで危険事象の発生を回避しようとする考え方。
• フェイルソフト：リスク低減の方法のひとつ。故障個所を切り離すなど、縮退を許してもシステムを完全には停止させず処理を続行する。
• フェイルオーバー：切り替え。
• パッシブセーフティ：人体の被害の影響を最小限に抑える技法。エアバッグなど。
• アクティブセーフティ：危険事象を未然に防ぐ技法。危険事象の前兆を監視し、正常状態への回復または危険事象の回避を行う。アンチロックブレーキシステム等。
• セーフティ・クリティカルシステムのテスト：信頼性保証のテストあるいは、危害を発生させないことを保証するテストのこと。OK/NGだけで判定するべきではなく、システムの安全性に対してどのように悪影響を及ぼしているのかという点を念頭に置いて評価し、安全度水準に沿って判定するべき。
• ハザードに対するシナリオテスト：ハザードの推測と列挙、ハザードから危険事象へのパスの道程、安全機能の動作評価の大きく3つに分けられる。ソフトウェアに対するハザードの推測は、機能府動作、仕様の穴、設計・実装障害、非定常入力の4つの観点から行う。

3.15セキュリティの技法

• KAOS：FTAを応用して、脅威と対策を関連付けながら、脅威分析と対策決定をサポートする分析技法。
• ミスユースケース法：通常のユースケースに加え、攻撃者となるミスユーザー、脅威を表すミスユースケース、その脅威への対策を表すセキュリティユースケースの3つの要素を追加している。
• SDL（セキュリティ開発ライフサイクル）マイクロソフトの提案した技法。設計段階の技法として、データフローに基づく脅威の分析技法が提案されている。DFDをもとに脆弱性を分析する。典型的な脅威として、なりすまし、かいざん、否認、情報漏洩、DoS、権限昇格の6つ（STRIDE）に分類。
• フォレンジック（デジタル鑑識）：サイバー攻撃など犯罪が発生した際、科学捜査のための証拠の収集方法を明記したもの。
• ペネトレーションテスト(侵入テスト）：情報システムに対して実際に侵入を試みるテスト。
• ファジング：ツールを活用した機械的な脆弱性発見の技法のひとつ。極端に長い文字列など問題を起こしそうなデータを送り込んでソフトウェアの動作状態から脆弱性を発見する技法。
• アタックツリー分析：セキュリティ要求分析の技法のひとつ。攻撃や脅威が顕在化する状況の分析のため、木構造のゴールツリーを使って分析する。

3章は、、知ってたことを省略したというのもありますが、時間切れにて随分手を抜いてしまいました。

次は合格したかもわからないですが、受験の所感でも投稿の予定です。

初級ソフトウェア品質技術者のシラバスから用語まとめ（2章）

初級ソフトウェア品質技術者の資格試験のシラバスVer2.0から第2章分のメモです。

第1章はこちらです。

yb300k.hateblo.jp

脱線、SQuBOKはよくこれだけまとめたなという感想ですが、単語だけ紹介されているものなどは、ググらないとよくわからない場合があります。ググった結果を使うときは、科学技術連盟のものをできるだけ使おうとは思いましたが・・そうもいかなかったので、参考まで、ということで。

2ソフトウェア品質マネジメント

＜組織レベルのソフトウェア品質マネジメント＞

2.1ソフトウェア品質マネジメントシステムの構築と運用

• QMS（QualityManagementSystem)：組織の主たるアウトプットである製品・サービスの「品質に関して組織を指揮し、管理するためのマネジメントシステム」。ISO9000シリーズに規定されているのは、品質マネジメントシステムは品質計画、品質管理、品質保証、品質改善の4つの活動から構成され、トップマネジメントによる品質に関する方向付けのもと、目指すべき品質目標が設定されている。日本のTQC、TQMのなかの品質マネジメントシステムは上記とは異なっていて、お客様に安心して使っていただけるような製品を提供するすべての活動であり、顧客満足の追及や品質を中核とした全員参加の改善が基本。
• TQC（TotalQualityControl）総合的品質管理：全社的品質管理、品質管理の教育・訓練、方針管理、マーケットイン思想、QCサークル活動、QC診断、全国的品質管理推進活動などの特徴を持つ。1997年に呼称がTQMにかわる。理念は引き継がれ、経営管理技術へと発展した。
•  TQM（TotalQualityManaement）総合的品質マネジメント：経営管理の技法。品質第一の考え方、データ・事実に基づく管理、人間性尊重 の3つの思想がTQMを支えている。継続的改善の技法として代表的なのは方針管理、機能別管理、QCサークル。
• 現地・現物：実際に問題が起きた現場に足を運び、実際の現場で自分の目と足で確かめ、事実を確認する。 その上で、頭で考える
• 小集団活動：従業員の経営参加の方法の一つであり、企業内で少数の従業員が集まったグループを結成し、そのグループ単位で共同活動を行うことを目的として運営するもの。QCサークルが広い分野で展開されたものが、より一層の人と組織の活性化を目指す動きとして、間接部門を含む全員参加の幅広い改善活動として進化したもの。
• プロセスアプローチ：組織内で用いられるプロセス及び、特にそのプロセス間の相互作用を体系的に明確にし、運営管理すること。

2.1.1品質マネジメントシステム

• QCサークル：同じ職場内で品質管理を自主的に行うグループ活動。QC手法を活用して職場の改善などを全員参加で行う。
• 方針管理：会社から出た方針を達成するための取り組み。たとえば（中長期の）経営計画→年度方針→部門方針といった具合に、全社的な方針（重点課題）を徐々に展開（ブレークダウン）していく。
• 機能別管理：製造や販売といった直接的な実施部門での取り組み（部門別管理）に対し、品質や原価といった各部門に共通するような、管理部門の視点から見た取り組み。実施部門ごとの縦割りで見るのではなく、たとえば実施部門同士を品質などの視点から横串を通し、定められた目標を達成する取り組みであり、部門横断的な役割を担う。そのため、英訳ではcross-functional managementと表現される事もある。
• 人間性尊重：TQMの思想の一つ。はたらく人に負荷をかけるのではなく、主体的な取り組みを助長することによって効率や安全性、企業としてのパフォーマンスを向上させる。

2.1.2セキュリティのマネジメント

• セキュリティのマネジメント：守るべき資産の価値が損なわれる脅威を回避、もしくは軽減するためのマネジメント。
• 脆弱性管理：開発段階において脆弱性を作り込まないことを目的とした活動と、出荷後の運用段階で脆弱性が発見された場合に対応することを目的とした活動がある。脆弱性の悪用による被害を最小限にするために脆弱性管理を行う。
• CC/CEM：1章のメモ参照。CCがセキュリティ評価の共通基準。CEMが評価方法。
• プロテクションプロファイル：CC（コモンクライテリア）に従って、調達者が要求するセキュリティ要件を定義した文書。主に政府機関で調達要件として使用される。
• セキュリティターゲット：プロテクションプロファイルを満たすための、開発者がその製品固有のセキュリティ要件を定義した文書
• CC承認協定（CCRA、CommonCriteriaRecognitionArrangement）：条約に準ずる国際協定。CCに基づいたセキュリティ評価・認証の相互承認に関する協定。2003年に日本が参加。2017年は27か国参加。
• 暗号アルゴリズムの危殆化：コンピューターの能力向上や、新たな攻撃手法の発生などにより、特定の暗号アルゴリズムの安全性が危ぶまれる状態になること。

2.1.3ソフトウェア品質推進活動

• シックスシグマ：ミスの発生確率を100万分の3.4以下にするという目標を実現するための経営革新技法。DMAICと呼ばれるシックシグマ達成プロセスを繰り返すことにより6シグマのミス発生確率を達成する。
• DMAIC：Define、Measurement、Analysis、Improvement、Controlの5段階のプロセス。GEがDefineを追加する前は、モトローラの開発したMAICだった。
• SWQC（SoftwareQualityControl）：NECで行われてきたソフトウェアの総合的品質管理活動。”品質を追求しよう！生産性は後からついてくる”
• Qfinity：富士通が全社的に進めている品質改善活動
• 品質会計：NECが考案したソフトウェア品質マネジメント技法。バグを負債とみて、バグ件数を主要メトリクスとしてバグ摘出目標管理を実施。
• TPS（ToyotaProductionSystem）：トヨタ生産システム

2.2ライフサイクルプロセスのマネジメント

• ライフサイクルプロセスのマネジメント：システムやソフトウェアの構想から廃棄までの活動に対するマネジメント。

2.2.1ライフサイクルモデル

• ソフトウェアライフサイクルプロセスに関する規格（ISO/IEC12207）：ソフトウェアを開発し、運用するための標準プロセスを提供する規格。企画から廃棄までの43個のプロセスを包含している。各プロセスは7つのカテゴリに分類されている。目的と成果を定義した後に、アクティビティに分解し、具体的な活動をタスクとして定義している。
• システムライフサイクルプロセスに関する規格（ISO/IEC 15288)：システムを開発し、運用するための標準プロセスを提供する規格。システムの要求定義から設計、実装、運用、保守、処分までの25個のプロセス。各プロセスは合意、組織プロジェクトイネーブリング、プロジェクト、テクニカル、の4つに分類されている。（※2008だとそうだったらしい。2015だと、30プロセスで、合意、組織プロジェクトイネーブリング、技術管理、技術の4プロセス）

2.2.2セーフティ・クリティカル・ライフサイクルモデル

• セーフティ・クリティカル・ライフサイクルモデル：災害や事故防止のための安全機能に使用されるシステムやソフトウェアのためのライフサイクルモデル。安全性重視のためのライフサイクル。安全性解析・開発・安全妥当性確認の三つの要素で構成する。
• 安全度要求：想定したハザードが引き起こしうる危険事象に対するリスクとSIL。
• 安全機能要求：リスクを許容範囲内に収めるために必要な安全機能。
• 安全妥当性確認：安全度要求に応じた安全機能要求が高い信頼性で作り込まれ、想定したハザードが発生しても危険事象に至らないことを検証する。
• 機能安全（IEC61508）：機能安全の基本安全規格。7部で構成されていて、1部から3部が要求事項を含んでいる。
• 自動車電子制御の機能安全（ISO26262）：安全に関する国際規格のうち産業分野用に詳細化したグループ安全規格の一つ。各ハザードに対して対応の厳格さの目安となるASIL（自動車用安全度水準）を決定する。
• セーフティゴール：安全要件の最上位。危険事象を回避、または影響を低減するための目標。
• 医療機器ソフトウェアーソフトウェアライフサイクルプロセス（IEC62304）：医療機器ソフトウェアの安全設計・保守に必要なライフサイクルプロセスに関する要求事項を規定した規格。アクティビティ及びタスクからなるライフサイクルプロセスのフレームワークと各ライフサイクルプロセスに対する要求事項を、ソフトウェア安全クラスに応じて規定する。
• ソフトウェア安全クラス：危害が患者、操作者、他の人におよぼす影響に応じて分類したもの。クラスA、B、Cがあり、Aは負傷または健康障害の可能性はない。Cは死亡または重傷の可能性があるもの。
• SOUP（Software Of Unknown Pedigree）：開発過程が不明なソフトウェア。医療機器のIEC62304では、SOUPに対する要求事項を定義する。

2.2.3プロセスモデル

• FDD(機能駆動型開発）：アジャイルプロセスモデルのひとつ。ユーザーにとっての機能価値（feature）を重視した開発手法。あらかじめビジネスモデルを理解し、ログイン機能や購入機能といったユーザー機能を中心に計画をたて、設計や開発を行う。
• クリスタル：取り決めがゆるい。プロジェクトの規模や影響度に応じて，必要となるメンバーの役割や作成すべき成果物を分類・定義。

  Part7 最も取り決めの緩い「クリスタル」－－「反省」を通してプロセスを改善 | 日経クロステック（xTECH）

• プロダクトライン開発：多品種製品向けのソフトウェア開発技法。PLEまたはSPLと呼ばれることもある。複数製品における共通のコア資産を構築して、そのコア資産から各製品を導出する戦略的な開発技法。フィーチャー（ユーザー視点でのシステム特性）に基づく可変性分析の導入が特徴。
• 派生開発（XDDP）：すでに開発済のソフトウェア資産に対して、製品価値を高めるための新しい機能の追加や既存機能の改善を行う開発のこと。設計作業が必要かどうかの観点で、要求を機能追加（設計が必要）と、変更（絵設計不要）に分ける。
• スペックアウト：上記変更の最初の手順として行うこと。要求仕様書、設計資料、ソースコードなどの既存資産から、現状の仕様を抽出すること。
• USDM：要求と仕様のまとめ方の方法。自然言語を用いて「要求」と「仕様」を階層化して整理するのが特徴。

  ｢要求｣と｢仕様｣を階層化する【USDM】で｢要求仕様書｣を作成

• トレーサビリティマトリクス（TM）：変更要求仕様に対する既存のシステムへの影響範囲を確認するため、変更要求仕様を「行」、システム構成要素（フォルダやファイルなどの単位）を「列」としてマトリクスを作成する。各升目に関数を記述する。

2.3ソフトウェアプロセス改善のマネジメント

2.3.1ソフトウェアプロセス能力改善のためのプロセスモデル

• CMMI(Capability Maturity Model Integration 能力成熟度モデル統合)：顧客及び最終利用者のニーズを満たすための高品質な製品とサービスを開発する活動に対して、包括的で統合された一連の指針を提供するモデル。組織におけるプロセス改善に焦点を合わせており、場当たり的で未成熟なプロセス(初期）から、改善された品質と有効性を伴った秩序ある成熟したプロセス（最適化された）への進化の改善経路を、22個のプロセス領域により示す。成熟度レベル（１から５）と能力度レベル（０から３）という2種類の改善経路を持つ。ARCに要求事項がまとめられていて評定できる。評定方法のクラスとしてABCの3つがあり、クラスA準拠の評定方法としてSCAMPIがある。
• PSP（パーソナルソフトウェアプロセス）：技術者の自己改善のためのプロセス。技術者のQCDにかかわる見積精度、生産性、成果物の質を向上させるのが目的。
• TSP（チーム・ソフトウェア・プロセス）：チームでソフトウェア開発を行うプロセス。役割別に前提スキルや実施すべき活動を述べる。
• TPI（テストプロセス改善）：TMap（TestManagementApproach for structuredtesting）構造化されたテストプロセスの方法論をベースにした、テストプロセスを改善するための技法。テストプロセスを20のキーエリアに分け、それぞれのプロセスの成熟度のレベルをAからDの4段階（一部のキーエリアは2-3段階）で評価。進化版がTPI NEXT。

  TPI NEXT入門

• TMMi（テスト成熟度モデル統合）：テストプロセスを段階的に改善していくための技法。CMMIと親和性があり、CMMのテストプロセス部分を補完する。5段階の水準とそのゴールで構成されている。アセスメントをサポートするTMM-AM（TMMアセスメントモデル）が定義されている

2.3.2ソフトウェアプロセス改善のためのマネジメント技法

• プロセスアセスメントに関する規格（ISO/IEC15504）：アセスメントと改善方法について規定した規格。プロセス参照モデル、測定の仕組、プロセスアセスメントモデルによりアセスメントを行う。
• IDEAL：継続的及び組織的なソフトウェアプロセス改善のライフサイクルモデル。初期フェーズ（Initiating）、診断フェーズ（Diagnosing）、確立フェーズ（Establishing）、実行フェーズ（Acting）、学習フェーズ（Learning）の5フェーズから構成されている。PDCAに比べて手順が詳細に示されている。プロセス改善を計画する際のフレームワークとして利用できる。
• ポストモーテム：ソフトウェア製品を開発した後に、開発時の良かった点、悪かった点を洗い出し、次期開発への改善点を明確にするための検討会。開発に参加した人から意見を集め整理する。整理した情報をもとに関係者を集め検討会を実施する。
• 落穂拾い：日立製作所で行われている事故やトラブルの再発を防ぐための検討会。
• なぜなぜ分析：根本的な原因を論理的にもれなく検討し、障害の再発防止を図るための分析技法。
• 三階層SEPG（Software Engineering Process Group）：東芝。大規模組織で効果的にソフトウェアプロセス改善活動を推進するための階層的な活動体制。開発部門SEPG,カンパニーSEPG、コーポレートSEPGと三階層で、それぞれが役割と責任をもって推進する。現場、現物、現実を重視する三現主義でソフトウェア開発部門のプロセス改善活動を推進する。

2.4検査のマネジメント

• 検査計画：検査方針、検査体制、検査方法、検査環境および検査日程などの基本的な計画を明確にし、検査計画書を作成する。検査計画書には中間成果物の検査であるドキュメント検査や探針、製品検査の各段階の検査内容を盛り込む。
• ドキュメント検査：中間成果物である設計書やユーザーマニュアル、テスト計画を検査し、合否判定を行う。
• 中間品質監査：各開発工程の完了時や、検査工程開始前に、製品品質が検査に耐えうるものになっているか否かを判断するために各工程の品質把握を行う。テスト工程での摘出障害件数や摘出傾向の妥当性評価によるテスト工程完了監査や探針を行う。
• 製品検査：検査部自らがテスト項目の設計、テストツール、てすとプログラム、テストデータなどのテストジョブの作成、テスト環境の構築を行い、検査を実施する。開発部門のテスト結果も確認して合否を判定する。

2.5監査のマネジメント

• 第一者監査、第二者監査、第三者監査：組織の内部の監査員が実施するのを第一者監査、顧客及び発注先またはその代理人などの組織に利害関係を有する者が実施する監査を第二者監査、外部の独立した組織によって実施される監査を第三者監査と呼び区別することがある。
• 購買先プロセス監査：購入者が購買先に対して、作業プロセスが適正化、標準に対する順守状況はどの程度かを確認し、必要に応じて作業プロセスの是正および改善勧告を行うこと。
• ソフトウェア開発における監査：ソフトウェア開発の各工程において、プロダクト監査またはプロセス監査の観点で確認する。
• プロダクト監査：あらかじめ定めた各工程での成果物が、当該工程において作成されていることを外形的な要件を中心に確認する。
• プロセス監査：当該工程において当該組織で定めた作業プロセスを順守して実施していることを確認する。

2.6教育・育成のマネジメント

2.6.1スキル標準

• ITSS（ITスキル標準）：経済産業省が策定した人材の育成及び有効活用のための職種と能力を関連付けた共通指標。役割ごとに分類した１１の職種と、それらの職種の下に全部で35の専門分野を設け、各専門分野に応じて7段階のレベルを規定している。レベル１，２がエントリーレベル、３，４がミドルレベル、５，６，７がハイレベルである。経験や実績を評価する達成度指標と、実務能力を評価するスキル熟達度がある。
• ETSS（組込みスキル標準）：組み込みソフトウェアの開発力強化のため、技術スキルを体系化した「スキル基準」、必要とする職種や職掌を定義する「キャリア基準」、産業横断的に使用可能な「教育研修基準」の３つの基準を骨格に構成する。
• UISS（情報システムユーザースキル標準）：ユーザー企業における情報システム機能の枠組みを体系的に示す。調達、評価、活用に関する職務とその能力もITスキルとして定義した。15の業務機能と10の人材像をマトリクス型で定義。
• CCSF（共通キャリア・スキルフレームワーク）：ITSS、ETSS,UISSの3つのスキル標準が備えるコンテンツを、「タスク」「職種・人材像」「スキル・知識」を軸に整理し、「タスクモデル」「人材モデル」「スキルモデル」の3つのモデルを定義。改訂版としてiコンピテンシ・ディクショナリ」が発表された。

  i コンピテンシ ディクショナリ概要：IPA 独立行政法人 情報処理推進機構

2.6.2教育・育成のマネジメント技法

• アンカーキャリア：最終的に目標となる職務。
• PS(パートナー満足）：プロジェクト形態の業務における仕事満足。さまざまな組織から人材が集められることが多いため、一企業に閉じず、プロジェクトにおいて共同する仲間の相互満足をはかる。

2.7法的権利・法的責任のマネジメント

2.7.1知的財産権の法的権利・法的責任のマネジメント

• 知的財産権法：産業財産権法、不正競争防止法、著作権法などから構成される。
• 特許法：アルゴリズムなどのアイデアが「発明」として特許法により保護される。
• 著作権法：プログラムやコードで表現したものが著作権で保護される。プログラムは創作性のあるもの、データベースは配列やデータ素材そのものに思想が創作として表現されている場合、画面は創作的表現と認められる場合、ゲームソフトの映像の部分、が著作物となりえる。
• OSSライセンス：OSSを利用する条件を、OSS著作者が定めたもの。利用とは主に改編や再頒布をいう。著作権法で保護されている。

2.7.2知的財産権以外の法的権利・法的責任のマネジメント

• 不正アクセス禁止法：不正アクセス行為の防止を図ることを目的として、不正アクセス行為の禁止と処罰、不正アクセスを受ける立場の防御措置という２つの側面から定めた法。
• 個人情報保護法：個人情報保護法の義務の対象となる個人情報取扱業者（個人情報の数が5000を超える者）が遵守すべきルールを定めた法。
• PL法（製造物責任法）：製品が通常有すべき安全性を欠いているために生じる生命、身体または財産におよぼす損害を、被害者損害の因果関係ではなく被害自体を立証できる場合に、製造者に対して賠償を求められるようにする法。PL法による責任は「製造または加工された動産」が対象のため、プログラムだけでは法の対象にはならない。

＜プロジェクトレベル（共通）のソフトウェア品質マネジメント＞

2.8意思決定のマネジメント

• IPD(統合製品開発）：IBM製品開発現場で適用されているプロセス群。意思決定メカニズムだけにとどまらない。製品開発のフェーズを「構想」「計画」「開発」「評価」「量産＆初出荷」「ライフサイクル（本格的な製造販売保守）」の6フェーズにわけて、この間に4つの意思決定チェックポイントを設けて、次フェーズへの着手を判断することにしている。開発期間の短縮と、投資回収期間の短縮を狙いとしている。企業における最上位のビジネス用プロセス群。

2.9調達のマネジメント

• オフショア開発：自国以外の事業者や子会社にソフトウェア開発を委託すること。両者の橋渡し役のSE（ブリッジSE）を置いて種々の事柄の伝達を円滑にし、問題解決を図る。

2.10リスクマネジメント

• リスクマネジメントに関する規格（ISO/IEC16085）：システム及びソフトウェアの全ライフサイクルにおけるリスクマネジメントのためのプロセス内容を規定したもの。6つのアクティビティからなる。1)リスクマネジメントの計画及び実行２）プロジェクトリスク台帳の管理３）リスク分析の実施４）リスク監視の実施５）リスク対応の実施６）リスクマネジメントプロセスの評価
• システム及びソフトウェア保証に関する規格（ISO/IEC15026）：「保証ケース（AssuranceCase）という文書体系を導入して、ユーザーなど利用環境と相互作用するシステムやソフトウェアが、内在する不確実性やリスクに対して目標通りに動作することを、系統的に検討して保証する方法を規定したもの。
• リスク識別：リスクを発見し、プロジェクトへの影響を見定め、その特性を記録すること。
• リスク分析：発生原因であるリスクの因子や、因子とその結果における因果関係を分析し、リスクの発生度合いや影響度合いを明らかにすること。発生確率と影響度からなるマトリクスに識別したリスクを記入し評価することで、リスク対応への優先順位を決定する。

2.11構成管理

• 構成管理：システムやソフトウェアライフサイクルの全般にわたり、構成要素の機能や特性を特定狩野西、それらに対する変更を管理・検証し、その状況を記録する活動であり、その活動により要素間やその変化が追跡可能となる。
• 構成管理計画書：以下のような内容を含む文書。構成管理の目的、組織と責任、適用標準、ツール、構成の識別（構成管理対象の選定とベースレベル）、構成制御（変更管理方法）、ベースレベル計画（時期）、ベースレベル管理表

2.11.1変更管理

• CCB（ChangeControlBoard）：製品のために提案された変更要求と新しく提案された機能のどれを受け入れるかを決定する人々の集合。構成管理委員会または変更管理委員会とも呼ばれる。

2.11.2バージョン管理

2.11.3不具合管理

2.11.4トレーサビリティ管理

• トレーサビリティ管理：考慮の対象となっているものの履歴、適用または所在を追跡できること。要求のトレーサビリティ管理、成果物のトレーサビリティ管理、製品のトレーサビリティ管理に分類できる。

2.12プロジェクトマネジメント

2.12.1プロジェクトマネジメントの体系

• PMBOK（プロジェクトマネジメント知識体系）：プロジェクトマネジメントに固有なプロセス群を10の知識エリアに分けて示している。PDCAサイクルをプロジェクトマネジメントプロセスの基本としており、各知識エリアの総計47プロセスは立ち上げ、計画、実行、監視・コントロール、終結の5つに分類されて時系列的な把握が容易になっている。
• プロジェクト&プログラムマネジメント（P2M）：経産省の主導のもとに開発された日本発のプロジェクトマネジメント知識体系。プロジェクトマネジメントにとどまらず、それを包含するプログラムマネジメントを規定している。企業など組織の戦略の具体化のために複数のプロジェクトを有機的に統合した事業単位をプログラムと呼ぶ。
• プロジェクトにおける品質マネジメントの指針に関する規格（ISO10006)：ISO9000シリーズは個々のプロジェクトの品質マネジメントの機能や組織、技法を網羅していないのでISO10006が手引きを提供する。プロジェクトの規模、複雑さ、期間、実施環境に関わらず適用可能。
• プロジェクト計画に関する規格（ISO/IEC/IEEE16326）：プロジェクトマネジメント計画書の標準的な章構成を9章構成で具体的に示し、各章ごとに記述すべき内容とその参考情報を詳しく述べている。

2.12.2プロセス設計におけるテーラリング

• テーラリング：プロジェクトの成果を最大化するため、組織の標準プロセス群の集合を、プロジェクトの個別事情によって変更し、詳細化して「プロジェクトの定義されたプロセス」を定義すること。テーラリングの方法や制限をルール化することで、プロジェクト間のプロセスのばらつきを減らし、組織として定量的なプロジェクトマネジメントが可能になる。

＜プロジェクトレベル（個別）のソフトウェア品質マネジメント＞

2.13品質計画のマネジメント

• ベンチマーキング：業界内外のすぐれたベストプラクティスと自組織のプロセスのパフォーマンスを比較し、そのギャップを分析することにより、プロセスを見直す一連の活動。

2.14要求分析のマネジメント

• 機能要求：業務要求、ユーザー要求、システム要求の3つのレベルに分けられる。
• 非機能要求：品質特性、制約条件、外部インターフェースの3つに分けられる。

2.14.1要求分析の計画

• 要求分析の計画：要求抽出、要求分析、要求仕様化を対象とする。

2.14.2要求の妥当性確認と評価

• 要求の妥当性確認：仕様書として文書化された要求が、もともとの要求の発生源としてのステークホルダーなどが真に求めるシステムを定義していることを確認すること。要求分析の初期段階でテスト計画とテストケースを作成し、妥当性を確認することも要求の問題を発見するために有効な手段。
• 要求の評価：要求の明確さやリスクの抽出状況、要求間の整合性、記述の一貫性、明確性を確認すること。

2.15設計のマネジメント（設計の計画、方針の決定、評価）

• 設計の計画：設計のプロセスや方針、用いる技法、評価方法を決定すること。開発プロセス、保守プロセスの局面において発生する。
• 設計方針の決定：設計上の技法や、方法の選択を根本的に左右する基本戦略を関係者全員が共有できるように定めておくこと。ソフトウェアの構造に一貫性を持たせるための設計戦略を設計方針と呼ぶ。
• 設計の評価：設計結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか、を設計成果物のレビュー、テスト、検査を実施し設計結果に評価を与えること。設計を評価する際は、設計の評価方法や評価基準の妥当性をチェックする。

2.16実装のマネジメント（実装の計画、方針の決定、評価）

• 実装の計画：実装方法に従い、WBS、品質を含むメトリクスの目標値・計画値、コンポーネントを作成して結合する順序、品質管理プロセス、その他を定める。
• 実装方針の決定：品質要求を含む各種の要求を満たすために必要な実装のルールを設定すること。採用する言語と再利用部品の利用、コーディングルールや規約、外部標準や内部標準の利用などを考慮する。
• 実装の評価：実装結果が正しく要求仕様を実現しているか、求められている品質目標を達成しているかを実装成果物のレビュー、テスト、検査を実施し、実装結果に評価を与えること。主要な対象や作成したコード、修正もしくは変更したコード、再利用したコード、プロジェクトによる実装作業。

2.17レビューのマネジメント

• デザインレビュー（設計審査）：品質保証のための合否判定の一手段として位置づけられている
• レビュー計画：開催時期、対象成果物、レビューア、適用するレビュー方法及びリーディング技法などのレビュー計画。レビューの完了判断基準を明確にし、計画内容が妥当であるかを確認する。
• リーディング技法：アドホック、チェックリスト（Checklist-BasedReading,CBR、肥大化に注意）、シナリオ（Scenario-Based Reading、SBR、シナリオ列挙に手間がかかる）、パースペクティブ（Perspective-Based Reading,PBR、手間がかかる）がある。

2.18テストのマネジメント

• テストドキュメントに関する規格：IEEE　Std829は、テストドキュメントのテンプレート集。MasterとLevelにわかれている。ISO/IEC/IEEE29119-3は、テスト方針やテスト戦略に関するドキュメント、テスト環境やテストデータに関するドキュメントをすべて含んで体系化されている。
• テストの組織：一般に、開発組織とは独立したテスト組織によってテストを実施するとテストの効果が向上する。
• テストレベル：テストアクティビティのまとまりのこと。V字モデルにおいては、開発の4つの工程に対応して、コンポーネントテスト、結合テスト、システムテスト、受け入れテストの4つのテストに分けられる。
• W字モデル：V字モデルの左側の開発工程の段階から対応するテストアクティビティを開始するプロセスモデル。上流工程ではレビューやインスペクションなどの静的テスト、下流工程では動的テストがアクティビティとなる。
• テスト計画：プロジェクトで実施されるテスト活動の目的やスケジュールの定義など、テストにおける計画活動全般。
• テストリスクマネジメント：プロジェクトあるいはプロダクトのりすくのうち、てすとにかかわる要素をマネジメントすること。実施すべきテストが漏れることにより発生しうる損害について、損害の発生確率や影響を最小限に抑えるようテストを計画し管理する。
• テスト進捗マネジメント：テストプロセスが計画通りに進んでいるかどうかのモニタリングと、その結果をもとにした作業のコントロールを行うこと。消化状況や、障害情報、要求・仕様やコードに対する確認の網羅性などの情報を収集する。
• テスト環境マネジメント：計算機などの設備やOSなどのソフトウェアの保守、管理、利用計画を作成し、管理する。
• テストに関する規格（ISO/IEC/IEEE29119）：テストの考え方や用語、テストプロセス、テストドキュメントが示されている。

2.19品質分析・評価のマネジメント（プロダクト品質の分析・評価、プロセス品質の分析・評価）

• プロダクト品質の分析・評価：品質分析・評価は品質に関するニーズを定義した品質要求に即して行わなければならない。品質要求は、障害件数の観点だけではなく、品質特性の観点などから定義する。
• 品質要求定義：品質に関するニーズを定義したもの。品質特性、副特性、メトリクスを使って定義する。
• プロセス品質の分析・評価：開発過程で得られる開発データを用いて、プロセスの実行結果を分析・評価すること。プロセスを実際に実行しているかどうか、実行結果は予定通りの効果をもたらしているか分析、評価する。プロセスは高品質のアウトプットを効率よく作り出す手段であることを肝に銘じ、プロセスが目的になってしまわないように留意する。

2.20リリース可否判定

• リリース：プロセスの次の段階に進めることを認めること
• 出荷判定：プロセスの次の段階が市場への出荷の場合は、出荷判定と呼ばれる。
• 特別採用：規定要求事項に適合していない製品の使用またはリリースを認めること。リリース可否判定で不合格と判定された場合でも、製品の使用方法によっては許容できると判断されリリースが認められることがある。

2.21運用のマネジメント

• SLM（サービスレベルマネジメント）：ITサービス提供者と、サービス利用者が事前にサービスの内容と品質水準について明示的に契約したSLAを達成するための継続的な品質改善を目指すマネジメント活動。

2.22保守のマネジメント

• 保守に関する規格（ISO/IEC14764)：保守プロセスの実行計画立案、実行とコントロール、レビューと評価、終了に対するガイド。対象はプログラム、コード、データ、文書、開発時に作成した支援ソフトウェア(テストソフトウェア、テストデータベース、テスト環境など）。利用者がカスタマイズしたものは対象としない。
• 是正保守：訂正の一部。ソフトウェア製品の引き渡し後に発見された問題を訂正するために行う受け身の修正。是正保守の一部として、緊急保守（是正保守実施までシステム運用を確保するために、計画外で一時的な修正）がある。
• 予防保守：訂正の一部。引き渡し後のソフトウェアの潜在的な障害が運用障害になる前に発見し、是正を行うための修正。
• 適応保守：改良の一部。引き渡し後、変化したまたは変化している環境においてソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正 。
• 完全化保守：改良の一部。引き渡し後のソフトウェア製品の潜在的な障害が、故障として現れる前に、検出し訂正するための修正。

初級ソフトウェア品質技術者のシラバスから用語まとめ（1章）

資格試験関連の話です。公式サイトはこちら。

www.juse.jp

来週が試験日です、、問題集は解いていたものの過去問から出るわけじゃなさそうな気配を感じて、今更ながらにシラバスから用語を簡単にまとめます。

シラバスの中身は、

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) | SQuBOK策定部会 |本 | 通販 | Amazon

 のどの章が試験対象なのか、求められる知識レベルは、がまとまっています。

今気づきましたが、発売日2020/11/21でSQuBOK GuideのV3がリリースされているのですね。じきに試験の方も追従するかもしれないから、ぜひ受かっておきたい。

なお、過去問はこんな感じです。用語をよく知っておかないと間違います。

www.juse.jp

SQuBOKが分厚い＝範囲が広いので、この記事でメモる用語は第1章分です。（なお、自分が不安な用語だけです。また本記述はあくまで個人用メモです。利用して何か不都合が発生したとしても責任は持てません、、あしからず）

１．ソフトウェア品質の基本概念

1.1品質の概念

• コトづくり：顧客の行動様式の変化をもたらすような価値の提供。総務省2013年提言。
• ソフトウェア品質：解析的に把握する品質モデルがISO/IEC25000シリーズ(SQuaRE）。ISO/IEC25010の品質モデルでは、ユーザーを一時利用者、二次利用者間接利用者に分類定義。ISO/IEC25000シリーズでは要求の実現のために「利用時の品質モデル」と「製品品質モデル」を定義している（25010:2011）。
• 誤差・誤り/エラー：計算された値や観察値と正しい値の相違
• 障害/フォールト：機能単位の能力の縮退または喪失を引き起こす異常な状態。バグはここに入る。
• 故障：機能単位の脳録画なくなること。バグのせいでソフトウェアが意図通りに動かない現象は、故障（failure）。

1.1.1品質の定義

• 品質の相対性：「品質には、立場によって重視することが異なる」品質とは、を一意に定義することはできない。
• RAD（Rapid Applicatioin Development）：JamesMartin。開発期間の短縮化と顧客のニーズに素早く対応することに注目している。
• QCサークル活動：全員参加の品質管理活動。
• QC診断：経営者自ら現場部署を訪ね、生産性や品質の阻害要因を除去していく活動。
• 特性要因図：要因と結果の関係を整理する手法、フィッシュボーンダイアグラム。

1.1.2ソフトウェア品質モデル

• SQMAT（Software Quality Measurement and Assurance Technology）：NECで開発されたソフトウェア品質の手威力的に計測する技本。8種類の品質要求尺度と23種類の品質設計尺度が定義されている。
• 利用時の品質モデル：ISO/IEC25000シリーズ。有効性、効率性、満足性、リスク回避性、利用状況網羅性の5つの特性からなる。利用者が目標を達成できる程度。
• 製品品質モデル：ISO/IEC25000シリーズ。機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の8つの特性からなる。
• データ品質モデル：ISO/IEC25000シリーズ。15の特性からなる。
• 外部品質特性、内部品質特性、品質特性、品質副特性：ISO/IEC9126シリーズ。ISO/IEC25000のご先祖で、特性の数が少ない。利用時の品質（4つの特性）と、外部及び内部品質(6つの特性）を定義。

1.1.3ディペンダビリティ

• ディペンダビリティ：アベイラビリティ性能及び、これに影響を与える要因、すなわち信頼性性能、保全性性能及び保全支援能力を記述するために用いられる用語。時間の経過や使用状況の変化の中での品質という意味合いもある。アベイラビリティ、リライアビリティ、メンテナビリティを含む用語で、定性的。定量的に信頼性脳を表現する場合は、信頼度という。IEC60300と、JIS C 5750で総合的な体系が規定されている。

1.1.4使用性

• 使用性：明示された使用状況において、有効性、効率性および満足性を持って明示された目標を達成するために、明示された利用者が製品またはシステムを利用することができる度合い。「ユーザビリティ」「使いやすさ」「使い勝手」などと呼ばれる。
• UCD（User　Centered　Design）人間中心設計：ISO13407により広まった。これによりソフトウェアだけでなく、マニュアルやパンフレットなどのユーザー設定も考慮対象となった。

1.1.5セーフティ

• 危害（harm）：システムによって人命が損なわれたり、身体に害が及ぼされたり、社会に広範な悪影響が与えらえること。
• ハザード：危害を発生させる原因。
• セーフティ：ハザードの発生を抑制する性質、ハザードが起こっても危害に至らない性質、ハザードが起こっても危害を回避できる性質。
• 本質安全・固有安全：ハザードを抑制する性質のこと。
• 機能安全：ハザードを危害に至らせない、危害を回避できる性質のこと。
• SIL（Safety Integrity Level）安全度水準：セーフティに関するリスクの許容範囲の小ささ。故障(ハザード）の発生確率により等級化した4段階からなる定量化尺度。SIL（レベル）が高いほど、ハザードの発生頻度を少なく、危害は小さい必要がある。
• レジリエンス：システムが想定された条件や想定外の条件の下に要求された動作を継続できるために、自分自身の機能を、条件変化や外乱の発生前、発生中、あるいは発生後において調整できる本質的な能力のこと。

1.1.6セキュリティ

• コモンクライテリア（CC）：ソフトウェア、ファームウェアまたはハードウェアとして実装されたIT製品のセキュリティ評価のための共通基準。CCのための共通評価方法がCEM。セキュリティの実現程度を評価することは、ソフトウェア品質を評価すること。セキュリティ評価制度がコモンクライテリア評価制度として国際相互認証制度化されている。

1.2品質マネジメントの概念

• 品質マネジメント：品質の良い製品・サービスを提供するために組織を指揮し、管理すること。
• 結果系：結果である製品やサービスに対する検査を強化して、悪いものを外に出さないことを基本にする。
• 要因系：製品とサービスを作り出すプロセス重視のマネジメント。

1.3 ソフトウェアの品質マネジメントの特徴

1.3.1 プロダクト品質とプロセス品質

• プロダクト品質：製品品質と利用時の品質を総称した呼び方
• 製品品質：内部特徴（中間製品の静的な測定量）やと、外部特徴（実行時のコードの振る舞い）を測定することによって評価することができる
• プロセス品質：プロセス能力や工程能力、工程性能と呼ばれる。アウトプットのばらつき＝成果物の障害だけではなく、コストや納期も管理対象。

1.3.2品質つくり込み技術の考え方

• 品質作り込み技術：成果物を作成する過程で品質を確保するための作業を施し、のちに続く工程に障害を流さないようにするという考え方に基づく技術。
• ソフトウェアパターン：開発の工程や領域で繰り返し適用されてきた熟練者による解決策に名前を付けて抽象化したもの。
• モデル化：認知したいと考えている構造、振る舞い、現象などについて別の効率的な形式や方法による表現を用いること。大抵の場合は抽象化（単純化）を伴う。

1.3.3システムおよびソフトウェア測定の考え方

• システム及びソフトウェア測定：測定量の値を決定するという目的を持った操作の集合。
• GQM（Goal、Question、Metric）：測定目的と測定量を結び付ける代表的な手法。
• 測定プロセス：4つのアクティビティからなる。１）測定に対する確約の確立および保持（管理者とのにぎり、リソース確保）２）測定プロセスの計画 ３）測定プロセスの遂行 ４）測定の評価

1.3.4システムおよびソフトウェア評価の考え方

• システム及びソフトウェア評価：ある”もの”が規定要求事項をどれだけ満たすことができるかの程度を示すための体系的な審査。品質評価には、評価結果の善し悪しの判断根拠となる要求事項があらかじめ明確化されていること、評価プロセスが確立されていることが必要。

1.3.5V&V（Verification ＆ Validation）

• Verification 検証：仕様適合性を確認する。正しく成果物を開発しているか？工程の成果物が、その工程の開始時に課された条件を満足しているかどうかを決定するために、システムあるいはコンポーネントを評価するプロセス。
• Validation 妥当性確認：ニーズ充足性を確認する。正しい成果物を開発しているか？システムあるいはコンポーネントが規定要求事項を満足しているかどうかを決定するため、開発プロセスの途中あるいは最後にシステムあるいはコンポーネントを評価するプロセス。

1.3.6日本におけるソフトウェア品質保証

• 日本におけるソフトウェア品質保証：レビュー重視、障害分析に基づく改善、独立した品質保証部門の存在が特徴。

参考サイト

https://blogs.techvan.co.jp/quality/jcsqe

テストから見えてくるグーグルのソフトウエア開発 メモ

書籍の内容から自分が使えそうなところ紹介です。

テスト関連の書籍を読み始めた背景

ServiceNowというPaaSをカスタマイズ（開発・・かな）するチームにいるのですが、どうもテストの範囲や粒度がつかめんなぁと思っています。

特にバージョンアップの時。半年1回大きなリリースが入りますが、その時に問題ないかチェックする・・チェックってどこまで？？？ってなります。全然使えなくなっているはずはないと信じて進むのですが、翻訳違いを見つけたり、思わぬところが動かなくなっているのを発見したり、値がコピーされなくなっていたり。といっても全カスタマイズの単体テストからやり直すのも時間的にありえないでしょうと・・。

ソフトウェア品質知識体系ガイドとかも今後見ていきたいと思っていますが、先に面白そうなグーグルのテストの紹介の本です。

www.amazon.co.jp

グーグル社の開発の規模(2011年ころ）

• 毎日数百万のソースファイルに数億行のコードを詰め込んでリリース
• 毎日数十億のビルド操作
• 毎日数百万の自動テストが数十万のブラウザーで実行される
• ウェブアプリケーションはほとんど連続的にリリースされている
• エンジニアリングプロダクティビティチームには約1200人の精鋭エンジニアがいる。

エンジニアリングプロダクティビティチームって？

• ソフトウェアテストを縄張りにしているチーム（直轄部門）
• フォーカスエリア（広告、アプリ・・などのビジネス単位組織）にまたがる組織横断型の独立組織。
• 開発者とテスターが使うツール、リリースエンジニアリング、安泰レベルのテストから探索的テストまでの様々なテストを担当。
• テスターは、開発者の生産性を引き上げることを目的にしている。
• 以下に紹介するSET、TEが所属している。
• SET、TEは、フォーカスエリアのプロジェクトに貸し出される。
• この製品の品質は大丈夫です！とお墨付きを与えたり、バグが出たときに謝るチームではない。

Google用語

• SWE ソフトウェアエンジニア：従来の開発者。製品のオーナーとして品質に責任を負う。テストをするのは当然。
• SET ソフトウェアエンジニアインテスト：テスト機能を提供する開発者のひとつ。設計をレビューし、コードの品質とリスクをチェックする。コードのリファクタリングもやる。単体テストフレームワークも作るし自動化もする。SWEのパートナー。SWEが積極的にテストケースを書けるようにする。品質とテストカバレッジの向上に力を注ぐ。 
• TE テストエンジニア：第一にユーザーのため（製品がユーザーのニーズを満たせるかどうかたしかめるため）にテストを推進する。全体的な品質チェックを組織し、テスト結果を解釈し、テストの実行を指揮してエンドツーエンドのテスト自動化を行う。製品のエキスパートであり、品質のアドバイザー、リスクの分析者。コードを書く人も書かない人もあいる。契約テスター、クラウドソーステスターなどを動員するのもTEの仕事。成否にゃサービスを全体的にみて最もリスクの高い分野を探し出して力を貸す。途中からプロジェクトに投入されることも多い。
• Sテスト：1つの関数またはモジュールの機能をチェックする。データ破壊、エラー条件、off-by-oneエラー)（境界条件の判定）などをチェック。モックやフェイクを使う。
• Mテスト：たがいに呼び出しあったり、直接やり取りしたりする関数の相互作用を確認する。SETが主導。
• Lテスト：3つ以上の機能から構成され、実際のユーザーが使うシナリオを表現し、実際のユーザーデータソースを使う（本番環境で行う）テスト。TEが主導。

TEの立案するテストプラン

（「ユーザーが利用可能か確認」というキーワードから、自分が一番興味があるポイントなのでここだけクローズアップ）

TEの仕事に「テストプランを立案する」がある。

理想のテストプランとは・・・

• いつも最新の状態を保っている
• ソフトウェアの意図、ユーザーがソフトウェアを愛する理由を記述している
• ソフトウェアがどのような構造になっているか、さまざまなコンポーネントや機能にどのような名前が付けられているかを示すスナップショットを含んでいる
• ソフトウェアが何をすべきか、どのようにして実現するかの概要を記述している。
• 作るのに長時間を必要とせず、すぐに書き換えられる
• 何をテストしなければならないかが書いてある（テストケースを導くことができる）
• 進歩の度合いや、カバレッジのギャップをわかりやすくして、テスト中役立つ

上記のために、ACC（アトリビュートコンポーネントケーパビリティ）分析が導入された。

Googleテストアナリティクス

Google Testing Blog: Google Test Analytics - Now in Open Source

として自動化されている。

• A アトリビュート： 製品の存在理由。競合製品から区別するための性質や特徴。セキュア、安定、エレガント、無料、便利、正確、高速、共有、簡単、拡張性、プライバシー、表現力など。
• Cコンポーネント ：製品の機能のかたまり。システムがよほど大規模でない限り、10ならよいが20では多すぎ。小さなものは省略してよい。オンラインストアなら「カート」「精算機能」などで、ワープロなら「整形」「印刷」など。
• Cケーパビリティ：ユーザーに提供される機能。ユーザーのコマンドを受けたときにシステムが実行する動作。Chromeなら、ウェブページのレンダリングや、Flashファイルの再生など。オンラインストアなら、カートの商品追加・削除、送料の計算など。最も大切なのは「テストできること」

＃コンポーネントは、製品のアトリビュートを満足させるために何らかの仕事を行い、その仕事の結果がユーザーにケーパビリティとして返される。

サンプル：Google＋のACCスプレッドシート例

1. 縦方向に、コンポーネントを並べる。 プロフィール、人、サークル、通知、ポスト、コメント
2. 横方向に、アトリビュートを並べる。ソーシャル、表現力、簡単、適切、拡張性、プライバシー
3. それぞれのセルに、ケーパビリティを書く（一つでも複数でも）
4. それぞれのセルで、リスク分析を行う(頻度×インパクト）

ちなみに上記3では以下のような書く。

• プロフィール×ソーシャル ： 友達、知人らとプロフィールを共有する
• プロフィール×プライバシー：プライベートデータを非公開に保つことができる
• プロフィール×プライバシー：承認した適切な人々とだけデータを共有する

それぞれのセルのリスク判定結果で色をぬれば ヒートマップが完成。

高いところから順にテストを行っていく。

自動化や、テストのレポートのためのツール

・Autotest

・Selenium  Selenium WebDriver

・BITE  バグ登録を効率化、Chromeエクステンション

Google Testing Blog: Take a BITE out of Bugs and Redundant Labor

・QualityBots 複数リリースChrome間でのピクセルベースDOM分析

Google Testing Blog: Unleash the QualityBots

・RPF（Record/Playback Framework）

Google Testing Blog: RPF: Google's Record Playback Framework

所感

• 2012年（日本での発刊は2013年）なので、ツールだとか情報が古そうで、アップデートを探し出す必要があると思う。
• ACCで機能の優先順位をつけるのはいいかもしれない、、すべてをテストできないなら、重要なところからやります、って言えばいいのだから。。
• ジェームズ・ウィテカーのインタビューの中に、グーグルのテストのマジックの４つの秘訣としてあげられているのが「１．テスターのスキル（コンピュータ科学の学位を含む）、２．デベロッパーがテストを書き、テスターが仕事を最適化する強制的な要因となっているテスターの人手不足、３．自動化優先（コンピュータが得意でないことだけを人間がやる）、４．速いイテレーションとユーザーからのフィードバックのスピーディーな統合」・・・人手不足もひとつの鍵とは、、、そこだけは真似できそうだ。
• 本としては、話があっちこっち、技術になったりマネジメントになったり採用になったり、目まぐるしい印象。カバー範囲は広いから、興味のあるところだけ読むのがいいんじゃないでしょうか。
• 日本のゴリゴリ品質管理も調べてみて、違いを見るのが楽しみ・・といって自分を鼓舞します。ふー

テスト駆動開発（TDD Boot Camp 2020）のメモ

TDDのサイクル

YouTubeでTDD Boot Camp 2020 Online #1 基調講演/ライブコーディング、

t-wada（ケントベックの「テスト駆動開発」書籍の訳者）さんのLIVEを視聴。https://www.youtube.com/watch?v=Q-FJ3XmFlT8&feature=youtu.be

＃TDDBC-Onlineチャネルです。

さらっとでてくるノウハウがとても美しかったので、メモです。

お気づきの点はぜひTwitter(@yb300k) へ。

TDDのサイクル

ざっくり言うと

実装する仕様を細かく区切った目標を決める→テスト書く→失敗させる→最短で成功するコードを書く→成功する→リファクタリング

をぐるぐる回す。

その流れをざくっと紹介。

１・問題を細かくわけて、個別に撃破。最初は聞いた仕様をそのまま書いてみるが、それはそのままToDoリスト（あるいはテスト項目）にはならない。

FizzBuzz問題（1から100までの数をプリントするプログラムを書け、ただし3の倍数なら数のかわりに「Fizz」とプリント、5の倍数なら「Buzz」プリント、3と5両方の倍数は「FizzBuzz」プリント）

上記はこのままだとToDoやテスト項目にはなってない。→ 後述します

ToDoリストができたところでどこから手をつけるかというと・・

1周目は重いので、軽いところからやるべし。（環境もファイルも何もなく、設計の意味合いが強いので）

                      テスト容易

                              ｜    ①

需要度低い    ーー ｜ーー      重要度高い

                              ｜

                     テスト難しい

２．３．最初にテストを書いて、失敗（Red）になってから

４．コードを書く

５．Greenにするためにはコピペなどキタナイ手を使ってもかまわない。（キタナイコードでも動作すればよい）

６．成功しているテストが成功しているままコードをきれいにするリファクタリングを行う。（外部からのふるまいがかわらない、ではない）

リファクタリングのやめ時は、

案１）時間。5分とか。

案２）重複をなくす。共通の処理を関数に切りだすとか。

ここまできたら、１．に戻ってToDoリストを見直す。

※ここからデモになっていったので、その流れにあわせて以下ノウハウを書いていきます。

個別に撃破するタスク分解の考え方の流れメモ

 ★観測が容易 なようにタスクを分割するのがポイント

・１から100まで素直にやるんじゃなくて、どこまでやればひと区切りできるだろう？（１，２，３，４，５，６，７，８・・・100まで全部書く人はプログラマじゃない）

・「プリントする」のテストの方法は？

   → プリント・・・目で見る？テストの仕組みが複雑であるわりに、あまり意味がない。テストやりにくい。→あとまわしだ

・「プログラムを書け」→これは自明だからいいや

・3の倍数、5の倍数、3と5両方 のToDo項目の書き方をあわせてわかりやすくする。

   ※プリントする、変換する、出力する、などごちゃごちゃにせず、一貫性を持った記述にする

  3の倍数のときは数の代わりに「Fizz」とプリントする

   を分解して、

  3の倍数のときは数の代わりに「Fizz」に変換する  ＋プリントする と分解。

  5 でも同じように書く。

 ・最初に手を付けられる、テスト容易性：高、重要度：高 のToDoを作りたい

・「ただし」という文言があると、通常ではない振る舞い

  正常系 があって、 ただし で異常系を作っているはずだ

  1から100までの数をプリントする  が 正常系だと思い出して・・・

  対称な形になるように、正常系の文言をつくる

  →1から100までプリント

     を

   (正常系として） 数を文字列に変換する    というように分解すればOKだ

タスクの整理は、テストの書きやすい、書きにくいがわかるまで、トライアンドエラー

観察のしやすさ、十分小さいか、オブザビリティ

『クリーンアーキテクチャ』という本はテスト容易性は「入出力からの遠さ」と表現している。このように書籍の知識を得るのもおすすめ。

最初にできあがったToDoリスト

分解した結果のToDoリスト

 テスト環境の最初の準備

JUnitでテストを書き始める

テスト対象とテストユニットを対応させて名前を決めて、、「FizzBuzzTest」

まず  fail（"hoge"） で、 FailureTraceにきちんと”hoge”が出ることを確認すること。

＃JUnitつかえてないとか、環境構築がミスってた、でエラーになってたんだ！時間無駄した！！を防ぐために有効。

日本語でテストコードを書くと、わかりやすいのでおすすめ。

なぜなら、動作するドキュメント（仕様書）であってほしいから。

テストの書き方

4フェーズテスト  準備、実効、検証、後片付け のステップになる。

Javaだとガベージコレクションで後片付けがいらないので、

Arrange  Act  Assert  （3A）ともいう

そして、一番下のAssert（検証）から書いていく。複雑なケースでも単一のゴールをぶらさないために、下から書いていく（上のArrangeから超大作を書いていくといろいろ混ぜたくなり、ぶれる）

Assertは 値の検証が基本（期待値 expectedになること をチェックする）

数を文字列に変換する（）ってテストできる？

・・・・で、expectedは 何になるのか？！がわからなくなる

どうすれば数が文字列になったと言えるのだろう？？

と手が止まったら、これはよく考えられていなかった ということに気づける（早いうちに気づいたほうがいい。これがテスト駆動開発のメリット）

ToDoに戻り、抽象度をさげて

「1を渡すと、文字列1を返す」に言い換える。こういう具体化抽象化の繰り返しもテスト駆動化初の特徴。

assertEquals("1",actual);  ← ツールや言語によって、引数の順番をよく確かめること。大量にテストコード作った後で、逆だったと気づくと、とってもつらい

テストコードだけ書いて Runするとエラーになる。（コンパイルエラーもredとカウントする。）

＃エラーが原動力になるので、これは悪いことではない。

コードを書き始める。

コードを書く時の心得

作る前に、「使う」 という意識でコードする。

コードの作りやすさと、使いやすさというのは一致しない。

今コードを書いている自分が書きやすいではなく、後で見た誰でも使いやすい、読みやすいほうが大事。

＃わかりにくい関数名にしないとか、引数の並びが異常なのは止めようとか・・・

fizzbuzzクラスの、convert という関数ならわかりやすいなと考えて

Runすると、convert(1)からNullが返ってくるので、Redになった。

最短距離で走るために、まずconvert(int i)  に return "1" を入れる。

ひどい茶番に見えるが、

この絶対に間違っていない茶番コードで、テストがGreenにならないとしたら、テストコードが間違っているということになる。 

defect　insertion 

＃テストコードにバグがあったらどうするの？という議論があったが・・・

  テストコードのテストコードのテストコード・・・を書き続けるわけにはいかない。

  初期段階でわざと判別可能な誤りを入れてみて、予想通りにテストが失敗することを確かめる。

★ convert関数のコードを、return　"0"; に変えてみて、redになることをチェックする。

＃mutation　testing というテストの仕方もある。いじれるところ全部変更してテストし続けるが、恐ろしく時間がかかる。

テストが本当にredになることもあるかチェックしてみて、最終的にコードがGreenになるように修正、確認。

プロダクトコード優先でリファクタリング、その後 テスト コードもリファクタリングして1周目を完了とする。↓変数に関数の戻りを入れてから使っていたのを修正し、コメントも直している

三角測量

ToDoリストに戻り、三角測量 として、 次のToDo

2を渡すと文字列2を返す  を増やしてテストを書き始める。

ここは最初の段階なので歩幅を小さめにしている。あまりジャンプしない。

テストコードのかたまりの書き方

テストを書くときに一つのメソッドにAssertを二つ並べるか？テストメソッドを増やすか？ → 増やしていくべき。

なぜなら、2行assertEqualsを並べると、最初に失敗するまでの上にあるAssert行しかチェックしない（一度エラーになると、それより下は実行しない。テスト全部Greenで通るか見たいのに。）し、テストメソッド名と、テストの内容が一致していないことになるから。

アンチパターン：アサーションルーレット  ＜大量にAssertが並んでいるテストコード

Greenになったら、リファクタリング。

リファクタリング（重複除去）のタイミング

テストコードのリファクタリングとしてnew　FizzBuzz（）の重複除去・・するか・・？

＃2アウト派、3アウト派がいるので、上記2個の時にどうするかは迷うが、3個まで放置してもいい

リファクタリングしたらToDoリストに戻る。

メソッド内に複数のAssertionになってしまうときは分解が間違ってるか？

→まとめてAssertしないといけない状況であれば仕方ない。

   でも分解ができてない状況もあり得るので確認のこと。

  実行の重いEnd2Endのテスト、インテグレーションテストであれば、Assert1つの原則は外してもいい。

 その形でくりかえす・・

 最短距離でGreenにして、リファクタリングに進む という選択肢もあり。

 newが重複している問題に対応

 →前準備の重複を排除

テストメソッド間の依存関係

テストメソッドはどこから動作するかわからない（あえて、テストツール作成者が上から順に実行しないように散らしている）

テストメソッド同士の間に依存関係を作ってはいけない。

テスト1の次にテスト２が動くことを前提に、テスト１に前準備を入れたりしてしまうようになるから。すべてのテストを一気に流すとき分散型で処理することもあるので、依存関係があるとエラーが出まくってテストができないという実害がある。

@BeforeEachに前準備をまとめた結果がこれ。

そろそろテスト側の誤りに不安がなくなってきたので、コードをまともなものにしていく。リファクタリングも完了し、実装にも不安がなくなってきたら明白な実装をいきなり始める。

仮実装・三角測量・明白な実装の3つのギアで、歩幅を調整しながら進んでいる。

TDDのスキル

『実践テスト駆動開発』という本もバイブル

受入テストを先にするというやり方が書いてあるので、それをどうぞ

テストの構造化とリファクタリング

数年後・・・人がかわってこのコードとテストコードを引き継いだら？

上記のままだとテストを見てGreenで動くのはわかるし、ふるまいはわかるが、何をしたかったのかがよくわからない。

仕様レベルの言葉がないので、逆アセンブルして仕様を読み取ることになってしまう。

テスト駆動開発の成果が、動作するドキュメントになっていない。

なんでこうなった？

・抽象度を下げてしまってテストや実装を進めたので仕様が伝わらなくなっている。

→ テスト名を長くするというのがひとつの伝統的な解。

→ 他には、実装がツリー構造になっているところに目を付けて、テストコードの構造化が解になる。

  抽象的な仕様と具体的な実装がツリー構造のToDoリストになっていることに目を付けて、ToDoリストのインデントを、テストコードに反映する

JUnitだと、@Nestedを使うことでネスト構造を作れる。

これでテスト結果   を見てみると

階層化のレベルがちぐはぐになっていることに気づく。

・補集合があったことに気づき、以下のようにきれいにする（ドメイン理解を進める）

以下のように書いておけば引き継いだ人も理解できる！

 なぜ三角測量してるんだろう・・？？

「テストを減らすことができるのは書いた本人だけ」

不要なテストは減らして人に渡す。

動くドキュメントとして使えるように、テストの仕様の構造、テストの中身が頭に残っているうちに、構造化・リファクタリングすることを通して、資産にすること。

＃テストを不良資産にしないこと。使い続ける人がテストのメンテを引き受けないといけない。つらい。

参考にできそうなリンク

・t-wadaさんの 「私にとってのテスト」 

https://www.slideshare.net/t_wada/testing-casual-twada

・タスクの分解に関しての知見

kyon mmさんの「テストとリファクタリングに関する深い方法論」

https://www.slideshare.net/KyonMm/wewlcjp

参考図書（として紹介されていた書籍）

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp

自宅環境改善・2台のWin10ノートPCを、ノートPC＆拡張ディスプレイとして使う

リモートワークの波がやってきまして、

・バランスディスク(バランスボールの平面版）：腰痛と運動不足対策

・100均のスライム：キーボードに角度をつける

など、日々改善に努めております。

まだしばらくリモートが続くのでディスプレイを買うか悩んでいたのですが！

すんげーハックを見つけたのでコツを紹介します。

前提となる環境

自宅用ノートPC（Win10Home）と、会社に持ち込んでいたBYODノートPC（Win10Home）の2台が机の上にあります。

＃昨日まではそれぞれ別マシンとして使ってました・・・

　なお、左側のマシンの位置が高いのは、Web会議対策です。

rocketnews24.com

2台あるけど、会社にリモートデスクトップで接続できるのは1台だけなので、片方はZoom専用機になってしまっておりました。スマホでええやん。

世間一般の？2台のマシンを1台として使う方法

まず最初にいくつかやり方があることもお知らせしておきます。Win10×2台以外の人はこの中のどれかが使えると思います。

mupon.net

自分はこの中の一番上、Miracastを使いました。

つながらない・・・

はまったのが。

「アクションセンター」（ツールバーの吹き出しマーク）から、「接続」をクリックしても、「デバイスの電源が入っていて、検出可能になっていることを確かめてください。」メッセージが出て進めない。

「検索」で手入力でデバイスの名前を入力してもダメでした。

確認ポイントはこちらのサイトにも詳しいですが、自分の場合は原因は別でした。

itojisan.xyz

結局これだった！原因2つ

原因１）違うWiFiにつないでいた。

　片方は2g、もう一方は5gのWiFiネットワークに接続してしまっていました。

　負荷分散のために分けていたのを忘れていました。まずこれを合わせます。

原因２）WiFiの設定

　WiFiのネットワークプロファイルが、「パブリック」になっていました。

　「プライベート」になっていないと、検出できません。

　確認方法は、接続しているWiFiの「プロパティ」をクリックします。

次に、以下の設定画面で、「プライベート」を選びます。

完了！これでようやく検出できるようになりました。

なお、デュアルディスプレイにした時に、物理的な左右の並びと違って動きが気持ち悪かったのでこの記事を参考に修正しました。

www.4900.co.jp

まとめ

ちょっとはまりましたが、無料でデュアルディスプレイ環境を手に入れることができました。

調べてみるもんですね、、各種記事を公開されている皆様ありがとうございました。めでたしめでたし。

参考になれば幸いです。