グローバルなソフトウェアテスト組織 における課題と戦略 Challenges and Strategies in a Global Software Testing Organization

角田　俊 Shun Tsunoda CQO室 プロセスエンジニアリング部 CQO Office Process Engineering Division 社外活動（Other Activities) ● JSTQB 技術委員 (JSTQB Technical Committee)

Company-wide CQO室の立ち位置 法人向けサービス / Corporate Business 個人向けサービス / Consumer HOME 金融機関向けサービス / Financial Institutions X Consumer Service Department Corporate Service Department Co-creative Services Department HOME Department Data Forward Office （Company-wide Organizations） CPO Office / MFBC-CTO Office / Business Platform Development Department / CQO Office SMB Development Department HR Solutions Department ERP Development Department Legal Solutions Department Group Management Solution Department CQO(Chief Quality Officer) Office Support Positioning of the CQO office

MFのQAの分布 QA(Quality Assurance) engineerも開発チームと同様に各拠点に存在する。
 Distribution of QA engineers at MoneyForward 日本 / Japan ベトナム / Vietnam インド / India Similar to development teams, QA (Quality Assurance) engineers are also located at each location.


CQO室の役割 作業内容
 ● シフトレフトの推進
 ● 非機能テストの推進
 ● 自動テストの推進
 ● メトリクスを活用したプロダクトの評価と 改善
 ● 社外の障害の管理、改善
 ● ソフトウェア開発プロセスの改善
 
 Responsibilities of the CQO Office Work Contents
 ● Promotion of Shift Left
 ● Promotion of non-functional testing
 ● Promotion of automated testing
 ● Evaluation and improvement of products using metrics
 ● Management and improvement of external failures
 ● Improvement of software development processes
 


CQO室の役割 作業内容
 ● シフトレフトの推進
 ● 非機能テストの推進
 ● 自動テストの推進
 ● メトリクスを活用したプロダクトの評価と 改善
 ● 社外の障害の管理、改善
 ● ソフトウェア開発プロセスの改善
 
 Responsibilities of the CQO Office Work Contents
 ● Promotion of Shift Left
 ● Promotion of non-functional testing
 ● Promotion of automated testing
 ● Evaluation and improvement of products using metrics
 ● Management and improvement of external failures
 ● Improvement of software development processes
 


グローバルなQA組織の課題と戦略 Challenges and Strategies in a Global Organization

コミュニケーション QAエンジニア間の共通言語はもちろん英語になる。
 正確なコミュニケーションを取るためには、共通認識、共通して理解できる言葉を使 用する必要がある。
 Communication The common language of QA engineers is English.
 In order to communicate accurately, it is necessary to have common understandings and use words that can be commonly understood.


情報へのアクセス 日本語でのみ存在する情報が共通認識として使用できない。
 Access to information 日本語の書籍 / Japanese Books 日本語のwebサイト / Japanese Websites 日本語のテスト、品質用語/ Tests and quality terminology in Japanese We cannot use information that only exists in Japanese as a common understanding.


テスト用語 テスト関連の用語はそもそも意味の統一が難しい
 ● テスト計画とは？
 ● テスト戦略とは？
 ● テスト観点とは？
 ● テストレベルとは？
 Test terminology The terminology related to testing is difficult to unify 
 ● What is a test plan? 
 ● What is a test strategy?
 ● What is a test perspective?
 ● What is a test level?


標準を参考にする QA組織で同じ理解をするため、グローバルでのスタンダードを使用する。
 スタンダードを活用しているのは以下のものがある。
 ● テストドキュメント
 ● テストプロセス
 ● 障害分析
 Refer to standards To ensure a common understanding within the QA organization, we use global standards. 
 The following are areas where these standards are applied:
 ● Test Documentation
 ● Test Process
 ● Incident Analysis


標準を参考にする QA組織で同じ理解をするため、グローバルでのスタンダードを使用する。
 スタンダードを活用しているのは以下のものがある。
 ● テストドキュメント
 ● テストプロセス
 ● 障害分析
 Refer to standards To ensure a common understanding within the QA organization, we use global standards. 
 The following are areas where these standards are applied:
 ● Test Documentation
 ● Test Process
 ● Incident Analysis


標準 Standards

紹介するスタンダード 本発表で紹介するスタンダードは以下。
 ● ISTQBのシラバス、用語
 ● ISO/IEC/IEEE 29119
 Standards to be introduced The standards introduced in this session are as follows:
 ● ISTQB Syllabus and Terminology
 ● ISO/IEC/IEEE 29119


● ソフトウェアテストの国際認定を提供 している
 ● 130以上の国が参加
 ● 試験問題の知識としてシラバスを提 供している
 ISTQB （International Software Testing Qualifications Board） https://www.istqb.org/ ● Provides an international certification for software testing
 ● Participated by over 130 countries
 ● Provide a syllabus covering the knowledge required for the exam


