Classi開発者ブログClassi開発者ブログ教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。QAチームの竹林です。QAチームでは、単にテストをするだけのチームではなく品質向上をミッションとするチームとして、品質向上に向けた施策を実施してきました。QAチームの品質向上に向けた歩みの共有になりますので、QAの進め方について検討している方の参考になれば嬉しいです。QAの品質向上に向けた取り組みは「品質の見える化」から始めています。品質向上のための課題抽出や施策提案を、現状に最適な優先度や内容で進めるために、まずは現状を把握する必要性があるから、との考えからです。現状把握だけの利用でなく、今後の品質向上PDCAサイクルなど、QAの中長期的な取り組みのベースにすることを想定しています。「品質の見える化」の実装は、バグなどの不具合発生時に「どんな事象が?」「どこで混入した?」「なぜ混入した?」などの情報を残していく方式で進めました。この方式は、開発者の協力がないと成り立たないのですが、Classiの開発メンバーは品質意識が高くとても協力してくれるので、スムーズに進めることができました。(改めてこの場で感謝します。)「品質データの活用(第一弾)」を始める「品質の見える化」で見えてきた品質データは、「テスト結果レポート」を作るために活用しています。「テスト結果レポート」は、テストから得られた情報を基にしてリリースリスクを把握できるため、「リリース品質の向上」に繋げることが期待できます。リリース見解(総合的なリスク判断)「開発とテストの専業化」をトライアル「開発作業と検証作業を専業化するかどうか」は意見の別れる事案ですが、Classi開発では「専業化」をトライアルでスタートしています。開発スピードが企業戦略的にも重要な要素になっている現在では、専任メンバーがテストを専業することで得られる「開発メンバーの負担軽減」は大きなメリットです。一方で、専業化によるデメリットとして「開発者のテスト意識やテストスキルが低下する懸念」などがあり、今後はメリットとデメリットのバランスを観察しながら、随時ブラッシュアップしていく予定です。QAでも始めています。「上流でのバグ検出」を目的とする理由は、「品質のV字モデル」で提唱されるように開発後期(下流工程)で検出したバグは手戻りが多いため、できるだけ開発前期(上流工程)で検出したいとの考えからです。QAでも導入を開始しています。以前(10年以上前)からある自動化施策ですが、ここ数年は特に盛り上がりを感じており、多くの開発現場でデグレードに苦労していることが分かります。「品質データの活用(第二弾)」を始める品質データの活用(第一弾)では『リリース品質の向上』に活用しましたが、(第二弾)では課題や改善のヒントなどの見えた情報を開発工程にフィードバックして、『開発品質の向上』に活用します。QAでは挑戦を始めています。本施策については、当開発者ブログの別記事【QAチームが取り組む「品質の見える化」への挑戦】に投稿を予定していますので、併せてお読みいただけると嬉しいです。QAチームの品質向上施策をフェーズ分けすると、現在は後期に入ったあたりです。後期フェーズに入ったとはいえ、やることが少なくなったわけではありません。今後更にスピードアップが求められるソフトウェア開発や、日々進化する開発技術に対応するために、新しい施策の提案や実施済みの施策のブラッシュアップなど、タスクは尽きません。QAチームの品質向上への道は続きます。id:iri...2022-07-22データ基盤の品質向上への取り組みこんにちは、データエンジニアの石井です。先日公開した記事「...2022-07-19チームトポロジーを参考に新組織の編成を考えた話みなさん、こんにちは。Components配信アーキテクチャコミュニケーションチームのid:NozomuMiyamotoです。Corp.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。