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

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

ユーザビリティを考えるうえでヒントになりそうな『バグトリデザイン』

 みなさん、こんにちは。
 この記事は、「ソフトウェアテスト Advent Calendar 2022」 7日目の記事です。
qiita.com

 「バグトリ」という言葉に惹かれて読んだ、『バグトリデザイン』という本を紹介します。

 最近、「デザイン思考」という言葉をよく聞きます。
 本書にこの言葉はあまり出てこないのですが、良いデザインをするために必要なこととして、「それを使っている人の行動をよく観察する」「それを使う人になりきる」といったことを述べている点では似ていると思います。

 本書の前半で著者は、製品やサービスを使ううえでの「トラブルの元凶は”モノ単体”志向」としています。

すべての事象は、ある特定された場所で「人とモノ」が時間とともに関係性を変化させながら推移しているのが常です。しかし、モノに注目するあまり関係性の片方、つまり人の側を見落とすことがよくあります。モノ単体を観て判断しているため、問題の本質を見抜けずに解決方法を誤ってしまうのです。

 これって、ソフトウェアにおいて「機能としては出来上がってるんだけれど、業務上ではどうにも使いづらい」という話に似ていませんか?

 この本では、ユーザの体験を遮る・損なう要素である「バグ」にはどのようなものがあり、そのバグがいかなる原因で起こるのかを整理しています。
 あくまでも、モノやコトをデザインする方法について述べた本なのですが、この分類は、ソフトウェアにおけるいわゆるシナリオテストやユーザビリティテストの観点として使えるではないかと思いました。

 この記事では、本書で説明されている6つのバグの現象と、それをもたらす7つの原因について紹介したいと思います*1
 自分たちの製品やサービスの使い勝手を考える際に、この6つの視点を眺めてみると、思わぬ欠陥が見つかったりするんじゃないかなと思います。

バグの「現象」

1. 非効率のバグ

定義: 行為の中断や損傷、やり直し、後戻り、無駄があり、次第に行為が非効率になるバグ

 例として、「5千円札や1万円札が使えない、駐車場の自動精算機」が挙げられています。人員削減が目的なのに、係員を呼ばざるを得ない非効率につながっています。

 個人的な体験でいうと、「オンラインバンキングで振込しようとしたら、最後にワンタイムパスワードを求められて、スマホに銀行アプリを入れているうちにタイムアウトに・・・」というのがあります。
 それってユーザ側の準備不足でしょと言われればそうなのですが・・・、「続けて行うべき手続きの途中に突然、事前に済ませておくことが前提になっている作業が割り込んでくる」というのは、見直す必要があるかもしれません。

 レシピをきちんと読まずに料理を始めてしまう料理下手が出会う、「十分に水切りした豆腐」みたいなやつです。

2. 迷いのバグ

定義: ユーザーに迷いが生じて適切な判断・選択ができなくなるバグ

 広いオフィスや会議室などで、「壁面に設定された照明Off/On操作パネルと、実際の照明の対応関係がわからない」といった例が挙げられています。

 Webサイトでいうと、「どこに行けば何ができるのかわからない」というのがありますよね。
 我が家では子ども向け教育サービスを利用しているのですが、そのサイトではログイン中にも関わらず、氏名や住所の入力を求められます。そのため、「今ってログアウト状態なのか?」「手順を間違ったのか?」というストレスにつながっています。

3. 矛盾のバグ

定義: 矛盾をはらんだ結果を生むバグ

 レジ袋のパラドックスが、例として熱く語られています。レジ袋こそ、廃油を再利用したうえで何役も兼ねているアイテムだったのに、それを排して貴重な静製油を使って大量のエコバックを生産していると・・・。

 よかれと思って*2作ったものが、ユーザにはかえって不自由なものになるかもしれない。
 『シニアが使いやすいウェブサイトの基本ルール』では、シニアをターゲットとしてサイトでは、「文中リンクは避ける」ことを勧めています。文中リンクは、ユーザが詳細を知りたい場合に簡単に飛べるように、利便性を目的に入れるものでしょう。ですがシニアにとっては、そのリンクは確認すべきものに見え、集中力を削ぐ要因になることが多いのだそうです。

4. 負環のバグ

定義: 当たり前だと思っているモノやサービス・仕組みについて、実は不便を含んでいるのに気づかず、負のスパイラルから抜け出せないバグ

 運動をしない→太ったまま→体を動かすのが億劫になる→筋力が衰える→運動をしない→ という悲しい例を挙げています。

 わたしはStreaksというアプリを使っています。いわゆる「習慣化」のためのアプリです。
 習慣化したいことを登録し、実行できたらそれを記録していく。すると「何日続いたよ!」とか、「今日も実行すれば、10日連続だよ!」と後押ししてくれる。達成状況を美しいグラフで可視化してくれるのも、モチベーションの源泉になります。

 しかし・・・、一度サボって連鎖が途切れると、かえってStreaksによる励ましがツラくなる。。。
 今日やっても、明日やらなければまた連鎖が途切れる・・・、なら今日はやらなくてもいいんじゃないか・・・。
 そんな驚きの心の弱さが露呈し、「習慣化アプリのせいで、習慣をサボってしまう」という悲しい出来事が発生するんですね。

 いいえ、アプリじゃなくて、悪いのはわたしです。アプリは良いです。お金を払う価値があります。

