ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

JaSST Online Cloverで、情報発信についてお話しました。#JaSSTOnline

昨日7/31(土)に、JaSST Online CloverというイベントでLightning Talksに参加しました。

jasst.jp

第3回であるCloverのイベントテーマは「技術の発信」ということで、ブログを細々と続けているわたしにも声をかけていただいた次第です。
LTゲストは、『ソフトウェアテスト技法ドリル』の秋山さんと、『テスターちゃん』の松谷さん。 すごいお二人と一緒にお話できたことは光栄です。

ブログを続けているモチベーションは何か?などと考えたことはなかったのですが、せっかくの機会なので整理してみた資料が、コチラです。

発表者として加わってみると、参加者の立場では知りえなかった運営チームの準備の大変さと丁寧さが見えてきます。いや、発表者から見えるのもごく一部で、運営チームの苦労と努力は相当だと感じられました。頭が下がります。
ZoomとDiscordとCommentScreenとJamBoard(とTwitter)という各種サービスを併用しての仕組みは、オーバーテクノロジー過ぎてわたしには理解しきれず、「すげえな」しかありませんでした。

事前に、音声・映像・画面共有ができることを何度か確認させていただき、その際「音が聞き取りづらい」というご指摘を受けたため、「いやいや、これは仕方ない、買わざるを得ない」と超正当化してマイクまで買ったのですが、

当日は、機器不調、ネットワーク遅延、資料先祖返り、妻子の闖入など様々なトラブルに見舞われ(全部自分以外のせいにしている)、運営チーム、参加者のみなさんに大変ご迷惑・ご心配をおかけしました・・・。結局マイクも活躍せず。。。

ともあれ、OSTも含めてとても楽しいイベントでした。みなさま、ありがとうございました。

JaSSTは、無印、Review、OnlineそしてNanoと、展開が続いています。オンラインならではの参加しやすさを活かして、どんどん参加しましょう!

『THE CULTURE MAP』が教えてくれる、国民性の8つの軸

 「日本人ははっきりとNoを言わず、米国人は何でも包み隠さずに直言する」。
 こういった「国民性のイメージ」は誰しも、多かれ少なかれ持っているでしょう。
 さすがにそこまで単純ではないにせよ、考え方や習慣は、国や地域ごとに無視できない傾向があるようです。

 「●●の国の人は約束の時間にルーズ」「▲▲の国の人は結論から話さない」、こういった国民性(のイメージ、場合によっては偏見)の断片を、もっとシステマティックに把握・理解することはできないものでしょうか。そして異文化のメンバーをチームを組む際に、効率的に信頼関係を築くことはできないでしょうか。

 これに答えてくれるのが、Erin Meyer・著、『THE CULTURE MAP』です。

 Erinさんは、ビジネスシーンで重要な要素を8つの軸で表現し、その軸上に各国をマッピングしています。

 たとえば第1章で扱われる Communicating Scale
 この軸では、左に Low-context、右に High-context を配しています。
 もっとも Low に位置するのが米国人で、もっとも High に位置するのが、わたしたち日本人。

 ハイコンテキスト・ローコンテキストという言葉は、最近でもよく使われるようになってきましたね。
 日本や中国のように、歴史が長く、人間関係が世代間を通じて継承されていくような国の人間は、「空気を読み」、相手の暗黙的なメッセージを拾い上げることに長けていると説明されます。
 一方米国のように国としての歴史が短く、また多くの異文化が移民とともに入ってきたような国では、メッセージを明白に、できるだけ曖昧さを排除して表現することが重要とされています。

 と、第1章のこの話はそんなに珍しい話ではありません。
 ではそんなわたしたちは、部下に対するネガティブなフィードバックをどのように伝えるか。これが第2章のテーマです。

 第2章で扱う Evaluating Scale は、部下を評価する際の伝え方を表したもので、左に Direct negative feedback、右に Indirect negative feedback を配した軸です。あからさまに伝えるか、オブラートに包むか、ということですね。
 この2つの軸の4象限に国をマッピングしたのが、こちらです。

