記録用ブログ

個人的な記録のためのブログ。主にソフトウェアテストの話題。

デシジョンテーブルテストの説明で「因子」「水準」にあたるものを何と呼ぶか

用語の話。
因子、水準はもともと直交表の言葉ですが、他の技法の話をするときにも使われているのを見かけます。
特にデシジョンテーブルテスト。デシジョンテーブルテストにおいて期待結果を左右するものは、JIS X 0125:1986 決定表にならえば「条件」となります。
が、現場でデシジョンテーブルを書くと、条件の詳細度を階層化して表現したいケースがあります。そういったときに因子、水準という言葉は便利です。
例えば、動物園の入園料を決める条件のひとつが年齢にまつわるものである場合、「年齢が6歳未満であること」「年齢が6歳以上であること」とも書けますが「年齢」の下に「6歳未満」「6歳以上」をぶら下げて階層化して書くこともできるという話です。

で、各種文献の、特にデシジョンテーブルテストの説明において、直交表の説明をするときの因子、水準にあたるものをどういう用語で表現しているか確認してみました。

確認結果を先にまとめると、そもそも「因子」「水準」に分けて説明していないものばかり。
まあ、予想はしていた。

じゃあどうするか。
個人的には、直交表以外では「変数」「変数がとりうる値」としておくのが無難な気がしています。
一番の理由は、プログラミングを少しでも齧ったことがあれば比較的分かりやすく、一般的な言葉だからです。実際のテスト技法を説明した文献にも、「変数」「変数がとりうる値」を使っているものはありました。今回はデシジョンテーブルテストについて悩みましたが、一般的な言葉なので他の技法の説明でも使えるというのも強みです。
また、テストの期待結果(JISにならえばデシジョンテーブルでは「動作」)についても階層化して表現したいことがありますが、このときも「変数」「変数がとりうる値」であれば問題なく使えそうです。
一方、「因子」は辞書によると、「ある関係や結果を生じる諸要素」あるいは「ある結果を成り立たせるもとになる要素。」(両方とも https://kotobank.jp/word/%E5%9B%A0%E5%AD%90-437343 より引用)だそうなので、期待結果や動作に対して使うのは、これも個人的には違和感があります。
難を言えば、テストやQAのチームにはプログラムを書いたことがなく「変数」という言葉に馴染みがない人も往々にしているので、とっつきにくい人は一定数いると思います。が、テスト技法を学ぶ前の人にとっての馴染みの薄さは「因子」「水準」も大して変わらないのでは。

直交表の話以外で「因子」「水準」が使われていても話す側も聞く側もその意味が何か理解しているならば、めくじらを立てるような話ではないと思っています。実際、直交表を齧ったことがある人にはイメージが湧きやすい言葉ですし。
ただ、自分自身が経験値が様々な複数の人にテスト技法の話をする機会があり、いろいろ考えてしまったので、この機に整理してみました。

以下は文献を確認した結果の詳細です。
それぞれのデシジョンテーブルテストの説明から、JISでいう「条件」をさしていると自分が判断した単語を抜き出してみました。今回調べた文献は概ね、JIS同様に「条件」でした。

本『ソフトウェアテスト技法ドリル―テスト設計の考え方と実際』秋山 浩一(著), 日科技連出版社, 2010年

  • 「変数」「規則」「条件」

本『はじめて学ぶソフトウェアのテスト技法』リー・コープランド(著), 宗 雅彦(翻訳), 日経BP, 2005年

  • 「条件」
  • 「第6章 ペア構成テスト」という、直交表や全ペアアルゴリズムを扱う章があるのですが、そこでも因子、水準は見当たらず「変数」「パラメータ」、「変数がとりうる値」「変数値」などと表現されていました。

本『ソフトウェアテスト技法』ボーリス バイザー(著), 小野間 彰(翻訳),日経BP, 1994年

  • 「条件」
  • 条件についての記述を以下に引用します。なるほど
    • p270『「条件」とは「述語」を意味する別の言葉である(仕様書の「述語」やプログラムの制御フローの「述語」のどちらでもよい)。』

JSTQB FLシラバス (ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

  • 「条件(主に入力)」
  • ちなみに、「条件(主に入力)」が書かれていたあたりを引用するとこちらの通り
    • p57「デシジョンテーブルを作成する際には、テスト担当者は条件(主に入力)と結果的に起きるシステムのアクション(主に出力)を識別する。条件とアクションは表の行となり、条件を上部、アクションを下部に記述する。」

JSTQB ALTAシラバス(ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03 http://jstqb.jp/dl/jstqb.jpdlJSTQB-SyllabusALTA_V311.J03.pdf

状態とは何か調べてみた

日常的に使うテスト技法のひとつに状態遷移テストがある。
が、そもそも「状態」とは何かが気になったので、いくつか文献を調べてみた。
具体例を多く知っているためにイメージは持てているのだが、ソフトウェア開発経験が浅い人に説明する場合に悩んでしまう言葉のひとつだ。

調べた結果、自分の理解は以下の通り。

  • 定義は、日常で使う「状態」と同様で問題ない
  • ただし、ソフトウェア開発においては以下の特徴がある
    • 状態は、時間の経過により変化するものに対して適用される
    • 状態は、過去の処理結果を先々使用するために適用される


過去の処理結果を使用するというのは、例えば、
会員料金支払い処理が済んでいることを「支払い済」ステータスとして記憶しておき、「支払い済」のユーザに限定して有料会員コンテンツを見せる制御に使う、といったことである。

特に参考になった文献の引用

辞書
ソフトウェア開発関係の文献より
  • 「これはプログラムがそれまでの処理結果を状態として記憶しており,その状態によって現在の処理を変えるような機能を持つからである.」

    • 松本 正雄 (著), 小山田 正史 (著), 松尾谷 徹 (著) (平成9年),『ソフトウェア開発・検証技法』初版, 電子情報通信学会, 153ページ
  • 『そもそも動的モデルでいう「動的」とは、インスタンスの属性が時間の経過に伴って変化することを指します。多くの場合、人間はその変化を連続的、あるいはアナログ的なものとはとらえないで、何らかの契機に伴う離散的、つまりデジタルな変化としてとらえます。実際の状態の変化はゆっくり進むこともあれば、きわめて短時間で進むこともあります。どちらにしても時間の経過を伴います。人間は、そうした変化の前後を取り出してそれぞれを状態と呼んでいるように思えます。それが人間の認知上、具合がいいからでしょう。』

  • 『状態は,「集合の状態」や「健康の状態」のように,通常の言葉と同じように使用する。Oxford英語辞典では,「状態」を「人や物に関する当分の間の状況と特性」と定義している。』

  • 「状態(state):あるオブジェクトの集合で,任意の時点に取るすべてのオブジェクトのすべての値の集合。たとえば,ユニットの状態,システムの状態,オブジェクトの状態,あるいは初期状態というように,状態はオブジェクトの集合と条件を定義することで特定できる。」

    • Boris Beizer (原著), 小野間 彰 (翻訳)(1997年), 『実践的プログラムテスト入門』初版, 日経BP社,2ページ

探索的テストのプロセスを図にしてみた

これは、ソフトウェアテストの小ネタ Advent Calendar 2020 2日目の記事です。

探索的テストは近年、書籍だけでなくインターネット上にも資料が増え、学習しやすくなってきました。

ところが、探索的テストのプロセスを図示したものは余り見かけない気がしたので、描いてみました。
詳しい人向けに補足すると、チャーターを使ってセッションベースドで行う場合のプロセスを想定しています。  

f:id:mejiro8:20201128232924p:plain
探索的テストのプロセス

さて、「探索的テスト」は人によって随分意味が異なる言葉です。
新人さんなど、システムやテストの知識がない人に敢えて実施してもらうテストという意味で使う人もいるようです。
JSTQBシラバスには次のように書かれており、このブログは、こちらに従っているつもりです。

『探索的テストは、形式的ではない(事前定義されていない)テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。』
テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J02 60ページより引用(http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf)

図示したプロセスの通りに探索的テストを行う場合、システムやテストの知識がない人が実施するのは非常に困難だと思います。
図中の「繰り返す」の点線枠内にある通り、テストの準備と設計、実行、フィードバックを基に次の準備と設計、…を繰り返します。
細かな期待結果が提示されていない中で、実行結果を検証しフィードバックを得なくてはなりません。このため、テスト対象そのものやテスト対象が持つべき価値の理解、そして観察力も要求されます。
次々得られるフィードバックを踏まえて素早くテスト設計をするには、テストの技術が必要です。
探索の内容や順序を、フィードバックを基に見直していきます。この見直しがうまくできないと、説得力のない結果になるかもしれません。
幅広くテストするという目的を掲げていたのに、結果的に特定の機能の特定のバグについてしかテストできていない、といったことが起こりうるからです。

探索的テストを行うときは、効果だけではなく、テストの目的を達成するためにどのような人や準備が必要でどのようなプロセスで行うのが良いか、考慮するのが良さそうです。

ちなみに、Advent Calendar 2020の1日目の記事に、テストの学習に使えるテスト対象アプリが掲載されていました。
探索的テストの練習に使えるというアプリも紹介されていましたので、これから勉強しようという方は、ご覧いただくと良いと思います。

読んでみた - 論文「THE GOAL QUESTION METRIC APPROACH」

GQM(GOAL QUESTION METRIC)について知りたくて、提唱者のV. Basili氏らの論文「THE GOAL QUESTION METRIC APPROACH」を読んでみました。
著者はV. Basili氏, G. Caldiera氏, H. D. Rombach氏、1994年の論文。

以下、論文から学んだことのメモ。

  • GQMは、設定したGOALに応じてデータを解釈すためのフレームワークである

  • GOALは概念レベル。部門やプロジェクトのレベルで特定される

  • QUESTIONは、仮定したモデルに基づいて、GOALを可能なかぎり完全に表すものである

  • METRICは、定量的に回答するためのもので、客観的なものと主観的なものがある

  • GOALの定義として、その目的、目標(プロセス、object(process))、視点(Viewpoint、誰にとってか)、問題(quality issue)を明らかにしている例が載っている

  • GOALを設定する上での情報源は、3つある

    • 組織のポリシーと戦略
    • 組織のプロセスとプロダクトの説明
    • 組織のモデル(組織構造のモデルや体制のことか?)
  • QUESTIONは、一般的には少なくとも3グループに分けられる

    • GOALに関して、対象となる製品・プロセス・リソースをどのように特徴付けることができるか?
    • 扱いたい問題に関して、対象となる製品・プロセス・リソースをどのように特徴付けることができるか?
    • 扱いたい問題に関して、対象となる製品・プロセス・リソースをどのように評価するか?
  • QUESTIONとMETRICの関連付けをする済に検討する事項はたくさんある。既存のデータが利用可能な場合は最大限に活用する。測定対象の公式度や成熟度により、客観的な測定値と主観的な測定値を使い分ける。GQMは改良と適応を必要とするモデルであるため、測定した結果を評価するためのモデルを改良するためのプロセスを検討する。


翻訳サイト、辞書サイトにずいぶん助けてもらったのですが、翻訳結果の意図を理解するのに苦労しました。
しかし、提唱者の研究結果に直接触れるのは楽しいですし、GOALの情報源など自分にとって新しい知見も得られたので、苦労した甲斐はあったかなと思います。

flutterのパスを変更した後にAndroid Studioでエラー

Android Studioを新しいパソコンにインストール、FlutterとDartプラグインもインストールした。
その後、別のパソコンで作ったflutterプロジェクトをインポートしたら、importがすべて失敗していてこんなエラーが出ていた。

Warning! This package referenced a Flutter repository via the .packages file that is no longer available. The repository from which the 'flutter' tool is currently executing will be used instead.
(略:ここにflutterのパスが書かれていた)
This can happen if you deleted or moved your copy of the Flutter repository, or if it was on a volume that is no longer mounted or has been mounted at a different location. Please check your system path to verify that you are running the expected version (run 'flutter --version' to see which flutter is on your path).

パソコンを変えるにあたってflutterのパスを変更していたので、それが原因のようだ。

試したこと:
* 環境変数を見てflutterにPATHが通っているのを確認してからAndroid Studioを再起動 →ダメ
* FlutterとDartプラグインを再インストール →OK。これでエラーが消えた

テストを減らさなくてはならないときに考えること

コスト等の都合で、特定の期限までに行うテストを減らさなくてはならない場合によく考えていることを、整理してみる。

  • 実施タイミングを変更できるテストはないか?

    • リリース直後は使われない機能やシナリオのテストを後回しにする
  • テスト対象を限定できないか?

    • 開発の目的やテスト対象ソフトウェアの存在意義と直結しない機能やシナリオのテストをなくす、減らす
    • リスク、特にプロダクトリスクが低い部分のテストをなくす、減らす
    • ブラックボックステストの場合は、ホワイトボックスで考えた時に関係ないといえる部分のテストをなくす、減らす
  • 網羅基準を変えられないか?
    • 同値分割のズームアウトをする、テストの抽象度合いを調整する
    • いわゆる正常系のテスト(システムや機能が持つ目的を達成できるテスト)以外をなくす、減らす
  • 他で同様のテストをしていないか?
    • システムテストと受入テストで重複部分があれば、なくす、減らす
      • 重複を安易に削ると、テストの目的、テストに求められる役割を果たせなくなることがあるので注意
  • 他のテスト、特により軽量にできるテストで代替できないか?
    • 入力値のバリエーションの網羅的な確認はユニットテストや狭い範囲での統合テストで行い、システム全体を対象にするテストでは検証しない
      • 似ているテストだと思って安易に削ると、テストの目的、テストに求められる役割を果たせなくなることがあるので注意


大体の場合は、どれか1つではなく、組み合わせて考えることが多い。

いずれを採用するにしても、ステークホルダーの期待値マネジメントは必須。このテストを減らしたときに何が起こるか?を説明しなくてはならない。
いずれを採用するか決める際は、削減しなければならないテストの規模、求められる品質レベル、他のテストやレビュー、プロセス、チームの状態を考慮する。

E2Eテストの定義を知りたい

E2Eテスト(end-to-end testing、エンドツーエンドテスト)という言葉の定義をちゃんと知りたいと思い、いくつかの文献の確認をしてみたメモ。

背景

「E2Eテスト」と言う言葉は、人によって、異なるニュアンスで使われているような気がしている。

  • 単に「エンドユーザーが触るところからバックエンドまで」といったスコープを示すために使っている場合、 ユーザーシナリオの確認といった目的が付随している場合

  • 厳密さの違い。  例えば、自システムと連携しているシステムをモックにしたら、E2Eテストではない?   (これに関しては、スコープを自システムに限ればE2Eテストと呼び、連携先も含めて語る時はE2Eと呼ばない、でいいのかもしれない)


確認結果詳細の前に、まとめ。

  • そもそも、定義している文献があまり見つからず。上述したニュアンスの違いについては、白黒ついてない

  • 「E2Eテスト」は、SQuBOK、SWEBOKには定義されていないようだ(あと、国際規格のISO/IEC/IEEE 29119にも?) JSTQBシラバスにも、「E2Eテスト」そのものはない。ただし、エンドツーエンドと言う言葉がシステムテストの説明で使われている

  • なので、使うときは「E2Eテスト」のイメージを確認した方がよさそう


以下、文献ごとに調べた内容。

ISO/IEC/IEEE29119

手元にあったPart 1:Concepts and definitions、Part 2:Test processesを検索したが、見当たらず。
他のPartは、未確認。

JSTQB(ISTQB)シラバス

「エンドツーエンドテスト」「E2Eテスト」「end-to-endテスト」といった文言はなかったが、いくつかのシラバスでは「エンドツーエンド」という表現を見かけた。
いずれも、システムテストの説明の中で使われていた。
例えば、

  • 「システムレベルの機能テストでは、エンドツーエンドの機能性を対象にテストする。」(Advanced Level シラバス 日本語版 テストアナリスト Version2012.J01)

  •  (「システムテスト」という箇条書きの子要素で)「ユーザストーリー、フィーチャおよび機能のエンドツーエンドのテストである」(Foundation Level Extension シラバス アジャイルテスト担当者 日本語版 Version 2014.J01)

  • ほか、Foundation Level シラバス 日本語版 Version 2018.J03のシステムテストの章でも登場する。


なお、以下のシラバスも探したが、見当たらなかった。


書籍 SQuBOK、SWEBOKなど

いずれも、索引になし。 

  • ソフトウェア品質知識体系ガイド(第2版) -SQuBOK Guide V2-  
  • ソフトウェアエンジニアリング基礎知識体系-SWEBOK V3.0-  
  • 実践ソフトウェアエンジニアリング ロジャーS.プレスマン (著)
余談1

インターネットで検索するといろいろ出てくるが、E2Eテストとは何か?に焦点をあてた記事は、案外少なかった。
E2Eテスト自体の説明は一言二言で、E2Eテストの自動化事例やTipsを紹介する記事や資料が比較的多い印象。

E2Eテスト自体を説明した記事も一部あり、踏み込んでE2Eテストの目的にまで踏み込んで書かれているものも見かけた。


余談2 E2Eテストの位置付けの変化

本「基本から学ぶソフトウェアテスト」の著者の1人のKaner氏のサイトと思われるところで「end-to-end testing」に言及されていた。

定義を詳細に語った部分は見つけられていないが、「end-to-end testing」が登場した部分をかいつまんで読んでみたら面白かった。

興味持った人は原文をあたっていただきたいが、興味深かった内容の自分まとめ:

  • 従来のアプリケーションでは、E2Eのテストの必要性を過小評価しすぎでは?  スタックオーバーフローやタイミングの問題など特定の問題は、大量の、システムレベルの自動テストで最も効果的に検出できた。パフォーマンステストでもE2Eテストは必要

  • 現在のモバイルアプリはHWとSWの構成が多様なので、より、システムレベルのテスト寄りになるのでは
     (この記事は、2016年付。テストの多くがシステムレベルのテストになる、ということか?)

  • システムが成熟すると、テストプロセスの歪みは徐々になくなる
     20年後には、モバイルのテストについても、他のアプリケーションに適用されるのと同様のピラミッドが適用されるだろう


2016年の20年後というと、あと15、16年経った後。モバイルアプリのテスト、特にE2Eテストやその周辺の難易度は、どう変わるか? また、他の分野とのテストプロセスの違いは小さくなる、または、なくなるのか?
モバイルではないが、WEBブラウザ間の差異については、適用できるように思った。ゼロにはなっていないものの、今から10-15年前はWEBブラウザ間の挙動の違いの話題が今より多かった気がする。