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

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

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

 Veriserveさんが、テスト設計技法を使うためのWebサービスをリリースしたと聞いて!
 GIHOZ(ギホーズ)というそうです。

www.veriserve.co.jp

 さっそく触ってみましょう。
 推奨ブラウザがわからないので Edge 87.0.664.41 で試してみます*1

GIHOZを動かしてみる

 初期画面です。
 真っ白だと不安になりますが、そこに「+」ボタンがあると急に安心しますね。これを押せば何か始まるだろうという。

f:id:kz_suzuki:20201121201331p:plain

 「+」ボタンを押すと、現時点でサポートされている4つのテスト設計技法の選択画面に移ります。
 現時点では、以下の4つのテスト技法がサポートされているようです。

  • ペアワイズテスト
  • デシジョンテーブルテスト
  • 状態遷移テスト
  • 境界値分析

f:id:kz_suzuki:20201121201229p:plain

 今回は、境界値分析から行ってみましょう。
 題材として、ブログでも扱った『ソフトウェアテスト技法練習帳』の「1.12 配達便の料金体系」で適用してみることにします。

 問題の概要はこちらもご覧ください。

www.kzsuzuki.com

テスト設計モデルの作成

 境界値分析の初期画面はコチラ。

f:id:kz_suzuki:20201121201235p:plain

 まずテスト設計モデル*2の名前を入力します。
 「数直線」はプレースホルダーっぽく見えますが、キャプションです。

 一瞬、何から始めればいいか迷いますが、「変数の追加」でしょう。
 問題に合わせて、荷物の「大きさ」から入力していきます。

f:id:kz_suzuki:20201121201240p:plain

 「値の増減幅」で、立ち止まってしまうかもしれませんね。
 この問題では、大きさと重さという連続的な値を扱っており、精度を考える必要がありそう*3ですが、ひとまず「1」としています。

f:id:kz_suzuki:20201121201244p:plain

 いや、まだ入力途中だから怒らないでくれw

 「確定」すると、数直線が描かれます。
 この薄青の帯の上にカーソルを当てると、そこに境界値を打てる。

f:id:kz_suzuki:20201121200221p:plain

 なるほど、まず最小と最大を指定して*4範囲の全体を描いたうえで、その範囲内に境界値を刻んでいくという手順なのですね。
 わたし自身は、下から順に範囲を考えていくという手順をとっていることに気づきました。そうか、こういう手順もあるのか。

 仕様に沿って、「境界を追加」*5しています。

f:id:kz_suzuki:20201121213427p:plain f:id:kz_suzuki:20201121201256p:plain

 なお、帯の0と60の間を選択して、「80」を入れようとすると、エラーになります。

 どこをクリックしても、入力に合わせて適切な位置に絵を描くという仕様がいいか、あくまでも選択した領域に対応した値のみを受け付けるという仕様がいいか。
 前者の方が便利そうですが、入力ミスを防ぐという意味では後者の方がいいのかも。何せ境界値分析は、「境界でバグりやすい」という傾向を前提にした技法なのですから、入力ミスによる誤った設計も予防できるとよさげです。

 荷物の「重さ」の方も入力して、パーティションの名前も編集すると、以下のようになります。
 パーティションの有効無効も切り替えられます。グレーの帯部分が、無効パーティションです。

f:id:kz_suzuki:20201121201300p:plain

 なお、境界を修正する方法がわかりません。

f:id:kz_suzuki:20201121201328p:plain

 「境界を削除」したうえで、再度追加する仕様でしょうか。
 最小値と最大値は削除もできなさそうなので、変数追加の最初の時点で注意しておく必要があるかも。

テストケースの導出

 ともあれ、これでテスト設計モデルができました。
 「同値パーティション一覧を表示」ボタンで、各パーティションと代表値が表形式で導出されます。

f:id:kz_suzuki:20201121201305p:plain

 さらに「テストケースを生成」ボタンで、同値分割と境界値分析のテストケースが生成されます。

f:id:kz_suzuki:20201121201309p:plain f:id:kz_suzuki:20201121201313p:plain

 一見編集不可のテーブルに見えますが・・・、

f:id:kz_suzuki:20201121201318p:plain

 編集できます*6
 モデルから導出できない部分は手動で埋めて、テストケースとする *7わけですね。

 なお、導出&編集したこのテーブルは、CSVで出力することができます。

f:id:kz_suzuki:20201121201323p:plain