Streaks

Streaks

  • Crunchy Bagel
  • ヘルスケア/フィットネス
  • ¥800
apps.apple.com

5. 心理のバグ

定義: 不満、苦痛、迷惑、恐れ、不安、怒り、セクハラ、パワハラなどの精神的圧迫のバグ

 スーパーでくりかえされるテーマ音楽が、精神的圧迫につながるという例を挙げています。

 購読を意図したつもりのないメールマガジンをひたすら届けてくるオンラインショッピングサイトや、「ドメインが失効します!」みたいな脅しメッセージを投げまくってくるドメイン取得サービスを思い出します・・・。

6. 誤認のバグ

定義: 勘違いや思い込みなど、誤った認識がトラブルの誘因となるバグ

 ユーザーの動線に沿わせることが考えられていない、駅構内の張り紙やサインを例として挙げています。

 またも、子ども向け学習サービスへの不満をぶつけるのですが、キャンペーンや申し込みの動線がまったくわからず、「このアンケートには回答したか?」「手続きが終わったか?」と迷うことが多すぎます。その結果、「やっていないかもしれないから、一応もう一度やっておこう」とならざるを得ません。何が終わっていて、何を終わらせなければいけないのかがわからず、いつも不安な気持ちにさせられます。

バグの「原因」

 原因の方は、カテゴリーの定義の紹介にとどめておきます。

  1. プロセス因子: 手順の間違いが原因となること。
  2. 属性因子: 個人の性格、性別、人種、年齢、立場の違いなどが原因となること
  3. 慣性因子: マナー、クセ、無意識の行為、スキル、共感反応、拒絶反応など、後天的な経験によって習慣化された行為が原因になること。
  4. 記憶因子: 記憶のしにくさが原因になること
  5. 環境因子: 時空の変化が原因となること
  6. 不適正因子: 不適正なプラン・デザイン・設計・役割などが原因になること。
  7. その他の因子

 属性因子なんかは、ターゲットとする地域や世代を絞っている場合には、特に配慮すべきものでしょう。
 たとえば子ども向けにアプリをデザインする場合の心に留めておくべき事項として、『子どものUXデザイン ―遊びと学びのデジタルエクスペリエンス』では以下のように述べています。

子どものためにデザインすることは、決して、大人を対象としたコンテンツや画像やインタラクションの「レベルを下げる」ことではありません。ユーザーの認識、身体、感情面の現在地を把握し、ユーザーを適切な位置に導けるデザインが求められます。かといって、子ども向けのデザインを、大人向けとはまったく別のものとしてとらえてしまうと、優れたデジタルデザインの根幹をなす重要な慣習やパターンを見失うことになり、やはり望ましくありません。

 先に挙げたシニアでも同様ですが、開発側と利用側で、モノの見え方・感じ方は異なってくる。自分の感覚が絶対的で標準的だと思ってはならないですね。

 他の因子も、「よくないデザインに至る原因」として考えてみると面白そうです。

まとめ

 モノやコトのデザインにおける失敗とその原因の分類を、ソフトウェアやサービスのテストの観点として使えないか?というお話でした。
 本書では、この「現象」と「原因」をマトリクスにすることで、「バグ」の分析を行うことが述べられています。何だかQAの仕事と似ているようですね。

 書いているうちに、ふだん使っているサービスへの日ごろの鬱積をぶつける場になってしまいました。今日はこの辺で・・・。

Project 365 #71: 120317 Box Of Cogs

*1:ここでいう「バグ」は、プログラムというよりは、「ソフトウェアデザインの問題」を意味しています。

*2:エコバックの場合は、よかれとさえ思ってもいないかもしれない。本来必要なかったはずの需要を無理やり創出しているというのが、著者の見立てのようです。

2022年度上期に読んで特によかった本

 上期に読んだ本の中で特によかったものを、Twitterに放流した感想を流用しながら、紹介していきます。
 技術書もたくさん挙げられるといいのですが、技術書って「読み終わる」じゃなくって、「読み続ける」感じなので、完結したレビューが書きづらいんですよねー・・・。

IT技術系

脅威インテリジェンスの教科書

 コンピュータ・ソフトウェアのセキュリティだけではなく、もっと広く人的・組織的な側面も含めてのセキュリティ・脆弱性・インテリジェンスを説明した本。物理的にけっこういいサイズですが、例も豊富で説明もわかりやすいです。

 技術面に徹しているわけではなく、たとえば集めたデータを情報・インテリジェンスに昇華していく際に陥りがちな、心理学的誤謬といったものにまで言及があります。ソフトウェア開発者だけでなく、コーポレートセキュリティを守るような立場の人間が読むのにもよいと思います。

ビジネス系

アナタはなぜチェックリストを使わないのか?

 この本は今期読んだ本の中でかなり上位のお気に入りなので、個別の記事を書きました。

www.kzsuzuki.com

