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

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

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』

有志と #ソフトウェアテスト読書マップ を作りました!

 2022年9月9日にこんなツイートをしたところ、

 「一緒にやってもいいよ~」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました!
 みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。

 ということで、以下に公開します!

docs.google.com

 「閲覧者(コメント可)」というアクセス権を設定していますので、ご覧になっていただいて、気になった点はコメントいただければと思います。

ソフトウェアテスト読書マップ

 順番が逆ですが、この読書マップについて説明します。

目的

 素晴らしいことに、ソフトウェアテストの書籍・資料はそれなりの数が出ています。一方で、「どの本にどんなトピックが、どのくらい書かれているか」は、読んでみないとわからないという難しさもあります。

 このマップは、ソフトウェアテストを学ぶ人が、「どの本に何が書いてあるか」をざっくりつかめるようにすることを目的としています。
 もちろんわたし自身も修験者の一人として、このマップから「次」を探したいと思っています。

使い方

  • まずは、横軸を見ていただくのがいいと思います。一言に「テスト」といっても、いろいろなトピックがあることが、あらためてわかります。
  • 色塗りされているセルの多さと色合いから、それぞれの本が「広く浅く」なのか「狭く深く」なのかがわかると思います。テストの概観を学ぶには前者から、特定のトピックを学ぶには後者から選ぶことができます。
  • 特定のトピックの理解を深めたい場合は、「色合いが似ていてレベルが違う本」を読んでいくとよさそうです。ただ後述の通り、現状レベル分けにサワヤカな定義がないため、もう少し改善したいと思います。
  • 協力いただいた方のTwitterアカウントは、列Eにあります。

注意点

このマップは、「永遠のベータ」ってやつです。

  • 横軸は、JSTQB FLシラバスを参考に項目を作った後に、レビューや自動テストなどを追加しています。軸として一貫していなかったり、MECEでなかったりする点はご容赦ください。
    「こういう項目もあった方がいい」「少しブレイクダウンした方がいい」といったご意見は歓迎です。
  • 「レベル」は、参加メンバーのそれぞれの主観もあり、あまり安定していません。もうちょっとブレの小さい定義をしたいところですが、今後の課題と考えています。
  • フィルタ機能を使いたくなるのですが、フィルタ適用するとタイトルカラムが縦長になってしまうので、とりあえず外しております。。

お願い

  • コメントを入れられる設定になっていますので、フィードバックいただけると幸いです。すぐに対応できるかは別として・・・。
  • 「ここにない本を読んだことがあるので追加したい!」という方は、メンションくださいませ。

今後の展望

 このマップは随時アップデートしつつ、マップをベースに、次は #ソフトウェアテスト読書チャート として、「どういう流れで本を読んでいくと学びやすいか」が作れるといいなあ。「マップ」より難易度高いと思いますが・・・。

 初期バージョンに協力してくださったみなさんには、本当に感謝です。
 #ソフトウェアテストの7原則 もそうですが、瞬発力で挑むこの手のマイクロプロジェクトはまたやりたいな。楽しい・・・。

www.kzsuzuki.com