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

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

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

The Model.

 Veriserveさんがリリースしたテスト設計モデリングツール*1「GIHOZ」について、前回記事の続きです。

www.kzsuzuki.com

 残り3つの機能も触ってみましょう。

gihoz.com

今回は「デシジョンテーブルテスト」「状態遷移テスト」「ペアワイズテスト」の3つが、どんな感じで動くのかを紹介します。
 全体の所感と、わたしが勝手に期待していることは、次の記事に書きます。

デシジョンテーブルテスト

 今回も、『練習帳』の問題を使ってみます。ブログ記事はこちらです。

www.kzsuzuki.com

 仕様の概要は以下の通り。

  • 通常、1杯490円で提供されます。
  • 16:00から17:59まではハッピーアワーのため、1杯290円で提供されます。
  • クーポンを使うと、利用時間にかかわらずはじめの1杯のみ100円で提供されます。
  • ハッピーアワーでもクーポンは利用できます。
  • その時点で最も安い価格で提供されます。 1杯目のビールの価格を表すデシジョンテーブルを作成してください。

 「条件」にあたるパラメターは、「利用時間」「クーポン有無」になりそうですね。
 「動作」は、「金額」でいいでしょう。

 GIHOZでの初期画面はこれです。

f:id:kz_suzuki:20201128120528p:plain

  各セルは直接入力が可能です。

f:id:kz_suzuki:20201128120559p:plain

 条件を入力し、それに対する値を入力。また次の条件を入力、・・・と進めていきます。
 動作も同じですね。

f:id:kz_suzuki:20201128120617p:plain

 また他人とお作法が違うかもしれないので書いておきますが、わたしはテストケースを横に展開する前に、条件と値を書き出します。みんなそうだよね!?

 さて、ここから各値のY/Nを入力して、テストケースにしていきます。

f:id:kz_suzuki:20201128120635p:plain

 ハイフンが入っているセルで、「Y」「N」「-」のいずれかを選んでいきます。
 条件と値を決めたらY/Nの全組み合わせが自動生成され、ユーザはそれを剪定していくのかな?と想像していましたが、そうではないですね。

f:id:kz_suzuki:20201128120652p:plain

 Y/Nを入力したのが、1~4です*2

 テストケース#5は、「1つの条件で2つ以上の値がYになったらどうなる?」という観点。
 テストケース#6は、「Y/Nの割り当てが同一のテストケースがあったらどうなる?」という観点。
 後者については、期待通り、テストケース重複の警告が出ています。

f:id:kz_suzuki:20201128120704p:plain

 挿入や削除は、セル上の右クリックから。
 テストケースの上にある「有効/無効」は、同値クラスの有効無効とは関係なくて、以下の2つの目的で利用すると想定します。

1. 実施しない組み合わせを落とす。

 たとえば、そもそもありえない組み合わせを対象外にする。
 ヘルプで言及されているのも、この使い方です。

2. デシジョンテーブルの「簡単化」を表現する。

 これはわたしの勝手な使い方かも。
 たとえば仕様として、利用時間が「16:00から17:59の場合は一律100円」とするのであれば、Y/Nと有効/無効を以下のように修正することになります。
 また、ハイフンを「N/A」(どちらでもよい)の意味で使っています

f:id:kz_suzuki:20201128120718p:plain

 さて、ここまで作って気づいたのですが、「条件」部と違って、「動作」部は階層構造化できません。
 動作の方も、複数のパラメタを指定したいことありそうだけどなー。たとえば「金額」と、「お通し有無」とか。

 とりあえずは、金額を入力していきます。

f:id:kz_suzuki:20201128120728p:plain

 完成しました。
 同値分割/境界値分析と違って、ここから、各条件の値を指定した具体的テストケースへ落とし込むわけではないですね。

 ともあれ、直観的にテーブルを作っていけるツールに仕上がっています!

状態遷移テスト

 状態遷移テストについては、白紙からのスタートは厳しいということか、

f:id:kz_suzuki:20201128120736p:plain

 みんな大好きストップウォッチの状態遷移図がすでに描かれています。

f:id:kz_suzuki:20201128120744p:plain

 で、描いた状態遷移図に基づいて、スイッチカバレッジを指定してテストケースを自動生成します。  0スイッチと1スイッチを選択して生成してみましたが、とても速いです。

 まず状態遷移表。
 状態×イベントの形式と、状態×状態の形式、両方が生成されます。

f:id:kz_suzuki:20201128120754p:plain

 生成した状態遷移表の空きセルには、ignorecan't happen が選択できます。astah*と同じですね。
 この2つの値の意味については、この記事にメモしています。

www.kzsuzuki.com

  • ignore: 当該イベントが発生しても、発生しなかったように扱う。
  • cannot happen: 当該イベントは発生しえない。

