JaSST'22 Tohokuに参加してきました！

5/27(金)に行われたJaSST'22 Tohokuに参加してきました！　開催地・盛岡で久々に現地参加してきたので、会場の熱気も感じられました。

会場のウェルカムボード。てす政宗がかわいい

基調講演

自動化に取り組むにあたり

松尾 和昭さん

講演メモ

• テストピラミッド
  • テスト自動化を進めるときは底から
  • 逆ピラミッドになると失敗しやすい
  • 実行サイズの例 過去の松尾さんの発表スライド

• スコープを区切る
  • テスト範囲を狭めることで、問題発生時の原因の特定を補助、実行時間の短縮などメリットが

• デモ
  • UI　40s
  • Integration　3s
  • Unit　0.001s

• 自動化を学んで行くために
  • 社内の助けを得ることが可能な技術から始めるとよいことが多い
  • OSS、公式ドキュメント

　　
Q. テストピラミッドの構築具合を可視化したい
A. やりやすいのは件数ベース。
　他には実行時間、UIテストの環境依存の失敗率、変更してないのに失敗しているテストの数

感想

テストの実行時間、対象の性質上差はあるのは理解してたんですが、あまり意識できてなかったので数字でぱっと見せてもらうとこんなに差が出るのかと驚きました。現状で自分のやってる範囲はUIがほとんどなので、目的と実現可能性を考えて範囲を分けられるようになりたい。

ランチセッション

• 松尾さんに実行委員の根本さんがインタビューしていく形式
• 事前に集めた質問がmiroに貼ってあり、インタビューが進むにつれてそこにグラフィックレコードが加えられていく
  • なぜアメリカに行ったのかの話からスキルの話まで率直に答えていただけた
  • グラレコが的確でイラストがかわいい。これをリアルタイムにやるの本当にすごい。
• 根本さんのぶっこんだ質問にも答えていただけて、ランチ時間も充実した楽しめるセッション！
• オンライン参加だとランチ時間はわりともくもくご飯を食べることが多いけど、これだとオンラインも楽しめて良さそう！

事例セッション

テスト自動化導入後の課題の改善のビフォアアフター

江村 禎昭さん

江村さんの発表資料はこちら。
qiita.com

講演メモ

• テスト自動化の利用状況
  • 毎日実施、各サービスは2~3週に一度リリース

• 小さいチーム（サービス）- マニュアルテスト
• チームの拡大- サービス複数、テストも並行
  • →各サービスのテストが不明確、自動化が仕様変更で失敗増える

• Phase1 組織が大きくなる- 自動化チームの役割がさまよう
  • 自動テストの責任の範囲を明確に
  • 既存リグレッションと、仕様変更で修正が入る既存機能
  • 新規機能は余裕があれば、プロジェクト内で終わらせる必要はなく次の仕様変更までに使えるようにという優先度を置く
  • テストが成功している限り気にしないが、実行時間がかかるようになってきた
    • 原因：テストデータ等が肥大化、テスト間の依存関係

• Phase2 テスト自動化の問題があるのに気づかない
  • データの蓄積、可視化

• phase3 オペレーションの問題
  • 失敗したときに調べる手間がかかる
  • テスト自動化の運用工数が、スクリプト数に比例する
    • 失敗の7割を占める一時的な不安定さの場合、AutoHealingの仕組みを作り再実行を自動化

感想

各段階で取り組まれている内容やさらっとAutoHealingの仕組みを構築してるのもすごいし、改善のビフォアアフターをちゃんと数値で出せるよう準備できてるのすごいですよね（つい取り組みを先にやっちゃってデータとってないことが多いという自戒を込めて）

リグレッションテストをほぼ１００％自動化した話

橋本 悠我さん

講演メモ

• 目的：リグレッションに4人日かかる。目標達成の一番のボトルネック

• 自動化前　テスト以降は一気にやっている（アジャイルになりきってない）
  • テスト結果のフィードバックが遅い
  • MagicPodと契約があった

• ステップ(もう少しあった気がする。メモ抜けてました)
  • 現状のテストの見直し
  • 環境の準備
  • 手動→自動へのテストステップ見直し
  • 実際の自動スクリプト作成

• 目的としていた部分以外の変化
  • 開発者からの信頼を得られた　E2Eが強力
  • PR単位で実行することでFBが速くなる

• いつ自動テストやるの？今でしょ！
  • 「最大のリスクはリスクを取らないことだ！」

感想

自動化取り組み前の現状の見直しや、手動のテストの見直しをきっちりされている点が良いなあと思いました。E2Eが強力で開発者からの信頼が得られるのも素敵な流れ。
あと講演最後のメッセージが熱くて素敵でした！

初めての自動化導入は慎重に、計画的に

二河 亮さん

講演メモ

• 当初の課題
  • デグレがたびたび発生
  • リソース不足でシステム全体のリグレッションテストができていなかった

• E2E初心者の壁　未経験ゆえの漠然とした不安感
  • 壁の原因の深堀

1. どう自動化するのかから考える必要あり
　　→小さな一歩から試す
　　テスト自動化にこだわらず身近な作業から自動化
　　効果が出た。壁が下がった
2. ノウハウがない
　　過去の失敗から学ぶ（アンチパターンの研究）
　　アンチパターン
3. コーディングスキルなどの技術不足による不安感
　　ツールベンダー（Autify）のサポートを利用
　　スクリプトに対する不安感も薄れる

• 不安感を解消していった結果、次のステップも明確になる

感想

不安なところを一つずつ解消していって結果につなげていく過程が分かりやすかったです。漠然とした不安感で止まってしまうことは自動化に限らず多いと思うので、不安に感じている理由を丁寧に分解して対処した点が素敵でした。

ワークショップ

あなたの1票が未来を決める、参加者投票式マルチエンディングストーリーなワークを行います。テスト自動化にまつわるストーリーを体験する、ゲームブック形式のセッションです。選択にDiscordを使用します。(JaSST Tohokuサイトより)

