社内で実施したシラバスの「テスト技術者資格制度」輪読会に参加して良かったことのまとめ
はじめに
この記事では、社内で実施されたシラバスの「テスト技術者資格制度」の輪読会に参加した感想と得られた学びについて書きたいと思います。
JSTQBは国際的なソフトウェアテスト資格認定制度であり、このシラバスはその基礎レベルの内容を網羅しており、テストや品質について体系的にまとめた内容になっています。
参加理由ですが、
所属しているチームでは、スクラム開発を採用しており、2週間スプリントで開発に取り組んでいます。
開発の中でテストや品質について理解深めることがソフトウェア開発ライフサイクルの改善になる事と、
シラバスの「テスト技術者資格制度」のドキュメントは内容自体も難しい点も多かったので、個人で読み進めるより他の人の意見やアドバイザリとして参加しているテストマネージャーの方の意見も聞くことができるのが主な理由です。
輪読会の進め方
シラバスの「テスト技術者資格制度」のドキュメントを章ごとに発表者と参加者に分かれて当日までに準備をして当日の輪読会に臨みます。
参加メンバーの構成
輪読会への参加は挙手制で部署を超えて様々なメンバーが集まり開催されました。
普段接点のないメンバーと話すことや、
他チームの取り組みも聞くことができ参考になりました。
(リモートで働いていると接点がなかなか生まれないのでこういう機会も良かったと思いました)
参加メンバーは様々なチームや職種から計6名が参加しました。
【参加職種】
- フロントエンドエンジニア
- バックエンドエンジニア
- スクラムマスター
- PM
- ITコンサルタント
参加したメンバーの領域からもテストや品質はエンジニアだけではなく、
アプリケーションに関わる人の全てが気にすることで、関心のある領域だなと感じました。
事前準備と当日の流れ
輪読会は以下のような流れで進められました。
- 発表担当者は担当章を事前に読み込み、発表資料を準備
- 担当章は挙手制で早い者勝ち
- 個人的には5章の「テスト活動のマネジメント」の内容の理解が難しかったと感じました。
- 参加者は事前に資料を読み込み、質問と感想をMicrosoft Loopで共有
- 業務を通して行なっているテストや品質と章ごとに記載されている内容を行き来しながら疑問点と感想を記入しました。
- 発表担当者は共有された質問に関する回答を用意
- 「ソフトウェア開発ライフサイクル全体を通してのテスト」を担当しました。
- 各項目ごとで大事な観点を資料としてまとめて発表を行いました
- 当日は発表と質疑応答、ディスカッション
- 発表者の発表後は、運営やアドバイザリから補足や具体的な事例なども紹介してもらい、実践までをイメージするのに役立ちました。
- 質問の回答は自身で行なっていることや調べた内容を回答し、参加しているメンバーにも意見をもらい内容をまとめていくような形でした
- チェックアウト
- 運営の方まとめと次回の内容を告知して終了
輪読会から得られた気づきと学び
輪読会を通じて、テストや品質について視野が広がり学びが多くありました。
普段開発プロセスの中で行なっているテスト内容の理解を深めることができました
(テストレベルとテストタイプを組み合わせることで品質を高めることができることなど。)
特に印象に残った点についてのまとめと開発にどうフィードバックしていくかを書いていきます
テストの早期実施の重要性
ドキュメントのP18で紹介されている1.3節「テストの7原則」の3番目の原則
「3.早期テストで時間とコストを節約」に記載されている
シフトレフトは早期の問題発見によるコスト削減・品質向上の観点から重要性を再認識しました。
シフトレフトはソフトウェア開発ライフサイクルの早い段階でテスト活動を開始し、
品質向上とコスト削減につながることを意味しています。
具体的には以下のような事が考えられそうかなと考えました。
- バグの早期発見によるコスト削減・開発の初期段階でテストを実施することで、後工程での大規模な修正を防げること
- 静的テストは「ソフトウェア開発ライフサイクル」の早い段階で欠陥を見つけ出すことができる。シフトレフトの主要な目的と一致
- 静的テストと動的テストを組みわせることでテストの有効性を高めることができる
- 要件定義段階からテスト設計・ユーザーストーリーの作成時にテスト観点を考慮することで、要件定義の精度を上げることができる
開発プロセスの中で早い段階でテストを行うことで安心して開発に取り組めるのは心理的にも良い事だなと思いました。
フロントエンド開発におけるユニットテスト
フロントエンド開発において、自動テストはコードの品質を保証する重要な要素です。
プロジェクトの開発プロセスでは、以下の2つのテスト手法をCIに組み込んで自動化しています
フロントエンド開発におけるユニットテストはシラバスの中で、2.2 テストレベルとテストタイプとして記載されています。
- Jestを使用したユニットテスト
- Storybookを活用したインタラクションテスト
テストの観点やコンポーネントのテスト方法について、以下のような改善策を考案しました。
テスト作成の基準明確化
テスト戦略としてカバレッジを100%は目指さずにサービスにとって重要な箇所に絞り込みテストを作成していく方針ですが、
テスト作成する際の基準を明確にすることで、効率的かつ効果的なテストを作成できることを
考えてテスト基準について考えました。
- 複雑なロジックの関数
- 影響範囲の大きさとバグが混入しやすいため
- ユーザー入力を処理するコンポーネント
- 様々な入力パターンに対して動作をするか確認する
- 重要なビジネスロジックの関数
- ビジネス影響が大きくユーザー影響が大きいため
- 状態管理に関わるロジック
- 多くのコンポーネントで使用されて影響範囲が大きいため
テストの観点
効果的なテストを行うためのテスト観点についても考えてみました。
- 機能的側面:期待通りの動作をするか
- 実装が仕様を満たしているかを確認する
- エッジケース:境界値や異常系の処理
- 通常の使用パターン以外のケースでも正しく動作することを確認
- パフォーマンス:レンダリング効率
- 重い処理を含むコンポーネントのレンダリングを確認
シフトレフトをスクラムイベントで行う
シフトレフトをスクラムイベントにどの様に取り入れるのが良いのか考えてみました。
プロダクトバックログリファインメント: テスト観点の追加
プロダクトバックログリファインメントでは、ユーザーストーリーの詳細化と優先順位付けを行う。
- 各ユーザーストーリーに「テスト観点」の項目を追加
- 想定される主要なテストシナリオを列挙
- エッジケースや負荷条件などの非機能要件も考慮
例:
ユーザーストーリー: ユーザーとして、商品を検索したい
テスト観点:
- 正常系: キーワード検索、カテゴリ検索
- 異常系: 該当商品なし、特殊文字入力
- 非機能: 大量データでの応答時間、同時アクセス時の挙動
スプリントプランニング: テストタスクの明確化
スプリントプランニングでは、スプリントゴールの設定と作業の見積もりを行う。
- 開発タスクと並行してテストタスクを作成
- テスト設計、テストケース作成、テスト実行を別タスクとして扱う
例:
ユーザーストーリー: 商品検索機能
タスク:
1. 検索APIの繋ぎこみ
1. 検索UIの実装
1. 検索機能のテスト設計
1. 検索機能のテストケース作成
1. 検索機能の単体テスト実装
1. 検索機能の結合テスト実装
レトロスペクティブ: テストプロセスの改善
レトロスペクティブでは、チームのプロセス改善について話し合う。
改善点については、
- テスト設計や実装で困ったことを共有
- テスト効率を上げるためのアイデアを出し合う
まとめ
シラバスの「テスト技術者資格制度」輪読会を通じて他チームの意見や、疑問点を聞くことができたこと
ドキュメントの中で難しい内容については、アドバイザリーの方に詳細を聞くことができより具体的なイメージを持つことができました。
テストや品質について基本的な考えを網羅的に学ぶことができる良いドキュメントでした。
今回の学びを開発プロセスの改善に役立てていくことと、今後もテストや品質について書籍や勉強会などで学んでいきたいと思います。
Discussion