JaSST '18 Tokyo【E2】「やってみよう！探索的テスト ～ハイクオリティな妄想の高速ループ～」聴講メモ

内容のまとめ

  • 実際にアプリケーションを操作して探索的テストを体験できるセッション
  • 状況によって、スクリプトテストの実装よりも短時間で高い効果が得られる
  • 「アプリケーションの挙動」という学びをインプットに、「ユーザーが現実的にどう行動するか」を想像して、次のアクション(≒テスト設計)を考えると良い
  • 時間を区切らないと費用対効果が悪くなってくるので、タイムボックスで切るのがおすすめ

感想

  • バグ出しを始めると一種の「ハイ」になってしまい、「ユーザーが現実的にどう行動するか」の想像が後回しになってしまった(なので、チャーターなどを使った舵取りが必要ということに納得)
  • 今回のセッションでは体験しきれなかったが、テストキックオフ〜テスト振り返りのサイクル＋チャーターというフォーマットを実際に回してみたい

聴講メモ

  • 燻製をつくる人と食べる人のペアで探索的テスト
  • 似た言葉 探索、散策、冒険、探検、徘徊
  • ただ何となく徘徊するのは薄い ハードウェア壊すような冒険はやりすぎ
  • 探索的テストとは問診に近いイメージ
  • 今回のセッションは、自由度が真ん中から下寄りの探索的テスト
  • チャーターは手順ではなく指針
  • 探索的テストは、テスト設計はするけどテスト手順のドキュメント化はしない
  • 探索的テストとスクリプトテストをどう組み合わせるか
  • チビファ○ヤー○リオ
  • 探索的テストは「おもしろい！」
  • 手がかり＞ユーザーが実際にどう使うか想像する＞動かす
  • 「テスト実施」だけの状態(アドホック的)＞「テストキックオフ」＆「テスト実施」＆「テスト振り返り」のサイクル
  • 今回のセッションでは、探索的テストは「トレーニングを十分受けたテスト担当者」によってなされる、と定義している。ドメイン知識やテスト技法があると効果的

JaSST '18 Tokyo 「Advances in Continuous Integration Testing at Google」聴講メモ

内容のまとめ

  • Googleではすべてのテストを自動化している(UXに関するテストは例外)
  • CIのスケジューリングに対する取り組み&(効果は維持したまま)コストを削減するための取り組み
    • 変更の影響を受けない機能はテストしない
    • 過去のテスト結果を蓄積する
    • テスト結果を「状態」として時系列で記録し、変化がないものはテストしない
    • マイルストーンの設置頻度を減らす
  • 「Flakyなテスト」への対処
    • コード自体の変更が行われていないのに、テスト結果が変化したものを抽出→開発者にフィードバック

上記を支えるための文化

  • テストは書いて当たり前
  • テストを書きやすい設計を考えるのは当たり前
  • 再利用性のないテストだろうが自動テストを書くのは当たり前

感想

  • Googleは、良いプラクティスと言われていることをただ愚直に現実世界に持ち込んでいるだけ、という印象を受けた
  • 取り組みを評価するための数値化を、真摯に行っているという印象
  • ただそれだけのことがどうしてこんなにも難しいと感じるのか