ワークだったこともあってあまりメモできてないけど、楽しみながら自動化の勉強できるよう構成されていてすごかったです。こちらのワークの内容は後日ゲームで公開されるとのことなのでワクワクしながら待っています！以下メモと感想。

• ゲームブック形式で自動化の進め方を学べるワークショップ
• 参加者の選択で自動化のプロジェクトが進められ、プロジェクトをハッピーエンドに導けるか？というストーリー
• シチュエーションと提示される選択肢があるあるな内容でリアル
• 参加者もある程度経験のある人の割合が多いからかだいたい正解の選択肢を選ぶが、バッドエンドが見たい勢が一定数いるようだったｗ（カバレッジ100%にしたいというか、ストーリー全部回収したいというか気持ちはよく分かりますｗ）
• 選択肢の内容について、なぜそれが正解と考えられるのか、失敗と考えられるのかの解説があり面白さと勉強と納得感があって工夫がすごい
• 「かまいたちの夜」をオマージュしたグラフィックも音声もあって演出が素敵

招待講演

テスト自動化の成功を支えるためのチームと仕組み

井芹 洋輝さん

井芹さんの発表資料はこちら
speakerdeck.com

講演メモ

• テスト自動化の目的
  • 妥当な対価で目的を達成すること
    • 費用・効果・目的が釣り合う

• 適切な目的を立てる
  • その時のチームにとって有益で実現可能な目的を設定
  • 広い活動スコープでも目的を設定する（テスト担当→開発＋テストに広げる→ビジネスを巻き込む）

• ステップバイステップで目的達成を目指す
  • 成功しやすいものから始める。持続可能性が重要
  • 自動テストにとってのテスタビリティを高める

• 費用対効果を改善する
  • 自動テストにとってのテスタビリティを高める
• テストの妥当性を高める　自動化する価値のあるテストケース

• 自動テストの内部品質を作りこむ

• テスト自動化の計画とアプローチを工夫する
  • リソース確保、リスクのコントロール
  • 自動テストの活用の頻度と幅を広げる
  • 自動化インフラに自動テストを統合する
  • 監視とコントロール、保守で自動手うとを維持・改善する

• テスト自動化の成功を支えるチームと仕組み
  • 開発とテスト

• • テスト自動化の成功を支えるチーム文化の指向性

　　1．チームのテスト自動化の能力を確保し高める
　　2. Whole Teamでテスト自動化を推進する
　　3. チームでの自動テストの責務を確立する
　　4. チームにとっての自動テストの価値を高める
　　5. チームで自動テストの持続可能性を保つ
　　6. チームでテスト自動化の動機付けを行う

感想

自動化の成功に必要なことを、担当→チーム→ビジネスと視野を広げていく形で整理・解説いただけて本当に良かったです。本当はビジネスの視点から考えられるのが良いと思うのだけど、担当の立場だとつい目の前のことに目が行きがちなので、この公講演で全体感をみえるようにしてもらえる感覚がありました。すごくよいお話だったのでJaSSTの次の月曜に早速社内に紹介しました！

全体的な感想

久々の会場参加でリアル拍手ができたのが、なんだか感慨深かったです。ついオンラインのイベントの癖で、ついセッションが終わるとチャンネルに「88888888」を書き込もうと思ってしまいました。
基調講演から事例発表、ワーク、招待講演まで自動化にどっぷり浸れて勉強になることが多々ありました。とくに招待講演の内容でそれまでの講演がつながって一つにまとまる感覚があってよかったです。

会場とオンラインのハイブリッド開催はとても大変だと思うので、実行委員の方々には感謝しかないです。素敵な会をありがとうございました！

おまけ

盛岡滞在時間は短かったので、あまりご当地グルメを楽しむ暇がなかったのですがドーミーインのご当地メニューにあった盛岡冷麺はしっかり食べてきました。キムチがいいアクセントになってて美味しかったです。

盛岡冷麺。ドーミーインの朝食はご当地グルメにも力を入れてるのがいいですよね。

城めぐり 中世武士の館・足利氏宅跡「鑁阿寺」

室町幕府の将軍家・足利氏の本拠である足利荘の足利氏宅跡を訪問してきました。現在は鑁阿寺(ばんなじ)というお寺になっています。

お城の概要

•  名前 足利宅跡
•  所在地 栃木県足利市(東武伊勢崎線足利市駅から徒歩10分)

見どころ

日本史の教科書でよく出てくる中世武士の館のイメージほぼそのままです。地図で見ると堀が周囲を巡っているのが良く分かる通り、堀と土塁が周囲を巡る方形館になります。いわゆる「城」とはイメージが違いますが、日本百名城にも入っています。

現在の堀は鴨や鯉が泳いでて穏やかな様子。敷地の角の部分から見ると土塁が結構高さがありそうなのが窺えます。

門はお寺になってからのものだと思いますが、反橋と門が大変美しいです。

本堂は国宝に指定されています。屋根の上部に足利家の家紋（右が足利二つ引、左が五七の桐、真ん中は菊の紋みたいだったけど由来は分からず）がかかげられています。百名城スタンプとか御城印とかはこちらの本堂でいただける模様。

鑁阿寺本堂

重要文化財の経堂は行事の時以外は公開してないそうなのですが、行ったときにはたまたま公開されてました。足利十五代将軍の木像も公開されてて、拝観することができました。巡り合わせ良き！　内部の輪蔵（お経を納めた蔵）は回せるようになっていて、受付の方が「回し始めは重いから手伝いますよ」と言って手を貸してくださり一周回せました。お経を読んだのと同じだけの功徳が得られるそうです。

一切経堂

いつの時代のものかは正確には分かりませんが土塁もしっかり残っていて登れます。土塁の向こう側の家の1階部分がしっかり隠れているので高さは2メートル強くらいかな？

鑁阿寺東側の土塁

土塁の上から東門と堀を眺めた様子

