JaSST'20 RejectConに行ってきた

ピースオブケイクさんで、JaSST Tokyoに残念ながら落ちてしまったプロポーザルを供養するイベントがあったので、供養に参加してきました。イベント概要はこちら。
connpass.com

noteでのテスト自動化に関する取り組み（ピースオブケイク・増原さん）

※ちょっと遅れて到着したので、講演途中からのメモです。

• MagicPod使ってる
  • クラウドシミュレータでシナリオが作れる
  • サポートが速い

• 分かったこと
  • エンジニアを巻き込むの大事→はまりどころに二人で立ち向かえる
  • PR単位のFBになると実行時間長め
  • リリース前のテストで変更箇所に集中できる

Flow理論に学ぶレベルアップの鍵（Mark Wardさん）

リベラル・アーツの世界

リベラル・アーツはRIPPAなものを作るのに必要
フローはレベルアップの鍵。
強い状態（フロー）

• 楽しさ、幸福感
• 集中
• 複雑さ：込み入った問題を解くこと

→フロー状態は能力と挑戦が釣り合っている状態。釣り合ってないと不安だったり退屈だったりする。

• メンタルステート図
  • 挑戦と能力の度合いによって、心理状態にどう変化があるか
  • 挑戦ルート：不安→覚醒→フロー。フローに至るまでの速さは、理解の速さやスタート地点の差による
  • 能力ルート：くつろぎ→幸福→フロー。コントール感があるが、時間がかかる

→頑張れないなら、頑張り方を変える必要がある。それには組織の理解と協力が必要

WebアプリケーションE2Eテスト自動化の3つの壁（末村さん）

自動化の現実

自動化は進んだものの

• バグを検知できない
• 思ったより高頻度で実行できない
• どうでもいいところでコケまくる

バグ検出できないことへのアプローチ

• 網羅性が低い
  • スナップショットテスト：HTMLの差分を比較（Jestとか）
  • ビジュアルリグレッションテスト：スクショを比較（CodeceptJSとか）
  • 実行時エラーを検知

実行速度問題へのアプローチ

• テストデータをAPIやコマンドで作る
• 通信部分だけ実行する
• 状態をキャッシュする：ログインを毎回やるのはつらい
• 並列実行（Zalenium、Selenoidなど）
  • 注意点：何度実行しても同じ結果になるようシナリオを作っておく必要あり

安定性へのアプローチ

• 失敗したステップをリトライする
• シナリオをリトライする
• 不安定性を可視化する（Allure Reporterがいい）

まずはE2Eは難しいことを理解する

• E2Eでしかできないことに注力しよう

おまけ

• Playwright（https://github.com/microsoft/playwright）
• AppliToolのUltragast Grid（https://applitools.com/ultrafast-grid）

プロダクト開発におけるアジャイルQA活動（生井さん）

不採択の理由を踏まえる

• 品質は健康診断*アジャイル開発→最近QAとお医者さんの話題も上がってるし着眼点は悪くなかった
• 査読コメント
  • チームに展開した結果はどうだったかの事例がききたい（説得力）

伝えたかった事

• 開発に終わりはない：プロダクトは成長・複雑化していくが、テストリソースは同じ勢いでは増加しない
• 広さ*深さに加えて時間
  • 広さ：品質特性を軸にどこを見るか
  • 深さ：どこまで見るか
  • 時間：適切に発見できるか
  • 時間*深さ　素早く検査できるか、頻度を意識する必要がある
• ソフトウェアテストの海はとても広い
  • 物量が膨大になった中でどう理想に近づくかが腕の見せ所

当たり前のことを当たり前にやる

テスト？自動化？それよりもQA/QCの業務とは（仮）（gremitoさん）

プロダクトに最もあう品質チェック作業を模索または最適化

QA/QCのリーダーシップ
QA:品質保証
QC:品質管理

終盤にいくら頑張ってもバグをつぶせない

• 開発メンバとのコミュニケーションはとっていたか
• テスト計画は開発の序盤あたりから始められていたか
• 開発のMTGに参加して状況を把握しているか

開発チームの中にQAメンバがいる
QAは初めの方から参画する
品質チェックに入る前にテスト計画とテストケース作りを終わらせる
→開発チームの一員

ウォーターフォール（V字）開発でモブ設計してみた（t_isekiさん）

問題点

• 開発者が特定のモジュールを設計、開発する
• システムテストフェースで後戻りが大きすぎる

実現したかった事

• やり直しを減らしたい

なぜモブか？

• ファシリテーションが難しい（めくら承認、設計した人が悪者に）
• 作業管理が面倒
• 問題 vs 私たちの構図にしたい

モブ設計

• 準備
  • 主担当が章立てを容易
  • 章立てに対して気になることや注意点などを参加者がメモ