2030 半導体の地政学

 半導体の技術的な説明だけではなく、またそのビジネス的な側面だけでもない。「地政学」と銘打っている通り、国が生き残るために半導体がどれだけ重要な役割をもつか、主要国はどう動いていて、日本はどうすべきなのかをしっかりと説明した本。

 半導体というと日本はすっかり負け組という印象があり、実際そういう面もあるのだけれど、素材やパーツで強い企業はまだまだあり、また半導体サプライチェーンを確保するための日本の戦略も議論されていることがわかります。

 終章からの引用。半導体は単なるビジネス商品じゃなくて、文字通りの「戦」略物資なんですね。

半導体は”武器”であり、半導体サプライチェーンで連携すること自体が地政学的な国家戦略となる。クアッドに限らず、さまざまな国の組み合わせで「半導体同盟」とも呼べる連携が進んでいくだろう。インド太平洋、とりわけ環太平洋、そのなかでも南シナ海が主戦場となる。

 文章も比較的平易で読みやすい。前提知識も特になし。普段の仕事で半導体なんか関わりないって人にもオススメです。
 ただし、半導体についての一般的な知識はあることを前提としているので、技術面を補完してくれる本があるといいなーと思いました。

プロトタイプシティ 深センと世界的イノベーション

 それなりのボリュームのハードカバーなのに非常に読みやすく、ぐいぐい引き込まれる。
 なぜ深圳は強いのか。イノベーションを起こすために日本に必要なのは何か。ということが丁寧に説明されている。決して「深圳はすごい、日本は凋落した」というトーンではない、叱咤激励してくれる本。

 ソフトウェアQAとしては、第2章のこの話がよかったです。

「上司にソフトウェアの品質テストをどうするか聞いたんだが、『新しい機能が動くかどうかのテストをする前に、新しい機能が世の中に受け入れられるかのテストの方が重要』って言われたんだよ」

 これっていわゆる「リーン」「MVP」みたいなものですかね。まず出す、出して仮説検証して、・・・みたいな考え方が、徹底されている。
 中国で起こるイノベーションは、「先進国に中国が追いついてきた」ということではなく、社会制度も文化も考え方もまったく違うところで、別の道から突っ走ってきているのだという印象を受けました。

日本人のためのインド英語入門 ことば・文化・習慣を知る

 ネイティブの英語も大して聴き取れていないけれど、インド英語はまた独特でわたしには難しい。そんなときにTwitterで見かけて、読んでみました。

 最初の方で 「インド訛りの英語があるのではなく、インド英語という多様化した英語があるのだ」(意訳) という話があり、これは目から鱗でした。ネイティブっぽい発音や流暢さにシビれたり憧れたりするけれど、違ってもいいのかなーと。

彼らはインド式の英語の発音や抑揚の仕組みを確立し、それをうまく使いこなすことに成功しました。イギリス式の音韻体系を厳密に模倣する必要がなくなった分だけ、語彙や表現や構文よ学習に努力と注意を集中することが可能になったのです。

 インド人と英語でやりとりする機会のある人は、この本の第1章読むだけでも十分楽しめると思います。発音の特徴についての説明が特に役に立つのだけど、全体的にあまり教科書的ではなく、インド英語、そしてニホン英語に対する熱い気持ちが伝わってくる本です。

エッセイ・その他

6ヵ国転校生 ナージャの発見

 「A国はこうなのに、日本はこうだからおかしい、硬直的、前時代的、・・」みたいに責められるのでは・・・とついつい警戒してしまうんだけれど、それがない。読んでいて、変な優越感や劣等感を感じさせない。優劣ではなく、それぞれの文化でどこに重きをおくかによって、選んだものが違うんだと教えてくれます。

 たとえば、ノートに使う筆記用具。 ロシアではペンだったのに、イギリスは鉛筆。鉛筆で書くのは、下書きのようで納得がいかない。
 でも今は、こう解釈できる。

えんぴつを使って「書きやすく」するのか、ペンを使って「考えやすく」するのか、実は書く道具がそのプロセスを決めるのだ。

 数字の「フォント」の話も面白かった。
 ロシアなどヨーロッパでは、「7」の縦部分に横棒を入れるのが一般的。理由は、先端に折り曲げのある「1」と区別するため。「1」の折り曲げをなくすと、今度は「l」と競合する。仕方なく、日本向けとそれ以外で、数字フォントを使い分けたという・・・。

 こんな話が盛りだくさんで、一方でコンパクトにまとまってもいるので、中学生くらいで読むと楽しめるかなと思いました。
 エピローグに書かれたこの言葉が、とってもよくわかります。

「環境が変わると、ガラッと変わるものは?」
答えは、「ふつう」だ。

100均グッズ改造ヒーロー大集合

 その辺で売ってる大量生産品のデザインを活かして、ヒーローとしての造形に仕立て上げる、だけではなく、素直にカッコいい。燃える!
 写真集なので写真を紹介したいけれど、そういうわけにもいかないから、まずは著者のTwitterを見ていただきたい!

フィクション

