当時、参加してみてみんなでその気になり、その後、みんなで頑張って勉強してJSTQB Foundation試験を有明まで受けに行った良い思い出がありました。 それを契機に、私は脆弱性検査やペネトレーションテスト、自動化を行うセキュリティ関連の業務に従事することになるのですが、当時所属していた組織から離れることになってしまったため、JaSSTへの関与も希薄になってしまっていました。 風のうわさでみんなの活躍を見聞きすることはありますが、元気にやっているだろうか。 ちなみに、今回の JaSST'23 Tokyo 参加後、JaSST運営メンバーの方とお話できる機会があり、「次はALですね！」と言われて、お、おぅ。。と尻込んでしまいましたw

今回は残念ながら1人での参加になってしまいましたが、テスト活動に関連する職務についたので、当時の熱感を取り戻したくて参加しました。 会場は御茶ノ水にある日本大学ではなく、Discordによるオンライン参加でした。 2日間とも参加したのですが、会場移動がないので聞きたい講演を次々に回るのにはオンラインは便利だなと思いましたが、情報交換会をあまり活用できなかったなぁと反省しています。

現在も、当時と同じように効率的にテストが行えるようにツールを作ったり、UIテスト検証やAPIテストについての基盤作りに勤しんでいます。 Go言語で本格的に開発を行ったことはなかったので、ポインタや型アサーションなどの言語特徴を勉強しながら楽しく取り組んでいます。 当時と同じように、ソフトウェアの品質を高めるための「多層防御」を行うためにはQAだけでなくプロダクト開発に関わる組織全体で取り組む必要があるため、啓蒙活動も担当しているのですが、やっぱり一筋縄ではいかず、他社の事例や同じような職務についている方のお話を聞きたいという思いもありました。 全部は書ききれないので、参加した講演をかいつまんで紹介したいと思います。

基調講演 Chaos Engineering to Continuous Verification

• 講師：Casey Rosenthal（Verica）

継続的なCI/CDサイクルの信頼性や安全性を高めるために、カオスエンジニアリングを提唱していました。 意図的に障害を起こすことにより、その後に起きるシステム的な問題や復旧プロセスの問題をあぶり出そうとしています。 例えば、ある組織でStaging環境のKafkaを意図的に止めたら、Production環境のKafkaがStaging環境のKafkaに依存していて本番障害が発生してしまったことを紹介されていました。 このようなシステム間の依存性はなかなか顕在化することが難しく、ソフトウェアの複雑性が高い場合に起き得る問題であるとしています。 システムの複雑性はシンプルに保つべきですが、アベイラビリティ（可用性）の高いソフトウェアは複雑性が高くなり、実現可能ではないので、検証して問題把握に務めることが大事だとおっしゃっていました。

また、システムの複雑性の他に、人的なエラーについても言及していました。 医療過誤件数を減らすために、医療過誤を多く起こしていたスタッフの上位5人を解雇したが、結果的に裁判件数が増えてしまったそうです。 解雇したスタッフはハイスキルを持った人材であったため、ローレベルのスタッフがより多くの医療過誤を起こしてしまったことが原因だったそうです。 しかし、人がエラーを起こす確率はほとんど同じで、根本原因を解消しても、アベイラビリティ（可用性）を上げることは難しいそうです。 なぜなら、人は必ずエラーを起こすので、最終的に「気をつけましょう」的な対策しかできないからです。 エラーの原因を起こしてしまった1人のせいにするのではなく、組織のコミュニケーションレベルや予算配分を含めた原因に対処するほうが、アベイラビリティ（可用性）は上がるそうです。

私のチームで読んでいる [asin:B09MS8BML8:title] にも似た概念が書かれていましたが、ソフトウェアのアベイラビリティ（可用性）や品質を上げるためには、QAやエンジニアなどの特定のロールに責任を依存させるのではなく、組織全体で原因に対処する必要があることを再認識しました。