ソフトウェアテストについてのスタンダードを定義している。
 ISO等のサイトでPDFを購入可能。
 英語の書籍も存在する。
 ISO/IEC/IEEE 29119 ISO/IEC/IEEE 29119-1:2022 General Concepts
 ISO/IEC/IEEE 29119-2:2021 Test processes
 ISO/IEC/IEEE 29119-3:2021 Test documentation
 ISO/IEC/IEEE 29119-4:2021 Test techniques
 ISO/IEC/IEEE 29119-5:2016 Keyword-Driven Testing
 Defines standards for software testing. 
 PDFs can be purchased from websites such as ISO. 
 There are books in English.
 https://www.amazon.co.jp/dp/B0BZJBTPTP/

注意 複数のスタンダードなどを参照する際には気を付けることがある。
 ● 同じ用語でも意味が同じとは限らない。
 ● 用語以外でも完全に整合性が取られているとは限らない
 Note There are some things to note when referring to multiple standards.
 ● The same word may not always have the same meaning. 
 ● Multiple standards may not be fully consistent.


スタンダードを参考にしてプロジェクトに適応させる スタンダードになっているものは、ベストプラクティスではない。
 プロジェクトの特性に応じて、カスタマイズして活用する必要がある。
 ● 良い部分を取り入れる
 ● 不要な部分は取り入れない
 Reference standards and adapt them to the project Standards are not necessarily best practices.
 They need to be customized and applied, taking into account the characteristics of the project.
 ● Incorporate the good parts.
 ● Do not adopt the unnecessary parts.


テストドキュメント Test documentation

テスト計画 テスト計画はプロジェクトのステークホルダー内で、共通認識を得るためにとても重要な ドキュメント。
 テスト実施のスケジュールを記載するものと思われがちだが、
 それ以外にも考えることはたくさん存在する。
 Test plan The test plan is a very important document for achieving a common understanding among project stakeholders. 
 It is often thought to only include the schedule for test execution, but there are many other considerations as well.


プロジェクト内の達成するべきテストの目的を明確にする。
 ISO/IEC/IEEE 29119 テスト計画 ISO/IEC/IEEE 29119 Test plan Clearly define the test objectives to be achieved within the project.
 Test Plan - Project Details - Test level - Test Type - Test items - Test scope - Test basis - Assumptions and constraints - Stakeholders - Testing communication - Risk register - Test strategy - Testing activities and estimates - Staffing - Schedule

ISO/IEC/IEEE 29119 テストドキュメント ISO/IEC/IEEE 29119 test documentation ISO/IEC/IEEE 29119-3 ではテストドキュメントの体系が定義されている。
 Test policy Project test plan Level test plan Type test plan Test status report Test completion report Organizational test Practices ISO/IEC/IEEE 29119-3 defines the test documentation structure.


ISO/IEC/IEEE 29119 のドキュメントストラクチャ Document structure in ISO/IEC/IEEE 29119 組織の方針が存在し、それを元にプロジェクトの計画を作成する。
 Test policy Project test plan Level test plan Type test plan Organizational test Practices 組織としての方針 Organizational policy プロジェクト毎の計画 Test plan for each project Each organization has its own policy and project plans are created based on it.


組織の方針を展開 Share organizational policy 会社として目指す方向性のドキュメントを作成し、展開
 Organization test processes Project test plan Level test plan Type test plan CQO室としての方針 Policy of the CQO office 各事業部、各プロダクト、 各プロジェクト毎の計画 Test plan for each business department, product, project The CQO Office created the organizational and shared it.


テンプレート化 Create a template テスト計画についての説明や、記載するべき項目についてはテンプレートを作成。
 Create test plan templates explaining items to be included.
 ISO/IEC/IEEE 29119 テンプレート template プロジェクト後のテスト計画 Test plan for each project 参照 Refer

テンプレートの罠 ISO/IEC/IEEE 29119のテスト計画のフォーマットを埋めれば良いわけではない
 プロダクトの特性により書く内容は変わる
 ● 検討不要な部分は記載しなくても良い
 ● フォーマットになくても検討が必要なことはあるかもしれない
 Note for using template Simply filling out the test plan format of ISO/IEC/IEEE 29119 is not enough. 
 The content depends on the characteristics of the product. 
 ● It is not necessary to include parts that are not relevant to your project. 
 ● There may be necessary considerations that are not included in the format.


テストプロセス Test process

テストプロセス テストを検討するにはプロセスがある
 Test process テスト計画 / Test plan テスト分析 / Test analysis テスト設計 / Test design テスト実装 / Test implement ation テスト実行 / Test execution テスト完了 / Test completion There is a process for considering test.


テスト分析 Test analysis テスト計画 / Test plan テスト分析 / Test analysis テスト設計 / Test design テスト実装 / Test implement ation テスト実行 / Test execution テスト完了 / Test completion テスト分析では、テスト計画や、要求、ユーザーストーリーなどを元に、 「何をテストするべきか」を検討する。 In test analysis, the test plan, requirements, and user stories are used to consider 'What should be tested?'

