天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

バグ分類に合わせた品質評価 - エビデンスにもとづくシフトレフトとシフトライトテスティングに参加してきた

findy.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

本イベントでは、実証的ソフトウェア工学の研究をされている森崎修司（@smorisaki）准教授をお招きし、シフトレフトとシフトライトのアプローチを適切に統合し、迅速なリリースサイクルと品質向上をどのように実現するかに焦点を当て、森崎先生の研究（エビデンス）に基づいた解説と具体的な事例をお話しいただく予定です。

会の様子

森崎先生の講演

バグ分類と品質評価方法の例

最初に今回のタイトルにあるバグ分類と品質評価方法の例として、境界値分析が挙げられました。

境界値分析であれば、バグ分類が「仕様とプログラムで条件分岐が一致しない」になり、品質評価が「ペアプログラミング(未然防止)」「条件分岐の境界となる部分をコードレビューで確認する(検出)」「条件分岐の境界となるような値をテストする(検出)」の3つになるということです。

品質評価方法

先程の例でもわかるように品質評価方法は多数あり、合理的な方法を選択して併用することが大切だという話がありました。
また、開発の早期にできる方法に品質評価方法をシフトすることをシフトレフトとして言うという話もされていました。

バグ分類の設定方法

バグ分類の設定方法としては、

  • 過去バージョンや類似システムのレビュー観点を参考にしたりすることでバグ分類を直接指定する方法
  • 提供できていない保証内容や提供することを明示している保証内容からそれを損なうバグ分類を見つけたりする保証すべき内容を明らかにしてからその内容を損なうバグ分類を選ぶ方法

の2種類があるという話がありました。

森崎先生の研究紹介1〜設計時点のモデル図などから修正コストが大きい場所を予測する〜

モデル図やシーケンス図など設計時に作成するドキュメントから修正コストが大きいバグを予測し、実際にコーディングする際にその点に気をつけて実装することでバグを防止する事例の紹介がありました。(詳細は森崎先生の論文参照)

森崎先生の研究紹介2〜自動運転システムでの問題分類特定の取り組み〜

次の事例紹介として、検出されたバグや問題からバグや問題の分類に取り組み、単体テストレベルで見つかるバグをシミュレーションテストで見つけないようにシフトレフトした話がありました。

具体的には、継続的インテグレーションでバグが見つかりそうなテストを優先的に実行することでテストの効果を高めるようにしているそうです。

森崎先生の研究紹介3〜t-wadaさんの協力のもと、可読性向上の度合いからリファクタリングの優先順位を決める~

最後に、命名的問題があるコードと構造的な問題があるコードそれぞれを読んでもらったところ、アンケートだと構造的な問題があるコードのほうが読みにくいと言う回答が多いのに実際にコードを読解できているか(正答率)は構造的な問題があるコードのほうが高い結果になった事例を紹介してくれました。

Q&A

続いて、視聴者からQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

事例1とモデル検査は違うのか？

モデル検査はモデル自体が厳密に定義されていることが多いが、事例の場合はもっと柔らかく不備がある場合もある。

既に発生したバグをどういう粒度だったりどういうやり方で分類すると良いのか？

森崎先生も悩んでいるが、まずは実際にあったバグから分類をはじめていくといいのではないかと思う。

シフトレフトするだけではだめで比較勘案して戦略を立てるかという趣旨の話だと思うが、どの段階で行うかのトレードオフ判断の事例を知りたい

事例1であれば修正コストが大きい、事例2であれば修正時間がかかってリリースが遅れるかを基準としている。

修正時間がかかってリリースが遅れるかを基準とできればよいのだが、メンバーの力的に難しいというのが実情ではあると思う。

品質評価方法に関してはLLM活用も視野に入るのか？

入ると思うしやっているが、時間の関係もあるので説明しにくい。

境界値分析をするのに同値分割が必要だと思うがこの分割に決まった基準はあるのか？

あると思うが、それが最適化は吟味が必要。

分割の設定方法おアプローチとして事業によって適したアプローチはあるのか？

あると思う。メンバーのスキルやメンバーの意思決定方法や委託をどれだけするかなどの開発体制が大分変わってくるはず。

すごい極端に話せば、一人で日曜大工でプログラミングするときと複数人で開発するときだと全然入ってくるバグは違う。

事例2に関して、検出できると判断できる基準はなにか？

森崎先生個人の意見としては、検出方法(例えば単体テストの自動化など)が設定できれば、検出できると判断していいと思う。

今回説明した方法とODC分析は関連があるか？

めちゃくちゃある。ODCの方が良ければそちらから入ってもいいが、トリガーとか上がりにくいものもODCには入っているので、敷居が高い感じはある。

SSTが示すバグ可能性のどこまでをバグ分類すべきか？

SSTが示すバグの可能性は割と広めに取っているので、この変にたくさん警告あるから見にいってみようみたいな使い方をしつつ、本当に危ない部分は実際に見に行くという形になると思う。

過去にバグ分類を社内で標準化して工程特定できるようにしたのだが、アジャイル開発の浸透によって陳腐化してしまった。アジャイル開発時のバグ分類の観点をアドバイスしてほしい

森崎先生も困っているが、テストや受け入条件を増やすことができたらバグ分類になるのでは？と思う。

バグをどういった単位で分類しているのか？分析に使っている評価軸はあるか？

要因分類と、開発者へのざっくばらんなインタビューの2つを組み合わせられるとよいのではないか？と思う。

バグ分析はどのくらいの頻度で実施するものか？

やり過ぎはしんどいので、開発の仕方や体制、開発機能が変わったタイミングでしばらくしてからがよいかと思う。

仕様ドキュメントがなくQAのキャッチアップ時間がコストになってしまいがちな現場でシフトレフトをどう進めたらいいか？

最も大事なところを先に見せてもらうなどが考えられる。

シフトライトの話は出てこないのだが何を判断材料にするのか？

致命的でないUI不具合などからスタートするとよいのではないか？

認知負荷が上がらないことや開発者体験を損なわないための事例が知りたい

今日の話だと、名前がどうしようもないコードと条件分岐がひどいコードどちらを最初に直すのか？みたいな部分が該当すると思う。

QAエンジニアとして最初に学ぶべきことは？

どんなバグのパターンがあるか、が今日のテーマとしては挙げられる。あとは、どういうバグは不利益になってどういうバグは不利益にならないか？と考えられるとQAエンジニアとして第一歩を踏み出せると思う。

開発者視点と品質保証側の視点の違いを上手く組み合わせて方向性を一致させる際に気をつける点があれば聞きたい

どういうのがユーザーにとって利害があるのか？をすり合わせることなどが挙げられる。

ソフトウェア工学の研究者が、「エンジニア向けに示唆が深いことを言ったとしても自分の業績や評価は上がらない」と言っていたが同じことを思うか？

短期的な評価は上がらないかもしれないが、長期的に見ると役に立たない研究だと判断されて研究分野がしぼむと思うので、示唆が深いことを言う努力をすべきだと思う。

カナリアリリースをして不具合があった際どこまで戻すかに関してルールはあるのか？

ルールはないと思う。戻しやすなどで決めていくのかな、と思う。

会全体を通した感想

森崎先生らしさ全開の重厚な内容で色々な研究が紹介されていて、とても面白かったです。

Q&Aでも幅広い内容の質問が寄せられていましたが、どれに対しても研究者だからこそできる示唆が深い回答をたくさんしてくださっていて、勉強になりました。