ただ、本番で障害を意図的に発生させるなど、危険度の高い試みについてはビジネス層や経営層を巻き込んだ意思決定が大前提にあり、少しハードルが高いなぁと感じました。

カオスエンジニアリングの裏話

• 講師：堀 明子（オーティファイ）、松浦 隼人（オーティファイ）

カオスエンジニアリング ―回復力のあるシステムの実践

Casey Rosenthal,Nora Jones

オライリージャパン

Amazonで見る

オライリーから出版されている「カオスエンジニアリング」の訳者である Autify の松浦さんによる、カオスエンジニアリングをテーマにした講演を聞きました。 基調講演と同じく、私達が扱っているソフトウェアシステムの複雑性は高く、互いのコンポーネントがどのように干渉しあっているのかを把握することは、現状ますます難しくなってきています。 複雑性の高いソフトウェアに対して、ソフトウェアテストとカオスエンジニアリングがどのような関係性にあるのかを、以下のように説明されていました。

• Known knowns : 知っているし、理解している（テスト）
• Unknown kowns : 知らないが、理解している（直感）
• Known unknowns : 知っているが、理解していない（監視）
• Unknown unknowns : 知らないし、理解していない（カオスエンジニアリング、オブザーバビリティ）

ソフトウェアテストは妥当性確認を行うが、カオスエンジニアリングは未知のものを見つける作業であり、検証のアプローチが多いです。 Validation（妥当性確認）に重きを置くソフトウェアテスト、Verification（立証や検証）に重きを置くカオスエンジニアリングの対比を説明し、Unkown unknowns（知らないし、理解していない）部分を受け持つのがカオスエンジニアリングとのことでした。

• Testing vs Experiments
  システムが期待通り動くことを確認する作業と、仮説検証し実験を試みる作業
• Validation vs Verification
  妥当性確認を行う作業と、検証を行う作業
• Steady states
  システムの定常状態に関する仮設を立てる （Steadyは決まった恋人みたいな和訳もあるが、安定して不変な状態と説明）
• Blast radius
  実世界の事象を多様化（Vary）させること 多様化（Vary）させることが大事で、具体的には本番環境で実験すること、継続的に実行できるように自動化すること、影響範囲を局所化することなどを述べていました

Blast radiusは和訳すると「爆発半径」となるが、英語原文を直訳してわかりやすく「影響範囲」としたことなど、翻訳のときに使ったTipsを紹介してくれました。

セキュリティ監査を行うときにも通ずることだなぁと感じ、とても参考になる概念だなと思いました。 ソフトウェアテストにおいても、探索的テストがうまい人ってシステムの定常状態を把握し、仮説検証を自然と行える人がよく不具合を見つけられる印象を持っていたので、対立関係ではなく互いに参考になると思いました。

ローカル環境を用いたアジャイルテスティングの実践事例～より高速なフィードバックを目指して～

• 講師：村岡 里紗（freee）

私が所属している組織でも、開発が終わった後にQAを行っており、品質保証活動がボトルネックになっているという課題があり、同じような課題にfreeeさんはどのように取り組んだのか興味があったので講演を聞きました。 freeeではマイクロサービスアーキテクチャを採用しており、開発環境の構築が厄介なので、検証環境を準備して開発エンジニアにデプロイしてもらっているそうです。 しかし、そうするとどうしてもテストが後回しになり、不具合検知タイミングが遅れてしまっていたことを課題にしていたそうです。 そこで、軽量なローカル環境をQAエンジニアの作業PCに構築し、スプリント毎にテストを行い、スプリントが終わった後に通しのテストを行うことによって、1週間かけて行っていたQA活動が3日で終わるようになったとのことです。 ただ、軽量なローカル環境を使えている人はまだ少ないようで、操作知識や環境の拡張時において、課題となるみたい。 やっぱりDockerを使って環境構築しているようでしたが、ターミナル操作ができるQAエンジニアは少ないようです。 私も同じことを考えていたので、「QAメンバーにDockerなどの開発環境をレクチャーするコツなどはないですか？」と質問してみましたが、地道にコマンドから教えている、と回答いただき、熱心に取り組んでいるんだなぁと感じました。

