JaSST'21 Tokyoに参加しました。

Event Testing
このエントリーをはてなブックマークに追加 follow us in feedly

こんにちは、Optimal Bizチームの片岡です。

先日オンラインで行われたJaSST'21 Tokyoに参加してきましたので、その参加レポートを書きます。

JaSSTとは

JaSST ホームページ

JaSSTとはJapan Symposium on Software Testingの略で、NPO法人ソフトウェアテスト技術振興協会（ASTER）の主催するソフトウェアテストシンポジウムです。
日本各地で開催されており、これまでは北海道や東北、東京・関西など各地域でのオンサイト開催でしたが、コロナウイルスの影響で今回のJaSST'21 Tokyoはオンライン開催となりました。

オンライン開催の様子

オンサイト開催では、実際に会場がありその中で更に幾つかの会場に分かれ…というスタイルだったのですが、今回はeventhub上での開催となり、参加者には事前にeventhubのリンクがメールにて配られました。

会場にアクセスすると、左上に動画欄があり右側にメッセージやslidoを使えるカラムがあったり…というよく見るeventhubのページが表示されます。視聴セッションの切り替えも動画欄下部から簡単にできるので、初めての方でもスムーズにセッションを聞けそうと思いました。

セッション中はTwitter上で#JaSSTTokyoというタグ付きの感想/質問ツイートがリアルタイムで流れたり、slido上にも随時質問が投稿されたりなど、スクリーンを通して大人数が参加している活気を感じることができました。

新型コロナウイルス感染症の拡大によって、勉強会やシンポジウムなどのイベントがオンライン開催となることが多くなりましたが、リアルタイムで他の人の投稿する感想/質問を見ながら参加できるのは、その場での気付きが増えている感覚があって良いなと思います。

参加したセッションをピックアップ

2日通しで参加しましたので、その中から幾つかセッション内容をピックアップします。セッションで使われた資料のうち講演者から提供のあったものは後日jasstのホームページにアップロードされるようです。

(※以下、QA = Quality Assurance/品質保証, Q&A = Question&Answer/質疑応答 の意で用語を使用します。)

基調講演 "Being Agile about Architecture"

共同実行委員長の片山 徹郎さんのオープニングセッションの後、Refactoryを設立したJoseph Yoderさんによる基調講演からJaSST'21 Tokyoが始まりました。

(ほぼ)同じ内容の講演はこちらです↓↓
youtu.be

要約

  • アジャイルプラクティスを実践するのではなく、ビジネス上・チームとしての価値が何なのかを考えて、そのためにできることをどう実現するかという思考が大事。
  • その上で、アジャイルを支援する"アジャイルなアーキテクチャ"が存在する。
  • パターンやアーキテクチャを選ぶうえでの「巨人の肩に乗る」というコンセプト
    • 巨人＝これまでのテクノロジーやシステムなど、リファレンスとして使えるもの
    • 肩に乗った上で、自分たちに特に重要な要素を見定める。(＝Find Where It Hurts)
  • 達成すべき品質要件を最初に認識したうえで、それを実現する"最大責任地点"をロードマップの中で定めておくと良い。(＝Choose the Most Responsible Moment)
    • 最終的に見落とされがちなポイントなので、「誰がいつやるのか」という"責任"を明確にする。

Q&A(一部ピックアップ)

  • 使用性をどうやって可視化するか？
    • 使用性は測りにくいが、機械学習を用いてUsability Labを構築し、人がどうやってそのシステムを使っているのかを見ることができる。
    • シナリオを作りオンライントレーニングを行ってみるのも良い。本当にシナリオ通りに上手くいくか？という実験からフィードバックを受ける。
  • プロジェクトの進化性の定義は？計測の方法は？
    • チームが上手く機能するかについての指標としての進化性。
    • 機能追加のためにどれだけの時間を使ったかを測ることで、時間がかかり過ぎたかどうかを見ることができる。
  • slackタイムはプロジェクトの時間内で設けるべき？それとも時間外？
    • 内外ともに必要である。
    • 無いと問題が発生したときに大変になる。一時的にしのぐ必要が出てきて、技術的負債にもつながる。

「アジャイルなアーキテクチャとは何か」というテーマでの講演で、他にも"Tracer Bullets", "Test Architecture", "Know Your audience!", "Slack Time"といった概念やキーワードが紹介されていました。 Joseph Yoderさんはラーメンが好きだそうです。

Dev&QAのOneチームによるプロダクトゴールへの第一歩

