2021-12-15

ソフトウェアテスト技術文書の英語読み書き・付け焼き刃勉強法

「Calendar for ソフトウェアテストの小ネ | Advent Calendar 2021 - Qiita」の記事です。

今回は、ソフトウェアテストの英語技術文書のリーディング・ライティングを最低限できるようにするための、手っ取り早い付け焼き刃勉強法に触れます。
先の前置きとして、この方法は英語勉強法として十分ではありません（ドメインやサービス固有の文章、組織固有の文章は対応できません）。ただ、純粋なソフトウェアテスト技術についての文章ならば、片言レベルのリーディング・ライティングに手っ取り早く対応できるようになると思います。

手っ取り早いソフトウェアテスト技術文書の英語リーディング勉強法

ISTQBのシラバスとJSTQBのシラバスを使用します。

JSTQBのシラバス
 ISTQBのシラバス

その中で、英語版と日本語版両方が発行されている区分を使用します。基礎的な用語・文書をカバーしたい場合は、シラバスのうち以下の3つを対象とするのが良いと思います。

Foundation Level
Advanced Level Test Analyst
Advanced Level Test Manager

また余裕があるならば、以下も対象にすると、扱える文章が広がります。

Foundation Level Agile Tester
Test Automation Engineer

勉強法ですが、英語のISTQBシラバスをスラスラ読めるようになるまで、日・英のシラバスを併読します。
わからない用語が出てきたら、逐次辞書などで調べるのは少なめに、日本語シラバスから意味を掴んで、勉強のスピードとテンポを維持します。
結構量がありますが、英語シラバスの文書は簡潔で、限られた用語や表現が繰り返し頻出する内容となっているため、進展するほど勉強スピードが高まります。量ほど大変ではありません。

この勉強法でISTQBシラバスを難なく読めるようになったら、ドメインやプロダクト・組織固有の文書を除く、純粋なソフトウェアテストについての技術文章は、おおよそ意味がつかめるようになっていると思います。

注意として、日本語シラバスには誤訳の可能性があるのに考慮が必要です。また改定で内容が結構変わるので、併読の際は日英シラバスでバージョンを一致させる必要があります（バージョンは日本語シラバスの改訂履歴で照合できます）。

手っ取り早いソフトウェアテスト技術文書の英語ライティング対応法

ライティングについては、勉強法ではなく、付け焼き刃対応法です。
こちらもISTQBのシラバスとJSTQBのシラバスを使います。

やり方ですが、まず前述のリーディング勉強法で、英語のシラバスをスラスラ読めるようになるまで勉強します。
すると、シラバスのどこに何が書かれているかが、ある程度イメージできるようになります。

その上で、ライティングでは次のような手順で対応します。

ライティングしたい元の日本語に似た文章を、想起してJSTQBの日本語シラバスからピックアップします。
日本語シラバスの該当箇所に対応する英語文章を英語シラバスからピックアップします
英語シラバスの該当文章を参考に、英語文章をライティングします（コピペすると引用になり著作権等の制約が発生するため、あくまで参考にして英語文章を作ります）

例えばテスト目的についての文章を英訳したい→JSTQBのFLシラバスにテスト目的の解説があるのを思い出す→そこに対応するISTQBシラバスの文書を参考にする、といった流れで対応します。

この方法により、シラバスで書かれている文章限定ですが、ネイティブの文章を参考にライティングできるようになります。

欠点

ドメインやプロダクト固有の英語には対応できません。ソフトウェアテストの文書にとって、ドメインやプロダクト固有の文章は不可欠であり、内容の大部分を占めると思います。その部分は別で補う必要があります。
ISTQB/JSTQBのシラバスは一人称・二人称を徹底的に廃した文章ですので、それに従ってライティングを行うと「仕様書みたいな文章」と言われます。

2021-12-09

Tesseract OCRで文言描画の多言語対応テストを自動化する

「Calendar for ソフトウェアテスト | Advent Calendar 2021 - Qiita」の記事です。

多言語をサポートするプロダクトの開発では、各言語ごとに表示文言が正しく描画されているかテストしたい場合があります。
今回は、その文言描画の多言語対応テストを、Tesseract OCRで自動化するアプローチについて解説します。

環境

文字認識エンジンにはTesseract OCRを使用
- 学習データは対象言語ごとに以下から取得
- https://github.com/tesseract-ocr/tessdata_best
pytestでテストコードを実装し、PyOCR経由でTesseractを制御

テスト対象

今回はTwitterのUIのうち、英語、日本語、ドイツ語を対象にします。
次のような画像をキャプチャして、2列目の領域にそれぞれの言語の文言が適切に描画されているか、ビジュアルテストのアプローチで確認します。

eng.png
f:id:goyoki:20211215030022p:plain

jpn.png
f:id:goyoki:20211215030032p:plain

deu.png
f:id:goyoki:20211215030044p:plain

テスト