• 実施結果

＜Good＞

• 要件や設計思想の統一認識
• ドキュメント整備
• テスト設計のシフトレフト
• 当事者意識が芽生えた

＜Improve＞

• 長時間やるとだれる

感想

テストに対して、リベラルアーツや自動化やチームのお話など、色々な切り口からの発表があって、どの発表も楽しめました！　本当にこれRejectなのかと思うほど、素敵な内容でした。企画、登壇者、スタッフの皆様ありがとうございますー！

「テストの宿泊型ワークショップWACATE2019冬参加報告」で参加報告してきました

先日WACATEの参加報告会が、ビズリーチさんのD3で行われ、私もそこでLTをさせていただきました！
イベントの詳細はこちらからどうぞ。
d-cube.connpass.com
当日の様子はTogetterにまとめられてるので、雰囲気を知りたい方はこちらもどうぞ！
togetter.com
WACATEのテーマの一つに「加速」があるのですが、どの方のプレゼンも加速感あふれてて素敵でした。

K氏「開発者からQAになった話　とWACATEに行ってきた」

概要

• 知識量は土台、思考力がより良い結果を導ける
• テスト技法とかの土台があって、思考力によってより良い結果を導く。知識と思考のバランスが大事。
• プロセス改善もQAの業務。リリース後の問い合わせのパンクを防げたりした。
• 業務フローを把握していればシナリオテストに流用できる

感想

開発、QA、PM的な立場を経験されている方なので、それぞれで得た見方を、役割を変えても生かしてるところが素敵です。QAから改善のボールを開発に渡して、開発者が続けてくれてるのがすごいなと思います。

たおかさん「WACATEにより爆発的に加速したQA歴3か月の新卒の話」

なんと初LTとのこと！

WACATEにより爆発的に加速した QA歴3ヶ月の新卒のお話 from ssuserd00212

概要

• 新卒3か月目「QAだったらどうする？」開発者の質問に答えられず。→自分に自信がない。QAとして情けない。
• そんなとき、上司から「WACATEってイベントがあるよ！」
• お気に入りのセッションソフトウェアテストの7原則
  • https://speakerdeck.com/nihonbuson/seven-testing-principles
  • 「テスト完了することがゴールとなってしまい、品質保証（QA）がおろそかになっていた」と気づいた
• 参加後、自分で考えて動けること
  • 目の前のことではなく、その背景や理由を念頭に対応する
  • 言語化して誰かに表現することにより、真に自分の理解が深まる

感想

新人でWACATEに参加して、さらにLTまで立候補する加速感が素晴らしすぎる！　（自分が新人のころをふりかえると、日々の業務でアップアップでそこまでのチャレンジ精神はなかったと思います）
素敵なのは、自分で「テスト完了することがゴールになっていた」と気づいたことだと思います。内容も素敵だったし、初LTとは思えないくらいに堂々と発表されてました！

かなさん「WACATEに参加すると・・・？」

概要

• WACATE参加前「なんとなくテストケースを書いて、なんとなく実施する人」
• 参加した後
  • 言語化大事と気づいた！
  • なぜを常に考えるようになった
  • 社外に相談できる人ができた！
• WACATEではワークはうまくいかなかった。プロダクトの特性を考えずにテストしようとしてた。
  • しかしWACATEは業務でないので失敗できる。失敗をもとに加速できる！
• 自分のプロダクトで大事なものはなんだ？を考えて社内の同じチームの人に話せるようになった

感想

スライドをご覧になっていない方は、ぜひスライド見てください！　かなさんのイラストや図がとてもかわいいくて引き込まれます！　
WACATEの説明や、雰囲気などが伝わってきて、とても素敵なプレゼンでした！　WACATEについてやセッションの説明もとても丁寧で、WACATE未経験者にはすごく伝わりやすいプレゼンだったのではないかと思います。

02さん「WACATEとテストと開発エンジニア」

概要

• 参加の動機：品質悪いと上司に言われて夜泣いた→自分で品質を良くするために勉強したい
• 品質やテストについて一緒に勉強する仲間が欲しかった
  • とにかく手を動かして勉強したい
• セッション中の学び：ただ覚えるだけでは得られない経験・知識を得た
• 自分一人では理解できなかった分野を理解できた
• WACATEは一つのコミュニティ
• WACATE後
  • テストやテストコードをテーマに登壇するようになった！
  • 知識：ある程度実践した見たものばかりに！
  • アウトプット：たまにテストのテーマで登壇するように
  • テスト仲間：Twitterフォロワーの1/3！

感想

