Slide 1

Slide 1 text

2025/01/29 Findy イベント DevOpsに向けたテスト⽅針 〜 迅速なリリースとテスト戦略 〜 イオンスマートテクノロジー株式会社 CTO室QAチーム ⽩江 ⼤輔 ( @show_chan )

Slide 2

Slide 2 text

所属 • イオンスマートテクノロジー株式会社 • CTO室QA マネージャー 職歴 • 家電メーカで組込開発エンジニア • 携帯電話全盛期にテストマネジメントからQAへ • 携帯電話向け組込ブラウザの品質保証 • 国産 ⼿書きタブレット開発のテスト、QA • 品質コンサルティングなどを経験し現職 その他 • フルリモートになり奈良に引き篭り中 • ガジェット好き ⽩江 ⼤輔 @show_chan ⾃⼰紹介

Slide 3

Slide 3 text

会社紹介

Slide 4

Slide 4 text

イオンDX

Slide 5

Slide 5 text

膨⼤なIDと購買データを集約したアプリ「iAEON」 イオンDX iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。 提供開始から約3年で、iAEONは900万⼈以上の会員を抱え、独⾃のコード決済サービス「イオンペイ」は836万⼈ (23年5⽉時点)が利⽤しています。

Slide 6

Slide 6 text

イオンDX

Slide 7

Slide 7 text

品質改善のためのテスト設計とは︖

Slide 8

Slide 8 text

ChatGPTに聞いてみた 品質改善のためのテスト設計は、ソフトウェアや製品の品質を向上させるための戦略的プロセスです。 以下のポイントに焦点を当てることで、効率的で効果的なテストを計画・実⾏できます。 1. ⽬的を明確にする 品質改善の⽬標を具体化します。 •バグの早期発⾒: 開発プロセスの早い段階で問題を⾒つける。 •品質基準の達成: 性能、セキュリティ、使いやすさなど、特定の品質基準を満たすことを⽬指す。 •ユーザー体験の向上: エンドユーザー視点での満⾜度向上。 2. 要件の分析 要件を詳細に理解し、それに基づいてテストケースを設計します。 •明⽰的要件: 仕様書やユーザーストーリーに記載されている内容。 •暗黙的要件: ユーザーが期待する基本的な動作や品質。 3. リスクに基づくテスト設計 製品やシステムのリスクを評価し、重点的にテストすべき箇所を決定します。 •⾼リスク領域: バグが重⼤な影響を及ぼす可能性が⾼い部分。 •変更点: 新機能や修正された箇所はバグが潜む可能性が⾼い。 4. テスト技法の選択 適切なテスト設計技法を選択します。 •ブラックボックステスト: ⼊⼒と出⼒に基づいてテストケースを作成。 •ホワイトボックステスト: コード構造に基づいてテストケースを作成。 •探索的テスト: 短時間で効果的にバグを発⾒するためのアドホックな⽅法。 5. テストケースの設計 効果的なテストケースを作成するには以下を考慮します。 •カバレッジ: 仕様やコードの全体をどれだけ網羅しているか。 •優先順位: テストケースに優先順位をつけ、重要な部分を先にテスト。 •再利⽤性: 同様の状況で再利⽤できる汎⽤的なテストケースを設計。 6. ⾃動化と⼿動テストのバランス •⾃動化: 繰り返しが多いテストや⻑時間かかるテストに最適。 •⼿動テスト: ユーザー体験や直感的な操作性を確認するために必要。 7. 継続的改善 テスト設計プロセスを定期的に⾒直し、以下を実施します。 •振り返り: テスト結果やバグの発⽣傾向を分析。 •フィードバック: 開発チームや顧客からの意⾒を反映。 •プロセスの最適化: 効率性と効果を⾼める⽅法を模索。 8. 品質メトリクスの活⽤ テストプロセスの効果を測定し、改善ポイントを特定します。 バグ発⾒率: テストケースがどれだけバグを発⾒できたか。 カバレッジ: コードや仕様のどれだけがテストされたか。 テスト完了度: すべての計画したテストケースが実⾏された割合。 品質改善を⽬指したテスト設計では、戦略的な計画と継続的な⾒直しが重要です。 また、チーム全体で品質意識を共有し、改善を進めることが成功への鍵となります。 今回お話しする、 ⾃動化やプロセス最適化が 含まれていて、⼀安⼼

Slide 9

Slide 9 text

イオングループのDX 巨⼤な規模 膨⼤なシステム群 グループの独⽴性 参照: https://www.aeon.info/company/

Slide 10

Slide 10 text

話したいこと DevOps の導⼊ 👉巨⼤システム基盤への⾃動テスト導⼊の取り組み 開発と運⽤を統合 開発サイクルを効率化し、 迅速かつ安定した製品の提供を実現します QAはDevOpsと聞いて 何をするべきか︖

Slide 11

Slide 11 text

⾃動化の⽬的とは?

Slide 12

Slide 12 text