駅からのアクセスも良く、周りには坂東の大学と称された足利学校もあり、ぶらぶら歩くのによいところでした。

おまけ

一休みしに入ったカフェ・八蔵の「喫茶店のプリン」。固めでカラメルとよくあって美味でした。

JaSST'21 Tokyoに参加してきました！（1日目編）

日本最大級のソフトウェアテストのイベントJaSST '21 Tokyoが3/15(月)～16(火)に行われたので行ってきました！
こちらは1日目のセッションメモまとめです！
目次

基調講演 "Being Agile about Architecture"

Joseph W. Yoder 氏（Refactory CEO）

Agileのアーキテクチャ

Agile

• 常に短いループでフィードバックをもらう
• テスラなどのハードウェア企業でも使われてる
• 常に学習して自らを振り返る

Agileの神話

SimpleがBestかというとそうでもない（機械学習とかを取り入れると複雑になるがそうした方がいい場合もある）
速さだけでなくフォーカスを当てることが大事

Agile/Leanの価値

• 継続的な改善、改善を投入していく
• 価値があるから練習する

パターンとは？

• パターンはGood Practice
• 既知のテクニック、ソリューションを再利用できるかも

→繰り返してきちんとできるようになったら普通のプラクティスになる

• プロジェクトの一番初めに考えるべき、ずっと考え続ける必要もある

価値はプラクティスを推進する。価値は人によって異なる

＜プロジェクトのはじめに考えること＞

• 巨人の肩に乗る：どのようなフレームワークやDBを使うかなど、これまでのリファレンスを基にする
• 自分たちで追加でやる必要のある事を明確にする(信頼性、性能などなど)
• どこが一番問題があるのかに従って計画する
• 最終責任地点
• アーキテクチャのロードマップを作成する際に品質を一緒に考える（例：モバイルのセキュリティはいつ考える？な（）
• アーキテクチャそのものを検証する（アーキテクチャの進化の方向、品質にも影響を与える）
• テストアーキテクチャを構築する（プロジェクト中でも時々戻って考えたり確認したりする必要あり）
• 最大責任点を計画する

＜プロジェクト中に考えること＞

• バックログを作成して優先度を考える（色分けして考えると便利）
• 重要な品質が見えるようにする
• アーキテクチャのトリガーを設定しておく（測定しておいてフィードバックする）
• アーキテクチャのスパイク*1を設定しておく

- どのフレームワークがうまくいくか分からないとき、実験してどれがよいか意思決定するするタイミングを決定しておく？小規模な実験をたくさんやることを予め計画に入れておく

• 大きな泥団子（技術的負債）ができてしまうかも。できてしまうと後から綺麗にするのが難しい
• 見えないものは改善できない
• 横断的に可視化する

- 立場（開発者、マネージャー）によって見たいものが異なる
- 技術的な判断はビジネスの価値を踏まえて下すべき

• 継続的なインスペクション

- 効率的な運用に適用される自動化は、効率を倍増させる。非効率的な運用に適用される自動化は、非効率性を倍増させる　by ビル・ゲイツ

• アーキテクチャを再評価し続ける

• ★イノベーションのためにはちょっと止まる時間も必要（この時間もプロセスに入れておく）

- 新しいことを考えたり、好きなことを試してみたりする時間

• 速さと生産性はイコールではない

「よいアーキテクチャが高くつくと思うなら、悪いアーキテクチャを試してみなさい」

質疑応答

Q. ユーザビリティはどのように可視化するか？
A. ユーザビリティのラボなどがあれば、キーストロークやユーザの視線などのログをとって追跡することもある。シナリオを構築して実験しフィードバックを得る。難しいが数字に落とし込むことは可能。

Q. 進化性の定義と測定する方法があれば教えてほしい
A. ビルドからリリースまでどのくらいかかったかを記録して比較する

Q. SREについてどのくらい優先度を与えるべきか？
A. 対象の製品によって異なる。人の命にかかわるものでは信頼性の優先度が高い。

Q. 技術的負債の対応はどのようにする？
A. ビジネス上のインパクトをきちんと見せるべき（例：負債がたまるとDelivery Speedが下がる）。ビジネス、エンジニア、QAみんなで対応する

Q. 技術的負債やアーキテクチャレビューをどの頻度でやるか？
A. 日常的に行う

感想

プロジェクトのはじめからプロセスに入れておくべきことや、進行中に絶えずやり続けることまで網羅されていて勉強になりました。勉強不足でいくつか用語とかが分からないところがあったので、twitterで補足いただいた方々に大分助けられながらの聴講でした。まだまだ勉強が足りない。
終盤の「よいアーキテクチャが高くつくと思うなら、悪いアーキテクチャを試してみなさい」がツボでした。根幹になるところは時間かけて考えないといけないところなんですけど、最初の方には見えてないこともあってなかなか難しいと思ってます。それもあっての「立ち止まる時間もプロセスにいれておく」なんでしょうね。よく抜けてしまうところなので、実験の時間を入れておくのは意識します。
（この講演は時間を置いた後にもう一度見たい。Yoderさんの別の講演動画でも見てみようかな）

「アジャイル・DevOps時代のテストと品質保証 輝く未来を抱きしめて！技術やツールが変えてしまうこと、変えられないこと」

藤原 大 氏（mabl Japan）
発表資料：アジャイル・DevOps時代のテストと品質保証 - 輝く未来を抱きしめて！技術やツールが変えてしまうこと、変えられないこと / Tech and Tool for Testing and Quality Assurance in Agile and DevOps Era - Speaker Deck

• 顧客が本当に欲しいのは結果
• 自動化できるものを自動化（自動化できないものもある）
• マニュアルテストの自動化はアンチパターンになりがち
• 技術の恩恵を受ける　例：パイプライン実行
• 品質保証をビジネス全体の活動にする
• QAチームを作るのではなく、活動に（QAチームがすべてをやるのは不可能）