WACATEで得た仲間のことを「社外の同期」や「WACATEは一つのコミュニティ」と言っていたのがとても印象に残りました！　私の感覚としても、すごく実態に合ってる素敵なワードチョイス。「同期」という言葉が、気軽に相談できて、一緒に切磋琢磨できる感じを表してて本当に素敵です。
プレゼンの進め方も、ゴールの提示がはっきりしていてわかりやすかったです。

信頼貯金さん「WACATE参加報告　～WACATEに参加した前後で何が変わるのか～」

2019wacatehuyu sinraityokin from masatsuguH

概要

• WACATEとは
  • テスト活動の基礎からアドバンスドまで扱う
  • 分野の知見を豊富に持つ人から話を聞ける
• ワークや分科会で一気通貫で理解が深まる
• WACATE 2019夏
• テスト計画の誤った理解をアンラーニング
  • 「計画は守るために作るものだ」から、計画は手段、プロジェクトの狙いを反映していい、に変わった
• テスト計画を守れないとき、できないときはできないと言っていい。それはチームで解決すべき問題
• WACATE冬、テーマが多い。すごいポテンシャル
  • 複雑なモデリングは苦手な印象。思考が整理できない
  • →井芹さんが丁寧にモデリング
  • できるものなんだ！難しい問題こそモデリングを使おう
• 自分一人では到達できないできないところに到達できる！

感想

テスト計画に触れたところで「テスト計画を守れないとき、できないときはできないと言っていい。それはチームで解決すべき問題」と話されてたのが印象に残りました。「アンラーニング」がキーワードなのかなと思いますが、こう思えるようになった学びが素敵です。

shiromoto「WACATEで得たものとその活かし方」

Wacateで得たものとその活かし方 from Yuki Shiromoto

発表の感想

WACATEの参加動機、駆動方法は色々ありますが、その一つに「カープ優勝駆動」というものがございますｗ　勢いでも何でもいいので、飛び込んでみると世界が開けるよ、という話だったのですが、もし誰かの背中を押せてたら嬉しいな、と思います。WACATE参加で仲間が増えるのは、本当に参加のメリットなので、迷ってる人がいたらぜひ一度参加をお勧めします。

きんぢさん

概要

WACATE実行委員の宣伝のセッションでした。
WACATE実行委員をやると、次の力が身に付くそうです。

• アウトプット
• プレゼン構成力（少しずつ解像度を上げていく）
• 合宿の企画力
• 仕組化・自己組織化
• 実行委員はいいぞ！

感想

WACATEで参加者が解散した後、片付けや次の予約、次の次の仮予約まで済ませてくださってるという実行委員の方々には、感謝しかないです。毎回ありがとうございます！
WACATEで得たものを日々の業務で活かしたり、悩んでるテストエンジニアにWACATEを進めたりで、恩返しや業界への貢献をしていきます。

「数学ガールの秘密ノート/学ぶための対話」は、学生時代に数学をパターン暗記で乗り切ってしまった人にお勧め

昨年参加したソフトウェアテストの合宿形式の勉強会・WACATEのお楽しみ抽選的なイベントで『数学ガールの秘密ノート/学ぶための対話』をいただきました。

数学ガールの秘密ノート/学ぶための対話 (数学ガールの秘密ノートシリーズ)

色々とぐさりと来るところがあったので、ちょっと感想などを書いてみます。なお、数学ガールはシリーズものですが、私はこれ一冊しかまだ読んだことがありません。

この本をお勧めしたい人

数学が苦手で、パターン暗記で乗り切った人にお勧めします。私はほぼパターン暗記で学校の数学を乗り切ったタイプです。

なぜお勧めできるか

私は数学が苦手です。苦手な理由は、恐らくですが中学・高校時代に数学を理解せずにパターン暗記で対処していたからではないか、とこの本を読んで思いました。

本の中で何度か主人公で数学の得意な「僕」は、数学を教わりに来てる「ノナちゃん」から「暗記しますか？」と聞かれます。暗記ではなく理解するよう主人公は諭すのですが、まさに暗記してたのが昔の私です。たぶん今もその傾向は続いていると思います。

パターン暗記の問題点

自分の場合ですが、パターン暗記のやっかいなところは、パターン暗記で教科書の理解確認問題や中間テストは対処できるので、理解できてないことに気づきにくい点でした。そして、単に覚えているだけなので、当然忘れていきます。

範囲の広い実力テストなどになると、中間テストに比べると正答率が劣るので、うっすら「実は分かってないかも？」と疑います。その時に理解するよう動けばよかったんだと思いますが、今思うと、自分の対処は「暗記するパターンを増やす」と「反復練習して記憶から抜ける量を減らす」でした。受験対策としては間違ってないんですが、理解が進んだかといえば、ちょっと怪しいです。

この本のお勧めなところ