所感

 GIHOZの「境界値分析」機能を使ってみました。

 テスト設計モデルからテストケースを導出するこのようなツールを使うことで、テスト設計のモデルとテストケースを常に同期させることができます。そこから得られるメリットは、たとえば以下です。

  1. プロダクトの仕様変更を、モデルを通してテストケースに反映することができる
  2. テストの十分性を、個々のテストケースではなく、モデルから検証することができる

 状態遷移表、ペアワイズ法、原因結果グラフなど、各技法に特化したツールもありますが、GIHOZのように複数のテスト設計技法を扱えれば、テスト設計モデルを1つのツールで管理することができます。  モデルのバージョン管理他システムとの連携など、期待が広がるサービスですね!

 他の3つの技法についても、触ってみたいと思います。

*1:Firefox 82.0.3でアクセスすると、

ご使用のブラウザでは正常に動作しない可能性がございます。推奨ブラウザは こちら

となりました。

*2:GIHOZでは「テスト設計モデル」という言葉は出てこないのですが、わかりやすさのために以降、テストケースを導出するためのモデルのことをこう呼びます。

*3:『ソフトウェアテスト技法ドリル』ではこのような場合、幅を仮に「d」(differenceのことでしょう)と置いて、具体的な値は別途記述する、という方法を紹介しています。

*4:最大と最小は未入力にすることも可能です。

*5:「境界値」ではないところに、コダワリがありそう・・。

*6:モデルから導出した情報と、ユーザが補完した情報は、色分けした方がわかりやすい気がします。

*7:『練習帳』のこの問題では、大きさと重さを合わせて「サイズ」を判定しているので、テストケースと同値分割・境界値分析結果をマージしていくことになります。

夜型から朝型に切り替えて、朝活を習慣化するための諸々のお話

 こんにちは、Morning Activist*1 の鈴木です。

 子育て世代のエンジニアにとって、集中して本を読んだり何かを学んだりする時間の確保って、大きな悩みの一つですよね。
 特にこどもが小さいうちは、「寝かしつけ」という恐怖のタスクがあります。すっと寝てくれればいいのですがそううまくはいかず、むしろ自分の方が先に寝入ってしまうこともしばしば。仮に成功しても、自分もだいぶ眠くなってしまって、新たな活動をする気力も落ちていることが多いです。
 こどもがある程度(幼児くらい)大きくなっても、親がベッドを抜け出すと「どこ行くの?」となってしまい、やっぱり「夜に活動する」というのは厳しいもの。

 というわけで、朝活です。
 わたしも学生時代から生粋の夜型人間だった(受験および麻雀およびバイト)ので、「朝早く起きて何か行う」なんて不可能だと思っていました。が、ちょいちょい工夫を取り入れることで何となく形になってきました。
 この記事では、わたしの朝活のやり方について、ルーティンアイテムアプリタスクマインドセットの五つに分けてお話します。

前提

 わたしの一日の終盤は、夕飯を食べて、こどものお風呂・歯磨き・爪切り、寝る前の読み聞かせ、布団の中で少し会話して寝る、という流れです。共働きで夕飯が遅めなので、消灯は22時過ぎ。
 起きる時間は、6時間後の4時15分に設定しています。この時刻に起きられれば、6時半過ぎの朝食までの2時間くらいを自分のために使うことができます。

ルーティン

 夜寝る前から起きて朝活を行うまでのルーティンを決めておくのは、きっとよいことです。
 子供の頃から親や先生に言われてきた決まり文句って、中年になってから効いてきませんか?
 「規則正しい生活」は、その代表格です。

寝る前のストレッチ

 筋トレ、ストレッチ、ランニング。
 これらは30代までは一切興味がなく、酔狂な人たちの求道的な趣味と捉えていました。しかし40代を過ぎてから俄然健康志向おじさんになり、生活の中に運動が取り入れられるようになりました。
 covid-19による自粛期間が始まって2か月ほどで、両親が奇跡的に入手してくれたリングフィットアドベンチャーは、今もほぼ毎日続けています。

 ただ・・・、
 就寝前の運動とか、あるいは入浴って、いい感じに睡眠にいざなってくれそうなのですが、そうでもないみたいなんですよね。逆に目を覚ましてしまいそう。

www.nishikawa1566.com

 じゃあってことで、就寝直前にストレッチをすることにしています。
 わたしは肩・背中のコリもひどいので、快眠とコリ解消の両方を狙っています。
 参考にした動画はコチラ。