株式会社SHIFTの石井さん, 言美さん, 船橋さんによる講演

要約

  • QA to AQの流れを汲んだ講演で、Dev&QAのOneチームに焦点を当ててパターンを解説。
  • Break Down Barriers：企画・営業・開発・QAなどの間にある文化的な壁をどう乗り越えるか
    • 壁を乗り越えるための具体的なパターンとして、Whole Teamなどがある。
  • Whole Team：スクラムの中にQAも入り、「開発と共に行動する」という第1歩から始める
    • チーム全体の品質知識が上がり、全員品質を達成できる。
    • 同じ時間軸で過ごす、というのが肝。(スプリント周回遅れ、ではない。)
  • Product Quality Champion：品質に関するロードマップやバックログの検討を行い、品質の可視化をする。また、品質重視のチームとしての支援を行う。
  • System Quality Specialist：チーム全体の品質意識向上のため、重要な品質を発見する。また、品質に関連する専門技術・知識を具体的に活用していく。
    • 上記の2ロールは兼ねられる場合も多い。
    • スプリント序盤で開発とQAが話し合うことで、スプリント内でテストまで終えられるスケジュールを立てられる。
    • スプリント中盤で設計相談会を行う場合は、全員で細かな仕様の確認を行う。
      • どんなテストが必要なのかを開発が理解できるというメリット。
  • Automate As You Go：状況に応じた自動テストの目標設定が大切
    • 種まき目標：まずはやりやすいところから始めて、リズムを作り根付かせる。
    • 理想目標：最大限の費用対効果を発揮するために実装計画を立て実行する。
    • 過剰目標：絶対に壊れてはいけない部分に例外的な実装を行う。
  • 自動テストにはメリットが沢山あるのでやれると良いが、本当に自動テストでしか解決できない問題なのかは検討しなくてはいけない。

Q&A(一部ピックアップ)

  • DevとQAの人数はどのようなバランスがいい？
    • スクラム10人以下の中で2人くらいだとバランスが良くなりやすい。1人のリーダーが見られる人数が5~7人という話と同じ。
  • 既存のプロダクト(UIとAPIレベルの自動テストがほとんどない)に対して、あとから自動テストを導入していく場合はどのようにやるのがよい？
    • まずは何のために自動テストを行うかを明確にする。
    • UIテストとAPIテストをやっていないところから始めると開発側の負担が重くなるため、まずはGUIから入ってみるのもオススメ。
    • 一度自動テストを書いてみて、自動テスト良いよねという実感を得ながら進めていくことが良さそう。
  • プロダクトが大きくなるにつれて、E2Eの運用・保守コストが大きくなってきてしまった。こういう場合、どのように対応したらよい？
    • 保守しやすくするためにIDを入れてもらうアプローチが一つある。
    • 今やっているもので意味のないモノがないかどうか、肥大化していないかを確認することも大事。

テスト担当が開発担当とコラボレーションする動機に「開発側の考えを理解したい」というものがありますが、コラボレーションすることで同様に「テスト担当の考えを開発側に理解してもらえる」というメリットがあるため、双方にとって良い取り組みだなと思いました。
また「テストレポートによって、開発者が意識していなかったレベルまで仕様を書くことができる」ということもコラボレーションで実現できることなので、単にコミュニケーションを取るのではなく、その結果何が実現できるか？を考えることが大切だと思いました。

JaSSTのプレミアムスポンサーであるSHIFT様から招待状を頂けたので今回参加することができました。大変ありがとうございました。

アジャイル開発にQAはホントに要らないのか？

Visionalのbroccoliさん、グロービスのmarkさん、Pixivの島根さん、エムスリーの城本さん、電気通信大学の西教授によるトークセッション

要約

  • markさんのビジョナリーQAについてのブログ記事が発端
  • テストとQAは同じなのか？違うのか？
    • 日本ではテスターはテストをする人で、それより広い領域をQAが担っているイメージ
      • 日本だと「テスト＝誰でもできる」というイメージが何となくついてしまっていて、テスターというロールの価値が軽視されている印象。
    • 海外ではテスターと自称する人も多く、その中には日本でいうQA的なことまでする人も沢山いる。
      • テスターという概念が拡張されているイメージ
  • 記事では「QAがいないのが理想」とあるが、本当にQAが組織からいなくなってもよい？
    • テストを実行する人、という意味でのテスターはテスト自動化の中で確実に減っていく。
    • QAがいなくなる世界＝開発者が品質担保し続ける世界
      • 開発者一人ひとりがスーパーマンにならない限りベロシティが下がっていき、求められている開発スピードを保てなくなる。
    • 中長期的にはテスターはいなくなり、QAになっていく。
    • 組織の中に残り続けるQAは、全体を考えて品質保証戦略を考えたりアドバイスをしたり品質文化を作ったりカウンセリングをしたりを行う。

