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

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

GIHOZを使って、30分間探索的テストを試してみる

 あさって12/17(木)の19:00から、「人類よ!これが探索的テストだ!テスト実況生中継で学びを深めよう!」というイベントがあります。

mabl-japan.connpass.com

 Intended Audience、人類ですからね。

今回は、QAエンジニア福田里奈さま(@_rina_ )をゲストにお招きして「探索的テストのライブテスティング」を開催いたします。
アジャイル・DevOps時代のテストや品質保証として注目される「探索的テスト」。ただ、モンキーテストと誤解されてしまったり、そもそもやり方を説明できる人が少なかったりするのではないかと感じていました。
そこで、専門家に探索的テストを実況生中継(ライブテスティング)していただきながら、探索的テストがいったいどういうもので、なにができて、何ができないのかを参加者と一緒に考えていき、「探索的テスト完全に理解した」を目指したいと考えております。

 われらがリナさん*1です。ハードルを最高まで上げての煽り、最高です。

 さて近年、探索的テストについての「にし仮説」が発表されました。

 わたし自身は探索的テストマスターではないどころか、自分でしっかりと取り組んだ経験にも乏しいので、探索的テストについて一家言もないです。
 ただポエムとしては、先日の記事として以下のように詠じておきました。
 個人的には、この3つ目が重要なのかなと思っています。

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

www.kzsuzuki.com

 前置きが長くなりましたが、人類の一員としてあさって探索的テストを学ぶにあたり、自分でも探索的テストをやってみようと思い当たりました。
 対象は・・・ベリサーブさんが先月リリースしたテスト設計モデリングサービス・GIHOZです。

 さすがに自分のものでもないプロダクションサービスを勝手にテストをしてブログに書くほど荒くれものではないのですが、中の人がいいと言ってくれたのでいいのです! ふところひろし氏かよ・・・?

 先に断っておくと、このトライでバグは見つけていませんし、そもそも模範的な探索的テストの流れを見せられるわけでもありません。
 むしろどちらかといえば「幼稚な」思考過程をあからさまにすることになりそうですが、それは許してください。

準備

大方針

 まず、大方針を以下としました。

  • 1ポモドーロ・25分の中でやる。
  • 「同値分割」を対象とする。

 本当にバグを探ることが目的ではなく、勉強のためなので、時間を短く区切ります。
 また同じ理由で、機能として一番シンプルに見える「同値分割」をテスト対象としました。

チャーター

 GIHOZの同値分割では、パラメターの最小・最大を指定すると数直線が描かれて、その数直線上でのクリックで境界を指定するという直観的な操作ができます。
 ちょっと面白いふるまいとして、たとえば「0」と「5」の間をクリックして境界に値「10」を指定するとエラーになるというものがあります。数直線上の位置を判断しているということですよね。
 そういった振る舞いもあることから、このお絵かき部分を掘り下げてみることにしました。

 『Explore it!』的フォーマットで書くと、

Explore the feature for drawing a number line with various data to discover how the feature behaves.

って感じでしょうか。適当英語です。

実行

 この節では以降、引用符部分はその時点で考えたことです。

まずは普通の数字を入れて、典型的な動作を確認しよう。

 ということで、「普通の」数字を入れてみます。

f:id:kz_suzuki:20201215194525p:plain f:id:kz_suzuki:20201215194610p:plain

 特に問題なし。

オーソドックスに、変数の大小を逆転させてみる。

f:id:kz_suzuki:20201215194711p:plain

 想定通りのエラーで、問題なし。
 なお最大値=最小値でも「逆転」となったけど、ヨシ。

大きな数字を試してみる。

f:id:kz_suzuki:20201215194729p:plain

 最大桁はここまでのようです。
 これでお絵かきすると、丸図形の中に数字が収まらなくなるけれど、マウスオーバーで値を表示してくれるので問題ありません。

では、最大幅を確認する。

f:id:kz_suzuki:20201215194838p:plain

 入力OK。お絵かきも問題なし。

負の数としての最小じゃなくて、絶対値としての最小を後で、やろう。
先に増減幅の方が気になる。
まず、0.000...

f:id:kz_suzuki:20201215194901p:plain

 これ0と見なされ、正しく怒られます。

絶対値の最小を、増減幅で試そう。