www.youtube.com

 この動画はストレッチポールを使ったものです。動きを覚えて、10分かけずに終わらせています。
 「深い呼吸に合わせて行うことで副交感神経が優位になり」ます。いや、実際副交感神経って何かわかってないのですが、「ストレッチをすれば眠りにつきやすくなる」という思い込み・プラシーボ効果で、すっと眠れるようになりました。

寝るまでの思考

 「朝うまく起きられたら、何しよう、あんなこといいな、できたらいいな」と、起きるのを楽しみにするようなことを考えておくのがよさそうです。
 「あれもやらなきゃ、これもやらなきゃ・・・」という義務的思考だと、全然楽しくありませんし、そもそも眠れません

起床

 知っていましたか? 朝活を実現するにあたって一番の難関が、「起きる」ことなんです。
 目は覚めるけれど、「あと100数えたら起きよう」と思っているうちに100分経ってしまった・・・。というのはよくあることです。わたしは。

 この課題に対するソリューションは、もう「自分に克って体を起こす」しかない

 ほんとかどうか知りませんが、西郷隆盛の起床術とかいうのがあるらしいです。起きた瞬間に布団をけ飛ばすという。

woman.excite.co.jp

 さすがにこれはできないので、わたしは「うだうだ考えずにベッドから降りる」ようにしてます。ベッドから出ればあとは何とかなります。失敗も多いですけど。

起きてからのコーヒー

 起きてそのままキッチンにいって、コーヒー8・豆乳2くらいのソイラテを作ります。
 カフェイン中毒というわけではないのですが、部屋がコーヒーの香りに満ちていくと、目が覚めていくように思います。また、起きてからのすぐの行動が決まっていると、体もそれについてきてくれる気がします。

 コーヒーを飲むとおなかが空くので、ナッツとチョコを用意します。朝活しているので、罪悪感がまったくありません
 なお冬場は、豆乳とチョコのカケラをカップに入れて温めてからよく混ぜ、そこにコーヒーを注いで、チョコソイラテにしてます。最高においしいです。

15分くらいのウォーミングアップ

 コーヒーとおやつを伴って机に向かっても、いきなり勉強っぽい本を開くとしんどいです。
 最初の10~15分は、「それほど集中しなくてもできること」で脳を目覚めさせています。たとえばたまった「あとでよむ」を消化するとか、雑誌を読む*2とか。

 なお、スマホは遠くにおいておいた方がいいです。Twitter中毒の人は、スマホが無限に時間を溶かします。

時間を区切っての取り組み

 「時間を区切る」は必須ではないのですが、やりたいことがいろいろある人は、適切な時間で区切るといいです。
 逆に集中力がいまいちな人、すぐにTwitterを見に行ってしまう人(わたしです)も同様に、「この時間までは集中する」というのを設けると、少し集中力が持つようです。

 有名な「ポモドーロテクニック」は、割り込みタスクのコントロールの仕方などしっかりした仕組みが整っているのですが、まずは時間を区切るだけでもいいと思います。なんせ、朝活ではあまり割り込まれないので*3

 なおこちらの本は、ポモドーロ・テクニックの創始者が書いたもの。シンプルな仕組みが丁寧に説明されています。

朝食後のバッファ

 朝食後、子供を学校に送り出したり保育園に連れていったりした後、始業時刻まで1時間弱あります。ここは「おまけ」と考えて、やることを詰め込まないようにしています。
 やる気がみなぎっていたら、それをやる。その日の仕事に早く取り掛かりたければ、そうする。眠ければ寝る。

 わたしはショートスリーパーでも何でもなく、睡眠6時間だとやはり眠いことが多いので、この時間帯は「軽く読める本を読みながら眠る」ことが多いです。
 通勤必須だと選択肢が狭まってしまうのが難点ですが、思い切ってグリーン車を選ぶのもアリだと思います。

昼食後の昼寝

 「ランチこそ人脈を築く最大のチャンス!」的な発想もあるのですが、わたしはこの時間は、20分ほどでご飯を食べてから、寝てます。
 在宅勤務になってからはベッドで寝ようとしたのですが、食べたばかりで布団に入るのに抵抗があって、今では無印のでかいクッションに寄りかかって寝てます。あまり変わらないけれど・・。

 こんな風に、「朝活のために睡眠時間は割と短めなんだけど、必要に応じて睡眠を補える」スタイルにしておくと、眠ければ寝られるし、そうでなければ活動できるし、という状態を維持できます。健康にいいかは知らん。