Q&A(一部ピックアップ)

  • チームに寄り添うというのはとても共感したのですが、こちらが寄り添おうとしても向こう側が突っぱねる時もあると思います。そんな時はどんな風に対応されるのかを聞かせてもらえると嬉しいです。
    • 城本さん
      • 話を聞かせてくれるのならば、まずは話を聞く。
      • 話を聞くのも難しい状況であれば、開発チームに良いと思うことを小さなことから始める。
    • broccoliさん
      • 寄り添おうとした相手からみて押し付けになっていたらダメ。
      • 相手がどういうところに懸念を持っているのか、どう取り除けるのかを話していけると良い。
    • markさん
      • まず"ストーカーっぽくなっていないか？"という自問自答が必要。
        • テストやQAは品質第一が正義と思って動いてしまうが、そうではなく、"開発者の目線になる"ということが必要。
      • 最初から指摘するのではなく、とことん寄り添って仲間としてより良くするための提案をするスクラム参観を実践してみるのも良い。
    • 島根さん
      • 最初、テストは特に困っていないと言われ続けた。
        • このときはひたすら待った。
      • 押し付けると拒否される。困ってることない？と聞いて無いと言われたらもう待つしかない。
        • 何か起きたときに協力する姿勢を出す。
        • 相手に嬉しいことを考えてアプローチする。
  • 1つのサービスに対して複数のスクラムチームがあると、品質に関しても個々のスクラムチームの部分最適が全体最適だとは限らないのでそのへんを調整する横断的QAチームは必要なんじゃないかと思うのですが、そういうQAチームもいなくなりますか？
    • 城本さん
      • 横断的なチームも必要。
        • POをサポートするという意味でも必要。
    • broccoliさん
      • POが品質を見ていくなら、横断的なチームは無くなっても良い。
        • ただ、現実的に厳しいからサポートとして横断的なチームがあっても良い。
      • POが見きれないほど規模が大きい場合は、いたほうが良い。
    • markさん
      • QA起点で考えるのではなく、大規模スクラムの考え方を検討することを提案する。
      • そういったフレームワークでは横串でQAを置く必要がないと言っている。
      • "なぜ置く必要が無いと言われているのか"を考えてみると良さそう。
    • 島根さん
      • (全社を横断するQAとしてコメント)
      • 個別最適になってしまう部分はある。共通化していきたいという取り組みをしているが、全部共通にしようということはしない。
      • ルールとかプロセスを決める場合もあるが、横断的なQAに大事なのは、上からではなく丁寧に説明する姿勢。

「テスターはソフトウェアテスト周りのタスクを行い、QAはプロダクト品質を良くするための活動全般を行う」という整理は自分の認識とも合っていたので、日本の中では概ねこの前提の上で話をして良いのかもしれない、と思いました。 一方で、JSTQBの中ではテストに静的なテスト＝各種レビューも含まれているので、ロールについては上記のような前提を持ちつつ、個別タスクを組むフェーズでは言葉に持つイメージを擦り合わせる必要があると感じました。

招待講演 "パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術"

早稲田大学の鷲崎教授による講演

要約

  • 従来の品質保証とは
    • 主に特定の人々が特定の段階(開発完了後)に品質の確認を行っていた。
  • アジャイル品質とは
    • 専門家を交えたチーム全体で品質の確認を行う。
    • 開発とQAの棲み分けではなく、One Teamでの取り組みが必須。
  • アジャイル品質を論じるために、なぜパターンを整理したのか
    • そもそもパターンとは
      • 問題と解決について、共通の部分を抽象化してまとめたもの。
      • 言葉を与えることで、集団でのコミュニケーションの助けとなる。
    • そもそも品質とは
      • Quality is not an act, it is a habit. - Aristotle
      • 「xxxxをすれば品質が良くなる」ではなく、それを繰り返すことで品質が作り出される。
  • パターンQA2AQ(の一部をピックアップ)
    • QAを含むOneチーム
      • 最初からQA担当者をチームに含める
    • 品質チェックリスト
      • システムで共通の、一貫して満たすべき品質特性の期待値を記したチェックリスト
        • 肥大化してしまうと形骸化する。スリムに保つことが大切。
    • QAリーダーとペアリング
      • 開発者と他のチームメンバーを品質保証担当とペアを組ませ、品質関連タスクを行う
    • 品質シナリオ
      • 早い段階で、手軽な方法で、重要な非機能要件を扱う大まかな品質シナリオを作成
        • 枝分かれの無いストーリーでまとめるのが重要
        • ex)端末の利用者は、"ピーク時"に"報告をWeb経由で要求"し、1秒以内に"報告を受理"する。
    • 品質の折り込み
      • 品質受け入れ基準をユーザーストーリーに添付する
    • システム品質アンドン
      • 誰もが質問する必要なく、仕事中や休憩中に見ることができる品質特性のステータスのディスプレイを用意する
  • さらなる展開のために
    • 社内QAコミュニティを作り、障壁の解体・ナレッジの構築に向けて組織的に動けると尚良い。