翼はいつまでも

 中学生を主人公とする青春小説、ということで、「たぶんムズムズしちゃって読めないだろうなあ」と思ったけれど・・・良い
 「はい、ここで泣いてくださいね~」式ではない、教師たちの理不尽さ、大人への反発をもちながらも、自分の在り方を少しずつ変えていく少年の話。
 出てくる教師は本当に、ビックリするほどひどいんだけれど、彼らは彼らなりに若すぎたり、理不尽さんに押しつぶされたりしているんだろうなと。完全に中年目線。

 あまりにキラキラしていて、中年には眩しすぎる。それでも、そんなくすんだ大人でも、このキラキラならきっと受け入れられる。
 長男にも進めようと思ったんだけれど、「セックス」という単語が頻出しすぎて、気恥ずかしくて勧められない。勧めるなら、高校生になってからかな。

殺戮にいたる病

 「どんでん返し」系の小説を読みたいなーと思って選んだこの本。知らずに読んだらどんでん返された、ならともかく、この本は最初から「叙述ミステリの極致!」なんて言っちゃってる。確かに、ちょいちょい違和感(もちろん作者に意図的に仕込まれた違和感)はあるんだけど、ほとんど最後までトリックがわからなかった。

 叙述トリック系は一度読むとタネはわかっちゃうけれど、再読して初めて気づく巧妙な記述に気づくのが楽しいですね。
 欠点は、殺人描写が直接的すぎることかな。

medium 霊媒探偵城塚翡翠

 これも叙述トリック系。
 「霊媒として死者の声を聴くことができる」翡翠と、「推理小説家で手がかりから論理を紡ぐことのできる」香月。
 最初に答えを出してしまう翡翠と、その答えに客観的な証拠に関連付けていく香月、という設定が、まず面白い。
 で、最後にひっくり返されてしまう。いやあ、これは・・・。裏の裏をかかれます。

 今月からドラマが始まるみたいです。

www.ntv.co.jp

漫画

 漫画アプリは時間を無限に溶かしてしまうので、非常に危険ですが、日本漫画の裾野の広さがよくわかります。Twitter広告でも、知らない漫画にかなり出会いますが、アプリでカバーしている漫画には「これ、誰が誰のために描いているの? 聞いたこともない・・・」みたいな漫画だらけです。

喧嘩ばっかりしている漫画

 これまではまったく興味のわかなかった、「ひたすら喧嘩ばっかりしている漫画」にはまり込んでしまいます。

 『カメレオン』はひたすら下品で最低のギャグ満載、もう現代じゃ連載できないだろうなってモノ多数。作品へのコメントも、「これ、新規参入の若者じゃなくて、連載当時にリアルタイムで読んでたおっさんたちだな」ってよくわかる香ばしさはたまりません。「人気一位は松岡」は完全に同意。

 『A-BOUT』も、ほんとに、ほんとにひたすら喧嘩していて、学校とか街とかで「テッペン」をとることにどうしてそこまで意義を見出せるのか、授業も受けないし暴虐の限りを尽くしているのになぜ退学(や)めないのか、謎だらけです。いや、卒業はしたいのかよって・・・。
 とにかくずっと喧嘩してるんですが、キャラが立っているのと、そのキャラを壊さないきわめて繊細なラインでの高度なギャグ、このバランスが最高すぎるんですよね。

 『ドンケツ』は893さんがひたすらに暴れまわっている漫画です。以前だったら表紙を見た段階で絶対読まなかった漫画ですが、食わず嫌いってもったいないですね。人気のある漫画にはやっぱり、それだけの理由があるんです。
 ほんとにずっと争ってる(そして高校生の喧嘩よりえげつない)んですけど、芯の通ったストーリー、「喧嘩っぱやいが男気のある渋いヤクザ」というありがちな主人公象を真っ向から否定した主人公、取ってつけたようなオマケになりがちなサイドストーリーの面白さ、とってもレベルが高いです。まあとにかく喧嘩してるんで、その時点で合わない人は合わないと思います。

 Twitterでも話題になって実際めちゃくちゃ面白い『ファブル』から『ナニワトモアレ』も読んだし、髙橋ヒロシさんのこれまた喧嘩しまくっている作品も読んだし、もうだいぶ喧嘩に疲れてきました。下期は純愛路線でいきます

スポーツで燃えてる漫画

 上期は『弱虫ペダル』で燃えてました。高校生の「自転車競技部」の漫画です。
 主人公補正、ちょっと極端すぎる展開、突如後付けでさしはさまれるエピソードなどをおいてなお、スポーツ漫画のよいところを凝縮したような作品。自転車レースのことを何も知らなくても楽しめます。
 1年生編のインターハイは、めちゃくちゃ燃えます、震えます。「巻島センパイ最高ショ」は完全に同意。

酒ばっかり飲んでる漫画

 『神の雫』ですよね。
 ワインの知識ゼロで読んでも大丈夫、むしろワインがどんどん飲みたくなるし、それに合わせて、いや「マリアージュさせて」、よいアテも食べたくなる。

 主人公格2人の超絶なスペック(主人公は、猛吹雪のマッターホルンアタック中に、その頂上で開けられたワインの香りを嗅ぎあてることができる)と、よくストックが尽きなかったなと思うほどの異常なワイン表現力、続編の『マリアージュ』含めて最後までテンションを失わずに描き切った作品です。

 なお、これを読んだ後も特にワインに詳しくはならなかったし、ワインもまだそこまでおいしいと思えません