文言の内容の正確性（例えば翻訳の正確性）のテストは、実装中の文言データをチェックする方法が妥当な場合が多いです。
今回はそれ以外の、文言の描画の正確性（文字切れがないか、変な改行などないか、そもそも描画されているか）を自動でテストします。

1. 対象画面をキャプチャする

プロダクトの種類に応じた自動操作アプローチで、対象の画面を片っ端から静止画保存します。今回のように、WebサービスのUIを対象にして、pythonベースでテストを組む場合は、seleniumなどが妥当な実現手段になると思います。
今回は、その手段で、前述した英語・日本語・ドイツ語の設定画面キャプチャ画像（eng.png、jpn.png、deu.png）を、テスト対象画面として静止画保存します。

2. キャプチャ上の文言をOCRで抽出し、テキストベースで文言が正しいか確認する

次に、キャプチャ画像から文言を抽出して、テキストベースで文言の正確性を確認します。

テストオラクルとしては、コードが参照する文言データを利用できる場合が多いと思います。
サンプルレベルのかなり簡略化した例ですが、今回は、次ようなCSV形式で各国文言を列挙した文言ファイルがあるとします。テストではこれを読み込んで期待値に展開します。

stringdata.csv

"Your account","アカウント","Dein Account"
"Security and account access","セキュリティとアカウントアクセス","Sicherheit und Account-Zugriff"
"Privacy and safety","プライバシーと安全","Datenschutz und Sicherheit"
"Notifications","通知","Mitteilungen"
"Accessibility, display, and languages","アクセシビリティ、表示、言語","Barrierefreiheit, Anzeige und Sprachen"
"Additional resources","その他のリソース","Zusätzliche Ressourcen"

次にテストコードですが、一例として次のように実装できます。

test_display_all_words.py

import re
import csv
from PIL import Image
import pyocr
import pyocr.builders

def check_all_words(wordsfile, language, csv_column):
    '''指定された言語の表示文言が表示されているかチェック
    '''
    tool = pyocr.get_available_tools()[0]

    txt = tool.image_to_string(
        Image.open(language+'.png').crop((560, 100, 1200, 700)),#対象領域トリミング
        lang=language,
        builder=pyocr.builders.TextBuilder(tesseract_layout=6)
    )
    #言語特有の文字列処理
    if language == 'jpn':
        result = re.sub(r'([あ-んア-ン一-龥ー、])\s+((?=[あ-んア-ン一-龥ー、]))',r'\1\2', txt)
    else:
        result = txt

    with open(wordsfile) as f:
        reader = csv.reader(f)
        string_list_set = [row for row in reader]

    for string_list in string_list_set:
        if not string_list[csv_column] in result:
            print(f'failed: [{string_list[csv_column]}] is not found') #テスト失敗時の失敗箇所の提示のため-sオプション推奨
            return False
    return True

def test_all_words():
    '''各言語ごとの表示文言のチェック
    '''
    lang_list = [['eng', 0], ['jpn', 1], ['deu', 2]] #[lang_name, column_index of csv]

    for lang in lang_list:
        assert check_all_words('stringdata.csv', lang[0], lang[1]), lang[0]

テストコードの内容としては、対象領域に描画されている文言をPyOCRで読み取って、前述の文言ファイルの文言がその中で描画されているかチェックしています。

なおTwitter UIは文言描画がシンプルで明瞭なため、文言中の不正なスペース混入を除去する処理が必要な以外は、Tesseract OCRが提供するtessdata_bestの学習データをそのまま利用して十分な精度を確保できました。

テスト実行結果

テストを正常なキャプチャ画像で実行すると、テスト成功の結果が得られます。
次にキャプチャ画像を加工して、ドイツ語文言「Barrierefreiheit, Anzeige und Sprachen」の右端に文字切れを発生させてテストを実行すると、次のようにテスト失敗報告と、失敗原因となった文言を表示します。

pytest test_display_all_words.py -s
===================================================== test session starts =====================================================
(中略)                                                              

test_display_all_words.py failed: [Barrierefreiheit, Anzeige und Sprachen] is not found
F

========================================================== FAILURES ===========================================================
_______________________________________________________ test_all_words ________________________________________________________

    def test_all_words():
        '''各言語ごとの表示文言のチェック
        '''
        lang_list = [['eng', 0], ['jpn', 1], ['deu', 2]] #[lang_name, column_index of csv]
    
        for lang in lang_list:
>           assert check_all_words('stringdata.csv', lang[0], lang[1]), lang[0]
E           AssertionError: deu
E           assert False
E            +  where False = check_all_words('stringdata.csv', 'deu', 2)

test_display_all_words.py:39: AssertionError
=================================================== short test summary info ===================================================
FAILED test_display_all_words.py::test_all_words - AssertionError: deu
====================================================== 1 failed in 3.98s ======================================================

このアプローチの課題と対応方法

OCRを使った文言描画のテストの自動化には、利点・欠点それぞれあります。
結論を先に言うと、利点を活かし、欠点を補完するテストアプローチの工夫が求められます。

テストの偽陽性、偽陰性の課題