この本では、言及されている数学の範囲は、一次関数とグラフのみです。それだけなので、パターン暗記で覚えてしまおうとするとすぐ済む内容なんですが、暗記ではなく理解を促すように話が進みます。ちょうどパターン暗記してしまいそうになるあたりで、ノナちゃんが「暗記しますか？」と聞いてくれます。自分も暗記に走りそうになっていたことに気付けるので、ノナちゃんと一緒に意味を考えながら読めるようになっています。

数学をパターン暗記で乗り切った人が、意味を理解するってなんだろうと思いながら読むと、ちょうど良い本だと思います。

WACATE2019冬「あなたの番です」参加レポート2日目！

2日目レポートも行ってみまーす。

三浦海岸の朝焼け

モーニングセッション：Agile Testing Days 2019 参加レポート

（ブロッコリーさん）
資料はこちら！
speakerdeck.com
Agile Testing Days：ドイツのポツダムで11月に毎年開催、全日程6日間、参加費は約30万円。
800人くらいが参加する。キーノートだけで14個！本会議のセッションは9レーン。
セッションには認知科学や健康がテーマのものもある。
「人間てのは壊れた櫛だよ。人それぞれ得意不得意がある。だからチームとして動くといいよねー」みたいなこと主張してるセッションがあったり、ホームズとワトソンになりきってるセッションがあったり、着ぐるみで発表しようとしたけど暑くて開始3分で脱いだり、とか多様すぎる。ドイツと南アフリカにすむ二人が学習パートナーシップを組んだ結果、毎日カンファレンスに参加している気分になった！→距離について言い訳するのはやめようぜ！

感想

国際カンファレンス楽しそう！特にAgile Testig Daysはフリーダム度が高くて面白そうなのが伝わってきました。資金面は何とかするにしても一度行ってみたいですね。なお、手軽に国際カンファレンスを楽しむ手立てとしては、OnlineTestConf Japanもございますので、よろしくお願いします（宣伝）！

アジャイルとテスト

（つのださん）
資料はこちら！
speakerdeck.com

アジャイルについて

世の中の流れが速い、ニーズをそもそも完璧に確定するのが難しい

• アジャイル向きなシステム：外部要因に大きく影響を受ける
• アジャイル向きでないシステム：不確実性があまりないシステム。ミッションクリティカルとか
• アジャイルソフトウェア宣言→ソフトウェアをよりよく作るための考え方

アジャイルのテストについて

アジャイルのテスト→フィードバックを得るため

• 頻繁なコミュニケーション
• 手戻りを減らすための複数人同時作業

感想

アジャイルに向くもの、向かないものの説明も含めて、短いけど丁寧にアジャイルとテストをまとめてもらえたセッションでした。アジャイルのテストは「フィードバックを得るため」は、確かにそうだなーと思います。自分の現場でも、フィードバックを早めるための施策は試行錯誤してるので、レビューでのフィードバックなど地道にやっていきます。

ソフトウェアテスト業界でのステップアップを考えよう

(きんぢさん)
資料はこちら。

WACATE2019冬 ソフトウェアテスト業界でのステップアップを考えよう #wacate from Kinji Akemine

www.slideshare.net
メモも貼っておきます。

感想

「品質 is 何」や「3年後どうなっていたいか」のような問いかけで、班のメンバーから本当に現場に応じたいろいろな意見が出てきて面白かったです。自分にとっての品質は、「ユーザがシステムで解決したいことを解決できている」とか「やりたいことをより簡単に、楽にできるようになっている」とかだと考えています。これが医療機器とか自動車とかに携わる方になると、「人が死なないこと」とかが出てくるのだなーと自分にない視点が出てきて面白かったです。
テストの分け方はテストレベルやテストタイプ、自動化などいくつか種類があるので、この後のキャリアのために自分がどの位置で仕事しているのかを把握するのは重要だと思いました。キャリアマップを作りたいなーと思っているので、このセッションからヒントをいくつかもらえた気がします！

WACATE流勉強会の作り方

（えっちゅーさん）

• 勉強会をやるとよいところ
  • プロジェクト運営の疑似体験ができる
  • アウトプットすることで思考の整理、分かるところ分からないところの明確化ができる

• 勉強会をやるのに考えること

時間

• 必要な時間は？
• 会場、準備にかかる工数

会場

• 人数と会場の広さ
• 必要な設備が整っているか
• 開催希望日に利用ができるか

事前準備

• 参加者に事前にやってきてもらうと嬉しいことは？
• 持ってきてもらいたいものはある？

開催回数

• 今回限り？　何度も開催する？　定期/不定期？

対象者

• どういった人に参加してもらいたい？

運営にかかるお金

• お金をかけずに開催できる？　かかる場合、何にどれくらいおかねがかかる？
• 必要な金額はどうやって集めるか？