アイテム

 わたしの朝活習慣をサポートしてくれるアイテムに、以下のようなものがあります。

ストレッチポール

 だいぶ長い間クローゼットの肥やしになっていたのですが、ストレッチ習慣が戻ってからは毎日使われています。本人も幸せそうです。

Garmin

 ランニングを始めてしばらくして、妻が誕生日にプレゼントしてくれたスマートウォッチです。

 生活や運動の記録にもいいのですが、「目覚ましが手元で震える」ことのよさに気づきました。
 目覚まし時計やスマホのアラームの音は他の人も起こしてしまうし、振動モードにしてもけっこううるさいんですよね。腕時計が手元でブンブンするのは、「本人は気づき、他の人は気づかない」最適な起こしっぷりです。
 なおスヌーズにも対応しているので、いぎたないわたしたちにもぴったりです。

タブレット

 デジタルイミグラントのわたしは、パソコンで長い記事(特に英語)を読むことができません
 気になった記事はPocket(後述)に入れておいて、タブレットを机の上において、雑誌のように読んでます。指でスクロールする方が、キーボードやマウスによるスクロールより性に合います。
 とはいえ、Surfaceのタブレットモードは正直使いづらいので、いいタブレット欲しいです・・・。

 顔を上げて読みたいときには、タブレットスタンドを使ってます。これは会社のスマホで会議やるときにも使ってます。

ナッツとチョコ

 好きなものを選べばいいと思いますが、わたしは「2週間分のロカボナッツ」と、明治の「ザ・チョコレート」が大好きです。ザ・チョコレートは、商品を一新したようで、好きな味が買えなくなってしまった・・・。

明治 ザ・チョコレートビターアソートパウチ 40g

明治 ザ・チョコレートビターアソートパウチ 40g

  • 発売日: 2019/10/01
  • メディア: 食品&飲料

アプリ

 なぜか赤いアイコンばかりになってしまった。

Relax Melodies

 睡眠補助アプリです。

Relax Melodies: Sleep Sounds

Relax Melodies: Sleep Sounds

  • Ipnos Software Inc.
  • ヘルスケア/フィットネス
  • 無料
apps.apple.com

 入眠に適したいろいろな音、メロディを流すことができます。また、それらを組み合わせてミックスを作ることができます。
 ただ家族みんなで一緒に寝ているので、枕の下にスマホを置いて、自分にしか音が届かないようにしています。

Apple Music

Apple Music

Apple Music

  • Apple
  • ミュージック
  • 無料
apps.apple.com

 音楽サブスクリプションサービスなら何でもいいのですが、「朝活にかける感じの曲」を探すのも楽しいものです。
 わたしはApple Musicの「夜間飛行」というプレイリストなどを使っています。朝なんですけどね。

music.apple.com

Focus To-Do

 ポモドーロ・テクニックを行うためのツールです。

Focus To-Do: ポモドーロ技術 & タスク管理

Focus To-Do: ポモドーロ技術 & タスク管理

  • Shenzhen Tomato Software Technology Co., Ltd.
  • 仕事効率化
  • 無料
apps.apple.com

 25分集中、5分休憩。2時間あれば、4ポモドーロできます。そこまで詰めなくても、3つできれば上等でしょう。
 ポモドーロ用のツールもたくさんあるようですが、見た目が美しいこのアプリがわたしは好きです。アナログ時計的な効果音も入れられます。

Todoist

 タスク管理ツールです。

apps.apple.com

 やりたい・やるべきことは、とにかくここに放り込んでおきます。
 GTDみたいなことをやりたければまた別のツールが合うのかもしれませんが、今のところこれに落ち着いてます。

Pocket

 いわゆる「あとで読む」のアプリです。

Pocket

Pocket

  • Read It Later, Inc
  • ニュース
  • 無料
apps.apple.com

 Twitter、RSSフィードなどいろんなところから入ってくる、だけど今は読めないから後で、というネット情報はここに放り込んでおきます。Webアプリ版は正直、昔の方が使いやすかった気がする・・・。

タスク

 さて、確保した時間で、「何を」「どう」やるのがいいでしょうか。
 朝活で行うタスクについて、わたしの方針は、大きく3つあります。

