こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の様子
“品質”をみんなのものにするために行なっている入社者オンボーディングについて by miisanさん
まずはmiisanさんから、令和トラベルさんでやっているオンボーディング(全社関連のオンボーディング、)に関して紹介がありました。以下、やられているオンボーディングの内容を紹介します。
- 全社関連のオンボーディング(Slackのワークフローにて整理がなされていて、雇用形態に合わせてワークフローをこなす形で完了できるような工夫を取り入れている)
- 各部署のオンボーディング(部門を知るためのインプットやドメイン知識を知るための講座が用意されている)
- 担当部署のオンボーディング(プロダクトや仕様のキャッチアップの他、日次で1on1を実施して個別の困りごとを解決する)
また、非QAエンジニア向けにもQAオンボーディングを実施しているということで、これには以下のような理由があるそうです。
- IT未経験のエンジニアもいるため、QAという言葉自体に馴染みがない人がいるため
- 品質づくりをチーム戦で行えるようにするため(品質に関するものは全部)
- 品質とは答えがない定性的なものなので、QAチームだけではなく全員で一緒に考えていくようにするため
このQAオンボーディングでは、
などをしているそうで、プロダクトチーム全体で品質に対するマインドセットが向上していることや、QAがプロダクトチームと交流できるといった結果も出ているそうです。
ユニットテストの品質改善周りについて よけいさん
次によけいさんから、1ヶ月でテストコードを15,000行リファクタリングした話を聞いていきました。
リファクタリングの背景には、
- 元々のテストコードが読みづらく仕様がわからない
- 開発生産性の停滞
- 質とスピードのトレードオフが発生
があったそうで、妥当性/十分性/可読性の3つをポイントにして、テスト実行時間/テスト成功率/信頼できるテスト比率*1/定性指標をメトリクス*2にしながら、40%くらいのテストコードをリファクタリングしたということでした。
テストコード改善の際には、hotspot値分析をかけた後にブラックボックス的な観点でテストコードの十分性/妥当性を確認し、最後にホワイトボックス的な観点でテストコード改善をしたということで、改善をしていく過程で以下のような点を課題として感じたそうです。
- テストツリーのContextとitの抽象度が揃っていない
- 不要なテストが多い
- 定義されている変数がテスト対象から離れている
gTAAってなんなの？ やまずんさん
続いてやまずんさんから、gTAAに関する話がありました。
gTAAは、generic test automation architectureの略で、JSTQBのシラバスでは以下のような定義がされているということです。
gTAAは、gTAAのレイヤー、コンポーネント、インターフェースを表す。これらは特定のTAS向けのTAAとして具体 化される。これにより、構造化されたモジュール形式のアプローチを利用して、以下の方法でテスト自動化ソリューションを構築できるようになる。
• 内部および外部で開発したコンポーネントによってTASを具体化できるように、TASのコンセプト、レイ ヤー、サービス、インターフェースを定義する
• シンプルなコンポーネントを利用して効果的かつ効率的なテスト自動化を行えるようにする
• 各種ソフトウェアの製品ラインや製品ファミリー、およびソフトウェア技術やツールが異なるものを含め、 別のTASの開発やTASの改良の際 にテスト自動化コンポーネントを再利用する
• TASの保守や改良を容易にする
• TASユーザー用の基本的なフィーチャーを定義する
やまずんさんとしては、gTAAは下レイヤーから理解をしていくのがよいのではないかと考えているそうで、レイヤーごとに以下のような具体的なツールをイメージしているそうです。*3
- テスト適合レイヤー...selenium等
- テスト実行レイヤー...Junit5, Jenkins等
- テスト定義レイヤー...キーワード駆動とかのスプレッドシート, CucumberなどのBDDツール等*4
- テスト生成レイヤー...エッグプラント, GIHOZ, ChatGPT等
また、テスト自動化の世代からgTAAを考えてみると、世代が進むにつれて柔軟なTAA, TASが多くなっているなっているとも言えそうかもしれないという話も出ていました。
色々話したものの、謎が深い点*5もまだまだ多いそうで、是非フィードバックがほしいということでした。
エンジニア参加の実験や商用開発のケーススタディで欠陥やバグについてわかったことと今後の実験 森崎さん
最後に森崎さんの発表を聞いていきました。
まず、実現手段依存の欠陥について説明がありました。
実現手段依存の欠陥とは、仕様レビュー時には気が付かないが仕様確定後の決定で仕様が曖昧となってしまうコンテキスト依存な欠陥のことで、例えば「ファイルに出力するデータは改行で区切る」という仕様があった時、Unixで書き込んでWindowsで読み出すコンテキストでは欠陥が見つかるような欠陥を指すということです。
このような欠陥はシステムの主要な目的に着目してゴール指向要求分析を実施するのが効率的だということでした。
次に、PRレビュー戦略の調査の説明がありました。
この調査では、116名の技術者に振る舞いを変えるPR/振る舞いを変えないPRをレビュー計8つしてもらい、全部のレビューが完了した人の戦略を調査したそうで、以下4戦略を取っているという結果が得られたということでした。
- タスクの内容から既存コード、変更コードの特定部分を確認
- 既存コード、変更コードをざっと確認
- データの参照、更新部分や実行順序等の依存関係をたどって確認
- 変更部分のみを確認
同時に、所要時間がかかっているPRの調査もしたそうで、参照している/されている変数の数が多いほど読解時間をかけていることなどもわかったそうです。
以上の研究結果から、以下の2点が結論として導かれるということでした。*6
- 自分たちのコンテキストで未然に防止できているような欠陥、検出できている欠陥を把握すると効率的になる
- 検出できていない欠陥を把握すると検出できるようになる可能性が高い
会全体を通した感想
久しぶりの参加でしたが、濃密なプレゼンが多く楽しかったです。
いろいろな系統の発表が多かったですし、久しぶりにお話を聞く方もいらっしゃって、充実した時間を過ごすことができました。