おわりに

 総じて、たくさん漫画を読んだ半期でした。下期もたくさん漫画を読もうと思います。喧嘩とは無縁の、純愛路線でね。

テストケース管理ツールとスプレッドシートでは、テスト管理の何が違うのか

 テスト管理ツール導入を検討するにあたって、「Excelと比べて何がいいのよ?」という疑問は挙がって当然でしょう。
 ツールベンダからの情報はけっこうあるのですが、ユーザからの情報ってあんまりないんじゃないかと思って、ちょっと書いてみました。導入の検討の際に、何かしらお役に立てば。

はじめに

 まずこちらが、おおものとスプレッドシートで、テスト管理ツールとスプレッドシート、テスト管理においてどんな長所・短所があるかの私見をまとめたものです*1

docs.google.com

 本記事は、このバージョンの現時点版から転記したものです。メンテはスプレッドシート側のみに反映します。

注意点

 注意点は、以下の2点です。

  • あくまで機能面にのみ注目しており、たとえばコスト(ライセンスコスト、維持運用コスト、学習コスト、Excel職人コストなど)は対象外です。
  • わたしが 使ってみたツールの数は限られますので、「テスト管理ツールって一般的にこうです!」というのはちょっと嘘かもしれません。

 なおテスト管理ツールについては、テストケースのグルーピングについて以下のような記事も書いています。よろしければ。 www.kzsuzuki.com

テスト管理ツールベストプラクティス!?

 この手の話、つまり「テスト管理ツールの機能」の話じゃなくて、「テスト管理ツールをどう使うといいのか」という、「テスト管理ツールベストプラクティス」を考えるコミュニティ活動、やってみたいです。もう存在するなら仲間に入れてくれ・・・。

 検討したいテーマは、こんな感じ。

  • テストケースの集合のツリー管理やタグ付けといった、管理の方法
  • テスト実行のステータス遷移
  • テストケースの命名
  • ・・・

 では以下、比較です。ただ、スプレッドシートを見た方が早いです!


テスト計画

工数見積もり

従来のスプレッドシート運用
特になし

一般的なテスト管理ツール

  • 過去の実行結果に基づいて、実行工数の見積もりができる。
  • バーンダウン・バーンアップチャートなどが自動生成され、開始時点ですでに無理がないかを確認できる。

担当者アサイン

従来のスプレッドシート運用
特になし

一般的なテスト管理ツール

  • 実行担当者のアサイン、作業の平準化がしやすい。

テスト分析・設計

従来のスプレッドシート運用

  • 図・表形式で設計したテストケースを、そのままテストケースとして使うことができる。ただし設計ごとに表現方法が異なるため、集計は困難になる。

一般的なテスト管理ツール

  • テスト分析・設計をサポートしているテスト管理ツールは、一般的ではない*2

テストケース管理

一覧性

従来のスプレッドシート運用

  • テストケースが、詳細も含めて一覧化されるので、全体感がわかりやすい。

一般的なテスト管理ツール

  • テストケースごとに1枚の画面がある*3ため、全体感がわかりづらい*4

編集容易性

従来のスプレッドシート運用

  • 一括置換・コピペ・ 行移動・フィルタ・ソートなどが容易で、編集がしやすい。

一般的なテスト管理ツール

  • 複数のテストケースをまとめて修正する必要がある場合に手間がかかる。
  • 複数ユーザによる同時編集をしても、問題がない*5

属性の付与

従来のスプレッドシート運用

  • 必要な属性を自由に追加し、集計に使うことができる。Excel職人大活躍である*6

一般的なテスト管理ツール

  • テストケースに属性を追加したい場合、ツールがカスタムフィールドをサポートしている必要がある。

データの可搬性

従来のスプレッドシート運用

  • セル結合をしていると、テスト管理ツールへのインポートはいきなりハードルが上がる。

一般的なテスト管理ツール

  • スプレッドシートベースのテストケースや、他のツールのテストケースを、インポート/エクスポートすることができる*7

仕様とのトレーサビリティ

従来のスプレッドシート運用

  • 情報として持たせることはできる。

一般的なテスト管理ツール

  • チケット管理システムとの連動で、仕様とのトレーサビリティ管理ができる。

テスト設計とのトレーサビリティ

従来のスプレッドシート運用

  • 情報として持たせることはできる。

一般的なテスト管理ツール

  • 一般的には、サポートされていない*8

バージョン管理

従来のスプレッドシート運用

  • テストケース自体のバージョン管理がしづらい。

一般的なテスト管理ツール

  • テストケースはバージョン管理されることが多い*9。されない場合でも、テストケース実行時点のスナップショットは残っており、テスト実行時の内容が、その後のテストケースの修正の影響を受けることはないことが多い。

フルテストセット管理

管理容易性

従来のスプレッドシート運用

  • プロダクトのあるバージョンに対するテストのために、過去のテストケースをコピペして寄せ集めにしがちで、重複が多くなる。また、フルテストセット*10、「最新のテストケース一覧」という概念が成り立たない。

一般的なテスト管理ツール

  • 最新のテストケースが一元管理できる。