テスト⾃動化の⽬的のおさらい テスト⾃動化の⽬的は、ソフトウェア開発や運⽤における テスト作業を効率化し、品質を向上させることです。 以下の具体的な⽬的があります︓ 1. テスト効率の向上 •⼿動で⾏うテストは時間がかかり、⼈為的なミスが発⽣する可能性があります。 ⾃動化することでテストの実⾏速度が向上し、繰り返し実⾏する負担が軽減されます。 2. コスト削減 •初期導⼊コストは⾼いものの、⻑期的にはテストにかかる⼈件費や時間が削減され、コスト効率が向上します。 3. 品質の向上 •繰り返し可能なテストを正確に実⾏することで、ソフトウェアの⽋陥やバグを早期に発⾒し、リリース前の品質を⾼めることができます。 4. 再現性と信頼性 •テストスクリプトを使⽤することで、同じテストを何度でも同じ条件で実⾏でき、結果が⼀貫します。これによりテスト結果の信頼性が向上します。 5. 回帰テストの効率化 •新しい機能や変更が既存の機能に影響を与えていないか確認する回帰テストを効率的に⾏うことができます。 6. 頻繁なリリース対応 •アジャイルやDevOps環境では頻繁なリリースが求められるため、テスト⾃動化により迅速なリリースサイクルをサポートします。 7. カバレッジの向上 •⾃動化によって広範囲のテストケースをカバーでき、⼿動ではテストが難しい領域(例えば、⼤量データを使ったテストやパフォーマンステストなど) も実⾏可能になります。 8. ⼈為的ミスの削減 •⼿動テストに伴うミスを防ぎ、テスト作業の正確性を⾼めることができます。 9. チームの負担軽減 •単純で繰り返し作業が必要な部分を⾃動化することで、テスト担当者は複雑なケースや分析に集中できます。 テスト⾃動化を導⼊することで、開発プロセス全体がスムーズになり、ソフトウェアの品質と開発速度の両⽅を向上させることができます。 ただし、⾃動化には初期コストやメンテナンスの負担が伴うため、適切な計画と選定が重要です。 ChatGPTに聞いてみた (2回⽬)

Slide 13

Slide 13 text

DevOpsとテストの⾃動化 しかしこちらの有名な書籍によると、 「QAチームなどが作成管理する⾃動テストは、 ITパフォーマンスと相関関係にない」 とのこと。 その理由(ざっくり⾃分の理解 • 開発者がテストを作成するとコードがよりテスト可能なものになる • ⾃動テストを開発者責にするとテストの意識が⾼まる • QAチームのテストはE2Eに偏重する

Slide 14

Slide 14 text

QAチームが作る⾃動化テストの⽬的 • E2EによるUIを含めた⾃動化テスト • 頻繁なリリースに対応 • ⼈為的ミスの削減 • APIレベルの⾃動化テスト • 変更/影響範囲の網羅性確認 • ⾼速なテスト実⾏ リリース時リグレッションテスト デイリーヘルスチェック

Slide 15

Slide 15 text

テスト⾃動化への道 テスト項⽬の洗い出し ・⾃動化ツール側が対応しておらず、⼀部断念した ・既存のテストシナリオからの項⽬洗い出しはかなり時間がかかる ・テストシナリオの中で実は同じ項⽬(API)を何度も動作させていると気づく テストスクリプト作成 ・トライ&エラー&エラー&エラー...成功となりがち。そしてできた時の喜びは⼤きい ・このAPIを動かすには、まず別のAPIを動かして...ということが理解できた ・⼊⼒値の変数化を⾏うために、まず動作確認完了させ必要がある ・テストデータの命名規則をテストデータ作成前に決めておかないと混乱する ・シナリオ構成は表にしておく ・他の⼈が⾒てもわかりやすいような構成、命名を⼼がける ・実施可否の判断は早めに&エスカレーションも迅速に ・⽇々の成果物を必ず報告する(何してる?と思われないために) ・わからないことはガンガンサポートに問い合わせる シナリオメンテナンス ・テスト環境の変更情報への感度は⾼くする ・情報共有される場に参加していくことが望ましい ・ノウハウは整理して残しておく APIのテスト⾃動化を実装したQA担当者の声

Slide 16

Slide 16 text

テスト⾃動化カバー率 • APIテスト • リグレッションテスト項⽬換算 約50% のAPIをカバー • E2Eテスト • 通常リグレッションテスト 85% の項⽬をカバー • 336(⾃動化数) / 395(項⽬数) • フルリグレッション項⽬ 36% の項⽬をカバー • 336(⾃動化数) / 930(項⽬数) ビジネス基盤 (2024年12⽉末時点)

Slide 17

Slide 17 text

開発組織の⼀員として

Slide 18

Slide 18 text

チームパフォーマンス • Four Keys を意識する • デプロイ頻度 • 変更のリードタイム • 変更失敗率 • デプロイ失敗時の復元時間 • QAが活躍するために • この開発チームに必要な価値、品質を明確にする • ⼈が本当に⾒るべき観点に注⼒する • ツールは使いこなそう

Slide 19

Slide 19 text

QAとして。イオンにできること。そして社会のために • ⽣まれたイノベーションを安⼼、安全に使っていただける品質を⽬指して • 当たり前品質を迅速にリリースできる状態を作る • 魅⼒的品質を向上するための環境を作る 2024/12/04 Findy 198Presents イオンCTOやまけんさんの資料より引⽤

Slide 20

Slide 20 text

おわりに

Slide 21

Slide 21 text

幅広いポジションで積極的に採⽤中です︕︕ Fin.