Q&A(一部ピックアップ)

  • 品質の中に機能性などもありますが、品質バックログの品質は、どちらかというと非機能に関する品質を意味するのでしょうか？
    • その通り。ユーザーストーリー自体が機能性を持つが、非機能はユーザーストーリーに織り込まれるもの。
      • 保守性も品質バックログに含まれる。
  • 品質シナリオを抽出する方法は何か考えられてますでしょうか。着目しているシナリオに対して、品質特性をガイドワードとして発想するような形でしょうか？
    • その通り。典型的な入力・環境などを押さえておいて具体化しておくことが最初は入りやすい。
  • 一度チェックリストの項目に載ると、捨てるのは難しいです。例えば過去のバグ事例に基づく場合はなおさらです（それがめったに出ないとしても）。既存も含めて絞り込むためにどうすべきでしょうか？
    • 複雑さが増大するのは避けられない。
      • しかし大きくなりすぎると、形骸化してしまう。
    • 項目数を設定するという方法があるが、足し算引き算で考えるのが厳しい局面では、もう一度真っ新な状態からの構築をするべき。
      • このチェックは本来何のためなのか？を考えられると良い。
  • 従来型のQAから徐々にステップアップしていくことを考えると、どのあたりから取り組んでいくのがおすすめでしょうか？
    • まずは3つ取り組んでみると良い。
      • 品質の見える化
      • テスト/見える化の自動化
      • QAを含めたOneチームの構築
    • 従来の "ある程度できてから見てもらう"意識ではなく、一緒に作り上げる意識が重要。

ある程度確立したパターンであるQA2AQはその実践法も分かりやすいので、少しずつ取り入れることがし易そうと思いました。
金言ばかりという感じでどれもすぐ試したくなってしまうのですが、チームで試せそうなところから小さく試してみたいです。

QA to AQについては、昨年からcodezineにて連載がありますので、興味を持った方はそちらも読んでみてください。

感想

  • 2日通しで参加してみての気付きとして、QAという文脈に共通している主張や悩みどころがありました。
    • 「QAが求められる」という場面が多種多様すぎて、もう少し言語を与えたいねという方向の議論と、用語に頼らないでテーラリングすることが大切だよねという方向の議論が多くありました。
    • 各社のQAエンジニアが「どういうところに困ってどういう風に乗り越えたか」をその場で聞いて質疑応答で更に深掘りしていけるのは、規模の大きなイベントならではの良さだと思いました。
  • 実際の現場の事例やベストプラクティスの紹介では、アジャイルを大前提としているものが殆どでした。
    • ただ、アジャイルが浸透している前提というよりは、「アジャイルとは何なのか」まで遡って、「じゃあより良いプロダクト開発のために何ができるのか」を論じているセッションが多かったです。
  • QA & ○○ という構図(たとえばQA & Dev, QA & Management Line)のテーマも多く、「品質保証」という抽象的な領域からプロダクト開発に参画するQAにおいては、他のロールと比べても特にコミュニケーションが重視されるのだなということを改めて認識しました。
  • 招待講演やSHIFTさんのセッションで触れられていたQA to AQはより実践しやすいパターン集として整理されているので、まさしく「巨人の肩」として使えるものだなと感じました。

最後に

最前線で活躍している方々のお話を伺っていると「ここら辺の知識がまだまだ足りていない」「こういう視点で物事を捉えられてなかった」と自分の不足点をより認識できるとともに、「次はここを目指していけばいい」という指標も見えてきました。
いつかJaSSTで登壇できたら良いなとぼんやり思いつつ、学びを活かせるよう日々の業務を頑張っていこうと思います。

オプティムでは、品質向上のために一緒に働く仲間を募集しています！