技術の進化（AI/MLの利用）

• ペルソナを使った探索的テストの自動化
• 自然言語でテストケースを作成　例：「アレクサ、音楽かけて」
• ユーザ操作を学習してテスト作成

• シフトレフトよりも境界を越えよう
• 「バグというモグラを手でたたき続けるか、ユーザーに真の価値を提供するか」

「カスタマーサポートエンジニアの品質貢献」

登壇された方々（敬称略）

モデレータ：
　城風 智（KIOXIA）

パネリスト：
　加藤 敏之（LINE Fukuoka）
　齋藤 由佳（Autify）
　田向 祐介（ヴェルク）
　山田 恭平（日本マイクロソフト）
Q. カスタマーサポートとコールセンターは違うの？
A.

• コールセンターがマニュアルに沿ってお答えするというイメージなら違う。お客さんの困りごとを解決するのが仕事。最終的には安心感とか好印象を持ってもらいたい。QAにもお客さんがどこでつまづいているのかという観点を得るのに、カスタマーサポートを行ってもらいたい
• お客様とのコミュニケーション「どういう状況で何に困られてるのか？」
• 顧客の困っていることをいかに引き出すのか、がポイント。「〇〇機能がほしい」と言われたときに、それが欲しい理由をきちんと聞けること。
• 問い合わせ対応時に、過程を言語化してお伝えすることも大事。（問合せしてくださった方も、さらに先のエンドユーザーさんに調査に時間をもらうことを納得いただく必要があったりする）

Q. カスタマーサポートエンジニアがソフトウェアの品質に貢献していると思う瞬間
A.

• ユーザーの温度感（ここつまづきやすそうだな、みたいなこと）を開発者にフィードバックする→該当部分の問い合わせが減り、サービスとしての品質向上につながる
• 開発に伝えた後もフォロー

Q. カスタマーサポートにとっての成功とは？
A.

• お客様が口コミで評判を広げてくださること（例：「問合せしたらすごくよく対応してくれた」）
• サポートがいいからここの製品を使おうと思ってもらえること
• お客さんにファンになってもらうこと。お客さんがテストを効率化できることにどれだけ貢献できたか
• 違和感を拾って聞いてみたところ、問合せのあった事象の手前に問題があった（サービスの仕様を誤解していて間違った使い方をしていた）話を聞いて解決につなげられた
• 「お客さんの声がもともとベクトルが間違ってることがあって、それに対して真摯に対応してはいけないパターン」
• 問い合わせをいただいた時点で、サポートを頼ってでもサービスを使いたいと思っていただいている

Q. 品質という視点でサポートチームから開発、QAにお願いしたいことは？
A.

• 仕様や画面の変なところに事前に気づけるくらいの引き出しを持ってほしい
• お客さんのことを考えた回答が欲しい。事実だけではなく、提案とかもあると嬉しい。ユーザのことを想像する力を持ってほしい
• 調査時点で、どういう状況で何に時間がかかるのかを開発からCSに共有してもらえると、いいサイクルになる（海外だと時差があるので特に）

質疑応答

Q. サポートチーム内でどのようにナレッジを共有しているか
A.

• 問合せ、回答、注意事項のDBを作っている。問い合わせ時にはそこを見て対応。マニュアルは敢えて作らない
• 社内FAQを用意している。対応時に感じたことや注意点も記載

Q. サイレントカスタマー対策は何かしているか？
A.

• サイレントカスタマー（不満は持ってるけど声を上げない顧客）は問い合わせないので、SNSなどを確認している

Q. 開発とサポート担当で期待が違う場合調整はどうしているか？
A.

• 顧客からの不具合レポートを開発とサポートでレビューしていく。
• 既存のお客さんが使いやすくなるような改善と、サービスの進化方向のバランス

Q. お客様とのコミュニケーション面で技術支援以外で工夫していることは？
A.

• 共感する力をあげていく。

感想

私自身はQAですが、カスタマーサポートの問い合わせにも時々目を通すので楽しみにしていたセッションでした。ユーザーが本当は何に困ってるのかを聞きだしたり、問い合わせ対応時に対応状況を相手にお伝えしておくなど、確かにそうだなと思う共感ポイントがいくつかあって楽しく聞けました！

「テストプロセス改善のお悩み相談室 リターンズ ～テストプロセス改善技術の導入で悩んでいる皆さん、悩みを共有しませんか？～」

登壇された方々（敬称略）

モデレータ：
　田井 康平（ノハナ）

モデレータ補助：
　雨宮 寿幸（ベリサーブ）

パネリスト：
　上田 卓（ソーバル）
　大段 智広（豆蔵）
　山﨑 崇（ベリサーブ）

参考資料：
http://aster.or.jp/business/testprocess_sg/pdf/ASTER_TPIGuide_v1.0.0.pdf

お悩み1

テレワークに移行してからコミュニケーションが減ってしまい、仕様の理解不足や認識齟齬が発生している
テレワークに移行して生産性が下がってしまった

お答え1

特性要因図を使って要因を洗い出す
→TPI NEXTとテストプロセス関連の要因を紐づける
　TPI NEXTのチェックリストと要因を合わせてテーラリングしてみる

お悩み2

システムテストを行っているが、テストケースは秘伝のたれ状態で何をテストしているか分からない。改善したいが周りが話を聞いてくれない

お答え2

• 可能性1：硬直化したお役所仕事パターン

- 対処：仲間を作る、自分が偉くなる

• 可能性2：独善的な改善パターン（社外活動のハシカ）

- 対処：相手の立場の関心事で語る、自分のやりたいことと組織の関心事を整合させる

改善を回す際に、全体観をもって客観しできているか

• 提案内容は相手の関心事に沿った文脈か
• 組織やプロジェクトの制約や前提を考慮しているか
• 相手に寄り添うマインドになっているか
• やりたいことではなく、やることによる価値を伝えられているか

ビジネスゴール⇔ITゴール⇔BDTPI