まず欠点の１つ目ですが、テスト結果判定に機械学習を使用することから、テストの偽陽性、偽陰性の問題に遭遇します。

このうち偽陽性については、テストが失敗したら本当に失敗なのか追加確認する運用で、安全方面に倒せます。

しかし偽陰性の方は問題です。若干の描画欠けが発生しても、機械学習エンジンが頭良く補完してテストを成功させてしまう場合があります。そのため、次のようなテストのアプローチの工夫が求められます。

全文言の包括的なテストを、今回のOCRベースのアプローチで実装する
継続的テストとしてのリグレッションテストにも、今回のOCRベースのアプローチで実装する
一方、リスクレベルの高い文言描画については、適時のタイミングで、人による目視確認や、あるいは画像マッチングベースのアプローチでテストを実現する

描画座標依存によるFragile Testの課題

2つめの欠点ですが、次の要因から、今回のテストアプローチは対象画面の構成（レイアウトや描画位置座標）に依存します。

キャプチャ画像をそのままTesseract OCRに丸投げしても、複雑なレイアウト構成や、アイコン・境界などの意匠、透明化・影付きなどの効果といった、様々な要因で上手く描画文言を抽出できません。これに対策するためには、今回提示したテストコードでも実行していますが、対象領域をトリミングして、それぞれの領域に適した前処理や解析結果補正処理を実行する必要があります。すなわち、テストがレイアウトや描画位置座標に依存せざるを得ません。
キャプチャ画像の取得のため画面遷移の自動操作が必要です。全てを全自動にする場合、画面遷移操作をテストコード上に実装する必要があります。

上記の理由から、今回のテストアプローチでは、画面仕様や画面遷移仕様が変更される度にテストが壊れる場合があるという、Fragile Test問題に直面しがちです。

この対策として、例えば次のような工夫が求められます。

ソースコードから画面仕様や画面遷移仕様を解析してテスト操作を生成する処理を自動化する
テスト対象の限定。仕様が安定している画面の特定領域に限定してこのテストを適用する

2021-12-08

テストアーキテクティングをテーマに登壇

先週、JaSST東海というイベントで「テストを導くためのテストアーキテクチャの組み立て方」と題して登壇させていただきました。

テストを導くためのテストアーキテクチャの組み立て方/cetam - Speaker Deck

内容は、システムテスト/結合テスト/ユニットテスト、あるいは自動テスト/手動テストなど、開発ライフサイクルの全てのテスト活動の戦略立て・方針立てを行うアプローチについてです。

元々、その全体のテストの戦略立てや設計を手掛ける機会が度々あり、アプローチや考え方を明文化できればと考えていました。丁度そのテーマでセッション担当を依頼いただき、登壇に至りました。お声がけいただいた委員の方には深く感謝しています。

内容は、自分が経験してきたことをベースに組み立てました。大きなプロジェクトにてテスト全体を対象とした戦略立てや設計を手掛けると、様々な人たちとすり合わせをして、様々な担当者・有識者と連携・協力しながら、継続的に作り込んでいく必要があります。そうした苦労点に基づいて、連携と継続的洗練をメインテーマにしています。
現在テストアーキテクチャ設計については、テスト観点分析とテストコンテナ設計を中心としたアプローチが日本で主流となっています。それとはフォーカスする部分が少しずれた内容となっていますが、その主流を補強するものとして役に立てればと考えています。

なおDevOps、継続的デリバリ、アジャイルが代表例ですが、様々なテスト活動を連動させたデプロイメントパイプライン、開発プロセスを洗練させ、より高度なアジリティや価値創造を実現する開発アプローチは、需要がどんどん高まっています。今や、それを上手く実現することは、現代的な開発の付帯条件であると考えています。
その実現手段として、アーキテクティングという、設計技術を活用して要求を実行手段に変換するアプローチを活用するのは、有望な選択肢だと考えています。

聴講いただいた方・資料を見ていただいた方の何かしらの助けになれば幸いです。

2021-10-20

責務構造ツリー

責務構造ツリーは、活動の責務を分割するためのモデリングツールです。
QAアーキテクティングやテストアーキテクティングで、各QA活動、テスト活動の責務を分析し、詳細化するために使用します。

責務構造ツリーの概要