f:id:kz_suzuki:20210711194656p:plain
Communicating と Evaluating の2軸(『THE CULTURE MAP』より引用

 日本人は意外性なく、またもや一番右。直接的にネガティブなことを言わない強い傾向があります。
 一方米国人。Communicating Scale では最も左にいた米国人が、Evaluating Scale では真ん中あたりに位置しています。
 米国における評価では、「ネガティブなことを伝える前に3つポジティブなことを伝える。そして a few small suggestions といった前置きで、ネガティブなメッセージを極力やわらげて伝える」というのです。米国人は常にはっきりと物事を伝えるという単純なステレオタイプだけで米国人に接すると、大変な軋轢をもたらしかねないということですね。

 第4章で議論される Leading Scale は、コミュニケーションの仕方に地位や役職がどの程度効いてくるかを表現したもの。左が Egalitarian(平等主義)、右が Hierarchical(階層主義)。日本がここでもまた Hierachical に全振りしているのに対し、米国は左寄り。階層間の壁が相対的に薄いとうことで、ここには意外性ないですよね。

 一方第5章で扱う Deciding Scale、決定の手続きの傾向においては、米国は Consensual(コンセンサス型)ではなく、Top-down(トップダウン型)に寄っているんですね。ふだんのコミュニケーションにおいては比較的フラットな文化を持ちながら、決定においては地位の高いものの意見が強く優先される。これもまた「米国は人間関係がフラットだし、民主主義の国だから・・」などと思い込んでいると、誤ってしまいそうです。
 さらに、そもそも「決定」の意味・重みが国によって異なるという要素もあり、話はさらに面白くなっていきます。

 本書ではこのような軸8本を、それぞれ豊富な事例とともに紹介しています。
 もちろんこの8本をもってなお、国民性を表現するには十分ではなく、依然としてステレオタイプの部分もあるのかもしれません。特に日本人を引き合いに出している部分を読むとやはり「そんなに単純じゃないよ」なんて思ってしまいます*1。また同じ国の人間でも、個々人の特性もそれぞれ異なるでしょう。

 それでもなお、相対的な傾向と注意点を知っておくことには価値があると思います。
 いきなり人を殴りつけることは万国共通で無礼だとしても、ある国で当たり前、むしろ適切であるとされることが、他の国では失礼・マナー違反・プロフェッショナルでない、と受け取られることが、思った以上に多いのだということを思い知らされるのです。
 特に日本人は多くの軸において極端な位置にマッピングされており、変な民族なんだな~ということをあらためて感じさせられました。以下は、Harvard Business Reviewのサイトからの引用です。

f:id:kz_suzuki:20210711195919p:plain
マネジメントスタイル

 なお本書は、比較的な平易な英語で書かれており、英語を読む練習をしたい人にはぴったりだと思います。Audibleで、オーディオブックも提供されています*2
 わたしは修業のため、オーディオブック+本書でシャドーイングしながら意識高く読みました。英語の勉強にも良いコンテンツです!

www.audible.co.jp

*1:日本人との親睦を深めるには飲みにケーションが一番!といい切られてしまうと、うーん・・・となってしまう。いや、飲みにケーション好きですが。

*2:Audibleは毎月1枚コインが付与され、このコイン1枚でオーディオブックを1冊聴くことができます。要は、無料で聴けます。

Veriserveのテスト設計サポートサービス、GIHOZを触ってみる - その3

Naked tree"Naked tree" by Ivan Naurholm. thanks, for more than 500.000 views is licensed under CC BY-NC-ND 2.0

 GIHOZでクラシフィケーションツリー*1がサポートされたということで、練習も兼ねて触ってみました。

gihoz.hatenablog.com

 お題は、@halspringさんのこちらの記事の例です。

halspring.hatenablog.com

 結果として、大きく戸惑ったりすることなく、さわやかに作ることができました。
 各種モデリング技法が1つのプラットフォームで扱えるのはとても便利で、クラシフィケーションツリーの普及にも一役買いそうです。

f:id:kz_suzuki:20210711111418p:plain
クラシフィケーションツリーの例

 気になった点は以下です。

  • ツリーが大きくなると画面内に収まらなくなり、一覧性が失われてしまう。
    →不要にパラメタを組み合わせ過ぎているかも、木を剪定するタイミングか?と考える契機になるかもしれない(笑)。

  • 初期状態で、第2階層のクラシフィケーションにすでにクラスが生えているため、隣にクラシフィケーションを生やすことはできない。
    これ自体はクラシフィケーションツリーの仕様(のはず)だけれど、ぱっと見、「ルート以外にはクラシフィケーションを生やせない」と思ってしまいそう。
    →初期状態の第2階層は、クラシフィケーションからクラスが生えているノードと、クラシフィケーションからクラシフィケーションが生えているノードにしておくとわかりやすそう。

  • クラスからクラシフィケーションを生やすことはできなさそう。
    →なので、井芹さんの資料P.17のような絵は描けなかった。

 あと、これは他の技法でも同じことを書いたのですが、テスト設計のモデリングにおいては「意図」がとても大事なので、それを残せればなーと思います。

 先の@halspringさんの記事には、このように書かれています。

クラシフィケーションツリー法では人の意思を介入させることができます。

.

テスト対象の特徴や要件に合わせて網羅基準や水準の選定基準を考えます。

 「こういう根拠で、このように設計した」という意図を残しておくことは、その後でテストケース不足による欠陥流出が起きたときに「どこで」間違ったかをトレースできるようにしておくということです。
 記法に沿ってモデルが簡単に描け、そこからまた簡単にテストケースを導出できる。これはGIHOZのようなツールにお任せして、ヒトはその「意図」「根拠」をよく考え、確実に残しておくことが重要だと考えます。


 GIHOZを触ってみた過去記事は、以下です。

www.kzsuzuki.com www.kzsuzuki.com

*1: クラシフィケーションツリーの概要については、安定の井芹さんのスライドがわかりやすいです。

www.slideshare.net

テストオラクルとは何か

File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg"File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg" is licensed under CC0 1.0

 ソフトウェアテストの有識者の方々と、「テストオラクル」について話す機会があったので、自分なりの理解を整理しておきます。

 まずはおなじみ、I/JSTQBの用語集から。

テストオラクル(test oracle)
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

 要するに、期待結果を作るための元ネタでふね。

 ここで2つ、気がつくことがあります。

  1. (少なくとも明示的には)仕様書はオラクルと見なされていない。
     → オラクルにはどんな種類があるのか
  2. オラクルは、期待結果そのものではない
     → オラクルが期待結果そのものではないとは、どういうことか

 本記事では、この2点について考えてみたいと思います。

1. オラクルにはどんな種類があるのか

 「期待結果のソース」というオラクルの定義を考えれば、明記こそされていないものの、仕様書自体もオラクルに含めてもかまわないでしょう。
 これを含めれば、オラクルは以下の3つに分類できます。

そのソフトウェアをふるまいを記述したドキュメント

 仕様書、ユーザマニュアルなどがこれに当たります。

比較対象にできるソフトウェア

 まず、用語集で「ベンチマーク」と表現されているものがあります。Cem Kaner氏は、Microsoft Officeの競合品としてOpenOfficeを開発しているとすると、OpenOfficeの動作が「正しいか」は、Microsoftの「Word」が教えてくれるとしています*1

www.testingeducation.org

 またJRの運賃計算では、膨大なテストケースの期待結果を、1つ1つ人間が考えるのではなく、Nバージョンプログラミング、つまり同じ出力を持つシステムを複数作って突き合わせるということをしています。

www.publickey1.jp

テスト対象となる実機用の運賃ソフトウェアと、検証用の運賃ソフトウェアは別のチーム、別のアルゴリズム、別のプログラミング言語で作ります。実機用はC++ですが、検証用はJavaで言語特有のバグをなくそうとしています。でも検証用のソフトウェアにはそんなに予算が掛けられず少人数で作っているので、実機用はどうやって作ったのか聞きたくなるのですが、そこを我慢して作る。

過去の履歴

 「そのソフトウェアの前バージョンと同じ動きであれば問題ない」というオラクルもあります。リグレッションテストは、「過去の想定した期待結果の通りに動作する」ことを確認するので、テストオラクルの一覧ということができるでしょう。

人間の知識

 用語集では「専門家の知識」とあります。
 ですが、たとえば文字判別のソフトウェアにおいては、一般の人が「妥当」と考える常識的な判断がオラクルになりうるでしょう。

その他

 メタモルフィックテスティングはちょっと異色で、「正しいことがすでに分かっている期待結果」を派生させていくものです。

www.kzsuzuki.com

 このように、「期待結果のソース」は様々な種類があることがわかります。

2. オラクルが期待結果そのものではないとは、どういうことか

 oracleとは、神託のことですね*2
 世界観がぐちゃぐちゃですが、こういう絵になります。

f:id:kz_suzuki:20210411174734p:plain
神と神託

 神からのお告げを巫女さんが受け取ります。お告げは神秘と暗示に満ちていますから、解釈が必要です。専門職たる巫女さんがこれを解釈し、人々に伝えます。
 このアナロジーから言えることが、これまた2つあります。

  • 間違いが入り込む
  • 細かいことを教えてくれるとは限らない

間違いが入り込む

 まず、巫女さんが間違えます。
 たとえば「18歳以下は無料」という仕様を、「18歳であれば有料」と解釈してしまうと、誤った期待結果を得ることになります。

 次に、神が間違えます。
 神の無謬性を信じたいところではありますが、ソフトウェア開発において神託を告げるのは神ならぬ人。「仕様通りの動作である」ことがテストで確認できても、「間違った仕様通りの動作」なら意味がありませんね。

細かいことを教えてくれるとは限らない

 たとえば神たるお客様が「性能要件は、“旧システムと同様“ね~」と重々しく宣われたとしましょう。このオラクルは、システムのあらゆる性能要件を余すところなく記述したものと言えますが、「旧システムの性能を一つ一つ確認する」という「解釈」なしには、何も言っていないのと同じです。
 つまり、オラクルがあったとしても、テスト設計においてはそれを解きほぐす必要があるかもしれない、ということです。

まとめ

 まとめると、「適切なオラクルを適切に解釈しないと、適切な期待結果は得られない」という、ごくごく当たり前の結論になります・・・!

*1:まったく同じ話を過去記事でも書いていました・・・ www.kzsuzuki.com

*2:甲骨のことは、oracle bone というらしいです。

スモークテストとサニティテストとは何なのか

Sanity check"Sanity check" by foreverdigital is licensed under CC BY-NC-ND 2.0

 「サニティテスト」(sanity test)という言葉を聴くことがちょいちょいあったので、意味を捉えておきたいなと思っての記事です。なお、「本当の」「正しい」定義を見つけることが目的ではなく、「こんな風に捉えられていることが多そう」を理解することを意図しています。

 また、調べる過程で、自分がかつてまとめた以下のtogetterも見つけてしまったので、「テストタイプなのか、テストレベルなのか、テストフェーズなのか」 という議論も、ここではしません。

togetter.com

I/JSTQBでは

 まずはいつものここからですね。
 結論からいうと、サニティテストはスモークテストの類語とされています。

スモークテスト(smoke test)
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
Synonyms: コンフィデンステスト(confidence test), サニティテスト(sanity test)

 「スモークテスト」の方は、これでしっくりきます。本格的なテストを始めるにあたって、「そもそも最低限のところは動くよね」を一通り、さらっと見ることが目的です。ここでダメ、つまり最低限すらまともに動かないなら、それ以上テストをすることは無駄と判断できます。
 ネットワーク接続チェックの一番素朴なものであるpingになぞらえて、「疎通確認」という呼び方も聞いたことがあります。

スモークテストの由来

 Wikipediaを信じると、スモークテストはまず配管工事の分野で使われ、それが電気の分野に輸入され、さらにソフトウェアテストの分野に入ってきたようですね。

en.wikipedia.org

 配管の世界では、下水管などに対し無毒な煙を流し込んで全体を通過させ、パイプの劣化やひび割れを見つけるということを行っているようです。煙が漏れ出ていれば、そこに不具合(defect!)があるわけですね。

 電気の世界でこの言葉が拡張され、「回路基板の電源を入れた途端に煙が出てくるようなら、電源と落としてテストはおしまい」という拡張されたとのことです*1

 ここで、違和感を覚える人もいるかもしれません。
 電気の文脈では、「テストのしょっぱなの段階で、いきなりダメ」で煙が出るんですね。ソフトウェアのアナロジーだと、「インストーラが途中で止まる」とか「プロセスが起動しない」とか、そんな感じでしょうか。テストは始まってもいません。
 上のISTQBの定義の通り、ソフトウェアの文脈では「主要機能を網羅」するのがスモークテストなので、由来元の由来元である「全体を通過させ」る配管の文脈でのスモークテストの方が近いんですね。

 主要機能を網羅するとなると、わたしは自動リグレッションテストを連想してしまいます*2が、ISTQBの定義だと、リグレッションテストに限定していません。修正・変更後だけでなく、新しく作ったものを動かしてみる際にも、本格的なテストの前に軽く動かしてみる、これがスモークテストといえそうですね。

サニティテスト

 sanityというのは、「健全さ」「正気」という意味です。sanity testは「まともに動いているか」を確認するテストということになります。これだけだと、サニティテストとスモークテストは似たような印象ですね。

 両者の違いを説明した記事はけっこうあって、それぞれの主張があるのですが、共通的に見られる主張をテーブルにしてみると、以下のような対照がメジャーのようです*3

項目 スモークテスト サニティテスト
目的 プログラムの機能の主要な部分が正しく動作するかを確認するために行われる。 新しい機能の追加やバグの改修後が適切に行われたかを確認するために行われる。
特徴 浅く広いテスト。 (スモークテストに比べて)深く狭いテスト。
範囲 システム全体のEnd to Endが対象である。 システム全体の特定の部分が対象である。
対象 各ビルドに対して行われる。 比較的安定したビルドに対して行われる。
タイミング リグレッションテストの前に行われる。 スモークテストの後、リグレッションテストの前に行われる。
実施者 開発者、またはテスターによって行われる。 テスターによって行われる。
他のテストとの関係 受入れテストのサブセットである。 リグレッションテストのサブセットである。

 「他のテストとの関係」については、まったく逆の位置づけをしているサイトもあります。つまり、スモークテストがリグレッションテストの一部で、サニティテストが受入れテストの一部ということです。
 ただ上述の通り、I/JSTQBではスモークテストの実施タイミングを、プログラム修正に限ってない(プログラムの新規追加も対象にしている)ことから、上表での位置づけの方が親和性が高そうです。

終わりに

 用語の定義や、世の中で一定以上の共通認識があるものと、そうでないものがあります。「サニティテスト」は後者の一つのように思います。
 このような場合、組織やチームの中で定義を合意しておかないと、混乱のもとになります。
 スモークテストとサニティテストを別の概念として扱う場合の定義の一案として、この記事を参考にしていただければと思います。

参考サイト

*1:ただしこの話が載っているのはソフトウェアテストの書籍のようですが。

*2:パイプを煙が通過していく様子も、自動テストをイメージさせませんか?

*3:調べてみると、言い回しを含めて似たようなテーブルがたくさん出てきます。