登壇者

• 自分たちが話すか、講演者を呼んで話してもらうのか？

感想

WACATEに限らず応用できる話ですが、WACATEの実行委員の方々がすごくこだわって勉強会を作られてるのが伝わってきました。ここまで考えてくださってるの、本当にありがたいです。
自分が主催した勉強会で、テーマ設定と参加者のレベル感を上手く合わせられず、ちゃんと勉強会の設計しておけば良かったと後悔したことがあるので、次に活かします。

招待講演：テスト設計をより良くするモデリングと観点分析

資料はこちら！
speakerdeck.com

感想

講義のために簡略化されたとはいえ複雑なテスト対象をモデリングして、リスクまでクリアに見えてく様子がすごく綺麗でした！あれを自分でできるようになりたい。
モデリングはわりと難しくとらえてたところがあるのですが、比較的簡単なものはテスト技法ですでに使ってるというところで、ちょっと勇気が出ましたw　にしさんの「絵(図だったかも？)を描け」に通じるところがあって、本質はたぶん同じことを言ってるのではないかと思いました。
モデリングで知識の部分はごく一部で、目的に応じて使い分けるところが難しいと感じます。テスト技法自体は知っていても、現実のどの場合にどの技法を当てはめればいいのか、すぐには判断つくようになりませんでした。要件レベルになると経験があまりないので挑戦になりますが、ここができるようになるとビジネスに貢献できる幅が広がるので、自分としては今後の挑戦のしどころです！

2日間を通じての感想

テストに情熱を持つ方々とワークしたり、お話したりできて楽しかったです！場を作ってくださった実行委員の方々、話してくださった参加者の方々ありがとうございます！
今後やりたいことへのヒントがもらえました。息切れしないようにちょっとずつ加速しますw Twitterアイコンとご本人が一致した方が増えたのも嬉しかったです。またどこかの勉強会でお会いすると思うので、よろしくお願いします。

WACATE2019冬「あなたの番です」参加レポート1日目！

ソフトウェアテスト業界にはお馴染みのWACATEにやってまいりました！

若手（若手じゃなくても）が手を動かして学ぶ2日間合宿形式のワークショップです！さあ、加速できるかな？

BPPセッション

(はるにゃんさん)
何も言わない。これを見てくれ。

石油王に敬意を表して、私にしてはグラフィックなグラレコになりました。
BPPをとるために戦略的に考えて、インパクトに残るポジションペーパーにしているのかの過程を説明してくれて、すごく分かりやすかったです。人生初の登壇だったそうですが、間の取り方もうまくて何度も爆笑が巻き起こったセッションでしたｗ
テストラジオでもBPPセッションの裏話が紹介されているので、ぜひこちらも聞いてください！
testradio.fm

業務でも活用できるソフトウェアテストの7原則

(ブロッコリーさん)
資料やセッションの経緯は、ブロッコリーさんがブログで公開してますので、ぜひこちらでどうぞ。
nihonbuson.hatenadiary.jp

感想

ワークは、実際にテストの現場でありそうな会話から、テストの7原則に反してそうなものを見つけるという内容でした。ワークのまとめで言及されていたのですが、テストの7原則を理解した上で、「7原則があるからと言って、正義を振りかざすべきタイミングを見極める。原則に沿えない場合もあるので話を聞いて障壁を取り除く」ことができるのが重要だと感じました。次のワークでも感じましたが、相手を詰めても前に進めないので、7原則は、背景などを話した上で「じゃあどうするか」を考えるための材料にするべきものですね。

物語を想像して問いを立ててみよう

(かおりっとさん)
資料はこちら！
speakerdeck.com
「問い」をうまく活用して、相手の考えていることを紐解いていくセッションでした。
ワークで実施した内容は次の通りです。

• 相手に何かを思い浮かべてもらう
• 相手が思い浮かべたものを当てるために、「問い」をしていく。ただし「問い」で使えるのは、Yes/Noでこたえられる質問のみ。
• ワークでは時間が限られるため、実行委員が用意してくれたテストに関するキーワードの中から「答え」になるものを選ぶ
• 質問は5個まで

実際にやってみると、色々な想定外が発生し、思った以上に難しかったです。

• 「問い」を立てるって難しい
• 自分が「問い」で使った言葉で相手が同じものをイメージしているとは限らない
  • 「イベント」という言葉でWACATEやJaSSTを想定していたけど、相手は「レビュー」などの粒度で想定していた、という例があった
• キーワードの中から答えを選ぶ形式で、選んだものが同じ事態が発生。同じものを選ばないだろうというバイアスが働き、答えを当てられなかった

感想