責務構造ツリーは、責務分割構造をツリーでモデリングするものです。記法にはGSN(Goul Structuring Notation。https://scsc.uk/gsn)を使用します。
GSNの記法ルールの逸脱するものではないため、これは独自のモデリング手法ではなく、GSNの活用例の一種になります。

ただし、GSNの慣習との若干の相違点として、以下の特徴を持ちます。

Goalは責務に特化して記述します
Solutionは基本省略します

責務構造ツリーは「GSNでテストタイプを分析する - 千里霧中」で記述している、GSNによるテストアーキテクチャの分析で使用していたツールを持ってきたものです。元々の由来として、HAYST法のD-Caseによるテスト戦略立て（http://jasst.jp/symposium/jasst18tohoku/pdf/S1.pdf）から着想を得て具体化しました。

責務構造ツリーは、由来のD-Caseでも代替可能ですし、マインドマップなど他の一般的なツリーモデルでも代替可能です。

責務構造ツリーの例

QAアーキテクティング、テストアーキテクティングでの責務構造ツリーの用途

責務構造ツリーは、抽象度が最上位の戦略立てやアーキテクティングに適用します。例えばテストアーキテクティングの場合では、テストレベルや、抽象度の高いテストタイプの分析・関心事の分離に使用します。
ツリーモデルで表現できない、各責務の連携については、別途プロセスモデルやシナリオ記述などで補完して記述します。

なお、より抽象度の低い、詳細なテストタイプ、テスト観点、テスト条件などの分析では、ツリーモデルで表現できない要素や記述量の課題から、責務構造ツリーではなく、クラス図や無効グラフ、その他表などによる記述の方が適している場合が多いです。

責務構造ツリーの記法・書き方

GSNの記法を使用します。
責務構造ツリーで多用する記法を以下にまとめます。

書き方は単純で、上位の責務→「どう責務分割したか」を記述したStrategy→下位の責務を基本構造に、ツリー構造を構築します。

2021-10-12

QAアーキテクチャの事前検証

「QAアーキテクチャが本当に妥当なのか」は、大抵の場合、サービスやプロダクトリリース後の事後評価で判明します。例えば、以下のような指標の評価が、本当にQAアーキテクチャが妥当かの確認に有効になります。

ビジネスの成否。例えば、ビジネスのKPIの達成度、SLAの遵守度など
市場への欠陥の流出の程度
市場でのサービス・プロダクトの品質レベル。例えば、MTTF、実際のパフォーマンス計測結果、ユーザアンケート結果
QA活動の生産性の結果評価。例えば、実際にかかったコストやリソースが妥当だったかの評価

ただリリース後の事後評価では、QAアーキテクチャの問題を見つけても手遅れの場合が多いです。適切なQAアーキテクチャの実現のためには、開発途中の事前の検証で問題を見つけて問題是正する必要があります。

今回はそのQAアーキテクチャの事前検証手段について扱います。

QAアーキテクチャの検証手段の導出

QAアーキテクチャの検証手段は、QAアーキテクチャの目標に対応して選定されます。例えば「重大な欠陥の流出を防止したい」といった類の目標があれば、欠陥流出リスクについてのシナリオウォークスルーが検証手段として有効になります。
以降にQAアーキテクチャの検証手段を列挙しますが、これらも一律に有効というわけではなく、QAアーキテクチャの目標に応じて取捨選択していく必要があります。

QAアーキテクチャの検証のアプローチ

QAアーキテクチャの検証は、強いて言うならばモデルの検証のアプローチが多くなります。というのも、QAアーキテクチャは複雑で規模の大きいことから、特定のアーキテクチャ観点で観た、QAアーキテクチャのモデルに切り取らないと、レビューや検証が大変になるためです。
このアプローチはより具体的に書くと、目的に応じてQAアーキテクチャ観点を選び、そのアーキテクチャ観点に基づいてQAアーキテクチャをモデリングし、そのモデルを検証する、という流れになります（ここでのQAアーキテクチャのモデリングまでは、検証活動の一部として実施するのではなく、QAアーキテクチャ設計として行う場合があります）。

QAアーキテクチャの検証手段の例

シナリオウォークスルー

概要

具体的なシナリオにQAアーキテクチャが対応できるかをレビューしていきます。
QAアーキテクチャに限らず、アーキテクチャの検証手段として一般的な手法です。
使用するQAアーキテクチャモデルは、プロセスモデルあるいはパイプラインモデルが都合が良いです。

手順

プロセスモデルやパイプラインモデルでQAアーキテクチャをモデリングする
具体的な品質課題のシナリオを、上記モデルで対応できるかシミュレーションし、QAアーキテクチャを評価する

補足：使用するシナリオの導出について

QAアーキテクチャのシナリオウォークスルーで使用するシナリオは、QAの目標を具体化して導出します。例えば次のように実施します：

品質モデルを使って品質保証の目標設定をしている場合ならば、品質特性の代表的な具体例をシナリオに使用します。例えば「機能Aの資源効率性仕様Xを、どう品質保証するか」「機能Bの移植性の不具合Yを、どのように検出するか」といった品質特性を具体化したシナリオを導出し、そのシナリオをQAアーキテクチャでどう対応するかレビューしていきます。
品質リスクを使って目標設定をしている場合ならば、リスクレベルの高いリスクについて、リスクシナリオを導出し、それを使ってレビューします。

QA活動による品質リスクコントロール評価

概要

「QA活動によるリスクコントロール」に特化した品質リスク分析・評価です。
品質リスクに対し、QAアーキテクチャでどのように対応するか、そしてQAアーキテクチャでの対応後の品質リスクレベルが妥当か、確認していきます。リスク分析の過程では、リスクストーミングなど他の様々なプラクティスを組み合わせて使用します。
使用するQAアーキテクチャモデルは、リスク管理表です。またリスクの識別やリスクコントロールの評価のために、責務構造モデルやパイプラインモデルなどを使用します。

手順

品質リスクを識別し、評価します
リスクレベルに応じて、品質リスクをQAアーキテクチャレベルでどのように対応するか分析します。
QAアーキテクチャによるリスクコントロール結果が妥当か検証します。

これは言うなれば、時代が変容し、GoFのデザインパターンのコンテキストやフォースが、開発の状況と乖離するようになったと言えます。

パターンおよびパターンベースアプローチの陳腐化

一方、「デザインパターン＝GoFのデザインパターン」という誤解に基づいて、デザインパターンそのものが陳腐化したという意見を見ます。あえて言うまでもないことかもしれませんが、これは誤りです。
人間が本能的にパターン認識を使いこなしていることから、使い手が人間である以上、パターンベースのアプローチは普遍的に有効だといえます。それと同じく、パターンベースアプローチの一部であるデザインパターンも普遍的に有効といえます。

重要なのは、問題のコンテキストとフォースに合致したデザインパターンを選択することです。デザインパターンが不適切と感じるならば、それは問題にとってコンテキストやフォースがずれたパターンを適用しようとしているか、使っているパターンリポジトリが対応していない問題を扱っているかの、どちらかになるのがほとんどです。

未来予測の限界によるパターンの陳腐化

GoFのパターンのような実装依存のパターン（GoFのパターンは設計パターンですが、実質的に実装に依存するパターンとなっています）は、開発言語やプログラミングを支える環境に依存しています。そして開発言語や開発環境の変化は目まぐるしいため、コードレベルのパターンが陳腐化するのは基本的に避けられないと言えます。
例えば、GoFのIteratorパターンは、集合体の要素を取り出すのに、添字を使ったfor文を使うのが一般的な時代では有効でした。ただ添字やイテレータが隠蔽されたforeach文が普及した今となっては、主要なデザインパターンとして挙げる重要性が失われています。

このように、変化の激しいソフトウェア開発では、未来予測の限界から、将来にわたって通用するパターンを確立するのに限界があります。特に実装に依存するパターンは、定義されたときから陳腐化のリスクが高まると考えて良いかもしれません。

なお、将来の状況変化を見越したコンテキストやフォースの記述（例えばforeach文が普及しているなら適用外など）も同様に限界があり、パターンが自分自身で陳腐化したと判断する基準を提示するのも難しいです。
そのため、デザインパターンを使用したい場合は、使い手に、複数のパターンカタログ/パターン・ランゲージを比較して、そのコンテキストとフォースが対象の問題と適合しているか検討することが求められます。GoFのデザインパターンは1995年の開発現場を背景にして見出されたパターン・カタログです。それを使うかは、2021年現在の目の前のコンテキスト・フォースに適合しているか、よく考える必要があります。

ボトムアップのパターン識別アプローチと陳腐化

GoFのパターンような実装依存のデザインパターンは、GoF本でパターンを見出したアプローチとして書かれている通り、ボトムアップで識別されることが多いです。うまくいっているコードからデザインパターン（解決策）を見出し、それからその解決策のコンテキストとフォースを明らかにして、パターン記述として完成させるというアプローチです。

このボトムアップのアプローチで見いだされたパターンは、解決策から、解決対象の問題・コンテキスト・フォースを想起したり関連付けたりすることは容易にできます。
ただ、その逆方法、問題・コンテキスト・フォースから、解決策を関連付けするのが、陳腐化により難しくなることが多いです。例えば、問題に対する解決策が増えて、もともとのパターンの解決策がベストの解決策でなくなることがあるためです。

Singletonパターンを例にとると、解決策から「インタンスが唯一であることを保証したい」という問題・課題を読み取ることはできると思います。ただ今となっては、「インタンスが唯一であることを保証したい」という課題に対して、解決策に対してSingletonパターンが必ず挙がるとは言えません。

このように、ボトムアップで作られたパターンや、解決策に要点を置いているパターンは、陳腐化の圧力が強いと言ってよいと思います。

なおトップダウンで見出されたパターン（問題に対し、それに適切な解決策を付与してパターン記述を完成させる）は、ある程度普遍性を確保しやすい問題やコンテキストに依拠してパターン記述を完成させることから、比較的、ボトムアップ・アプローチより陳腐化圧力が少ないと考えられます。

例えばトップダウンで見出されることが多いパターンとして、マネジメントのアンチパターンがあります。これは、失敗、損害といった問題に着目し、その原因・解決策を見出してパターン記述を完成させることが多いです。このアンチパターンの場合、普遍的な問題から始まり、演繹的に解決策を見出していることから、問題→解決策の参照も比較的保ちやすいと考えられます。

2021-10-03

QAアーキテクチャの概要

QAアーキテクチャの定義

　まずソフトウェア開発における「アーキテクチャ」は、対象の基本的な概念・構造・特性を、構成、設計判断、設計原則で表現したものを指します。
　例えばシステムのアーキテクチャの場合ですと、ISO/IEC/IEEE 42010ではアーキテクチャという言葉を次のように定義しています。

Architecture:
fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
(対象の環境におけるシステムの基本的な概念や特性を、システムの要素、関係、設計原則・発展原則として具体化したもの)

　次に本テーマの「QAアーキテクチャ」についてです。
　QAアーキテクチャは、電通大の西康晴さんが先導的に整備している考え方で、「品質をどこでどう確実に作り込んで確実に保証するか」「どんなQA観点を作り込んで保証できているのか」の基本構造・基本方針を設計したものです。

QAアーキテクチャの設計による説明責任の高いテスト・品質保証
 Re-collection of embedded software qa in the last decade

　この一連の解説においては、前述の一般的なアーキテクチャの定義も加味し、QA(品質の保証)に特化して、QAアーキテクチャを次のように定義したいと思います。

QAアーキテクチャとは、「品質をどう保証するか」の基本的な概念・特性であり、それを品質保証の原則、基本方針、手段の構成で具体化したものである。

　またこの解説では、上記のQAアーキテクチャを実現し、改善・保守し、検証する活動全体を指す言葉として、QAアーキテクティングという言葉を使用します。

今なぜQAアーキテクティングが重要になるのか

現在の開発スタイルとして、次の2つの重要性が高まっています。

様々なQA活動を高度に連携させ、開発全体で優れたアジリティや価値創造を実現する開発スタイルが求められている
- 【継続的デリバリ、DevOps】様々なQA活動を包含するデプロイメントパイプラインを洗練させ、開発とビジネスの距離を縮める
- 【アジャイル】様々なQA活動を組み合わせ、継続的かつ高速なリリース＆フィードバックを実現する
創発的・反復的なQAアプローチが求められている
- 【アジャイル】イテレーションごとにQA活動を積み重ねつつ、全体の品質保証としての整合性を確保し、プロダクトの品質を継続的に担保する

上記に対応するため、様々なQA活動の総体をアーキテクチャとして扱い、アーキテクティングでその構造やメカニズムを工夫するアプローチが有効となります。

QAアーキテクチャの役割

　QAアーキテクティングの目的は、プロダクトの成功のために必要なQAを実現することです。そのためQAアーキテクチャは以下の役割を担います。

予測。以降のQA活動に大きな影響を与える判断を示し、準備や計画を支える
先導。QAの方針を示し、状況が流動的に変化するソフトウェア開発ライフサイクルのあらゆる局面で、QA活動がどこに進むべきかを先導する。
橋渡し。ビジネス、マネジメント、開発、QAなど様々なステークホルダ・関係者からのQAへの要求・制約の調停を行い、妥当なQAの実現を支える。
協調。複雑・大規模なリスクや問題に対応するために、各QA手段をどう強調させるかを示す。また複雑・大規模な問題を対応可能にするために、具体化・分割する。
全体整合の確保。QAの適切な全体像を構築し、その実現・維持を支える。

コミュニケーションツールとしてのQAアーキテクティング

QA活動は、様々なステークホルダから要求や制約を受け取り、様々な担当者で推進します。そのためQAアーキテクティングは、QA技術を活用した問題解決ツールの側面のほかに、コミュニケーションツールの側面も強く持ちます。具体的には、QAアーキテクティングは次の役割を果たすことが重要になります。

様々なステークホルダからの要求や制約を調停し、ステークホルダが納得するQA活動を実現する
様々なQA活動関係者からの納得を確保し、QA担当者の協力を促しその力を結集する

QAアーキテクチャの表現

　アーキテクチャは様々な特性を備えていることから、一般的に、複数のアーキテクチャ観点で観た、複数の側面でアーキテクチャを表現します。このアーキテクチャ観点は、ステークホルダの関心事や、開発上重要な側面に基づいて選択されます。アーキテクチャ観点の数は少なすぎるとアーキテクチャを十分に表現できず、多すぎると各側面の整合性の確保・維持が大変になるため、重要性に基づいた適切な数の観点を使用します。

　これはQAアーキテクチャも同様です。QAアーキテクチャはその役割上、構造的特性、プロセス的特性など重視すべき特性を持っていることから、それに対応したいくつかのアーキテクチャ観点で表現するのが有効です。

　QAアーキテクチャの表現で有効なアーキテクチャ観点を次に示します：

QAタイプの責務分割の観点

　QAタイプの責務分割を構造モデルで設計・整理する観点です。
　例えば、ツリーモデルでQAタイプを整理するものが該当します。このツリーモデルによる構造観点は次の理由から有益です。

QAアーキテクティングでは、複雑・巨大な品質保証を、扱えるサイズに分割するために「関心事の分離」が重要になります。ツリーモデルはこの関心事の分離をわかりやすく表現します。
QAアーキテクティングでは、十分なQAの実現のために、多数の様々なQA手段を集めて連携させる必要があります。ツリーモデルは、多数のQA手段の洗い出しや整理を支援します。

QAタイプの構造の観点

　QAタイプの構造をプロセスやデプロイメントパイプラインで設計・表現する観点です。
　QAでは、様々なQA手段を、重ね合わせ、役割分担、横断的連携のパターンで組み合わせて、全体のQAを実現します。プロセスやパイプラインモデルは、それら組み合わせや連携の関係をわかりやすく表現します。
　またQA活動は状況に応じて動的に変化することから、「通常デプロイ時」「Hotfixデプロイ時」などの条件をシナリオとして具体化して、シナリオごとにプロセスやパイプラインがどう変化するか補足表現する必要もあります。　

その他、QAアーキテクチャ要求に基づいた分析観点

　QAアーキテクチャには様々なタイプの要求・制約がインプットされます。QAアーキテクチャの構成要素と構造のほかに、それら要求・制約に基づいた観点で設計・表現を行うことが重要になります。
　特に、QAアーキテクチャの要求のうち、特に影響が重大なアーキテクチャドライバに基づいて、QAアーキテクチャの骨格を構成するのは、アーキテクティング手法として重要なアプローチになります。
　代表的なQAアーキテクチャの要求と、それに対応するQAアーキテクチャ観点を示します。

【要求：課題やリスクをリリース可能なレベルまでコントロールする】→QAタイプによる課題・リスクコントロールの観点で設計

　「課題やリスクをリリース可能なレベルまでコントロールする」というのは表現の程度はありますが、QA活動の一般的な要求になります。
　その要求があった場合、課題、プロジェクトリスク、品質リスクのコントロールに対し、各種QA活動がどう連携するかを設計・表現する観点が有効です。QAでは、目標や課題対応のために様々なQA手段を組み合わせます。その連携を記述する単位として、課題やプロジェクトリスク・品質リスクのコントロールを用いるということです。

【要求：様々なQAベースの実現性を保証する】→各QAベースとQA活動の対応付けの観点で設計

　大規模な開発の場合、多数の成果物タイプを扱うことから、それぞれのドキュメントや成果物がきちんと実現性保証されているかに注意を向ける必要があります。
　そうした要求があった場合、QAベース（QA活動のインプットになる成果物）を、どのQA活動で実現性保証するか関連付け・マッピングする観点が有効になります。

【要求：開発ライフサイクルの中で段階的に成長するQA活動を行う】→スケジュールやタイムラインの観点で設計

　PoC→開発→量産開発など、開発ライフサイクルが明確に区別された開発フェーズで分類される場合、それに応じて段階的にQAアーキテクチャを成長させていく必要があります。
　そうした要求があった場合、スケジュールやタイムライン上で、QAアーキテクチャをどう具体化し、成長させていくか設計する観点が有効になります。

　CEQAAMでは、QAアーキテクチャを、(いくつかの独自の記法を導入したモデル記法で)上記の観点ごとに表現した姿と、各観点の要素の詳細を説明するQAアーキテクチャ管理表を使って表現します。

QAアーキテクチャ群の構造

　QAアーキテクチャは、小さなサブQAアーキテクチャで構成することができます。例えば、QAアーキテクチャを、テストアーキテクチャや監査アーキテクチャ、レビューアーキテクチャに細分化して、それぞれでアーキテクティングを行う場合があります。

開発の特徴に応じたQAアーキテクチャの表現

　QAを複数人で分担する状況や、複数のQA手段を連携させる状況ならば、顕在的か/潜在的か、意図的に構築するか/無意識に生まれるか、の違いはでるものの、QAアーキテクチャは生まれます。
　ただそのQAアーキテクチャをどこまで明示的に表現するか、QAアーキテクティングをどこまで方法論的・形式的に実施するかは、プロジェクトの規模や複雑さ、スタイルに依存します。

　例えば、数百人程度の大規模プロジェクトであったり、難易度の高い品質保証が求められるプロジェクトならば、明示的にQAアーキテクチャを構築・維持する必要性がでてきます。

　一方、少人数のプロジェクトや、リリースごとの品質保証が1、2週間のスプリントで収まるような軽快な開発ならば、QAアーキテクチャが成立したとしても、QAエンジニア判断任せで、QAアーキテクチャを特に明示化しない場面もありえます。

QAアーキテクチャのライフサイクル

　QAアーキテクチャは、開発ライフサイクル全体に渡って構築・維持・保守されます。
　QAアーキテクチャのライフサイクルのフェーズを次に示します。

仕様化フェーズ：QAアーキテクチャ要求を収集し、各ステークホルダとすり合わせして、QAアーキテクチャを仕様化します。
発展フェーズ：QAアーキテクチャに基づいてQA活動を先導します。また、QA要求の追加・変化に応じて、QAアーキテクチャを発展・変更します。
保守フェーズ：完成したQAアーキテクチャを保守・再利用可能な形で記録し、保守開発や派生開発への展開を支えます。

　QAへの要求は開発が進展しないと出てこないことものもあり、また開発の状況に応じて変化することもあるため、上記フェーズがウォーターフォールに実行されることは稀です。多くの場合で、五月雨式に、反復的に上記フェーズが実行されます。

QAアーキテクティングと連動する活動

　QAアーキテクティングはマネジメント、ビジネス、開発、品質保証を調停することから、それらの様々な関連活動と相互依存関係をとっています。そのため、QAアーキテクティングの活動によって、それら関連活動の推進を促すこともあれば、ときにQAアーキテクタが作業代行する場合もありえます。
　QAアーキテクティングと連動する関連活動の代表例を次に示します。

■QAアーキテクティングと連動するマネジメントの活動

組織設計

　組織構造とQAアーキテクチャは連動しています。そのため組織設計とQAアーキテクティングは相互依存関係にあります。
　具体的には、QAアーキテクティングは、組織設計に対してあるべき組織構造を示します。また組織設計は、QAアーキテクティングに対して、結果としての組織構造を示し、QAアーキテクティングに制約を指定します。
　組織設計はQAアーキテクティングというよりマネジメントのタスクです。ただ上記の関係性から、QAアーキテクティングの活動を通じて、組織設計の推進を促したり、場合によっては代行したりすることが求められます。

開発プロセス設計

　開発プロセス設計もQAアーキテクティングと相互依存関係にあります。
　QAアーキテクティングは、開発プロセス設計に対し、QAプロセスや望ましい開発プロセスを示します。開発プロセス設計は、QAアーキテクティングに対して、結果としての開発プロセスを示し、QAへのインプットやQAのプロセスを指定します。
　そのため、QAアーキテクティングの活動を通じて、開発プロセス設計を促したり、その一部を代行したりする場合があります。

■QAアーキテクティングと連動する開発の活動

QA容易性や試験性（テスタビリティ）の確保

　QAアーキテクチャは、試験性を含むプロダクトのQA容易性に依存します。
　具体的には、QAアーキテクティングは開発に対し、必要なQA容易性・試験性を求めます。開発は、QAアーキテクティングに対し、結果として実現したQA容易性を制約として指定します。
　そのため、QAアーキテクティングの活動では、プロダクトの仕様定義や設計の活動に含まれる、QAに必要なQA容易性の仕様化を手掛けたり、促したりする場合があります。

QAアーキテクチャの設計方針

　QAアーキテクティングの基本方針として、QA活動を先導しながら、QAアーキテクチャの完成像に向けて累積的に・適用的に組み立てていくことになります。例えばアジャイル開発ならば、イテレーションごとに刹那的にQA成果物を使い捨てるのではなく、包括的な品質保証を組み立てつつ、イテレーションごとのQA活動も実施するように、QAアーキテクチャでQA活動を先導していきます。

　具体的なQAアーキテクティングの設計方針を次に示します。

開発全体で構築する

　開発全体の様々なQA手段を総動員してQAアーキテクチャを構築します。
　例えばある欠陥の流出を予防したい場合は、設計・実装で欠陥予防策を実現し、レビューで静的に欠陥を見つけ、テストで動的な欠陥を見つける、というように、様々なアプローチを組み合わせ、全体のQAを実現します。

発展的に構築する

　QAアーキテクチャは反復的、段階的に育て、完成させます。
　QA要求は流動的であり、開発の進展に従って徐々に明らかになっていくことから、QAアーキテクチャはBDUF（Big Design Up Front）で構築できません。最終的に実現すべきQAアーキテクチャが実現されるように、EDUF（Enough Design Up Front:EDUF⁠）で、反復的・段階的に拡張洗練させていきます。

ビジネス・マネジメント・開発・QAをすり合わせ構築する

　QAアーキテクチャはビジネス・マネジメント・開発・QAの橋渡しであり、それぞれの要求・制約を調停し、プロジェクトの成功の点で妥当な品質保証を実現させる役割を持っています。
　そのため、ビジネス・マネジメント・開発・QAと相互に連携しながら、適応的にQAアーキテクティングを推進します。

関心事の分離を推進する

　一般的にQAは大規模・複雑であり、様々なロールが分担して実現します。レビュー手法、テスト手法などを適用し、具体的なQA手段を実装するためには、QAの責務の分割が必要です。その実現のため、QAアーキテクティングは、QAの活動について、関心事の分離を行い、それぞれの具体的なQA活動を行えるようにすることが求められます。

集合知で構築する

　QAアーキテクチャは、様々なステークホルダの調停を行う点、幅広いQA手段を扱う点から、集合知的なアプローチが活用されます。
　そのためにも、QAアーキテクティングの活動にはコミュニケーションに関するプラクティスが多く含まれますし、QAアーキテクチャ自体がコミュニケーションを支える基盤になります。
　また、QA活動への要求や制約をどのように調停したのか、QA要求をQAアーキテクチャにどのようにインスタンス化したのか、といった重要な設計判断をどのような集合知で行ったか記録するのも重要な活動となります。

QAアーキテクチャの評価

以下の記事に分割しました：

QAアーキテクチャの事前検証 - 千里霧中