3/9(木)、10(金)で行われたJaSSTソフトウェアテストシンポジウム-JaSST'23 Tokyoに参加してきました!
今年のテーマは「相互理解で広がる世界」。カオスエンジニアリングの話から未来の話まで聞けて面白かったです。聴講したセッションと感想をざっくりまとめます。
- 「Chaos Engineering to Continuous Verification」
- 感想
- 「MBTで目指すこれからのテストづくり」
- 「カオスエンジニアリングの裏話」
- 「ローカル環境を用いたアジャイルテスティングの実践事例~より高速なフィードバックを目指し~」
- 「ロケーターを学んでテスト自動化上級者を目指そう」
- 「結合テストの自動化にQAはどうかかわっていったか」
- 「QAでE2Eテストを普及させるには?」
- 「開発とQAの垣根を越えるチームへ ~お互いを活かし合うWhole-teamアプローチ~」
- 全体的な感想
「Chaos Engineering to Continuous Verification」
Casey Rosenthalさん(Verica)
初期のネットフリックスはサービス品質が悪かった
→当時のクラウドのインスタンスは時々予告なく落ちていた
意図的にインスタンスをシャットオフする。上手くいったので徐々に拡大 Chaos.com
エンジニアは自分のマイクロサービスとその両隣は分かっている。
チーフアーキテクトはいない
→CHAP(カオスエンジニアリングのチーム)を作って対処
What could go wrong in a complex system?
例
Game Day:システムに悪いことが起こったときにどうするか考える日
問題
とあるサービスでStagingのkafkaを止める
→Productionが止まった!
原因:staginの構成をコピーしてprodを作ったときに書き換え忘れてstagingのkafkaを見に行ってる部分があった
Game Dayでエンジニアが集まっていたのですぐに直せた(Game Dayでまだよかったとはいえ現場は阿鼻叫喚だったのでは…)
Verica社のopen incident database
https://www.thevoid.community/www.thevoid.community
間違った神話1「医療過誤を起こす人を首にすれば医療過誤は減るのでは?」
→No. スキルのある人たちがリスクの大きい可能性が高いものに対処した結果医療過誤が起きていた
医療過誤を起こした人を首にした結果、より低スキルの人が対処することになり医療過誤が増えた
間違った神話2「ドキュメント通りにやれば問題はない」
→No. 致命的な問題はユニークなものが多い
間違った神話3「以前の根本原因から防御する」
→No. 気を付けていても人間はミスをすることがある。直接ミスを起こした人ではなく仕組みとかの問題(ここ理解合ってる?)
*1
間違った神話4「信頼性を定量的に測定する」
→No. 特定のインシデントがどのくらい悪いかなどは分からない
間違った神話5「リスクを避ける」
→No. 経験が蓄積されない
間違った神話6「シンプルにする」
→No. 機能を追加する=複雑になっていく
間違った神話7「冗長性を追加」
→No. 冗長性を加えたことでかえってダメになったことがある
エンジニアは経済性、安全性、負荷の3つの観点
カオスエンジニアリング
実験を促してシステムの弱みを認識する
複雑性に対する経済的な柱 1910年代のフォードの例
関係の制約:ライン生産方式
環境:鉄道より道路を整備して車が売れやすくした
可逆性:フォードの例だとここはできていない。ハードが絡む部分は時間が必要なので難しい。
- CI/CD/CV
- CV(Continuous Verification)システムが望んだ通りのふるまいをしているか確認する
感想
複雑なものをシンプルにできればいいのだけど、もうある程度複雑なまま扱わなきゃいけないからどうすればいいか、を考えるヒントが聞けて良かったです。間違った神話3で理解を間違えていたのだけど、他の参加者の方から補足いただけたり、質問も拾ってもらえて助かりました!
「MBTで目指すこれからのテストづくり」
須原 秀敏さん、蛭田 恭章さん(ベリサーブ)
MBT(モデルベースドテスト)とは
テスト設計を自動化する技術。モデル(形式化された仕様)を入力して決められた変換ロジックを使ってテストケースを生成する
メリット
- 説明性:どうやってそのテストケースが生まれたかを説明できる
- トレーサビリティ:MBTモデル(or開発モデル)からテスト家素へのトレースが撮れる
- テスト設計の品質向上
- モデルを書ければ誰でも同じテスト設計が再現できる
- 過去の欠陥を再発させないためのテスト設計の改善が実現できる
- メンテナンスコスト
- 単一のメンテナンスポイント
- アジリティ
ベリサーブさんにとっての意義
MBTパターンを蓄積して再利用することで、テスト設計の知恵が「ちゃんと」たまる
MBTによりテストプロセスをデジタル化し、コアなデータを再利用可能にする
特性が明らかになっている場合、MBTパターンを適用できるかできないかの選択と判断
GIHOZとの関係
GIHOZは限定された(&非常によく使われる)MTBパターンを使いやすくするツール
MBT実践事例
知見を形式知化するアプローチ
テスト設計者が持つ知見の取り込み
例:WebAPI仕様
仕様はSwaggerにより形式化かされていた。以下の手順でパターン化
1. テストケースの収集
2. 仕様の確認
3. 暗黙的な仕様の確認 例:パラメータ間の大小関係
4. 暗黙的な仕様のパターン化
過去不具合から得た知見の取り込み
事象:不揮発性メモリの信頼性の問題でデータ欠損、データ読み込み処理に失敗し遷移不可になった
解決策:遷移の確率モデルを組み込む
質疑応答(メモできたところだけ)
Q. 「MBTパターン」以前に「MBTモデリング」が重要だと思うけど、なぜ「MBTパターン」なのかな? どういうモデルがあればよいのかを先ず追求すべきでは? もうすでにモデルは十分あるという認識?
A. どういうMBTパターンを適用すべきか(テスト戦略)
→こういうモデルを書くべき(モデリングガイドライン)
Q. パターン増えていきそうですが、ある程度増えると選ぶのも大変では? ドメインが異なると適用可能かの判断が難しくならないか?
A. 抽象化する。どういうモデルの特徴があって、どういうパターンにするかの順になるのでそれを選べる形にしたい。数は増えていくので解決を模索中
感想
これからのテスト設計のお話を聞けた気がして楽しかったです。こちらでも質問拾ってもらえて助かりました。
「カオスエンジニアリングの裏話」
堀 明子さん、松浦 隼人さん(オーティファイ)
基調講演のCaseyさんが書かれたこちらの書籍の翻訳の裏側のお話です。
注目したワード
- テスト VS 実験
- 妥当性確認 VS 検証
- 定常状態
- 影響範囲
Unknow unknownsに対処する
Known knownsはテストなどで対処、Unknown unknownsはカオスエンジニアリングで対処
- 妥当性確認(validation)
- 個々の要素が期待通りに実装されていることの検証に重きを置く
- 検証(verification)
- ビジネスケースと総合的な出力に重きを置く
Unknow unknownsに対処する
Known knownsはテストなどで対処、Unknown unknownsは実験、カオスエンジニアリングで対処
カオスエンジニアリングの発展原則
カオスエンジニアリングの原則 - Principles of chaos engineering
1. 定常状態(Steady State)に関する仮説を立てる
2. 実世界の事象を多様化させる(Vary:ハイレベルな変数を変化させる)
3. 本番環境で実験する
4. 継続的に実行できるよう実験を自動化する
5. 影響範囲(blast radius:爆発半径)を局所化する
感想
カオスエンジニアリングをがっつり解説してもらって、基調講演の内容の理解が深まりました。本買います!
「ローカル環境を用いたアジャイルテスティングの実践事例~より高速なフィードバックを目指し~」
村岡 里紗さん(freee)
問題:環境的なハードルがあり、QAエンジニアが気軽に変更を確認しに行くのが難しい
講演での「ローカル環境」の定義:画面や主要機能が動くかどうかを確認するのには足りる(パフォーマンスや構成は本番同等ではなくシンプル)
環境の制約なくできたところからテストしていける
実践事例
0. 可能な限りすべての情報をキャッチする(仕様決めのMTGにはすべて参加する)
1. テスト内容はチーム全体で合意をとる(リスク洗い出し会を行う)
2. 探索的にテストをしていく
3. 必要に応じて自動テストを追加し、今後のデグレに備える
効果
全体の約50%のバグが通しテストの前に発見される
課題
- 実践できているのは一部にとどまる
- 立ちはだかる「操作知識」という壁 立ち上げは容易だが、拡張するにはひと工夫必要
- 適材適所の使い方をする必要がある ローカル環境でできないテストもある
- 開発チームとの関係性が大切
感想
課題感持ってるところが非常にあるあるで共感しながら聞いてました。Discordも盛り上がっていて楽しかったです。ローカル環境でテストしてるうちに副次的にドメインの知識も深まってる点も良さそうと思いました。
「ロケーターを学んでテスト自動化上級者を目指そう」
伊藤 望さん(MagicPod)
ロケーター概要
WebページのUIの各要素は裏でエンジニアがシステムIDをつけている
が、システムIDがなかったりする場合もあるので、その場合は要素の順番とかで指定している
HTML概要
- 「タグ名」で要素の種類が分かる(inputやbuttonなど)
- 「属性」で要素の各種情報を指定(nameとかidとかplaceholderなど)
トラブルシューティング
初級編
問題:見た目上ボタンがあるのに、E2Eテストで「見つからない」エラーで落ちる
原因:見た目は変わってないけどidが変わっていた
ロケーターの使い分け基準
よいロケーター=メンテナンス性が高い=画面の変更が入っても影響がない
data-testidのようなテスト専用のものを振ってもらうのが推奨
感想
ローコードのE2E自動化ツールを触ってるけどHTMLの知識は少ない人にぜひ聞いてほしい内容でした。資料は後日公開いただけるとのことで楽しみにしています!
「結合テストの自動化にQAはどうかかわっていったか」
永田 敦さん(サイボウズ)
Before:手動テストがメイン
新規チーム:自動テストをメインにする
- 方針 テスティングトロフィーにする(結合テストメイン)
- 何が自動化できて、何が自動化できないのかのテスト設計の議論
- より適切な場所、レベルで、テストを行う
- 開発者、QAのテスト設計の議論により
- 感謝の仕組みによってWhole Teamの実感が回っていく
感想
開発とQAの議論でよりよりテストができていくのが素敵でした。QAがテストコードも各チャレンジしているのがすごいですね。
「QAでE2Eテストを普及させるには?」
田中 龍一さん(freee)
E2Eテストの勉強会開催、成果
何をしたいツールなのかの説明からPullRequestのレビュー方法の説明まで行った
コーディングに興味を持ってくれる人が増えた
工夫
- 参加メンバを第一陣、第二陣に分けた(前提知識があったりフィードバックよくくれる特性の人が第一陣)
- 自動テスト何でも相談所を週一で開いた
- 勉強会を行うメンバーが同じプロダクトのメンバーであること(具体的なアドバイスがしやすい)
感想
勉強会に色々工夫されてるのが素敵でした。特に参加メンバー第一陣にフィードバック積極的にくれる人としている点は、うちでも真似させてもらおうかなと思いました。
「開発とQAの垣根を越えるチームへ ~お互いを活かし合うWhole-teamアプローチ~」
SigSQAの皆様
ラーニングアウトカム
- スキルや知識を【つくり方・進め方の知識・経験】と【バグ・トラブル・失敗】の2つの方向性で捉える"QMクリスタル"
- どのようなスキルや知識、経験をシフトレフトすればよいのか
- 本年度の課題感
- 実際の現場においてより良い開発を行うためには、開発者、PO、PM等とどのように相互理解してチーム一丸となる進めるか
Whole-Team Approachとは何か
プロジェクトを成功させるために必要な知識とスキルを持つすべての人を巻き込むアプローチ
役割が異なる人たちの間にも、役割が重なる部分を意図的に設計。職種間で役割・責任を共有している
- プロダクト開発へのチーム全体アプローチの紅葉
- チーム内のコミュニケーションと協調が強化される
- 品質を全員の責務にする
- QAしてのWhole-Team Approach
- チームで品質保証をするためにテストを見直す
QAクリスタルとは何か
- QAチームの知識・経験、開発チームの知識・経験
- 開発とQAが互いの得意分野を分かっていく感じ
パネルディスカッション
感想
Discordの流速がものすごくて楽しかったです。「面倒くさいの言い訳にスキルがないを使う説」とかちょっと耳の痛いコメントもあり、面倒くさいをどんどん倒していかなきゃなーとなりました。
全体的な感想
「相互理解で広がる世界」のテーマの通り、QAが(少なくとも私は)あまり踏み込んでこなかったカオスエンジニアリングを詳しく紹介していただけて面白かったです。予測できないことを、コントロールできる範囲でどう試していくか、みたいなのが今から必要になってくるんだろうなあ。まだまだ知識が足りてないので勉強しなくては!
情報交換会で、基調講演のグラレコ見ながらわいわいできたのも面白かったです。グラレコ本当に素敵でしたので貼っておきます!
基調講演のグラレコを放流しますー! @Sara999M に描いていただきました! #jassttokyo pic.twitter.com/wrx2kAMBr5
— うへの / Ayako, UENO (@yeHoaqko) March 10, 2023
*1:※discordでKTさんから補足いただきました Verica - Inhumanity of Root Cause Analysis 「根本原因=ミスをした人を特定して気を付けてもらう」ということを指しているそうです。 日本的な感覚だとそれは根本原因としちゃいけない奴だろうと思っていたので混乱しました。