テストセット管理

管理容易性

従来のスプレッドシート運用

  • フルテストセット*11と同じ理由で、同じテストケースが別のものとしていろいろな場所に重複してしまう。

一般的なテスト管理ツール

  • フルテストセットから、特定の目的をもったテストケースの集まりを定義できる。これによって、「毎回行うリグレッションテスト」といったテストセットを、テストケースのコピペなしに構成することができる。
  • 構成したテストセットを、テスト実行サイクルに割り当てることができる。これによって、ひとつひとつテストケースを割り当てる手間が省ける。

テスト実行管理

テスト実行管理

従来のスプレッドシート運用

  • 「テストケースに対して実行は1回」という暗黙の前提があるため、複数回実行した場合の結果を適切に管理しづらい。結果、同じセルに「×→〇(2022/10/1)」といった記載を始めてしまい、集計を破壊する。

一般的なテスト管理ツール

  • 1つのテストケースに対し、テスト実行が複数回あることが前提のデータモデル。いつ、どのテストケースが、どういう結果だったかが実行ごとに記録できる。これまでパスしていたテストがいつから失敗しているか、といった遡りも容易。

進捗管理

従来のスプレッドシート運用

  • 進捗やグラフは自分で作りこむ必要がある。Excel職人がいれば、必要なグラフを柔軟に作り込むことができるが、メンテナンスが難しい。
  • 担当ごと、機能ごとといった切り口での進捗状況が把握しづらい。

一般的なテスト管理ツール

  • ビルトインで用意されたグラフや表はリアルタイムに集計され、すぐに使うことができる。
  • ビルトインで用意されていないグラフは使えない*12

タスク管理

従来のスプレッドシート運用

  • 担当者間で実行項目のタスク調整をしても、リーダーから作業量が見えにくい。

一般的なテスト管理ツール

  • リーダーが負荷と状況を見て、担当調整がしやすい。
  • 担当者間でタスクのやり取りをした結果も、リーダから把握しやすい。

インシデントとのとのトレーサビリティ

従来のスプレッドシート運用

  • 情報として持たせることはできる。ただし、「1つの実行に対して複数のバグ」といった状況に弱い。

一般的なテスト管理ツール

  • チケット管理システムとの連動で、バグとのトレーサビリティ管理ができる。
  • あるインシデントが、どのくらいのテストケース実行のブロックになっているか、といった情報が把握しやすい。

おわりに

 まだまだ不完全な表でしょうし、本当の「イマドキの」ツールはもっと進化しているのかもしれません。
 Googleスプレッドシートはコメントを受け付けているので、よかったらコメントください。

docs.google.com

Greater and Lesser Yellowlegs

*1:表をマークダウンでブログに書くのも何だか・・・となってためらっていたのですが、最近「スプレッドシート形式ならGoogleスプレッドシートで作ってリンク貼ればいいんだよ!」とわかったので、今回もその方法で

*2:というのは言い過ぎで、単にわたしが知らない。

*3:帳票形式でテストケースを管理するツールもある。

*4:チケット型テストケース管理でも、全体構成をツリー表示できることがある。ただしこの場合には、テストケースの名称から内容がある程度把握できることが必要。

*5:複数人でExcelを編集した結果、ファイルが破損・・・という悲劇、かつてはよく見られましたが、今ではそこまで悲惨ではないと思います。自動バックアップもありますし。

*6:いずれにしても、属性の追加をし過ぎると、他の管理方法との互換性は低くなる。

*7:テスト管理ツールへのインポートは、インポート元のフィールドと先のフィールドを、ユーザが対応づけることによって行うことが多いようだ。

*8:テスト設計のためのモデリングツールはある。

*9:バージョン管理をテストケースではなく、テストセットの単位で行うツールもある。

*10:ここでいうフルテストセットとは、「定義されたすべてのテストケースの集合」の意味。

*11:ここでいうテストセットとは、「特定の目的のために、テストケース全体(フルテストセット)の中から一部のテストケースを選択したもの」の意味。

*12:保持しているデータを組み合わせてグラフをカスタマイズできるツールもあるが、正直難しかった・・・。

『アナタはなぜチェックリストを使わないのか?』に答えられないからチェックリストを使うしかない

 信頼できる読み手がTwitterで言及しているのを見つけて読んでみました、『アナタはなぜチェックリストを使わないのか?』。
 期待通り、とってもいい本だったので紹介してみます。

 この本は、「複雑な事象」に対応するにあたって、シンプルなチェックリストがいかに役立つかを紹介しています。エピソードが豊富で、特に医療・航空・建設など、些細なミスが死に直結するような現場における実践からの洞察は、説得力に満ちています。

 ただ、以下のようなアオリはちょっとどうかと思います。

オバマ大統領も認めた著者が贈る全米30万部突破のベストセラー書!
「チェックリスト」の作成こそが危機管理の特効薬だ!

 「特効薬」ではないんですよね。
 本書でいうチェックリストは、とても地味だし、すべてをカバーするものではないし、常に発展途上のものです。それでもなお、目に見える効果があるというのです。