お悩み3

組み込み業界で結合、統合テストの自動化で書く工程、製品ごとにプロセスがバラバラで無駄が多いと感じている。組織全体でプロセスを作りたい
TPI NEXTは読んだけどよくわかっていない

お答え3

各工程、各プロセスでどんなテストをやっているのか可視化
1. プロジェクトプロファイル
2. 問題の絞り込み
3. アセスメント実施
4. 問題の検証

フィッシュボーン図で問題を整理し、アセスメントモデルを使って視野を広げるのが良さそう

質疑応答

Q. 「プロセス改善前に現場を可視化しようというと「工数かさ増ししているのでは？」 と言われる問題」
A. 怒る/喧嘩するところ。可視化して問題を特定する前に着手すると結果的に苦しむことになる

Q. 社外活動のハシカにかからないようにするには？
A. 正直難しい。かかってしまったら、周りの反応とかからいち早く気付くようにする

Q. テスト改善というとすぐ「テスト自動化」と言われる。それ以前の問題が山積みの場合の説得は？
A. 開発全体で改善するべきところはないか、自動化以前の問題はないか、モデルを使って示す。
イケてないテストを自動化してもイケてないテストが高速化されるだけ。
上位層の説得にアセスメントモデルは便利

感想

どれもあり得そうなお悩みで、お答えも納得しながら聞けました。質疑応答に上がってきたお悩みもこれまたリアルでよかったです。カスタマーサポートのお話でも「本当は何に困ってるのか」を聞くのが大事という話が出ていて、本当の問題は何かを可視化するのがどこの過程でも同じなんだなと思いました。それだけ難しいということですよね。

*1:この文脈でのスパイクって何だろうとつぶやいたら スクラムにおける技術的スパイクの進め方 | Ryuzee.comを教えていただきました

JaSST Online Bergamotに参加してきました！

10/3(土)に開催された JaSSTソフトウェアテストシンポジウム-JaSST Online Bergamot に参加しました！　今回のテーマは「探索的テスト」！

セッション1：探索的テスト

＜概要＞
業務で探索的テストをされている nemorin さんに事前に録画してもらった探索的テストの様子を見ながら、質問者の方が適宜止めて気になるところを質問していくというスタイルで行われました。今回のテスト対象はtwitterライクなtestitterというWebアプリ。LIFULL株式会社さん提供だそうです。
※事前に質問者オプションを購入された方が質問できる形でした。面白そうだったので買えばよかった。

＜nemorinさんのテストの様子メモ＞
※雑にメモしたものなので、nemorinさんの言ってた内容と参加者の質問が混ざってる可能性があります。

• 今回はチャーターは作ってない、仕様書を3分程度眺めた程度（読み込むと頭の中でテスト設計を始めるので探索っぽくないかという意図）
• 探索テストの時間は1時間。当初の意図は30分程度で学習してあたりを付ける意図
• 最初はHappy Pathを通す。メイン機能を一通り見る。
• CRUDを見る
• 動かしながら出てきた点は、バグ、気になるところ（問い合わせ要）、メモの3つに分けてメモ
• 誤った操作も大事（ユーザも操作ミスする可能性があるので）
• 仕様書も古かったりするので唯一信じられるのは自分でやった結果（ただ、たまに押し間違ったりするので自分が信じられないときもある）
• （業務でやるときも）探索的テストを録画しておくのはよさそう

＜感想＞
探索的テストをしているときに何を考えてるか、を見ることはほとんどないので貴重な機会でした。時間区切って探索的テストやっている中で、このくらいの時間経過したときに何を考えているか、とか聞く機会ないので、質問者の方々の質問もありがたかったです。探索的テストで自分もやっていることもあれば、「なるほど、そういうアプローチなのかー」と思うところもあり、興味深いものでした。後ほどOSTでのお話によると、普段はチャーターを作ってるそうですが今回は未知のものなので作らなかったとのことでした。

様々な参加者がいる中でのオンライン視聴なので、全員の前提知識をそろえるのがすごく大変そうです。その点、探索的テストの対象選定からセッションの進め方まで、運営の方々がすごく考えて構成してくださってるなと感じました。nemorinさんも運営の方々にも大変感謝です！

セッション2：OST(Open Space Technology )

参加者駆動のセッション。最初に参加者で話したいテーマがある人がテーマを出し合い、みんなでアジェンダを作るところから始まり、話したいテーマのところに行って話したり、聞いたりするという形式です。

探索的テストをやるタイミングはいつにしてますか？

セッション1中に聞いてみたくなったのでセッションホストやらせてもらいました。参加者のみなさんからいただいたご意見をざっとまとめます。

＜お題：探索的テストいつやる？　目的は？＞

• テスト開始前
  • 仕様書がないシステムの場合、対象を学習・理解するために実施
  • 仕様書がある場合もイメージをつかむために実施
• テスト中
  • テスト工程進行中にこれ以上進まなそうなとき（開発に差し戻すが、致命的なバグを洗い出して）
  • スクリプトテストと並行して実施する
  • テスト実施者の中にバグだしのうまい人がいたら、その人にはずっと探索的テストをやってもらう
• テスト終了後
  • これ以上バグがないか確かめたい
  • バグをもっと出したい（計画したテストケースは終わったけど何かありそうな予感）

探索的テストどうやって勉強しますか？　指導しますか？

とろさんのセッションでした。

印象的だったのは、どなたかが言っていた「憑依系探索的テスト」。miwaさんが言っていた、高齢の方の手の震えによって発生するバグの話から想起された話です。なるべくユーザーの状況を想像し、なりきってテストをするパターンや、「悪いことやろうと思って操作する」というパターンが聞けました。「憑依系」はなかなかパワーワードですねｗ