f:id:kz_suzuki:20201215194919p:plain

 !?
 0.0000001と入力した瞬間、指数表記になる
 これはどういう動きなのでしょう。気になります。

これはいったんおいておいて、定義域最大、増減幅最小でお絵かきしてみる。

f:id:kz_suzuki:20201215194944p:plain

境界もキワキワにおいてみよう。

f:id:kz_suzuki:20201215194955p:plain

 これも通って正しくお絵かきできました。

ん? このように増減幅ギリギリに境界を設定すると、パーティションの上限下限が同じ値になって、図上で表現できなくなるのでは?*2
だけどこれは別に小数じゃなくても整数でも確認できるので、あとで。
上限側もやっておく。

f:id:kz_suzuki:20201215195011p:plain

 スクショはありませんが、これも正しく描画することができました。

この状態で、同値分割を出力してみよう。

 とっくにチャーターから外れてはいますが・・・。

f:id:kz_suzuki:20201215195021p:plain

 「値の範囲」を見て一瞬びくっとしましたけど、この「4」は、適当に付けたパラメター名でした。

この代表値はどうなってるんだ? これまでの感じだと、パーティションの上限と下限の真ん中に設定されていたと思うけど・・・。
負の数が入ると何か動きが変わるのか?
気になるけど、先にさっきの指数表記を触ろう。

 キャプチャはできませんが、「0.0000009」を「9e-7」にする(そして無効エラーが出る)だけでなく、「3e8」も「300000000」にされます

f:id:kz_suzuki:20201215195100p:plain

 途中まではこうなのですが、この次に「6」を入力すると急に受け入れてくれます。

f:id:kz_suzuki:20201215195110p:plain

 これは明示的に作り込んだ「機能」なのかはわかりません。
 実際にはプログラマーに質問して、意図しない挙動ならもう少し深掘りするのかなーと思いました。

 次に行きます。

ついでに、増減域広すぎパターンを見ておきたい。

f:id:kz_suzuki:20201215195123p:plain f:id:kz_suzuki:20201215195134p:plain

 何を入れても境界外になりますね。やってはみたものの、パラメターの仕様として通常ありえないはずなので、深掘りするところでもないでしょう。

刻みを中途半端にしても正しく計算できるかも確認しておく。

f:id:kz_suzuki:20201215195149p:plain f:id:kz_suzuki:20201215195201p:plain

 これも正しく計算できています。

ちょっと戻って、さっきの代表値算出を、負の数でやってみよう。

f:id:kz_suzuki:20201215195216p:plain

 特に問題なく、平均値になっている。

定義域がマイナス~プラスだとおかしくなったりする?

f:id:kz_suzuki:20201215195229p:plain f:id:kz_suzuki:20201215195240p:plain

やっぱり平均値になっているっぽいなー。・・・あれ!?

f:id:kz_suzuki:20201215195252p:plain

よく見たら、最大値と最小値が一桁違うじゃん・・・。

 そうなんです。正は、999,999,999。負は、-99,999,999。
 そりゃ平均値もプラス側にずれますよね。

 しかしやはり不思議な気もします。最大値と最小値の絶対値は、揃えるのが自然に思えるけど、何か意図があるのでしょうか。値そのものじゃなくて、マイナス記号含めて「文字列長」で値範囲が決まっているようにも見えます。
 これもプログラマーに聞いてみるやつでしょうかね。

 ここらでだいたい25分終了となりました。

やってみての感想

 探索的テストは、テスト対象を学習しながらテスト設計・実行していくものとされています。
 ですがこうやって過程を書き出してみると、(わたしの場合)思考が発散し、チャーターからも逸脱して、まったくシステマティックにならないことにあらためて気づきます。もちろん修練を積めばそんなことないのでしょうが。

 ただ今回のように、気になった点を都度メモっておくと、それをテスト観点として、いわゆるスクリプトテスト向けのテスト設計につなげられるのかなとも思います。
 今回でいうと、

  • 数字の桁数のコントロールってどうなってるのか。
  • 指数表記ってどういう期待動作になっているのか。

 あたりは、実装している人と話しながら、次のテストにつなげていくのかなーと。

 予習はこんな感じです。リナさんの探索を楽しみにしています!