デフォルトを決めておく

 朝の時間を使ってやりたいことが明確な人は、それをやればいいと思います。
 そうじゃなくて、とりあえずは漫然と、いろいろ勉強したいな~と思っている人は、曜日ごとに「やることのデフォルト」を決めておくのがオススメです。

 わたしの場合、たとえば月曜はITセキュリティ、木曜は英語、みたいに、勉強のテーマを設定しています。あくまで目安なんで、守らなくてもいいのですが、デフォルトがあると動きやすいです。

緊急のタスクを割り当てない

 朝活に合うのは、『7つの習慣』でいういわゆる「第2領域」(緊急でないが重要)のタスクだと、わたしは思っています。

 逆に緊急のもの、たとえば「明日の始業時刻までに間に合わせなければならない」ようなタスクを朝活の時間に賭けるのはリスクが高すぎます。てか眠れなくなりますよ。
 朝活には、直近に期限のない、前向きに取り組めるものを充てましょう。

 「領域」についてはこちらの記事がわかりやすいと思います。

jmatsuzaki.com

期限ドリブンにしない

 「先に全体期限があって、そこから逆算してタスクごとの期限を決めて取り組む」のは立派だと思いますが、仕事と同じ感覚を朝活にも持ち込むのは、わたしはつらいです。
 先にタスクを積み上げておいて、それに淡々と取り組む方が気楽なので、タスクドリブンにしています。
 もちろん資格試験のように、先に期限が決まっているものは、そうもいかないかもしれませんが。

 これはTodoistを使って、PyQでのPython学習を管理していた頃の名残りです。

f:id:kz_suzuki:20201104174656p:plain
todoistのキャプチャ

 チェックマークを入れていくのは、楽しいものですね。

マインドセット

 最後に、マインドセット。
 朝活を継続するために備えておくべきマインドセットが一つだけあります。
 それは、

自分を甘やかす、許す。

ということです。

 朝活は、始めた頃はもちろん、慣れてきてもなお、「起きられなかった」「起きたけどずっとスマホでTwitterを見てた」となりがちです(わたしは)。でもそこで「結局できない自分」と自罰的になる必要はありません。

 むしろ、「できない日がデフォルト」と考えましょう。
 朝活を必須のこととして捉えると、できない自分が残念になって、やる気もなくなります。
 朝活はオプションなのです。できた日が◎なのであって、できなかった日が×ではないのです。
 「朝活は自分に合わない」とすぐにやめてしまうのではなく、たとえ1か月のあいだ一度もうまくいかなくても、「今はスランプ、そのうち終わる」と考えておけばいいです。

 わたしも実際のところ朝活完全成功率は50%にも満たないです。
 ただもともと自分に甘いので、6時半より10分でも早く起きられれば「朝活成功」、テキストを半ページでも開けば「朝活成功」です。
 よってもって、わたしは朝活成功者です。

おわりに

 さくっと書くつもりが、長くなってしまいました。

 朝活、慣れるまではつらいのですが、うまく回りだすととてもいいです。
 特に休日、しっかり朝起きて好きなことをやって、そのあとランニングして朝食食べてもまだ8時!なんてなると最高の気分になった後、昼過ぎまで寝ていた学生時代の自分を思い出して絶望的な気分になります。

 みなさんもぜひ朝活仲間になって、Twitterでの朝活アピールにいいねし合いましょう!*4

a quiet morning"a quiet morning" by Marc.van.Veen is licensed under CC BY-NC-SA 2.0

*1:まったく流行らなかった呼称です。

*2:dマガジン、とても良いサービスです。安すぎて雑誌の人たちに申し訳なくなるほど。

*3:ただし、ポモドーロ・テクニックでいうところの「内的要因で起こる中断」は起きる。たとえば「何となくTwitterが気になる」。

*4:結局Twitterを開いている。

しゅっちゅう忘れるピボットテーブル操作メモ

Tables"Tables" by Jurgen Leckie is licensed under CC BY-ND 2.0

 わたしは今でもExcel大好きおじさんなのですが、「何度やっても忘れてしまう操作」というのがあるわけで。
 特にピボットテーブルで起こり勝ちで、そのたびにググるのも面倒なので、ここにメモしておきます。

ピボットテーブルでハマる①データにないフィールド値の消失

 なんでもいいのですが、テストで出たバグのどっかからエクスポートしてきて、Excelでちょいちょい集計をしたいとしましょう。
 フィールドには「連番」「発生日」「機能」「重要度」があるとします。
 こんな感じ。