似ているように見えますが、前者は「イベントが発生しうる」、後者は「イベントが発生しえない」ので、根本的に違いますね。

 なお、遷移すべき「状態」を入力して、状態遷移図に反映させるということはできません。図から表への一方通行です。

 ちょっと操作方法が直観的でないのが2つあったので、メモしておきます*3

1. 遷移図上のオブジェクトの削除は、[Delete] ボタンで。

 右クリックしてもメニューは出ません。

2. 自己遷移は、状態オブジェクトの端っこをドラッグアンドドロップ。

 「+」ボタンだと、自動的に別の「状態」も描かれてしまうので、「自己遷移はサポートしていない!?」と思いましたが、そんなはずありませんでしたね。ただちょっと操作は慣れが必要そう。

 まだおぼつかないですが、

f:id:kz_suzuki:20201128120803p:plain

 以下の記事で書いた例で、遷移図を描いてみました。

www.kzsuzuki.com

 1スイッチカバレッジのテストケースを生成!

f:id:kz_suzuki:20201128120813p:plain

 きれいに生成されました。

 表じゃなく図なので操作には慣れが必要ですが、すんなり描けますね。
 現時点で描けるのは状態と遷移のみなので、アクションなどの要素もサポートされるとさらに夢が広がる。

ペアワイズテスト

 こちらも初期画面で、サンプルが表示されます。

f:id:kz_suzuki:20201128120831p:plain

 ・・・が、なんかよくわからん!? ディスクフォーマットのテストでしょうか。
 「因子」「水準」という独特の用語は使わず、「パラメタ」「値」としています。

 『練習帳』の問題4.5.2のの仕様。

  • メタボ検診と婦人科検診は、年齢が35歳以上の人のみ選択できる
  • 脳検診は、年齢が45歳以上の人のみ選択できる
  • 婦人科検診は女性のみ選択できる

 これを適用していくと、

f:id:kz_suzuki:20201128120840p:plain

 このようになります。これもやはり、Excelのようにサクサク入力できます!

 なおここでやらかしたのですが、「保存」しないで「←一覧」を押すと、警告なしで一覧画面に戻ってしまいます・・・。

 次に、パラメタ間の「制約」を定義していきましょう。

f:id:kz_suzuki:20201128120853p:plain

 ここからパラメタ間の制約を追加していくのですが、ここで注意!

f:id:kz_suzuki:20201128120901p:plain

 ここで「制約表」「制約式」のどちらかを選ぶと、その後に選択し直す方法がありません*4
 今回はPictMasterでもおなじみの、表形式での制約入力をしてみます。

f:id:kz_suzuki:20201128120910p:plain

 PictMasterでは、IF にあたるパラメターのセルを色塗りするのですが、GIHOZではパラメタごとに制約を書く仕組みですね。
 年齢が20、34の場合は、任意追加項目で「メタボ検診」「婦人科検診」を選択できないという制約を、

f:id:kz_suzuki:20201128120917p:plain

 適当に書いてみました。

f:id:kz_suzuki:20201128120928p:plain

 適当に書いたらエラーになりました。

 このエラー内容を見ると、IF の部分は「20, 34」という1つの値として解釈されているのと、THEN の方も「メタボ検診か婦人科検診のどちらかと異なる」と解釈されていることがわかるので、修正します。

f:id:kz_suzuki:20201128120938p:plain

 おそらくですが、制約の表現の仕様として

  • IF に当たる部分は、値を1つだけ書ける。
  • THEN にあたる項目に複数の値を書くと OR で結ばれる。

となっているので、条件をばらして書いてあげる必要がありそうです。意図した通りの制約になっているかを確認したいので、できればこの制約表に対応する制約式が、エラーじゃないときも見えるようになれば・・・!

f:id:kz_suzuki:20201128120947p:plain

 制約を一通り埋めてみました*5

 さて、これでもエラーが出ます。

f:id:kz_suzuki:20201128120955p:plain

 よく見たら、「婦人科検診」を「婦人科」と書いていました。警告の意味は今回の場合、「任意追加項目が『婦人科』となる組み合わせが1つもない」ということです。定義されていない値が制約に入っているために起きるエラーです。
 これを修正して再度、組み合わせを生成すると、

f:id:kz_suzuki:20201128121003p:plain

 エラーなしできんと生成されました!

 GIHOZのせいではないですが、制約の書き方とそのエラーに慣れる必要がありそうですね。

*1:とわたしは呼んでいる。

*2:ヘルプを見ると、Yだけを入力し、それ以外はハイフンという使い方になっている。Nの使い道がわからない。

*3:両方ともヘルプに描かれている。ちゃんと読もう。

*4:正確には、わたしには見つけられませんでした。

*5:年齢に関する制約の可読性が悪いので、# で排除するのではなく、選択できるものを列挙することで制約をシンプルにできるかも。でもそれだと、今度は仕様との比較で面倒になる。

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、もちろん造語です。