聴講メモ

  • 1件あたり35回のテスト
  • 分散化してテスト
  • マニュアルQAは一切ない
  • 非常に高速
  • 非常に頻繁にプロダクトをリリース
  • テストの99％は合格
  • かなりお金をかけている
  • テストの文化を根付かせる
  • トイレに貼っている　ヒント　結構有効
  • テスティングブログ
  • 新規採用　一日目からテストを書いてもらう
  • QAを別部門としていない
  • 1チーム8人に1人か2人がテスト担当
  • テストのフレームワークを作る
  • 新しいシステムテストというものを追加するためにテストを整える
  • ST　という役割の人間が土台づくりをしている
  • 手作りの自動テストが主流
  • どうやってテストを選ぶのか　450万のテストをすべてするのか
  • 依存性関係を示したグラフ　図　を使って選定している
  • 影響を受けるテスト
  • バックエンドで同時並行
  • 変更リスト　IDをつけて2年間保管　パターンなどが見えてくる
  • キャパシティがあいたら　マイルストーンを区切って　その時点までの変更がテスト対象になる
  • 結果が出る
  • どの変更で緑から赤に変わったのか
  • パスからフェイルに移行した変更を見つける
  • 回帰テスト
  • 少数の変更ですべてに影響してしまう　すべてがそれに依存しているから
  • 実行しないテスト　ほとんどの問題は0.2%の箇所で起きる
  • リソースを節約するために、分析をする
  • 変更の半分は38のテストに影響する
  • 100％で400万のテスト
  • このテストが安心か否かをどう見極めるか
  • 赤い　フレーキー
  • 黒い　ビルド失敗
  • 現在のシステムは非常にコンサバです
  • マイルストーンの間の時間がある
  • いちマイルストーンは40分くらい
  • グリーンライクなサービス
  • インコンクルーシブ
  • 100％グリーンでなくても確信レベルに近ければリリースする
  • 新しいスケジューリングのアルゴリズム
  • 不合格を見落とすリスクはある
  • 少ないリソースでトランジションを見つける
  • テストをやめればよい
  • スキップするのが安全であるとはどういう意味か
  • パスという状態とフェイルという状態の遷移
  • フェイル＞フェイルもスキップして「よい」対象
  • パス＞フェイルは「安全でない」
  • パス＞スキップ＞フェイルの場合は「チェンジ2かチェンジ3が問題」
  • マイルストーンを少なくする
  • スマートスケジューラが悪い状態遷移を検知する
  • テスト戦略　テストコストを低くしたい
  • 遷移を見逃すリスクをおさえる
  • 遷移がなければテストは安全
  • どれだけの遷移を見逃すのか
  • 新しい戦略の評価
  • 2年間のデータ
  • インターンの方が作成した図
  • 3本の線
  • 横軸はスキップレート
  • 100％スキップしても0にならない
  • 90％以上の場合、テストをしなくても遷移は見つからない
  • オプティミスティック
  • 遷移がわかっているものはスキップする
  • 0.2％のみ実行する
  • 失敗するのがわかっていてもスキップしない
  • 中央の線は無作為
  • 直線にならない
  • 確率分布によるもの
  • フレーキーなテスト
  • 同じコードなのに、テストのパス/フェイルが両方出る
  • フレークの不合格は、リリースの支障となる
  • デベロッパーはフレーキーを無視する
  • 1ヶ月分のデータ
  • パスからフェイルの遷移の84％がフレーク
  • コードの変更が問題ではない
  • ブレークが起こっているのは非常に少ない
  • ペアプロのエビデンスが出た
  • 1人よりも2人のほうがいい
  • ジョーがボブよりもフレーキーを起こす可能性が高い
  • 言語によってはブレークが起こりやすい　C++とJava　Goはもっといい
  • 是非結果を記録してください
  • こんなものがフレーク
  • WEBドライバーのテスト
  • マルチスレッドのテスト
  • 環境の差異
  • 継続的に1.5％がフレーク
  • デベロッパーにプレッシャーはかけているものの
  • ある程度のフレークさは許容しなければならない
  • ほとんどのデベロッパーは、うまくいくまでサブミットし続ける
  • どれだけ頻繁に失敗するか
  • このテスト自身が、最近フレーキーだったかどうかのフラグを持っている
  • フレーキーデータベース
  • 明日のチュートリアル

  • データセット

  • 質問

  • マニュアルテストは一切やってない
  • ハードウェア含めた自動化のアイディアはあるか
    • どれだけデジタル化が進んでいるかによる
    • 信号機の制御アルゴリズムだけをテストすれば足りるはず
  • カバレッジをどの程度達成しているのか
    • 測定はしているが、チームの成熟度によって差がある
  • テストの設計の話を知りたい
    • コードレビュー　ほとんどピアによってコントロールされる
  • 小さな変更を非常に大事にしている
    • フレーキーという言葉の由来
    • 語原はミッコさんも知らない　どちらかというと見下げたことば
    • 一貫性に欠ける人　不安定　などというニュアンスがある
  • グリーンをトップダウンで導入したのかボトムアップで導入したのか
    • ボトムから、費用対効果のトレードオフをトップに説明した
    • お金がかかるというのが課題感だった
  • 3名以上　相関関係が見えてきた
    • 3人以上になると規模が大きくなるので、3人がすべてのエキスパートになるのは難しい
    • 1人よりは2人のほうがいい　他の人の目があるほうがいい　気づき
  • 新規サービスのマニュアルテストもないのか
    • 自動化できている　自動化できるということは、イレテーションが短いということ
    • 多少問題があってもクリティカルな問題にはならないサービスだから
  • UXテストも自動化できるのか
    • ユーザビリティテストは人がラボでやっている　エスクペリエンスの確認
    • 実験も含めている　それはある程度自動化といっていいのではないか　ライブのテスト　実験的なテスト
    • UIテストは自動化している
  • テストの記録には個人名が入っているのか　個人に注目してどこまでやっていいのか
    • よい質問です　アメリカでは、従業員の情報は取ることができる　すべて匿名化されている　マシンラーニングのほうでそれは対処してくれる
  • 開発者へのフィードバックについて
    • 依存関係は精度が高い　テストのグラフ　ご関心があればベーゼルをご検討ください
  • 開発者以外にフレーキー以外にフィードバックすること
    • 様々な分析結果　
  • (不具合を)見逃してリリースしてしまったことはないか
    • 何かを見逃すリスクは低い　見逃さないと思っている　トレードオフをみている
  • 組み込みのCIに興味がある　想定されるリスクなどあるか
    • 少し考えさせていただきたい　興味深い分野だと思います
  • グリーンにする社内共通基準のようなものがあるか　チームごとに違うのか
    • チームごとにテストの内用は決めている　でも、ある程度チーム間で合意は取れているとは思う
  • 再利用性が低いテストを自動化しているのは何故か
    • マニュアルテストしているのは翻訳のみ　迅速にリリースするため　36時間以内にライブに出すというルールがある　レアなテストでも、テストを書くということにコミットしている　文化的に組み込まれている
  • 自動化にはまらないコードはどうしているのか
    • もはやそういった問題はない　2006年に文化を変え始めた　2006年以降のコードは96％程度
    • どんなベストプラクティスでもコードに組み込んでいく
  • カオスエンジニアリングのような新しいテスト手法をやっているか
    • インテグレーションは根づいている
    • 実験的　ファジング　ランダムテスト　つかっているが　いまは根幹にはなっていない
  • 全体としてのテスト計画を誰が考えるのか
    • 各プロジェクトチームが、全体的なテストプランを考えている　Googleでは、少数のユーザに使ってもらって、フィードバックを得ている　各チーム自律的に動いている　チームが個々に決断できる
  • テスト変更の適切さをどう担保しているか
    • レビューをしている
  • テストの変更で失敗することはないか
    • コミットする前に動かして確認している
  • AIの活用
    • AIは使うもの　テストの選定　スケジューリング　機会学習のテストは難しい　テスターとしてそこは心配している　数学をわかる必要がある　もし壊れても気付けないおそれがある　業界全体が直面する問題
  • 人数について
    • 強い相関関係がある　複数に人が同じファイルを扱うとテストに影響する　3人以上は影響が起きやすい　3人より2人　2名が最適という判断　なぜなのかはまだわからない　ルールまでは設けていない
  • 特別なレビューはあるのか　レビュアーに必要なスキルセット
    • リーダビリティ　言語の可読性　コーディングスタイルをよく知っている　その言語をよく知っている　チームではテックリードの役割　直接同じプロジェクトに関わっていなくても、ピアプレッシャーによってうまくいっている
  • トライビュー？というフレームワーク　静的な分析　コードレビューの自動化　使えないボタン　すべてに対して修正をかけるより効率的