Maze Wallpaper Green"Maze Wallpaper Green" by Tiger Pixel is licensed under CC BY-NC-ND 2.0

*1:なぜかアンダースコアが省略されていますが、ちゃんとTwitterアカウントにはリンクされています。

*2:実際にはこのように、同じ値を別の位置に描いています。特に問題ありませんでした。f:id:kz_suzuki:20201215195900p:plain

テスト設計モデリングツール・GIHOZと、テストプロセスのつながり方について

Circle of Life

 Veriserveさんからリリースされた、テスト設計モデリングツール「GIHOZ」のおためしを、2回の記事で紹介しました。

www.kzsuzuki.com www.kzsuzuki.com

 今回は、GIHOZへの期待と、テストプロセスのツールってこうなるのかなーという想像について書きます。

GIHOZ、こうなったらいいな!

 所詮は無課金ユーザの勝手な要求ではありますが、軽く触ってみての感想です。
 状態遷移テストにおけるイベント・トリガー以外の要素だとか、ペアワイズにおけるエイリアス・重みづけなど、個々の機能の「あったらいいな」もあるのですが、もう少し全体について、三つほど。

1. 「意図」を残したい

 ソースコードに、コードそのものだけでなく、人類向けのコメントを含めるように、テスト設計モデルにも設計意図を明示するためのコメントを残しておきたいです。

 たとえば同値分割で、同値パーティションで特定の値を「ひいきして」選んだ意図は何なのか。デフォルト値なのか、平均値なのか、ランダムなのか。
 あるいはペアワイズにおける制約について、対応する仕様は何を意味しているのか。
 テストとしての意図だったり、仕様についてのメモだったりを残せたらいいなと思います。

2. 「あともどり」をもう少し許容してほしい

 これは単にわたしがウカツなだけかもしれませんが、同値分割の境界設定や、ペアワイズにおける制約式/制約表の選択が、一度やってしまうと戻れないのが、せっかくのサクサク感をやや損ねていると感じます。修正させてほしい!

3. ヘルプが充実するとさらに嬉しい

 もちろん、GIHOZを動かすうえでの必要な情報は、今のヘルプでも整っています。
 そのうえでゼイタクをいえば・・・、
 今の内容はあくまでもGUIの操作方法。テスト設計技法はある程度理解している前提で、具体例+考え方+モデリング方法くらいまであると、とても有益だと思います。

ツールってこういう風につながっていくの?

 ツールチェーンとかいうとカッコいいのですが、また、適当なパワポお絵かきです。
 GIHOZのようなツールって、こんな風に位置づけるとかっこいいでしょうか?

f:id:kz_suzuki:20201129130730p:plain
※四角が成果物、丸がプロセスの、なんちゃってPFDです。

黄色枠: テスト設計モジュール

 GIHOZは、テストアーキテクチャ(というものがあるとして)に記述された観点に基づいて、テスト設計を行うのがこのモジュールです。GIHOZはここにあたりますね。モデルを描いて、そこからテストケースを導出するところまでを担当しています。

 なおVeriserveさんの場合、「TESTRUCTURE」というツールも提供しています(すみません、使ったことありません)。

www.veriserve.co.jp

  • STEP1: テストベースの理解・分析
  • STEP2: 階層的整理
  • STEP3: 詳細化対象の決定
  • STEP4: テストケースの作成

 以上のような機能をサポートしているということで、上の絵でいうと緑の部分までカバーしているのかも。またGIHOZは、TESTRUCTREの補助ツールという位置づけなのかもしれませんね。

オレンジ枠: テスト管理モジュール

 テストケースそのものや、その実行を管理するモジュールです。
 有名どころだと、Test Rail、PractiTest、Test Pad、TestLinkなどがあります。

www.guru99.com

 Veriserveさんでいうと、Quality Forwardが対応するでしょうか(これも使ったことがなくてすみません・・)

www.veriserve.co.jp

 テスト設計モジュールから、テストケース*1を受け取り、テスト手順と組み合わせることで、手動で(も)行えるテストケースになります。
 ここで、テスト手順はデータ駆動テストの考え方に基づき、パラメタライズされている*2ことが期待です。上位からパラメタを受け取ることで、一つ以上の具体的なテストケースとして実体化されます。

 このようにできたテストケースの実行状況・実行結果までを管理することになります。
 なお、テストケースは、GIHOZでサポートしているようなテスト設計技法から導出されるものばかりではないことには留意が必要です。