＜感想＞
OSTの参加も、セッションホストも初めてやりました！　ホストやった時は、沈黙が続いちゃうタイミングがあったらどうしようかと、ちょっとドキドキしてました。ですが、参加者の皆さんが積極的に自分のエピソード話してくださったり、途切れたタイミングで別の質問を出してくださったりで、盛り上がれてよかったです！　対象となるシステムや仕様書の整備具合、あとはシステムに対して知識がどのくらいあるかによって、探索的テストをどう実施するか、参考になる意見が色々聞けました。セッションに来てくださった方々ありがとうございます！
とろさんのセッションでも「憑依系」のパワーワードが飛び出したりと楽しめました！　オンラインだと話し合いの輪の物理制約がないので、わいわいしやすくていいなーという気がします。話すネタはないんだけど聞いてみたい方にも、ハードルが低そうな印象があります。

全体通した感想として、ほぼ探索的テストだけをネタに盛り上がるという貴重な機会をもらって、すごく楽しかったです。nemorinさん、運営の方々、参加者の方々、ありがとうございました！　自分の仕事で探索的テストをどうしているかは別途言語化してみようと思います。

JaSST'20 Kansaiに参加してきました！

9/12(土)にオンラインで行われたJaSSTソフトウェアテストシンポジウム-JaSST'20 Kansaiに参加したので、気になったセッションをレポートします！　関西は初参加！
今回のテーマは「テストについての分解・再構築」です。
本文中にリンク貼った書籍や資料は、当日のTwitterで教えていただきました。
当日のまとめはこちら
JaSST'20 Kansaiまとめ（オンライン） - Togetter

「テストの視点でシステムを分析する」

見えないものと取っ組み合う

望月 信昭（ウェブレッジ）さん
＜概要＞
テストベース分析で困りがちなこと

• ソフトウェアは目に見えない　→　何となく理解した感じで作業を進めてしまう

対象をテスト視点で理解する

• モデル化してみる（図を描く）
• 記法とかがハードル高いと感じる人は「テスト技法を使って問題を解いてみる」と考えてみるのも手（対象を理解するためのツール）
• ただし対象に対してどの技法を使うのが適切かを選ぶのもハードル高い
• →ちょっと使ってみて考える。失敗してもこの対象にはこの技法は会わないという学びをゲット

対象の振る舞いを理解して、見えないものを見えるようにすることができる

テストの視点でシステムを分析する

堀川 透陽（ベリサーブ）さん
＜概要＞
テストのシフトレフト
前提

• ビジネスモデルキャンバス（ビジネスゴールを導くためのツール）

顧客・tesuto 対象をビジネス視点で書き出していく

• PEST分析　仮想課題から気付きを得る

外部環境の変化から生まれる要求、見直される要求があるのではないか

USDM（要求仕様記述手法）による要求と仕様の再構築
言葉にする→言葉にかけないものを作ってはいけない
メリット

• 要求と背景が明確になることで、テストのゴールも明確化される
• 合意形成しながら進めることで、仕様の妥当性があがる

デメリット

• 作成に熟練を要する（作り直し）
• 合意形成のための工夫が必要

USDM作成→テスト設計HYST法のFV表、FL表へ接続できる

＜講演中で触れられてたことの参考文献など＞
USDM参考書籍

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

テキストマイニングによるテスト分析、リスクベースドテストへの応用の詳しい事例
https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol19.pdf

テストの視点でシステムを分析する　～アジャイル開発を例に

江添 智之（バルテス）さん

• 仕様化以前の状態で品質を考える
• 何ができればOKか　を上流工程から考える
• エピック→スプリントに入りきらないユーザーストーリー → 受け入れ条件を考えるとユーザーストーリ―に分割できる
• 要求の「完成」の定義と受け入れ条件で整理する

「スペックアウト」でソースコードを理解しよう

池田 祐一（AFFORDD関西部会）さん

スペックアウトとは

設計書の不足を補うために、ソースコードから必要な設計書を起こす行為
知りたい機能、知りたいこと、必要な調査資料、投入できる時間etcを目的を明確にして取り掛かる
　

スペックアウトの手順例

1. 資料やソースファイルの一覧を用意する
資料、内容、用途などを表にする
2. 関数の一覧を用意する　ファイル名、関数名、説明（目的語と動詞を各）を表にする
3. 変数の一覧を容易　ファイル名、変数名、説明（名詞を書く）

4. データ参照関係を調査する　関数と変数のマトリクスにCRUDのどれを行っているのかをつけていく
5. 知りたい機能の処理構造を調査する　変数名表からあたりを付けて構造図に落とす
6. 必要に応じて処理手順を調査する（複雑なパターンなど）　処理パターンを抽出してPADフローに表現
7. 要求仕様を復元する　コードや構造図を参照しながら、イベントから始まる一連の動作を表現する
8. テスト仕様を作成する
9. テスト結果を記入する

＜講演中で触れられてたことの参考文献など＞

• https://affordd.jp/conference2017/affordd_conference2017_poster1.pdf
• プログラム構造表記法（PAD）

究極のプログラム設計図 PAD解説: 構造化チャートによる設計図法 － 素晴らしいPAD図 － 究極の技シリーズ (計算機屋さんの技)

テクノロジーセッション

「試験に役立つモデリングのススメ」

渡邉 豊幹（サイボウズ）さん
サイボウズさんの米国市場向けの販売管理システム開発チームの話

問題点

• 影響範囲が把握しにくい
• 新規メンバー/他チームへの教育コストが高い

対策

• モデルを作成してみる。文書より図の方が人間には分かりやすい

モデルとして残すもの

• Keeps

- システム全体の構造shisutemuzentainokouzou
- 業務で扱う対象とそれらのつながり
- システムの（ユースケース図、コミュニケーション図）渡されるデータや実行APIを記載

それ以外はTempsとして一時的な資料、メンテナンス等はあまり考えない

結果

• 概要が把握しやすい、俯瞰しやすい
• モニタリング対象の洗い出しやE2Eテスト

「Global QAチームを目指して ～日本とシンガポールの2拠点QAチームを築く上での気づきと大切にしたこと～」