探索的テストとそうでないテストのJSTQB的まとめ

JSTQB 方言

きっかけ

Feedlyを設定している途中、showさんのエントリを拝見しました。

surumegohan.hatenablog.com

「探索的テストはベテランがやるものだと思ってた」というのは私もよく耳にする言葉で、「そのソフトウェアについてのドメイン知識をそれなりに有している人が、テストケースとは無関係に動くソフトウェアを使用し、ソフトウェアに対するフィードバック(主として欠陥=defectの検出)を行うこと」という行為を指して「探索的テスト」という言葉が使われることが多い印象を持っています。さらに、まったく同じ文脈で「アドホックテスト」「モンキーテスト」「ランダムテスト」という言葉が使われていることも多いと感じています。

(テスト方言あるある)

「探索的テストっぽいグループのテスト」が持つ要素

要素を箇条書きにすると、以下の2点が特徴になるかと思います。

  • 有識者だけが実施可能である
  • テストケースは書かない

ちょっと整理してみたかった

上記の捉え方には個人的にいろいろ疑問を感じているので、それを整理してみたいと思いました。 物差しとしては、JSTQBの用語を使います。

JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-

探索的テスト

まず、「探索的テスト」は以下のように定義されています。

用語 定義
探索的テスト（exploratory testing） 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。