青枠: テスト自動化モジュール

 テスト手順が標準化された記述になっていれば、キーワード駆動テストにつなげることができるでしょう。
 自然言語に近い形で記述されたテスト手順の各ステップをスクリプトに対応付けておくことで、テスト手順+スクリプト→実行可能な自動テストケースとなります。
 これによって、モデルの作成/変更→テストケースの実装→自動テストの生成→自動テストの実行 とつながるようになって幸せそうですよね。

 自動テストの生成と、その自動テストを何らかのトリガー*3で自動実行するところまでが、テスト自動化モジュールのお仕事ですかね。
 実行結果の管理もここで行うかもしれないし、テスト管理モジュールに統合するかもしれない。

ピンク枠: イシュー管理モジュール

 テスト実行の結果から、テストアーキテクチャを洗練させていくことになります。
 たとえば、テストケースの目的とは違うところで欠陥が発見されたなら、それを新たなテスト観点として還元し、反映するでしょう。あるいはプロダクト要因でなくテストの誤りでテストがコケた場合は、その誤りをモデルから修正する必要があります。

 まあ、こんな感じでぐるぐる回るとかっこいいよね!というお話です。
 絵のキレイさを優先しているので、細かいことは気にしないでいただきたい!

連携のための標準化

 さらに妄想です。
 ツール間の情報のやりとりのために、二つの標準化を行う必要があります。ここでは、TDMP と、MTCP と呼んでおきます。言いたいだけです。

TDMP(Test Design Modeling Protocol)

 TDMPは、テスト設計モデルの記法に基づいて作成されたモデルの情報を、ツール間・プロセス間で受け渡しするための標準形式です。
 入口は二つ考えられます。

 一つ目は、仕様・設計からのインプットです。上の絵でいうと、「Spec Model」がテスト設計モジュールに入ってくるところですね。
 設計段階で作られたモデルをテストの入力情報として受け取り、テスト側でそれをテスト設計モデルとして拡張して、テストの生成につなげていく。あるいはその過程で得られた知見を設計側にフィードバックします。

 二つ目は、他のモデリングツールからの/へのインプットです。
 テスト設計モデリングをするためのツールはGIHOZに限らず登場すると思いますが、あるツールで作成したモデルがそのツールでしか使えないというのは辛過ぎます。データ形式を標準化し、ツール・サービスの乗り換えが容易にできると幸せそうです。

MTCP(Model-based Test Case Protocol)

 MTCPは、テスト設計モデルから生成されたテストケースの情報を、ツール間で受け渡しするための標準形式です。
 生成されるテストケースの形式は、テスト設計技法ごとに異なります。状態遷移テストであれば、最低限「前状態」「トリガー」「後状態」がセットになりますし、デシジョンテーブルテストであれば条件部のパラメタ値の組み合わせと、動作部のパラメタ値の組み合わせというセットになります。これを明示し、受け取り側が理解できるようにする必要があります。

 MTCPによるデータの受け取り手は、テスト管理ツールです。上の絵でいうと、「Test Cases」がテスト管理モジュールに入ってくるところです。上位からのインプットは、前回差分の情報を持ってくれていると嬉しい。あるいはそれはテスト管理モジュールのお仕事なのかな?

 ええ、なんか、プロトコルって書くとカッコいい気がしてそういう名前にしましたが、別に通信規約ってわけでもないので、変ですね。まあいいか・・・。

おわりに

 GIHOZを触ったおかげで、たくさんの妄想を膨らませることができました。本当にありがとうございます。
 こういうことをいい加減に書いたり描いたりするのは簡単ですが、実現はすごく難しそうで、でも楽しそうですよね。
 効果的・効率的で、同時にワクワクするテストをしたいので、それを支援してくれるVeriserveさんを応援しています!

*1:最終的に実行可能なレベルまで具体化するのを、どのタイミングで行うべきかは議論したい。

*2:たとえばログイン画面における「ユーザ名」「パスワード」が変数になっているイメージです。

*3:プロダクトやテスト設計モデルの更新などを想定しています。

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を開いている。