角 尚美（チームスピリット）さん

シンガポールで採用

QAエンジニアの役割定義をアップデート

• コアスキル(ISTQBのFLレベル)
• スペシャリスト(ISTQBのFLレベル＋α)

の2軸で定義

リモートでも2か月で立ち上げ
　開発チーム全体でSG-QAのオンボーディングのサポート

招待講演

「ゆもつよメソッドによるテスト分析の成り立ちと狙い」

湯本 剛（freee / ytte Lab）さん

例：西暦和暦変換アプリのテスト

テスト分析

テスト対象フィーチャ：和暦西暦変換
テスト条件（仕様と期待結果）：西暦の年月日から和暦へ変換した日付を出力する

テスト設計方針
テストケース：この辺で一般的なテスト設計技法を活用

分析と設計について

分析：対象を把握する→分析結果は客観的、誰が見ても分かる
設計：枠組みを考える、アイディアを決定する→設計結果は主観的。人によって答えが異なる

要求分析：システム要求を分析して仕様を作成する

あー、テスト分析だと確かにインプットするものの名前じゃないので分かりにくいのかも。文脈にもよるだろうけど、より正確にはテスト要求分析というと誤解がないのかな

テスト分析では理解したことを以下のように整理する

• 仕様項目の特定と列挙
• 期待結果の特定と列挙
• テストパラメータ列挙（テスト設計時により明確に定義していけばよい）

テストカテゴリー
　テスト条件を見つける際に一貫性のある解釈をするために論理的昨日構造の各要素にテスト対象から見てふさわしい名前付けをしたもの
テストカテゴリと意味づけ

テスト設計
テスト設計方針を決める→テストパラメータ導出方法、同値のサイズ、組み合わせ方法

テスト条件を網羅するためのテストケース設計モデルの選択をする　技法の選択とか

モデル化する：必要なものを取り出し、不要なものを削る

テスト設計の変遷
テストカテゴリーをベースにしたテスト分析の方法

テスト分析手法の概要

• ドキュメントフォーマットと実施順序のルール化/テスト分析マトリクス
• 論理的機能構造→テストカテゴリー
• 仕様項目特定パターン（研究中）

メリット
大きくとらえてテスト対象を網羅しているかが分かりやすい
テストしなければならないことを先に洗いだすことができる
→テスト条件（仕様項目）の段階でテストが十分か、漏れがないか、といった確認が可能になる

ドキュメントフォーマットと実施順序のルール化

複数人でテスト設計するときの記述内容を合わせる
テストカテゴリーは確認箇所を汎用化させたもの

論理的機能構造

テストカテゴリーになるべきものを決めるためのモデル

• メンバ全員が参照モデルを深く理解する必要はない、テストカテゴリに対する認識合わせが最も重要

仕様項目特定パターン

テスト実行時のデータ入出力パターンですべて特定
テスト実行によって呼び出される小機能の結果確認

感想

「自分たちが扱っているシステムやプロダクトで何がしたいか」をどう整理すればよいかを改めて考える機会になりました。
色々な手法があるけど、どうとらえてチームでどう納得するか、というところがミソなんだろうなと思います。
ゆもつよメソッドの話をちゃんと聞いたのは今回が初めてだったんですが、論理的機能構造をどう作っていくかが私の中で落とし込めてないので、そこをもうちょっと深めたいです。

関西は今回が初でしたが、オンラインで開催していただけて自宅から参加でき、移動ゼロで素敵なお話が聞けてありがたかったです！
登壇者、運営の方々、参加者の皆様ありがとうございました！

おまけ：いろんな方から紹介いただいた理解の助けになりそうな資料

• JaSSTで話題になったテスト設計をモデル化してみた - Qiita
• テスト設計をより良くするモデリングと観点分析/ Improve Test Design with Modeling - Speaker Deck

JSTQBシラバスに出てくる「ヒューリスティック」とは何ぞや

JSTQBのテストアナリストやアジャイルテスターのシラバスで、「ヒューリスティック」という言葉を見かけて意味が分かりにくかったので、自分なりにまとめてみます。しっくりくる日本語がないので、英語のままにした方がよさそうな単語ですが、いきなり出てくると意味がとらえがたい単語ですね。

ヒューリスティック(heuristic)の辞書的な意味

Google先生に聞いてみたところ、以下の意味になります。

enabling a person to discover or learn something for themselves.
（人が自分で何かを発見または学習できるようにします。）

（）内は私の訳なので、間違っていたらすみません。
語源は何だろうと調べてみたところ、ギリシャ語由来らしいです。これまたGoogle先生情報です。

early 19th century: formed irregularly from Greek heuriskein ‘find’.
（19世紀初頭：ギリシャで「見つける」を意味するheuriskeinから不規則活用された）

ちなみにアルキメデスの「エウレカ！」と同じ語源のようです。

こういう豆知識が好きなので個人的にテンションがあがりますｗ
雰囲気としては、経験などから発見して学習する、みたいな意味合いになるでしょうか。

ヒューリスティックという言葉が出てくる分野

ざっとググってみた感じ、心理学、教育分野、IT、証券などで出てくるようです。人の心の動きに関わるものなので、人間のかかわる活動全般に出てくるということかと思います。「経験から学ぶ」といういい意味でも使われるし、「経験に縛られる」という悪い意味でも使われるようです。

JSTQBテストアナリストで出てくるヒューリスティック評価法とは何か

テストアナリストのシラバスでは、使用性テストの文脈で出てきます。該当箇所はこちら。

ヒューリスティック評価（使用性に関するユーザインターフェース設計の体系的なインスペクション）は、設計における使用性の問題を発見するのに使用できるので、イテレーティブな設計プロセスの一部として使用できる。
（4.2.4.2 使用性テストの詳細 p44）