探索的テストはあくまで「設計技法の一つ」として定義されており、「テストを設計しない」という考え方はされていません。「テストを実施する過程で、テスト担当者がテスト実施情報を活用」することがポイントで、ソフトウェアが動いた後に、動くソフトウェアを見ながらテスト設計を行うという段取りになっています。テスト実施情報は、ドメイン知識に基づく情報以外にも、一般的なソフトウェアの設計知識や、ソフトウェアが動作する環境に対する知識からも導くことができると思います。実際の現場ではドメイン知識を持っている人が圧倒的に強い(効率的に欠陥を検出できる)と思われますので、そこがフォーカスされるのは仕方ないと思います。

探索的テストと似ているが、別の言葉で定義されているテスト

次に、「探索的テスト」と同じような文脈で使われることが多いけれども、用語として分かれているものを以下に挙げます。

※他にもありましたら教えてください！

用語 定義
モンキーテスト（monkey testing） 製品の使用法については全く考慮せず、広範囲の入力からランダムに選択し、ボタンをランダムに押すことでテストを行なう方法。
アドホックテスト（ad hoc testing） 非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。
ランダムテスト（random testing） ブラックボックステスト設計技法の一つ。擬似ランダム生成アルゴリズム等を使い、運用プロファイルに合致するテストケースを設計する。信頼性、性能等、非機能属性のテストに利用できる。

モンキーテストは、「製品の使用法については全く考慮せず、広範囲の入力からランダムに選択」するところがポイントだと思っています。テスト設計もしませんし、テスト実施情報も見ません。場合によっては、「ふつうログインするときにはパスワード入れるでしょ。。。」みたいな固定概念が無い、ド素人の方が強かったりします。

アドホックテストは、「非公式に実施する」というところがポイントだと思います。公式に取り決めたプロセス以外で実施するテストですが、「実績のあるテスト設計技法を用いず、テスト結果も予測せず」というだけで、全くテスト設計をしないとは言っていません。頭の中にしかテスト設計がなかったとしても、現状に対してゼロベースで適切なテストを考えて実行する方法、というくらいのイメージです。

ランダムテストは、「設計技法の一つ」と書かれているとおり、テスト設計を行うというところがポイントです。ただ、そのアプローチとして「擬似ランダム生成アルゴリズム等」を使っているだけです。

表にまとめてみると

以下のようになりました。

用語 有識者が必要か テスト設計を行うか
探索的テスト NO(有識者がいるとベター) YES
モンキーテスト NO NO
アドホックテスト NO(有識者がいるとベター) NO寄りのYES
ランダムテスト NO YES

私が携わったプロジェクトでは、上記のうち「アドホックテスト」に該当するテストを、それ以外の呼称で呼んでいることが多かったかなと思います。

IFTTTを使って、Twitterに流れてくるテスト関連の話題をSlackに流し込んでみました

f:id:trickmr:20180304153429j:plain

きっかけ

先日、Google Homeから「もくもくなう」とつぶやけるアプレットを作ってみました。 no-plan.hatenablog.jp そのときに利用したのが「IFTTT」というサービスで、これがとても面白かったので、別のアプレットを作ってみました。

ユーザーストーリー

  • 個人の趣味として
  • Twitterに流れてくる「ソフトウェアテスト」に関する話題を見逃さないために(見逃してもあとで気付けるようにするために)
  • テスト関連の話題を拾って記録しておいてくれるようにしたい

IFTTTとは

「IF This Then That」の略で、要するに「This」に設定したアプリケーションのふるまいを入力として、「That」に設定したアプリケーションのふるまいとして出力してくれるサービスのことです。

IFTTT - Wikipedia

『Google Homeから「もくもくなう」とつぶやけるアプレット』を例に取ると、

  • 「This」のふるまい：「Googleアシスタント(Google Homeの中の人)」が「『もくもくなう』という文字列を受け取ること」
  • 「That」のふるまい：「Twitter」が「『もくもくなう』とつぶやくこと」