テスト設計 Test design テスト計画 / Test plan テスト分析 / Test analysis テスト設計 / Test design テスト実装 / Test implement ation テスト実行 / Test execution テスト完了 / Test completion テスト設計では、テスト分析で認識した「何をテストするか？」を元に、 具体的な値や、網羅性などを検討し、「どのようにテストするか？」を検討する。 In test design, based on the 'What to test?' identified in test analysis, specific values and coverage are considered to determine 'How to test?'

テスト実装 Test implementation テスト計画 / Test plan テスト分析 / Test analysis テスト設計 / Test design テスト実装 / Test implement ation テスト実行 / Test execution テスト完了 / Test completion テスト実装では、テスト設計したものをベースに、テストケース作成、テストデータや、テスト環境の作成、テスト スクリプトの作成を行う。 Test implementation includes creating test cases, test data, test environment, and test scripts.

テスト条件 ISTQBでは、テスト分析で認識する「何をテストするか？」というものを、
 テスト条件と呼んでいる。
 テスト条件は抽象的なものから、具体的なものまで存在し、階層構造で整理すると良いと 説明されている。
 Test condition In ISTQB, the concept of “what to test” identified in test analysis is referred to as test condition.
 Test conditions range from High-level to Low-level, and it is recommended to organize them in a hierarchical structure.


テスト条件の例 機能：
 ショッピングサイトでクレジットカードで決済を行 う
 抽象的なテスト条件：
 クレジットカードで購入をテストする
 具体的なテスト条件：
 マスターカードを使い、与信枠が100万円の時 に10万円の商品を購入し、成功することをテス トする
 Examples of test condition Feature：
 Perform credit card transactions on a shopping website.
 Hight-Level Test Condition：
 Verify the purchase using a credit card on the shopping website.
 Low-Level Test Condition：
 Verify the successful purchase of a product priced at 100,000 yen using a Mastercard, given that the credit limit of the card is 1,000,000 yen.


テスト条件の構造化 Structuring test conditions Credit cards can be used for payment Master card Visa card JCB card Payment success Payment failure Security code is invalid Expiration date expired Security code is 111, but entered 999 ・・・ ・・・ 抽象的 High-level 具体的 Low-level ・・・ ・・・

テストモデル テストモデルについては、ISO/IEC/IEEE 29119-2で紹介されている。
 テストを網羅的に作成するために、カバレッジや、テスト対象の振る舞いを元にモデルを 作成する。
 モデルを作成するにはテスト技法などを活用する。
 Test model Test models are introduced in ISO/IEC/IEEE 29119-2. 
 To comprehensively create tests, models are created based on coverage and the behavior of the test targets.
 Test techniques are used to create these models.


モデルを作って網羅性を確認する モデルを作成して、テストのパラメーターなどを設計する
 Create a model and check comprehensiveness Credit card security code equivalence partitioning input Equal valid invalid Not equal integer String output Show payment success page Show Credit card Authorization failure page Create a model and design test parameters.


改善後のテストプロセス ISTQB、ISO/IEC/IEEE 29119を参考にテストプロセスを改善した
 Testing process after improvement Before User Story Test case After User Story Test case Test condition Test model Improved testing process with reference to ISTQB and ISO/IEC/IEEE 29119


改善後のテストプロセス Testing process after improvement User Story Test case Test condition Test model ユーザーストーリーを元に、テストするべきことを検討する。 テストするべきことは、階層的に表現する。 テスト技法が適用できるところまで具体的に認識する。 Consider what to test based on user stories. Express what needs to be tested in a hierarchical structure. Recognize concretely where test techniques can be applied.

改善後のテストプロセス Testing process after improvement User Story Test case Test condition Test model テスト条件を元に、テスト技法を活用し、モデルを作成する。 （デシジョンテーブル、状態遷移図、組み合わせの表、など） Create a model by using test techniques based on test conditions. (Decision tables, State transition diagrams, combination tables, etc.)

Test case Test case Test condition Test condition Test case Test case Test case Test case トレーサビリティ テストプロセス改善で、トレーサビリティも改善
 Tracablity Before User Story Test case After User Story Test case Test condition Test model Improving the test process also improves traceability
 ？

Test case Test case Test condition Test condition レビューも簡単になる テストケースのレビューの時間も削減できる。
 Simplify the review process User Story Test case Test condition Test model テスト条件： ユーザーストーリーから どういったことをテストする必要があるか テストモデル： テスト条件を網羅的にテストするためにどのように検討し たか Test conditions: From user stories, what needs to be tested. Test models: How do we consider the testing to comprehensively cover the test conditions. Test case review time can also be reduced.


まとめ Conclusion

まとめ MoneyForwardでは、色々な国に拠点が存在し、色々な国のエンジニアが存在する。
 そのような環境では、共通認識を持つことが必要となる。
 ソフトウェアエンジニアの領域ではスタンダードが多数存在しそれらを活用することができる。
 Conclusion Money Forward has offices in various countries and engineers from various countries.
 In such an environment, it is necessary to have a common understanding.
 In the field of software engineering, there are many standards that can be utilized.


まとめ 今回紹介した内容は、どのような組織でも活用できる方法です。
 参考にしていただけたらと思います。
 Conclusion The methods introduced here can be used by any organization.
 I hope you will find them useful.


No content