ユーザビリティの専門家が対象となるシステムを見て、経験則に基づいてUI上の問題点を発見する手法だそうです。専門家ではなくても、あらかじめ用意されている観点があるので、それに沿って評価できます。あらかじめ用意されている観点としては、ヤコブ・ニールセンのユーザビリティ10原則が有名です。原題は「10 Usability Heuristics for User Interface Design」です。ヒューリスティックという言葉が出てきてますね。
詳しい内容はこちらのサイトで確認できます。
www.nngroup.com

JSTQBアジャイルテスターで出てくるヒューリスティックとは何か

アジャイルテスターのシラバスでは、探索的テストの文脈で出てきます。該当箇所はこちら。

テスト時には、一連のヒューリスティックを適用できる。ヒューリスティックは、テストの実行方法と結果の評価方法についてテスト担当者をガイドする [Hendrickson]。たとえば、次のようなものがある。
A set of heuristics can be applied when testing. A heuristic can guide the tester in how to perform the testing and to evaluate the results [Hendrickson]. Examples include

• 境界
• CRUD（作成（Create）、読み取り（Read）、更新（Update）、削除（Delete））
• 構成のバリエーション
• 中断（ログオフ、シャットダウン、再起動など）

（3.3.4 探索的テストとアジャイルテスト p44）

最初の説明部分の文章は、分かりやすくするために英語版を併記しました。「A set of heuristics」と書かれているので、ここでは「経験則一式」くらいの意味で書かれているのだと思います。

以上、JSTQBの文脈で出てくる「ヒューリスティック」についてまとめてみました。何かの参考になれば幸いです。

参考

こちらのサイトや書籍を参考にいたしました。
・ヒューリスティック評価
https://u-site.jp/usability/evaluation/heuristic-evaluation/
・ユーザーエクスペリエンスの測定

ユーザーエクスペリエンスの測定 (情報デザインシリーズ)

テスト手順、詳しく書くかざっくり書くか

こんなことをつぶやいたら、色々ご意見をいただいたので自分なりにまとめてみます。

テスト手順どこまで書くか。実行するメンバーの熟練度次第になるけど悩ましい。

— yuki shiromoto (@yuki_shiro_823) February 10, 2020

具体的テストケースと論理的テストケース

JSTQBのテストアナリストのシラバスには、具体的テストケースと論理的テストケースについて言及があり、ざっとまとめてみると次の通りになります。

	具体的テストケース	論理的テストケース
概要	テスト担当者がテストケース（すべてのデータ要件を含む）を実行し結果を検証するために必要な特定の情報と手順のすべてを提供する	テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする
メリット	テスト担当者の経験が少なくてもテストケースを見れば、テスト実行可能。再現性が高い。監査にも使用可能。	テスト実行時の変更を許容するため、具体的テストケースよりカバレッジが高い場合がある。
デメリット	メンテナンスに労力がかかる。テスト実行者の想像力を阻害する場合がある	再現性が低い場合がある。

（Advanced Level シラバス日本語版 テストアナリスト 「1.5.1 具体的テストケースと論理的テストケース」　p13）
上記の概要は、シラバスからの引用ですが、具体的テストケースの方は、テスト実行の主語が「テスト担当者」となっているのに対し、論理的テストケースの方は、主語が「テストアナリスト」となっています。テスト実行するのが誰かによって、テスト手順や期待結果の粒度をどの程度書くかが意識されてるように思います。

具体的テストケースと論理的テストケースをどう使い分けるか

自分の使い分けについて考えると、テスト実行するメンバとの物理的距離と熟練度が大きく影響しています。

テスト実行するメンバが同じ場所にいる場合

使用するテストケース

論理的テストケースです。「××欄に任意の値を入れる」などの表現をよく使っています。

前提

テスト実行に入る前に、テスト実行してもらうメンバに、テスト対象の目的の説明やテスト対象を一緒に動かしてみるなどを行います。物理的距離が近いと、実行メンバの理解度の確認やなにかあったときのフォローが容易にできます。
ある程度複雑な手順が必要だったり、使用するコマンドなどを具体的に指定した方が良い場合は、テストケースとは別途、確認手順書を書いて具体的な内容はそこに寄せるようにしています。メンテナンスは必要ですが、テストケース一つ一つに手順を書くことに比べると、共通化できている分楽です。

良い点

テスト対象の目的、それで実現したいことを共有しておくと、こちらが想定していなかった問題を見つけてもらえることもあります。（逆に、うまく共有できていない時には、細かすぎるバグを大量に報告してしまったこともありました）
テストケースを書く量が少なくて済むので、メンテナンスが楽です。詳細にテストケースを記載する時間が浮くので、教育とかバグを見つけるための活動に時間を使うことができます。Twitterでもこのようにアドバイスをいただきました。

目的はテスト手順書通りに操作することではなく、バグを見つけることだから。
ですから、「最低限の手順書ってなんだ？」と考えて、余った時間を教育に充てるのが良いと思います。

— あきやま☃️ (@akiyama924) 2020年2月11日

テスト実行するメンバが離れた場所にいる場合

使用するテストケース

具体的テストケースの方が多いです。特にあまりフォローができない場合は、テスト実行に迷わないように具体的に書きます。

良い点

テストケースの記載通りに進められる場合は、経験の少ないメンバでもスムーズに進められます。

悪い点

ちょっとしたUI変更で、テストケース通りに進められない場合は質問の嵐になることがあります。テストケースを修正するにも時間がかかります。物理的距離が離れていたり、さらに時差がある場合はフォローがしにくいので、自分の中には、この問題への対処策はこれといったものがありません。ある程度実行メンバを教育して、修正案を出してもらい、自分はそれを判断するだけにする、とかでしょうか。。

まとめ

テスト実行メンバが同じ場所にいる場合は、論理的テストケースを作成して、メンバへの教育を手厚くするのが良いと思います。離れた場所にいる場合は、よい対応策を募集中です。
最後に、ふとしたつぶやきにアドバイスをくださった皆様、ありがとうございました！