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.