となります。

実装

IFTTTのUIに従って、以下の要領でアプレットを作ります。

  • 「This」に「Twitter」を指定し、トリガーとして「New tweet from search」を選択。
  • キーワードに「テスト戦略」など、好きな用語を指定。
  • 個人のSlackアカウントに、書き込み先に使う専用チャンネルを作成。
  • 「That」に「Slack」を指定し、先ほど作成したチャンネルを指定。

IFTTTのここがすごい

ノンコーディングで、下記のカスタマイズを除けば、3分程度で実装完了してしまいました。 お昼休みにちょこっと調べてさくっと実装。これはやばい。

困ったこと

実際に動かしてみると、部分一致でキーワードを拾ってきてしまいました。 たとえば、「テストタイプ」キーワードの場合、「心理テストです！あなたの性格タイプは～」みたいなものが拾われてしまいました。 そこで、伊藤由貴(@yoshikiito)さんに頂いたアドバイスなどを参考にしながら、以下の要領で「This」の検索条件をカスタマイズしました。 ついでに、複数のキーワードをひとつのアプレットにまとめてみました。

  • キーワードを「"」でくくる
  • 各キーワードをOR条件でつなぐ

要するにSQLのWHERE句を書くイメージですね。

以下の要領で書いていけば、キーワードをどんどん増やせます。

  • 「"テスト戦略" OR "テスト計画" OR "テスト設計" OR "テスト観点" OR "テストタイプ" OR "テストレベル" OR "テスト手順"」

※あまり増やすと怒られそうなので自重しています

結果

こんな感じで、指定したチャンネルに情報が流れてきます。 f:id:trickmr:20180304145905j:plain

まとめ

お手軽簡単便利にアプレットが実装できるというのがとにかくすごいですね。 多くのサービスに対応していて、パズル的に色々な組み合わせを試してみたくなる仕掛けになっているところも面白いです。 「アプリケーションをつくる」作業を辛くない、むしろ楽しいと感じさせてくれるサービスだなと感じました。 今後も色々とレシピを試してみて、自分が動かなくても済むように頑張っていきたいです。

Google Homeから「もくもくなう」とTwitterに投稿できるようにしました

きっかけはこちらの記事。

smarthacks.jp

とりあえずTwitter連携が面白そうだなー、ということで、記事を参考に作ってみました。

手順

  1. スマホにIFTTTをインストールする
  2. My Appletsを選択、「+」でアプレットを追加
  3. +this にGoogleアシスタントを指定
  4. 「Say a simple phrase」でトリガーとなる言葉を設定(例：チャーハンなう)
  5. +that にTwitterを指定
  6. つぶやきたい言葉を設定(例：チャーハンなう)
  7. 手順に沿って保存して完了(デフォルトでActiveになります)

動作確認

  • Google Homeに向かって「おっけーぐーぐる、ちゃーはんなう」と喋る。これだけ。
  • 成功すると、「わかりました。ちゃーはんなうとつぶやきます。」と返ってきます。
  • その後、Twitterに「チャーハンなう」と投稿されます。

使い道

チャーハンなうだと利用頻度が限られるので、「もくもくなう」にしてみました。 もくもく会に参加するときに便利！たぶん！

うまく動作させるコツ(？)

  • はっきりとはわかりませんが、イントネーションが重要みたいです。
  • 「もくもくなう」の場合、いわゆる「もくもく会」のイントネーションで「もくもく」と言ってしまうと、「すみません、わかりません」と返ってきてしまいました。「雲がもくもく」のイントネーションで発音するとうまくいきました。

さいごに

Google Homeで遊びたくてインストールしたIFTTTですが、むしろIFTTTの方が楽しいんじゃないかと思い始めてきました。 こちらもいろいろ遊んでみようと思います。

Scratchで遊んでみました

Scratch

scratch.mit.edu

きっかけ

デブサミ以降1週間くらい、(自分にとっては)濃くて重たい情報のインプットが続いていたので、気分転換になるものを探していました。ついでに、ボランティア活動で使えるネタ、つまり子ども向けに提供できる何かが見つかればラッキーという魂胆もありました。

Scratchを選んでみた理由