f:id:kz_suzuki:20201017155309p:plain

 これを、機能×重要度のピボットテーブルにしてみましょう。
 3つの機能、5つの重要度があるので、15個のデータセルが出てきます。

f:id:kz_suzuki:20201017155313p:plain

 ここで、機能Aを非表示にしてみましょう。すると・・・?

f:id:kz_suzuki:20201017155317p:plain

 このように、重要度「Pessimal」と「Show-Stopper」が表示されなくなってしまいます
 機能Bと機能Cにはこの重要度をもつデータがないので、自動的に非表示になるのですね。
 なお機能C×重要度Endsvilleのデータもないのですが、機能B×重要度Endsvilleのデータはあるので、ピボットテーブル上では前者はゼロ件(空白)として表現されています。

 重要度のカテゴリーは、機能をフィルタしてもしなくても、一定にしておきたいですよね。
 これを解決しましょう。

 まず該当するフィールドを右クリック。
 今回の場合は「重要度」の列の上です。集計値の入ったセル上での右クリックではダメです。

f:id:kz_suzuki:20201017155324p:plain

 フィールドの設定画面の、データのないアイテムを表示するチェックボックスをチェック。

f:id:kz_suzuki:20201017155330p:plain

 無事、表示されました。

f:id:kz_suzuki:20201017155335p:plain

ピボットテーブルでハマる②なぜか残っているフィールド値

 ①のデータのないアイテムを表示するでよく出くわすのですが、「データセット上にないフィールド値」が亡霊のように現れることがあります。
 こんな感じ。

f:id:kz_suzuki:20201017155229p:plain

 「亡霊」という重要度をもつデータは1つもないのに、現れてしまいます。
 これは、「過去のデータにはあった重要度」なんですよね。ピボットテーブルはこれを覚えているようです。「テーブル上にデータがなくなっても、カテゴリとしては残しておきたい」といった需要に応えるものと思いますが、基本的には「ゴミ」であることが多い。

 以下の手順で消しましょう。
 ピボットテーブル オプション画面のデータ ソースから削除されたアイテムの保持-1 フィールドに保持するアイテム数で「なし」を選択し、ピボットテーブルを更新する。

f:id:kz_suzuki:20201017155234p:plain

 消えました。

f:id:kz_suzuki:20201017155239p:plain

ピボットテーブルでハマる③日付なのに日付軸っぽくないピボットグラフ

 次に、元のデータセットを日付と機能のピボットテーブルにしてみます。

f:id:kz_suzuki:20201017155243p:plain

 これを横軸日付のピボットグラフにして、バグ発生のトレンドを見てみましょう!

f:id:kz_suzuki:20201017155247p:plain

 ・・・え? いや、まあそうだけど。確かに10/6のデータはないからゼロ件なんだけど、もっとこう、日付らしく並ばない? 10/4~10/5の間隔と、10/5~10/9の間隔って、違わない?
 なおこれは、グラフの設定で横軸を「日付軸」にしても改善されません。

 ここで①の手順データのないアイテムを表示するを行います。すると、ヤバいことが起こる。

f:id:kz_suzuki:20201017155251p:plain

 存在する日付すべての行が現れてしまう
 もちろん、超過去と超未来は丸めてくれているけれど・・・。

 もう少し何とかしてあげしょう。
 発生日フィールドを右クリックし、グループ化

f:id:kz_suzuki:20201017155255p:plain

 各フィールドで、いらない部分をフィルタしていきましょう。
 今回は10月と11月だけを見ればよさそうなので、「月」で絞る。

f:id:kz_suzuki:20201017155243p:plain

 いい感じのピボットテーブルになって・・・

f:id:kz_suzuki:20201017155304p:plain

 グラフも、バグゼロの日がちゃんと表示され、傾向がわかるようになった!

おわりに

 完全に自分用のエントリーでした。
 3つ目のは特に、VLOOKUP 関数使えば?という異論はあるでしょうけど、わたしはピボットテーブル派なんですよ!

探索的テストとスクリプトテストを対比するのはミスリードかもしれない。#JaSSTOnline

Forked Lightning

 JaSST Onlineで、ネモさんの探索的テストセッションを観ました。

jasst.jp

 他の人の探索的テストを見る機会ってあまりないので、とてもよいですね! ネモさんの思考の過程を見るのも楽しいし、他の参加者の方が発想を次々に投げ込んでくるのもとても良い。面白いセッションでした。オンラインの不自由さを逆手に取った企画で、とても好きです。

 さて、今日のポエムです。
 思いつきの吐き出しに過ぎないので、箸休めと思ってください。

