金融機関向けサービス / 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
改善 • 社外の障害の管理、改善 • ソフトウェア開発プロセスの改善 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
改善 • 社外の障害の管理、改善 • ソフトウェア開発プロセスの改善 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
/ 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?
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
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
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
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/
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.
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.
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.
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
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.
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.
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.
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.
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?'
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?'
analysis テスト設計 / Test design テスト実装 / Test implement ation テスト実行 / Test execution テスト完了 / Test completion テスト実装では、テスト設計したものをベースに、テストケース作成、テストデータや、テスト環境の作成、テスト スクリプトの作成を行う。 Test implementation includes creating test cases, test data, test environment, and test scripts.
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.
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.
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.
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.
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.
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 case トレーサビリティ テストプロセス改善で、トレーサビリティも改善 Tracablity Before User Story Test case After User Story Test case Test condition Test model Improving the test process also improves traceability ？
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.
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.
imtnd
ivargrimstad
yusukebe
furukawayasuto
goyoki
happymana
seike460
tomohisa
javiergs
nekomatu
memory1994
naokihaba
manfredsteyer
pauljervisheath
samlambert
kneath
destraynor
trallard
aki_iinuma
danielanewman
eileencodes
3n
hatefulcrawdad
mongodb
malarkey