問いって本当に難しいなーと感じました。問いはうまく使わないと、相手を詰めてしまう凶器になりかねないとは思ってます。ワークの短い間でも、背景のずれやバイアスがかかったりとかを、ちゃんと意識できる状態で体感して、「ここまでずれるものなのか！」という実感が持てたのは大きいな、と思います。
「自分たちのシステムを使う人はどういう人だろう？」と考えるときとか、何かの認識ずれでバグが発生してしまった時のふりかえりとかで「問い」が使えそうな気がしています。

形式手法ってなんだろう？

(べにさん)
speakerdeck.com
形式手法は数論理学に基づいた手法。

• 仕様を厳密に書ける、明確に意味を一つに絞れる
• プログラミング言語そのまま？　いいえ、実装ではなく仕様を記述することが可能です

形式手法のいいところ

• 仕様を厳密に書ける
• 実装ではなく仕様を記述できる
• 実装前に検証が可能
• 何が複雑なのかを把握できる

感想

形式手法は、基礎知識がないと難しいと感じました。例を真似すれば書けはするのだけど、自分が何を書いてるのかわからなくて同じチームの方に解説してもらいました。チームメンバに助けてもらえるの良かったです。ただ、すみません、形式手法は私には早かった。。。あまり理解できてないので要復習です。。

ディナーセッション、夜の分科会

美味しいごはんを食べたり、飲む人はお酒をいただきながら夜23時までテストについて語り合う変わり者たちの宴です！　夜の分科会では、よしたけさんのテスト観点共有会のセッションに参加しました。電話番号に関する観点を出し合ったのですが、みんなで観点を出し合うと、自分にはない観点をもらえたり、相手の出した案に乗ってそれをより深められたりというのが面白かったです。
成果物はこちら。

テスト観点共有会の詳しいやり方は、よしたけさんのブログをどうぞ！
yoshitake-1201.hatenablog.com

おまけ

WACATEはご飯も美味しいですよ！


三浦半島の海の幸を堪能する意味でもぜひWACATEへ！

テストマネジメントツールを適用する前に考えること

この記事は、ソフトウェアテスト Advent Calendar 2019の10日目の記事です。
qiita.com
前の記事はこちら。
halspring.hatenablog.com
9月にいくつかテストマネジメントツールについての勉強会に参加して、考える機会が多かったので、ちょっとアウトプットしてみました。参加したイベントはこちら。
connpass.com

テストマネジメントツールとは

テスト管理ツールは、主にテストケース、テスト実施結果（OK/NG/再実施など）、進捗、実施履歴などをWebで管理するツールです。要件管理はあるものとないものがあります。呼び方は「テストマネジメントツール」だったり「テスト管理ツール」と呼ばれていたりします。

導入時に考えること

テストマネジメントツールに限らず、ツール導入の際にはいくつか事前に考えておくべきことがあります。

• ツールで解決したい問題は何か？
• ツール導入でメリットは得られるのか？（デメリットの方が大きくなることはないか？）
• ツールが課す制約がこれまでのテストのフローを妨げる場合、それを許容できるか？
  • 導入時には「ツールで解決したい問題」に目が行きがちですが、「ツールが課す制約」についても考える必要があります。これについては後で述べます。
• コストはどのくらいか？
  • 初期費用や月額費用
  • 導入にかかる教育コスト
  • 運用コスト（手順を整えたり、オンプレやOSSの場合は自前でメンテナンスするコスト）

導入してメリットがある条件

ツールのメリットを享受するための前提はあまり触れられてないなと思ったので、自分なりに整理してみました。なお、テストマネジメントツールを使わない場合、テストケースの管理はExcelやスプレッドシートで行われることが多いので、比較対象はスプレッドシートとします。

複数人で使用すること

利用者が一人であるなら、次の理由からスプレッドシートでよいと思います。

• 管理対象とするテストケースや結果が、自分で把握、説明できる分量に留まると予想される
• すでにスプレッドシートで運用しているなら、学習コストや利用フローの整備、ツールの利用料などのコストを払うのに見合わない
• 古のExcelの場合、複数人で操作してファイルが壊れることを想定しなくてよい（それでも「予期せぬエラー」で壊れる場合は想定しておいた方が良い）

テストケースの再利用を前提としていること

テストマネジメントツールは、テストケースの「普遍的な部分（実施手順、確認内容など）」と「テスト毎に毎回変わる部分（実施予定日、実施予定担当者など）」を分けて管理できます。普遍的な部分を資産として持っていて、そこからテスト実行ごとに「テスト毎に毎回変わる部分」を付加して、「テストインスタンス」を生成するイメージです。湯本剛（@yumotsuyo）さんの資料の説明が分かりやすいので、引用させてもらいました。

20190906 practitestslideshare from Tsuyoshi Yumoto