最初は東急ハンズで工作＆ロボット系を物色していたのですが、とりあえずお値段がお高い。 もうちょっと敷居が低いものはないだろうか。。。と調べていたところ、「そういえばScratchって言語があったなー」と。

ScratchはGUIでコーディングができる(らしい)言語で、コンポーネントが非常にカラフルでポップなのが特徴です。 「あまり機能は充実してないだろうけど、敷居が低いというのはとても良い気がする。触ってみよう。」ということで、一冊書籍を買って始めてみました。

やってみた感想

書籍のサンプルプログラム(シューティングゲーム)を写経して、そのままいろいろカスタマイズしてみました。サンプルはだいたい30ステップで、めちゃくちゃシンプルです。リッチな開発環境が用意されているので、作業場所の構築をする苦労がありません。GUIなので、文法のタイプミスもありません。「セミコロンのタイプ漏れを見つけるのにウン時間費やす」方面のストレスが全く無く、ロジックに集中できます。

お決まりの教材ネタとしてFizzBuzzも書いてみましたが、普通の言語と特に何も変わらない形で作ることができました。

コンポーネントが「動き」「制御」「演算」といった形で色分けがされているので、可読性も非常に高いです。

動くものを素早く作ることができるのは、純粋に楽しいですね。

まとめ

「無料」「敷居が低い」「カラフルで楽しいうえに可読性も高い」「ミスしないように工夫されている」「素早く動くものが作れる」など、特徴を並べてみると「すごいなこれ」という感想になりました。

公開されているプログラムを拝見すると、結構複雑なものも作れそうですね。 ゲーム以外にも、しっかりしたアプリケーションも作れるのではないかと思います。

ということで、皆さま一度お試しあれ。

【WIP】状態遷移図を理解するために、RPG風に毒(猛毒)状態を状態遷移図で表現してみた

きっかけ

ブロッコリー(@nihonbuson )さんに状態遷移図の書き方を教えていただいたのがきっかけです。 そもそも状態遷移図をちゃんと書いたことがなかったので、いちど時間を使って書いてみよう、と思いました。

モチーフについて

もともとゲームが好きなので、いわゆるRPGをモチーフに書いてみようと思いました。 最初は特定のIPに寄せて書きました。

まず書いてみた＆発表してみた

とりあえず勢いで書いてみた内容を、Toshiyuki Manabe(@ToshiManaPlus1 )さん主催のオンライン飲み会でレビューしていただきました。 元々は、書いた内容をブログに公開するだけの想定でいましたが、 「発表やってみたいんですがハードルが高くてですね」と発言したところ 「オンライン飲み会で喋ってみてはいかがでしょう」とお声がけいただきまして、レビューをいただくことができました。 誠にありがとうございます。

この時の内容は、特定のIPに寄せて書いた内容となっていたため、外部公開する予定はございません。

修正してみた

↑のレビューでコメントしていただいた内容を取り込んだ資料が、↓です。

f:id:trickmr:20180218172336j:plain

実際に書いて見た感想として、文字情報で仕様を羅列するよりもビジュアルに訴えることができるため、「抜け漏れに気づくことができる」という効果を実感できました。 特に、毒状態から毒状態への矢印など、「状態が変わらないことを確認するための矢印」が抜けてしまっていたので、これに気づけたことが大きかったと思います。(レクチャーで同じ内容を伺っていたにも関わらず、最初は書けていませんでした)

困ったこと

実際のRPGでは、毒状態以外にも複数の状態が同時に存在するため、それをどう表現するかが難しいと感じました。 たとえば、毒状態で(毒に関係のない)バフ・デバフを行った場合、毒状態は維持されつつ、そのバフ・デバフの効果は発生しなければなりません。 やや冗長にも思いましたが、「毒→毒」「猛毒→猛毒」の線について、項番を設けてバフ・デバフを表現しました。

困ったこと　その2

毒/猛毒を取り巻く「別の状態」について、どこまで資料に盛り込むかを悩みました。 結論として、今回は「死亡」と「鉄化」という2つの状態について、毒/猛毒に関係する矢印のみ作図しました。 例えば、実際には「死亡→死亡」や「死亡→通常」という状態遷移がありえますが、今回テストケースとして整理したい情報はあくまで「毒/猛毒」に関する状態遷移ですので、意図的に書きませんでした。

今後について

次回は、上記に続いて状態遷移表を作成してきたいと思います。