チェックリストのよくある問題点

 「チェックリスト」という言葉自体に、激しい嫌悪を感じる人も多いと思います。
 あれやるにもチェックリスト、これやるにもチェックリスト。セル結合のExcel、3桁レベルのチェック項目、謎の職印欄、よくわからない内容・・・(フィクションです)。

 チェックリストには、それ自体と、それを使う人間の方、両方に問題が出がちです。

チェックリスト自体の問題

  • 項目の抽象度のコントロールの難しさ。いろんな局面で汎用的に使えるものにしようとすると、ふんわりしすぎていて何をしていいかわからない内容になる。逆に具体的にしすぎると、個別の話にしか適用できない項目が山盛りになってしまう。
  • メンテされないことによる項目の肥大化、重複、陳腐化。

使う側の問題

  • チェックリストの項目はすべてを網羅しており、他のことは考えなくていいと考えてしまう。
  • チェックリストの記述は常に正しいと思考停止してしまう。
  • チェックリストの項目の背景にあることに注意しない。

 その結果「チェックリストは使えない」となって使わない、メンテしないの負のループ。
 心当たりはないでしょうか?

本書でいうチェックリスト

 本書でいうチェックリストは、そういうものではありません。
 本書第6章で、著者は明確にこう言っています。

チェックリストはマニュアルではない。すべての手順を詳細に説明するものではない。熟練者を助けるためのシンプルで使いやすい道具なのだ。素早く使えて、実用的で、用途を絞ってあるという特性こそが肝要だ。

 すべてを網羅したリストではなく、外してはいけないクリティカルなポイントを簡潔にまとめたもの
 それが本書でいうチェックリストなのです。

 パイロットのためのチェックリストは、チェックリストに「載せる」「載せない」それぞれについて面白い判断があります。

 まず、「載せない」もの。
 たとえ重要な手順であっても、プロのパイロットが忘れることが考えられないもの(たとえば「管制塔に連絡する」)は、意図的にチェックリストに含めないそうです。チェックリストはすべての手順を網羅するものではないので、載せても価値のないものはできるだけそぎ落とすのです。

 一方で、「載せる」もの。
 エンジンが停止した時のためのチェックリストには、エンジン再始動の方法が6つの手順に凝縮されているそうです。その1つ目の手順は、なんと「飛行機を飛ばせ」。あまりに当たり前に思えますが、パイロットはしばしば、エンジン停止の原因分析に集中してしまい、もっとも肝心な「飛行機を飛ばす」ことが頭から抜けることがあるのだと・・。

 著者はこうも言っています。

人々が手順を忠実に守らない理由の一つに、硬直化が怖い、というのがある。機械的にチェックを行っていたのでは現実に対処できなくなる、チェックリストばかり見ていると心のないロボットのようになってしまう、と思い込んでいる。だが実際は、良いチェックリストを使うと真逆のことが起きる。チェックリストが単純な事柄を片付けてくれるので、それらに気を煩わせる必要がなくなる*1

 難しい状況、変化が激しい状況にあっては、人間が迅速に決断をしていく必要があります。チェックリストは、それ以外のことに判断力・記憶力を使わなくてすむようにしておくためのツールなんですね。

ソフトウェア開発で使いどころはあるか?

 「注意すべきことを網羅的に整理したもの」ではないので、ソフトウェア設計とかテスト観点のレビューには、あまり合わないように思いました。
 本書に出てくるエピソードを読む限りは、以下のような場合に合うんじゃないかと思います。

  1. 重要かつリスクの高いリリース
  2. システム障害時の対応

 手術準備完了のチェックリストには、「手術台の上にいるのは正しい患者か」「手術するのは右側か左側か」という極めて基本的な項目があるそうですが、システムを操作する際の「ログインした環境は正しい環境か」なんて、そのままなんじゃないかと思います。

 ところで本書では、チェックリストの副産物として、2つのことを繰り返し強調しています。
 「コミュニケーション」「責任の分散」です。

 手術に臨む際のチェックリストには、「1分でもいいから全員が必ず話し合う」という項目があり、これが2つの効果があるそうです。

  • お互いの名前と役割を理解し合う。お互いの名前を知っているグループの方がチームワークがよい。
  • 最初に懸念を表明する機会を与えられると、当事者意識と責任感が高まり、その後も問題提起や提案をしやすくなる。

 各メンバーが、「からの指示通り動く作業者」ではなく、「成功に至るための責任者の一人」として振る舞えているかも、チームとしての成功に大きく関わることだと思います。

おわりに

 書評を見ると、「文章にまとまりがなく、長すぎる」といったものがあり、確かに否定できません。チェックリストうまく作る・使うための洗練されたレシピみたいなもの*2を求めている人には、このハードカバーは長すぎでしょう。

 ただこの本は「ノウハウ集」ではなく、「チェックリストの効果、それを普及させるたも経緯を追体験する」ような形で書かれており、ストーリーを追って読むものです。読み物なので、厚い割には意外なほどスルスルと読めるのですよ。

 この本から、チェックリストのあるべき姿を学び、自分の仕事のどんな場面で使えそうかを考えてみると面白いでしょう。

*1:少し、自動テストの発想にも似ている。機械的にできることは機械にやらせる。人間は人間にしかできないことに時間を使う。