資産化しておくことでテストケースの複数回の利用を容易にしているのが、テストマネジメントツールの利点であるため、単発でしかテストケースを使わないのであれば恩恵は大きくはないと思います。
テストケースを再利用することを前提とすると、テストマネジメントツールの恩恵を受けやすいのは継続して開発、リリースする案件で使うことだと思います。条件に合う案件は、自分の観測範囲では自社サービス、ツールの開発案件が多い印象です。
単発の案件であっても、同じような案件が複数あるのであれば、観点とか項目といったナレッジの蓄積を目的として使うのは意味がある気はします。

ツールが課す制約を許容できるか

制約というちょっと強い表現を使いましたが、ツールを導入することによって今までと作業フローが変わったり、不便なことが出てきたりするが、それを許容できるか、という観点です。これ以下の内容は、私の主観が強いので当てはまらない場合もあると思います。

前提

私が触れたことのあるテストマネジメントツールは、Squash TM、TestRailの2つ、あとはKazu Suzuki（@kz_suzuki）さんのブログでPracti Testを少し眺めたくらいです。
www.kzsuzuki.com
そのため、それら2つ(+1つ)をベースにして、スプレッドシートでの運用と比較しています。
スプレッドシートでのテストケースの運用時には、「ID、テストケース名、手順、期待結果結果、実施予定日、実施予定担当、実施結果」を1行で管理しているものと仮定します。

テストケースの一覧に見るテストマネジメントツールとスプレッドシートの比較

テストマネジメントツールとスプレッドシートでは、設計の思想が違います。テストマネジメントツールは、もちろんテストに関するあれこれ（要件、テストケース、実行結果など）の管理を目的として作られたツールですし、スプレッドシートは表計算を主眼として作られたツールです。
テストマネジメントツールとスプレッドシートでテストケースを作成する場合、テストケース一覧の表示内容、運用に差が顕著に出ていると思ったため、次の項目について比較してみました。比較したのは、「前提」でスプレッドシートでの運用時に管理対象として仮定した「ID、テストケース名、手順、期待結果結果」とプラスアルファです。「実施予定日、実施予定担当、実施結果」については、テストマネジメントツールの場合、テストケース作成の段階で管理しないため省略しました。

比較対象	テストマネジメントツール	スプレッドシート
ID	〇	〇
テストケース名	〇	〇
優先度	〇	△
手順	×	〇
期待結果	×	〇
表示項目のカスタマイズ	ツールで表示対象に設定できる項目のみ	追加が可能（組織でテンプレートとして定められている部分を除く）
一覧に表示できる行数	制限あり（TestRailでは2000行だった）	スプレッドシートの限界までは理論上可能

凡例：
〇：デフォルトで表示対象、記載対象とされている
△：デフォルトではないが、多くの場合表示/記載あり
×：なし（表示できる対象として設定されていない）
　　補足：テストケース名から参照的に手順、期待結果を表示することは可能。ただし選択した1ケースのみ。

テストマネジメントツールの導入で変わる部分

スプレッドシートでの運用している時と比べると、変わる点は次のようなものがあると考えています。

• 手順、期待結果をレビューする場合、テストマネジメントツールではテストケースの一覧上でできない
  • 手順、期待結果を含めたCSVなどでのエクスポートは可能
  • ただし、ツールによってはテストケース名の一覧と手順・期待結果の一覧は別のシートで出てきて多少見づらい
• テストケース名で、テスト内容の分かりやすいサマリを表現することが求められる
  • 期待結果が一覧上でも見えていれば、テストケース名を多少適当につけていても、テストの意図を補完できたが、それができなくなる
  • スプレッドシートでもテストケース名を分かりやすくつけていた場合は従来と変わらない
• 一覧に表示する項目をカスタマイズできない
  • スプレッドシートだと、運用上の良し悪しは置いておいて、欄外にメモ欄など追加できたが、ツールではできない

上にあげた例では、スプレッドシートでの運用に問題があるものもありそうですが、ツールの導入によって、今まではできていたことができなくなることは考慮する必要があります。

まとめ

テストマネジメントツールは、ツールのメリットを出せる状況下で使えば、効率化を素晴らしくサポートしてくれるものだと思っています。ただ、ツールの導入には利点だけでなく、従来はできていたことに制約がかかるパターンがあるので、制約を考慮した上でもなおツール導入のメリットがあるのかは考える必要があります。

福岡で小早川隆景、乃美宗勝の足跡巡り+柳川で立花氏巡り

JaSST Kyushuに行くついでに前日ちょっと早く福岡入りして、私の好きな戦国武将である小早川隆景と乃美宗勝ゆかりの地を巡ってきました。

宗勝寺

乃美宗勝のお墓のあるお寺です。