他にも、QA活動の一環として、開発の状況を把握するため、ミーティングに参加しまくっているそうです。 これについて、私はできていないなと反省しました。

軽量なローカル環境を持てるようにすることについての意義について、とても参考になりました。 定量的な成果（1週間〜3日）が出たことは素晴らしいのはもちろんですが、副次的な効果として、テスト担当者のドメインに対する習熟が促進され解像度が上がることも、品質活動に関して良い効果を生んでいるのではないかと思いました。 その結果として、より早い段階で不具合を検出でき、より具体的なフィードバックを行えるようになり、リリースサイクルの短縮にも寄与していると思います。 しかし、そのようなサイクルを回すには、QAエンジニア側も多くの負担を強いられるので、完全な形で実現するために色々考えて実施していかないとダメなんだろうなぁと感心しました。

結合テストの自動化にQAはどうかかわっていったか

• 講師：永田 敦（サイボウズ）

続けて、サイボウズさんのテストの自動化に関する取り組みに関する講演を聞きました。 UIテストよりE2Eテストの優先度を上げ、自動化の普及に取り組んでいるそうです。 APIテストのオーナーが開発チームにある場合、テストをどのように設計したら良いのかわからないそうです。 逆にオーナーがテストチームにある場合、修正に膨大な時間が取られます。 その場合、開発チームはテストが壊れることにあまり意識が向かなくなるようで、DevOpsチーム全体でAPIテストのオーナーシップを持たなければならないと言っていました。 DevOpsチーム全体でオーナーシップを持つことにより、問題が発覚するまでの時間が短くなり、開発者がテストを壊すことに意識が向くようになるそうです。 結果的にフィードバックループが速く回転することにより、全体としての負荷が下がったそうです。

テスト計画にも問題があったそうです。 テストの観点や背景が、暗黙知が働いていて曖昧になっていたようです。 このテストで何を評価したいのか？、このテストでやるべきなのか？、などの議論がなかなか進まなかったそうです。 QAメンバーもテスト項目の言語化スキルが必要と分かり、結果的にQAもより深く目的や観点を考えるきっかけとなり、テストの責務について認識するようになったそうです。 それによって、自動化の設計がしやすくなり、工数も減っていったそうです。 このように、QAと開発者が互いに信頼やリスペクト意識を持つことにより、より質の高いテストコードの設計ができるようになったそうです。

素晴らしい取り組みだと思いましたが、QAと開発の相互理解が肝となり、長い時間をかけて今の状況を作り上げたのではないかと感じました。 私は開発者なので、どうしても開発者目線でQAチームを見てしまうことがあるのですが、暗黙知が働いたテスト計画書を見た覚えはあります。 目的が明確でないと自動化の設計がとても複雑になり、冗長な設計になり、結果的に自動化することによって逆に負荷が高くなってしまいます。 QAと開発者が互いに尊重しあい、前向きに議論できる関係性が構築できれば質の高い自動テストが実現できる事例を紹介いただき、大変参考になりました。

終わりに、 JaSST'23 Tokyo に参加してみて、開発チームとテストチームは互いに尊重しあう文化作りが大切だなと改めて実感しました。 テスターからの不具合報告に「バグ」というキーワードを織り込んではいけないとかはよく耳にしますが、テストチームからの過度なへりくだった対応もあまり良い効果を生まないような気がします。 逆に開発チームがテストを破壊することに無関心でいることも、良い結果を生みません。 現在、テストの自動化に取り組んでいますが、ツールの検証や実装だけでなく、組織の文化的な側面にもアプローチしていかなければならないと感じました。