テストの2つの目的

 以前、ISTQBで定義されている「テストの目的」について書きました。

www.kzsuzuki.com

 今では7個もあってなかなかややこしいのですが、わかりやすいのは、「バグを見つけること」と、「品質の程度を把握すること」の2つだと思います。記事の最後にある2011年版の記述でいうと、それぞれ「Finding defects」「Gaining confidence about the level of quality」ですね。本記事ではそれぞれ、目的A・目的Bと呼びます。

 この両者でわたしが重きを置いているのは目的B、「品質の程度を把握すること」
 これがこの記事の大前提で、バイアスかかっていることをお含みください。

 さて、目的A「バグを見つける」と、目的B「品質を把握する」で、テストはどう違ってくるでしょうか。
 端的に言うと、前者は「リスクの高いところ、怪しいところを狭く深く狙う」。後者は「提供する機能すべてを、広く浅く拾う」。 ってことじゃないですかね。
 もちろん前者であっても、ある部分は少しもテストをしないということはないでしょうし、後者であってもリスクに応じた重みづけはするので、あくまで傾向です。

テストの目的と探索的テスト

 探索的テストって、前者の目的A、つまりバグを狙っていくことを押し出したスタイルですよね。
 対象のソフトウェアを触りながら怪しいふるまいのしっぽをつかんで、そこを攻めていって、バグを叩き出す。 これは価値のある成果だと思います。

 一方、後者の目的B、品質を把握するという観点から見ると、どうでしょう。

 探索的テストはしばしば、成果の説明が難しいと言われますが、その理由は「システマティックでない(ように見える)ため、何を保証しているかの説明が難しい」ということだと思います。たくさんバグを検出するという目的Aを果たせても、目的Bについてうまく語れない。

 では、目的Bから見た探索的テストの価値とは何でしょうか。
 いくつかあるとは思いますが、重要な一つとして「テスト観点の導出」があるでしょう。
 仕様書や、devチームとの会話からでは得られなかった、実物を触ったからこそ得られたインスピレーション、テスト観点。

 探索的テストのセッションの時間は限定的です。思いついた観点すべてを、セッションの中では消化しきれません。むしろ、実際にやれたことより、新しく追加された「やりたいこと」の方が多いかもしれません。
 セッションが終わったら、新しく得られた観点をできるだけ網羅できるようにテスト設計を行い、テストケースとしてテストセットにフィードバックしていく*1。これを、evolvable test design(進化可能なテスト設計)と呼びます*2

 目的Bに観点に立つと、品質把握の精度を上げるための観点が得られたことの方が収穫で、バグを見つけたことはその過程での(嬉しい)副産物、という位置づけだと捉えることもできるのではないでしょうか。極端かしら。

探索的テストとスクリプトテスト

 ところで、探索的テスト以外の「普通の」スクリプトテスト(scripted test、手順のあるテスト)で、こういうことってしないでしょうか。そんなことないですよね。

 わたしのチームでは、あるテストケースを実行した際に気の付いた点、別途確認したいと感じたことを書き残すようにしています。ですので、テストケース1件を消化したら、0.5件分の潜在的テストケース*3が生まれているような感じになります。
 その意味では、スクリプトテストでも、探索的テストを同じことをしているんですよね。
 つまりこの視点では、手順の有り無しは本質的じゃあない

 じゃあ何が違うか。
 違いは、テスト実行中に観点を見つけるために通れる道の多さ、なんじゃないですかね。

 スクリプトテストの書き方・粒度はいろいろありますけれど、インプットと期待するアウトプットはまあ、決まってますよね。通れる道は、1本。せいぜい2~3本でしょうか。
 探索的テストは、何をインプットするかはその場で決まります。すると、選べる道はかなり増えます。増えすぎるとワケがわからなくなるので、チャーターで「方向」は決める。ある方向に向かう道は、それでも何本もあるので、いろんな道でいろんな気づきを得られる。
 いわゆるモンキーテストは、その方向もゴールも何もないので、運がよければ気づきを得られるでしょうけれど、同じ場所をぐるぐる回っているだけかもしれない。

 目的Bの観点では、探索的テストの「選べる道の、ほどよい多さ」が、テストとしての価値につながるのではないか、と思いました。