福岡の交通網が集まる天神からバスで20分程度で到着します。近所には毛利氏の勢力と大友氏の勢力が攻防を繰り広げた立花山城があります。宗勝公は朝鮮出兵時に病を得て、九州に戻ってきてこのあたりで亡くなったと伝わっています。ごく普通のお寺なので、本堂に軽く参拝してから宗勝公のお墓へ。

本堂左手の細い山道を通って向かいます。地蔵堂らしきところの裏手を通ってさらに山の中へ。

落ち葉がこんもり積もり、ところどころで倒れた竹が邪魔をしてきます。案内板が順路はこちらと示しているし、道はこれ以外にないので乗り越えて進みます。ちょっと愛を試されてる気分のする道でした。雨が降ってたら引き返してたかもしれませんw曇りぐらいで本当によかった。あと夏だと虫が多そうなので、冬でよかったです。

ほどなく重臣のお墓へたどり着きます。

この奥に宗勝公と奥様のお墓がありました。

向かって左のお墓に「宗勝寺殿」「勝運」の文字がありますので、こちらが宗勝公ですね。

なかなか福岡までくる機会がないので、今回お参りできてよかったです。基本的に曇ってたのですが、宗勝公のお墓の前に来た時にちょうど晴れ間が来たのも嬉しかったです。偶然晴れただけとは思いますが、なんか「よく来たな！」って歓迎された気分になれました。

筥崎宮

日本三大八幡といわれる筥崎宮にお参りしてきました。こちらは小早川隆景によって楼門が造営されています。

元寇の際に敵国の調伏を祈ったことから「敵国降伏」の額が掲げられています。筑前は豊臣政権期に小早川が領有していたので、こちらの筥崎宮や太宰府天満宮に隆景公の足跡がちょこちょこ見られます。今回は太宰府まで足を延ばせませんでしたが、また太宰府にも訪れたいと思います。

柳川藩主立花邸御花

筥崎から足を延ばして柳川まで行ってきました。

ほぼ佐賀の隣なので、筥崎から移動すると1時間強かかります。正直1日に詰め込みすぎな気はしましたが、目的は好きな戦国武将である立花宗茂ゆかりの資料館を見たり、ウナギのせいろ蒸しを食べたりすることでした。

柳川藩主立花邸御花は、明治維新以降に華族となった立花家の邸宅が公開されており、同じ敷地内にレストランやホテルも建っています。現在も立花家が経営されています。旧大名家、華族の多くが、明治維新や戦後に資産を手放されたことを考えると、現在も経営されているのはすごいことなのでは、と思います。

さて正面から入ると、瀟洒な洋館が迎えてくれます。

敷地内のレストランでウナギのせいろ蒸しをいただきました。レストランのナプキンに立花家の家紋が入っていて、この時点でテンションがあがります。

せいろ蒸しは蒸し上がるのにちょっと時間がかかるので、その間に洋館内部を見学しました。伯爵家にふさわしい格式のために、意匠に凝っているところや、家族だけが使うためシンプルに作られているところなど丁寧に解説されていて、興味深く見学できました。柳川名物のさげもんが飾ってあって、写真を撮れるスポットなんかも準備されてました！

さげもんの拡大したものがこちら。色とりどりでとてもきれい。

洋館部分と接続して和風建築も建てられており、そこからはお庭が眺められます。縁側、とよぶにはちょっと規模が大きい気もしますが、縁側もあるのでのんびり庭を眺めながら一息付けます。

別の建物からお庭全体と和風建築部分を眺めてみました。

見学を終えて戻ると、ちょうど蒸したてのせいろ蒸しがやってきました。せっかくなので奮発して、う巻きとうざくのついたおすすめセットにしてみました。

蒸してあるのでウナギがふわふわ、たれのしみ込んだご飯も美味しくてペロっと食べてしまいました。せいろの下部分は全部ご飯なのでかなり量はあるんですけどねwしっかり蒸しあげてあるためか、ごはんも最後まで温かい状態で楽しめました。

敷地内にある立花資料館にも行ってきました。立花宗茂所蔵の鎧や江戸期の大名としての立花家に伝わる華やかな大名道具が見ごたえありました。

特に宗茂所蔵の鎧は、一度見てみたかったので良かったです。腕の部分は全部鎖帷子風になっていて、シンプルで動きやすそうな印象を受けました。色々な逸話から、いざとなれば自分も前線に出て戦うタイプの方という印象があるので、何となく納得感のある鎧でした。宗茂公は70代で島原の乱に出陣して、有馬城の一番乗りをされた方ですからね。

個人的に小早川隆景と立花宗茂は、大河ドラマの主人公になってほしい歴史人物のNo.1、2なので、弾丸旅行でもこの二人にゆかりのある地を巡れてすごくよかったです！