コード品質を確保するための試み

JaSST'22 Kyushu での Lightning Talk の資料です。

Transcript

1. コード品質を確保するための試み すずき しょうご JaSST'22 Kyushu Lightning Talk
2. 本 Lightning Talks の目的  静的解析ツール(SonarQube)を利用して、コード品質を確保しようとしている試みの紹介になります。  同じようなことをやっている方がいましたら、コメントとかアドバイスをいただきたい。  こんな活動しているコミュニティとかありましたら情報をおしえていただけるとうれしいです。 2 2022/11/05
3. 自己紹介  すずき しょうご  某メーカ系会社の品質保証部門に所属。システム開発業務を経て、品質保証部門に異動。 以降開発側とは、独立したポジション(ロールとか権限とかとか)で、プロダクト/サービス開発にかかわる。 主に、エンプラ・業務系システムのQA業務に従事。 (QA業務＝外部設計レビュー、リリース可否判定(出荷検査)、プロセス改善などなど) 近年は、レビューの改善(ISO/IEC 20246 をベースとしたプロセスの見直し)や テストの改善(ユースケーステストの検討、キーワード駆動テストの試行)などを実施。  JSTQB Advanced Level Test Manager / Test Analyst ソフトウェア品質技術者(JCSQE) 初級 / 中級 3 Twitter : @rin2_
4. 背景  コードを見てみると、適切ではない(と思われる)コード記述が散見される。  テストで検出された不具合を確認すると、コーディングの質に起因する不具合が検出されるときがある。  検出/再テストを実行などの影響で必要になり、この影響でテスト工数が嵩んできている。  テスト実行前に不具合を推定/検出できるようになれば、テスト工数も削減でき、品質向上も図れるのではないか？  開発工程、特にコーディング工程、については、開発者個人とその周辺に閉じていて、「コードの品質」については、十分共有されて いない。  共有されるのは、開発規模、テストで検出された不具合件数 などが限られた指標や内容が中心。  「コードの品質」について、より詳細なメトリクスや情報を確認し、シフトレフトを加速させる必要があるのではないか。 4
5. 手段  コードメトリクスを利用することでコード品質を評価しよう。 → SonarQube を利用して、コード品質を定性的/定量的に可視化する。 5
6. やってみた！(環境構築)  ひとまず、小さいところからはじめる、ということで、WindowsローカルPCに環境を構築。  環境構築をスピーディに行うため、オフィシャルの Docker コンテナを使って、SonarQube 実行環境を構築。  詳細は、以下メモ書き(?) に記載 「改訂版 コードメトリクスからコード品質を確保する話(0.9版)」 6
7. やってみた！(コード解析)  プロジェクト一覧から、コードの品質状況が可視化されてる。 7 GitHub で公開されているコードに 対して静的解析を実行
8. やってみた！(コード解析)  選択されたプロジェクトのコードの品質状 況が可視化されてる。  バグ指摘数  セキュリティの脆弱性箇所指摘数  コード記述があまりよろしくない個所数と修 正にかかるおおよその時間  テストカバレッジ 8
9. やってみた！(コード解析)  不具合指摘箇所とその内容、深刻度などが分かる。 9
10. やってみた！(コード解析)  セキュリティの脆弱性指摘  指摘内容と深刻度  指摘に該当するコード部分 10
11. やってみた！(コード解析)  テストカバレッジと技術的負債を可視化 11
12. やってみた！(コード解析) 12
13. どうだった？  テストを実行する前に、欠陥(と疑わしい箇所)検出が可能。  指摘内容を確認し、対応要否を検討できるようになる。  ソフトウェアのセキュリティに関わる脆弱性をテスト前に検知できる。  コードを細かく調べなくても、ある程度「コード品質」を定量的にリスクがあるコード部分をテスト前に推定/検知できる。  バグ指摘が集中しているプログラムファイル  コードが複雑でテストがしにくくなっている(条件式が複雑など)部分  コードの流れが理解しにくく、プログラム保守が難しくなっている部分  各プログラムのテストのバレッジがどれくらいあるか →(リスクある部分のコードレビューを手厚く(コストを費やす(人・時間をかける)、優先順位を高とする)などテスト前に手が打てそう 13 コード品質を確保する上で有効(そう？)
14. 気になること  静的解析実行結果と、現実の感覚の際の評価が必要。  コードをある程度理解したり、ソフトウェアをビルドできる知識やスキル、環境が必要。  非ソフトウェア開発者には厳しいときもありそう。  開発者と協力して推進する必要がある(→開発者との信頼が重要)。  ツール(SonarQube)を使いこなすために、学習コストがそれなりに必要になりそう。  自分たちのルールを実装するためにも、ツールの学習にはコストがそれなりにかかりそう。  開発標準などのルールの整備が必要。  ルールの背景が分からないため、実装すべきルールなのか整理や判断が必要。  ソフトウェア内で使われる言語は英語が中心。  英語アレルギーな人には、ちょい敷居が高いかも。 14
15. 今後のチャレンジ  自組織のコーディングに関するルールや知識をツールに実装する。  CI/CD のツールチェーンに組み込む。  コーディング時に不具合や技術的負債を作り込まないようにする  統合開発環境(IDE)に、SonarLint などを利用する。 15
16. まとめ  コード品質の確保したい背景  コードを定量的/定性的に視るツールの試行結果  コード品質を確認するための課題 16
17. 最後に  いろいろな組織のQA部門やQAのお仕事に興味があります！お話しさせていただけるとうれしいです。 17
18. 参考文献  ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方(翔泳社)  ゲームプログラマのためのコーディング技術 (技術評論社)  クリーンなコードへのSonarQube即効活用術 (リックテレコム) 18