まとめ

 まとめます。

  • テストの目的として、「バグを見つける」と「品質を把握する」がある。
  • 「バグを見つける」目的は、怪しい箇所を素早く狙っていく探索的テストが有効に働きやすい。
  • 「品質を把握する」目的に対して、探索的テストは特定のエリアのテスト観点の導出につなげることができる。
  • スクリプトテストにおいても観点の導出は行うので、本質的に違いがあるわけではない。

*1:これがオーソドックスなやり方かのように書いていますが、わたしのやり方がこうだというだけです。

*2:呼びません、カッコいい名前つけたかっただけです。evolutional より evolvable の方がかっこよさげに感じただけです。

*3:potential test case、もちろん造語です。

「シナリオテスト」とは一体、何なのか - その5

Kufi Script, 9-10th cent., qur'anic verse 3

 シナリオテストについての覚書。
 シナリオテストについては何度もオレオレ定義を書き散らしてきて、今回もその類なのですが。
 「その4」は、コチラ。

www.kzsuzuki.com

 シナリオテストを行ううえで、大きく2つのことを意識しているなと考えたので、メモです。
 2つというのは以下です。

  1. ソフトウェアの利用のEnd to Endを意識する。
  2. ソフトウェアを使う人を意識する。

1. ソフトウェアの利用のEnd to Endを意識する。

 テストシナリオ、つまり「ユーザがソフトウェアを利用する流れ」は、どのように考えるとよいでしょう。

 ソフトウェアが提供する機能から考えると、開発者目線に偏りがちになるように思います。
 シナリオを考える際には、機能からではなく、「ユーザが達成したいこと」を起点にするのがよいでしょう。
 「ソフトウェアが提供する機能を組み合わせて何ができるか」ではなく、「ユーザが達成したいことを、ソフトウェアが提供する機能はサポートできるか」で考えるというか。
 前者だと、当該ソフトウェアの外にあるもの、たとえば他のソフトウェア・ITシステム、物理的なモノ、人間系、時間の流れといったものが見落とされがちです。

 「達成したいこと」は、ソフトウェアだけで実現するとは限りません。ユースケース同士を、人間系でつなぐこともあります。ソフトウェア的には、先のユースケースの出力と、次のユースケースの入力が、いったん断絶することになります。
 ユースケースの間にある人間系で、その断絶が正しく埋まっているのか。これは個々のユースケースの確認だけでは検証できないんですよね。

 なお、「その1」では、「テストシナリオ」を以下のように位置づけていました。

テストシナリオとは、「テストケースの部分集合に順序をもたせたもの」である。

 今ではやっぱり違うかなと思っています。上述の「ユースケースの間」が無視されているように見えるためです。

www.kzsuzuki.com

2. ソフトウェアを使う人を意識する。

 ソフトウェアで複数のロールを扱っていて、ロールごとに持つ権限が異なる場合。
 権限そのものに関するテストでなければ、ついつい最強の「管理者」的なロールでテストをしがちということはないでしょうか。権限の限定されたロールだと、テストの準備のために権限を切り替える必要があったりと、ちょいちょい面倒が出るためです。
 このやり方だと、弱い権限のロールに、ソフトウェアの何が見えないのかが隠されてしまいます。

 また、たとえ持つ権限が同じであっても、ロールが異なれば見えている世界が違うはずですが、機能の入出力に注目するテストでは、この点も見過ごされがちに思います。

 シナリオテストにおいては、このロールと権限を常に意識する必要があります。
 そのロールのユーザが、何を知っていて、何を考えていて、何を求めているのかを意識しながら、ソフトウェアを触る。シンプルな入力系の画面でも、「この情報はこのロールの人は知っているものなのか」「この用語はこのロールの人にとって理解できるものなのか」を考える。このような視点は、入力値のバリエーションとその出力を検証する機能テストではあまり現れません。

 突き詰めると、「この人は、このソフトウェアを、自然に使えるか」ということを検証したいんですね。
 よってシナリオテストの各ステップには、「どのロールとして行うか」を明記して、テストをする人はそのロールになりきる努力が必要です。

あとがき

 シナリオテストにおいて意識するとよい2つのことについて、書きなぐりました。
 もう少し、具体的なソフトウェアを例にとって述べられるといいのですが、本業に抵触すると面倒なので、抽象的な話になります。。。

 シナリオテストは、テストの中でも特に面白いと個人的には思うので、もう少し方法論作られたらいいなあ(ずっと言ってる)。