*2:それに近いもの、「チェックリスト作成のためのチェックリストが巻末に載っている。

ソフトウェアテスト分野のFizzBuzz、「Myersの三角形問題」に学ぶ、テストについての教訓

 テストエンジニアの多くが一度は耳にし、解いたことがあるであろう「Myersの三角形問題」
 社内のソフトウェアテスト勉強会で、n年ぶりm回目で解いてみました。
 この10分ほどのトライを通じて、以下のようなことを再認識しました。

Myersの三角形問題とは

 Myersの三角形問題とは、J. Myers氏の書籍『ソフトウェア・テスト技法』で提示された問題です。

 『ASTER標準セミナーテキスト』から、内容を引用します。
 やってみたことのない方は、ぜひトライしてみてください。

<問題>
以下のプログラムをテストするのに十分と思われる一連のテスト内容(何を確認するか?)を書いてください。

このプログラムでは、ユーザーが3個の整数を入力します。
この3個の値は、それぞれ三角形の3辺の長さを表すものとします。
プログラムは、三角形が、不等辺三角形、二等辺三角形、正三角形のうちのどれであるかを決めるメッセージを出力します。

 一見、シンプルな問題。テストケースなど簡単に導けそうに思えるかもしれません。
 ですがあらためてこの問題を解いてみると、以下の3つのことを再認識できました。

1. 仕様の正確な記述は、とても難しい
2. シンプルな仕様のテストがシンプルとは限らない
3. テストすべき観点やケースの唯一解はない

 順に、説明していきます。

1. 仕様の正確な記述は、とても難しい

 この問題を見て、「そもそも仕様が曖昧なのでは?」と感じる人もいると思います。
 勉強会参加メンバーの一人は、「三角形の定義」から始めて、

ここでいう三角形は、ユークリッド空間における三角形を指すのか?

というところから確認していました。わたしは、こんなこと考えてもみませんでした。

 もちろん、何から何までクリアに、誤解の余地なく記述することはできないでしょうし、過剰だとも言えるでしょう。
 そうはいっても、テストを検討するうえで必要な部分は明らかにしていく必要があります。仕様検討とともにテスト設計を始めることで、仕様をより詳細・具体的に書き下して、両者の認識を合わせていくことができるでしょう。

 それでも、仕様を考える人とテストを考える人、両者が無意識に前提としていることは、議論もされないかもしれません。そしてその前提は、ユーザの前提とは違っているかもしれないのです。

2. シンプルな仕様のテストがシンプルとは限らない

 三角形問題の著名人による解が、辰巳敬三さんのブログで解説されています。テストケースの数は、4個という人もいれば、185個という人もいるそうです。

a-lifelong-tester.cocolog-nifty.com

 また、山浦恒央さんの連載記事*1では、16個のテストケースを提示しています。

monoist.itmedia.co.jp

 わたしの解を山浦さんの解と比べてみると、以下の観点を漏らしていました。

  • #9「2辺の和<残り1辺が長い」はあるけれど、#10「2辺の和=残り1辺が長い」がない。
  • #7「小数2.5」はあるけれど、#8「小数5.0」がない。
  • #14「入力しない」がない。

 まあぶっちゃけ・・・、けっこう恥ずかしいのを落としてますよね・・・。
 さらに先の勉強会メンバーは、こんな観点を教えてくれました。

  • 数式、たとえば「1+2」は、「3」と解釈されて処理されないか。
  • 数式が解釈される場合、逆ボーランド記法「2 3 +」も解釈されないか。
  • eは自然対数として解釈されないか。
  • 「010」が、8進数で「8」と(Java的に)解釈されないか。

 そしてこのような面白い観点を出してくれたメンツをしてなお、「ユーザが許容できる時間内に結果が返ってくるか」「入力しやすい画面になっているか」といった非機能的な観点はあまり出なかったのです。

 このように、誰でも理解できるような単純な仕様ですら無数の観点があるし、人は(特にわたしは)その観点を見逃してしまいます

3. テストすべき観点やケースの唯一解はない

 このように無数の観点があるなかで、どの観点を選び、その観点からどのようなテストケースを選ぶか。
 これは「ソフトウェアテストの7原則」の言う通り、「テストは状況次第」なのですよね。
 JSTQBのシラバス*2から引用します。

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる。

 ユーザが求めていることは何か。どこまでの品質を求めるか。バグによりどんな悪影響が考えられるか。といった外的な要素もあれば、
 入力値の制約はされているのか。どんな言語を使っているか。プログラマーが不安に思っているのはどこか。といった内的な要素もあります。

 状況に依存しないただ一つの解はない。
 その中で、合理的でみんなが納得できるテストを選ぶための活動が、テスト分析とテスト設計です。

 『ASTER標準セミナーテキスト』で、Myersの三角形問題は、テスト設計の解説の導入部分として用いられています。シンプルながらやっぱり、含蓄の多い問題だなあとあらためて思いを深めた次第です。

 しかし「入力しない」を漏らしたのはダメすぎる・・・(一生悔いてる)。

Turner Margate

*1:『ソフトウェア技術者のためのバグ検出ドリル』の元ネタになっています。

*2: 『ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02』