開発エンジニアとQAエンジニアが語る夜（Dr.Sum編）〜見せてもらおうか、Dr.Sumの品質活動とやらを〜

update Copyright © 2021 WingArc1st Inc. All Rights Reserved. October
26, 2021 開発エンジニアとQAエンジニアが語る夜（Dr.Sum編）～見せてもらおうか、Dr.Sumの品質活動とやらを～

page No. 2 Copyright © 2021 WingArc1st Inc. All Rights
Reserved. 01 Dr.Sumの開発プロセス 02 Dr.Sumの自動テスト 03 Dr.SumのCI/CD 04 質問タイム INDEX

page No. Dr.Sum開発とQA体制 Dr.Suｍ開発部部⾧兼プロダクトオーナー笹原 Dr.Sum開発部副部⾧橋田
兼務 Dr.Sum開発G GMG Dr.Sum開発リーダー橋田 Datalizer開発G GMG Datalizer開発リーダー増井第1T 主にエンジンの開発を担当第2T チームリーダー川代主にエンジン以外の開発を担当 DEQI GMG 坂口 Dr.Sum担当 Datalizer担当 Datalizer開発を担当 SPQI部部⾧伊藤 SPI T チームリーダー荒川プロダクト横断でプロセス改善を担当 Copyright © 2021 WingArc1st Inc. All Rights Reserved.

page No. 新バージョン開発プロセスの概要 Copyright © 2021 WingArc1st Inc. All Rights
Reserved. システムテスト要求リリース開発KickOff 資料新製品 KickOff 仕様書検証実装コンセプトビジョン目玉機能ステークホルダーに新製品の概要をレビュー要求の積み上げを繰り返す ×N

Reserved. 要求とチームいわゆるチケットだったりプロジェクトだったりという単位を『要求』という言葉でまとめている。要求毎にチームが作られる。そのチームが実装から検証までを担当する。要求の内容や規模に合わせて、開発グループ、QAグループから適切な人員を割り当てている。チームA チームB チームC

Reserved. 開発フェーズと検証フェーズ開発フェーズ検証フェーズ新製品 KickOff 要求A 要求B 要求C 受入検証システムテスト要求D 非機能検証（速度評価、ロングランテスト）要求は個々に並行して進められる検証フェーズ中に要求を進めることもある非機能検証は随時行われる

page No. 要求に対する開発プロセス・要求に対する実現方法検討・設計、仕様の考案・テスト自動化可否の確認・自動化のための機能追加・ステークホルダーに設計・仕様案を共有・検証方針を決める
・QE(SET)、QA担当を決める Copyright © 2021 WingArc1st Inc. All Rights Reserved. R&D プロトタイピング仕様検討要求 KickOff 仕様作成仕様レビュー実装検証観点レビュー開発検証実施検証結果自動テスト資産システムテスト実施・観点の優先度を設定・実施フェーズを決める・仕様書作成時に実装者視点の検証のキモを記載・開発、QA以外にマニュアル、保守チームも参加・「開発フェーズで実施対象」とした検証項目・「検証フェーズで実施対象」とした検証項目

page No. 要求に対する開発プロセス・要求に対する実現方法検討・設計、仕様の考案・テスト自動化可否の確認・自動化のための機能追加・ステークホルダーに設計・仕様案を共有・検証方針を決める
・QE(SET)、QA担当を決める Copyright © 2021 WingArc1st Inc. All Rights Reserved. R&D プロトタイピング仕様検討要求 KickOff 仕様作成仕様レビュー実装検証観点レビュー開発検証実施検証結果自動テスト資産システムテスト実施・観点の優先度を設定・実施フェーズを決める・仕様書作成時に実装者視点の検証のキモを記載・開発、QA以外にマニュアル、保守チームも参加・「開発フェーズで実施対象」とした検証項目・「検証フェーズで実施対象」とした検証項目開発フェーズ「実用レベルの機能性」まで検証

page No. 開発リーダー開発、検証の役割役割開発作業設計・仕様決め実装者 QE（SET）
QA 組織図上の所属開発チーム QAチーム開発チーム QAチーム検証作業 Copyright © 2021 WingArc1st Inc. All Rights Reserved. 仕様レビュー設計・仕様決め（設計・仕様決め）仕様レビュー開催仕様レビュー（設計・仕様決め）仕様レビュー仕様書作成実装検証観点レビュー検証観点レビュー開催検証観点作成検証項目作成・実施検証観点レビュー検証結果確認検証観点メモ作成テストフレームワーク作成

page No. 開発リーダー開発、検証の役割役割開発作業設計・仕様決め実装者 QE（SET）
QA 開発チーム QAチーム開発チーム QAチーム検証作業 Copyright © 2021 WingArc1st Inc. All Rights Reserved. 仕様レビュー設計・仕様決め（設計・仕様決め）仕様レビュー開催仕様レビュー（設計・仕様決め）仕様レビュー仕様書作成実装検証観点レビュー検証観点レビュー開催検証観点作成検証項目作成・実施検証観点レビュー検証結果確認検証観点メモ作成組織図上の所属テストフレームワーク作成

page No. 観点メモを開発者が作成 Copyright © 2021 WingArc1st Inc. All Rights
Reserved.

page No. テスト観点(ここからテストケースに展開する) Copyright © 2021 WingArc1st Inc. All Rights
Reserved.

page No. 上流工程から品質にコミットするということ Copyright © 2021 WingArc1st Inc. All Rights
Reserved. プロトタイピング仕様検討要求 KickOff 仕様レビュー実装検証観点レビュー開発検証実施検証結果自動テスト資産より上流工程から、実装者・QE・QAがともに開発作業を行うことにより、高い品質に作り込むということをコンセプトにしているシステムテスト実施実装者 QE（SET） QA 三位一体論作りながら検証観点を残せる ⇔ 作りながら品質を担保できる具体的な検証観点、テストケース作成、テストフレーム作成、実装へのフィードバック俯瞰的に品質を作りこむための適切な工程かを確認。非機能や利用シナリオを踏まえた上で優先付け

page No. 品質の作り込み(QI視点) Copyright © 2021 WingArc1st Inc. All Rights
Reserved. プロトタイピング仕様検討要求 KickOff 仕様レビュー実装検証観点レビュー開発検証実施検証結果自動テスト資産 QAグループメンバー開発支援・開発進捗を押し上げる・QAとしてのナレッジ共有システムテスト実施開発グループメンバー検証支援

page No. 品質の作り込み Copyright © 2021 WingArc1st Inc. All Rights
Reserved. プロトタイピング仕様検討要求 KickOff 仕様レビュー実装検証観点レビュー開発検証実施検証結果自動テスト資産品質は開発時に作り込む QAグループメンバー品質が作り込まれていることを検証で確認開発支援・開発進捗を押し上げる・QAとしてのナレッジ共有システムテスト実施開発グループメンバー検証支援

page No. Dr.Sumの自動テスト（機能テスト） Intranet / Cloud Dr.Sum Data Funnel Dr.Sum
Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor Copyright © 2021 WingArc1st Inc. All Rights Reserved. HTTP(S) HTTP over TLS Secure Transport Agent クライアント端末 Enterprise Manager Web Browser

Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor RegressR2(SQL、DS Script、コマンドバッチ、Python連携)：80,000ケース API Test（Java、.NET）：3,500ケース OLAP自動テスト：100,000ケース Copyright © 2021 WingArc1st Inc. All Rights Reserved. HTTP(S) HTTP over TLS Secure Transport Agent クライアント端末 Enterprise Manager Web Browser

Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor RegressR2(SQL、DS Script、コマンドバッチ、Python連携)：80,000ケース API Test（Java、.NET）：3,500ケース OLAP自動テスト：100,000ケース Copyright © 2021 WingArc1st Inc. All Rights Reserved. HTTP(S) HTTP over TLS Secure Transport Agent クライアント端末 Enterprise Manager Web Browser In-Memory QueryTest 30,000ケース

Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor RegressR2(SQL、DS Script、コマンドバッチ、Python連携)：80,000ケース API Test（Java、.NET）：3,500ケース OLAP自動テスト：100,000ケース Copyright © 2021 WingArc1st Inc. All Rights Reserved. HTTP(S) HTTP over TLS Secure Transport Agent クライアント端末 Enterprise Manager Web Browser In-Memory QueryTest 30,000ケース TestComplete 1,300ケース

Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor RegressR2(SQL、DS Script、コマンドバッチ、Python連携)：80,000ケース API Test（Java、.NET）：3,500ケース OLAP自動テスト：100,000ケース Copyright © 2021 WingArc1st Inc. All Rights Reserved. HTTP(S) HTTP over TLS Secure Transport Agent クライアント端末 Enterprise Manager Web Browser In-Memory QueryTest 30,000ケース TestComplete 1,300ケース WebConsole E2Eテスト

Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor RegressR2(SQL、DS Script、コマンドバッチ、Python連携)：80,000ケース API Test（Java、.NET）：3,500ケース OLAP自動テスト：100,000ケース Copyright © 2021 WingArc1st Inc. All Rights Reserved. HTTP(S) HTTP over TLS Secure Transport Agent クライアント端末 Enterprise Manager Web Browser 作る君と、流す君 81ケース In-Memory QueryTest 30,000ケース TestComplete 1,300ケース WebConsole E2Eテスト

Reserved. Cloud Hub ファイル操作タスクスケジューラモニタリング機能管理ツール管理ツール Java, .NET JDBC, ODBC 共通内部 API 共通内部 API 管理画面 tomcat UI API Server Dr.Sumの構成バッチコマンド Dr.Sum SQL DS Script ユーザー管理・システム管理インポート・エクスポート In-Memory 高速集計インメモリ永続 Python連携 Windows OS Data Funnel リアルタイムデータ処理データ加工 tomcat 内部 Web API Thrift

Reserved. In-Memoryの自動テスト（機能テスト）管理ツール Java, .NET JDBC, ODBC 共通内部 API UI API Server バッチコマンド In-Memory QueryTest（30,000ケース）直接In-Memoryのライブラリを通して、 SQL実行し、結合レベルのテスト UnitTest In-Memoryを構成するクラスやライブラリに対する単体+αレベルのテスト Python連携のエミュレータに対するテスト Dr.Sum SQL DS Script ユーザー管理・システム管理インポート・エクスポート In-Memory 高速集計インメモリ永続 Python連携

page No. 27 Dr.Sumの自動テスト（機能テスト）管理ツール (Delphi) Java, .NET JDBC,
ODBC UI API Server バッチコマンド(C++) 共通内部 API (C++) TestComplete：画面からの権限制御に主眼を置いたテスト RegressR2(コマンドバッチ) インポートなどのコマンドバッチに対するテスト API Test(Java、.NET)：3,400ケース各APIのUnitTest OLAP自動テスト(JavaAPI)：100,000ケース Datalizerからの集計を想定したテスト RegressR2 ：合計80,000ケース (SQL) ODBC/.NET API経由でSQLを実行して、実行結果の妥当性を確認するテスト In-Memoryに対するテストも多数存在 (DS Script) .NET API経由でDS Scriptを実行して、各実行ステップ結果(変数の値など)の妥当性を確認するテスト (Python連携) ODBC経由でSQLを実行して、Python連携処理の実行結果の妥当性を確認するテスト UnitTest Dr.Sumを構成するクラスやライブラリに対する単体+αレベルのテスト Dr.Sum (C++) SQL DS Script ユーザー管理・システム管理インポート・エクスポート In-Memory 高速集計インメモリ永続 Python連携 Copyright © 2021 WingArc1st Inc. All Rights Reserved.

Reserved. Data Funnel (Tomcat) リアルタイムデータ処理データ加工管理ツール共通内部 Web API UI API Server Data Funnelの自動テスト（機能テスト）作る君パイプライン定義を外部ファイルから指定して、生成する流す君生成したパイプライン定義にテストデータを流し込んで、パイプライン処理を実行するこの2つのツールを組み合わせることで任意のデータを使って、任意の設定を行ったパイプライン定義の処理結果を確認 UnitTest 設定やデータのバリエーションを実装している Data Funnelを構成するクラスやライブラリに対する単体+αレベルのテスト

Reserved. UI API Server Cloud Hubの自動テスト（機能テスト） Cloud Hub (Tomcat) ファイル操作タスクスケジューラモニタリング機能管理画面 React, Redux WebConsole E2Eテスト Playwrightによる画面操作テスト Dockerとの組み合わせを行い、任意の環境で実行できる仕組みとなっている UnitTest Cloud Hubを構成するクラスやライブラリに対する単体+αレベルのテストプロトコルテスト Secure Transportのプロトコルに対するテストモックオブジェクトを利用して実装内部 Web API Thrift

page No. Dr.Sumの自動テスト（非機能テスト） Intranet / Cloud Dr.Sum Data Funnel Dr.Sum
Cloud Hub Dr.Sum Server Message Broker Funnel Server 全体 - IoT機器からのデータ取得、データ加工 - 他プロダクトへのPublish HTTP Agent Web Console Secure Transport Server Secure Transport Bridge Server モニタリング DS Script - データ投入 - データ加工 SQL - データ取得 - データ更新全体 - ユーザー管理 - サーバー管理 In-Memory Server Python連携 - AIや機械学習インメモリ永続 - データの永続化ダッシュボードアラート IoT Device CSV/JSON HTTP(S) MQTT(S) MQTT(S) MQTT Publish Command 管理ツール - EnterpriseManager - ScriptEditor Funnel ロングランテスト性能テスト WebConsoleロングランテスト性能テスト：5,000ケース Dr.Sumロングランテスト Copyright © 2021 WingArc1st Inc. All Rights Reserved.

page No. 31 Dr.Sum、In-Memoryの自動テスト（性能テスト） Copyright © 2021 WingArc1st Inc. All
Rights Reserved. スクリプトファイル RegressR2 GUI CUI 測定結果測定対象スクリプトファイルを選択測定対象の処理を実行測定結果を Dr.Sumに投入測定結果を Datalizerから分析ここまで自動化

page No. 32 Dr.Sum、In-Memoryの自動テスト（性能テスト） Copyright © 2021 WingArc1st Inc. All
Rights Reserved. Datalizer測定結果分析画面様々な軸で分析可能

page No. 33 Dr.Sumの自動テスト（ロングランテスト） Copyright © 2021 WingArc1st Inc. All
Rights Reserved. Dr.Sum Data Funnel Cloud Hub ツール検証対象処理結果 1週間以上連続実行実行内容 JavaAPIから集計やインポートなどを並列実行画面操作の HTTPリクエストを並列実行 20並列でデータを常時投入し、リアルタイムデータ加工処理を実行リソース消費状況

Reserved. テスト内容並列実行数実行回数インメモリテーブル、ビューへの集計集約、検索、ソートを行うクエリ実行 20 45,923 インメモリテーブルのロードを実行 10 2,761 インメモリテーブルへのインポートを実行 1 3,751 インメモリテーブルで様々なJOINを実行 10 2,276 NULLを含むデータや、境界値をまたぐ件数のインポートとクエリを実行 1 1,079 ハイブリッドモードのテーブルにインポート、データ削除、コンパクションを実行後、ロードして、クエリを実行 1 229 高速エクスポートを1億件になるまで繰り返し実行 5 61 コピーモードのROTATE TABLEを1億件になるまで繰り返し実行した後、クリアモードで実行 1 2,546 Dr.Sum、In-Memoryの自動テスト（ロングランテスト）ロングランテスト実行内容

Reserved. Dr.Sum、In-Memoryの自動テスト（ロングランテスト）各処理プロセスのメモリ使用量を確認 ※横軸は3分ごとに取得したデータのID DWLogProxyW DWLogSvrW DWMemServer DWODSW DWSyncW 70 75 80 85 90 95 1 169 337 505 673 841 1009 1177 1345 1513 1681 1849 2017 2185 2353 2521 2689 2857 3025 Process Private Bytes[MBytes] 400 450 500 550 600 1 160 319 478 637 796 955 1114 1273 1432 1591 1750 1909 2068 2227 2386 2545 2704 2863 3022 Process Private Bytes[MBytes] 0 100 200 300 400 500 1 140 279 418 557 696 835 974 1113 1252 1391 1530 1669 1808 1947 2086 2225 2364 2503 2642 2781 2920 3059 Process Private Bytes[MBytes] 0 500 1000 1500 1 169 337 505 673 841 1009 1177 1345 1513 1681 1849 2017 2185 2353 2521 2689 2857 3025 Process Private Bytes[MBytes] 0 20 40 60 80 1 160 319 478 637 796 955 1114 1273 1432 1591 1750 1909 2068 2227 2386 2545 2704 2863 3022 Process Private Bytes[MBytes]

page No. 要求に対する開発プロセス (再掲) ・要求に対する実現方法検討・設計、仕様の考案・テスト自動化可否の確認・自動化のための機能追加 (テストフレームワークの作成) ・ステークホルダーに
設計・仕様案を共有・検証方針を決める・QE(SET)、QA担当を決める Copyright © 2021 WingArc1st Inc. All Rights Reserved. プロトタイピング仕様検討要求 KickOff 仕様レビュー実装検証観点レビュー開発検証実施検証結果自動テスト資産システムテスト実施・観点の優先度を設定・実施フェーズを決める・実装者視点の検証のキモを記載・開発、QA以外にマニュアル、保守チームも参加・開発フェーズで実施対象とした検証項目・検証フェーズで実施対象とした検証項目『要求』に対する開発内容が具体化されてきた早い段階で「どのレイヤからのテストが有効か」を議論して、製品側にテストインターフェースを用意したり、ログやデバッグの機能を相手したり、テストフレームワークを開発していくことが鍵になる。

Reserved. 自動テストの実行 • 各自動テストの実行 • RegressR2(BVT)の分散実行 develop／作業ブランチのビルド • ユニットテスト、静的解析 • コンパイル、リンク • パッケージング • インストーラーイメージ作成 Bitbucketとの連携 • ビルド、自動テスト結果をBitbucketに通知 • Pull requestマージ時にWebhookを受け取って、自動でビルド Dr.SumにおけるJenkinsの役割

Reserved. 自動テストの実行 RegressR2

Reserved. 自動テストの実行 In-Memory QueryTest API Test

Reserved. 自動テストの実行 In-Memory QueryTest API Test Jenkinsを自動テストのエントリーポイントにすることで、いつでも、誰でも実行できる

Reserved. 自動テスト実行ジョブのビルドパラメータテスト対象のビルドテストケースのブランチ

Reserved. 自動テスト実行ジョブのビルドパラメータ開発、QA問わず、任意のビルドに対して、任意のテストケースブランチで自動テストを実行できるテスト対象のビルドテストケースのブランチ

Reserved. develop／作業ブランチのビルド

Reserved. develop／作業ブランチのビルドユニットテストの実行カバレッジ、静的解析の実行

Reserved. Dr.Sumのビルド ①ブランチをpush ②ビルドジョブ実行 ③ソースコード取得 ④ビルド／BVT ⑤ビルド／BVT結果通知

Reserved. BVT(Build Verification Test: ビルド検証テスト) 新たに作成した各ビルドに対して、完全性を確認し、主要な機能性、安定性、および試験性を検証する自動化テストのセット。 ISTQB Glossary(https://glossary.istqb.org/jp/term/build-verification-test-2)

Reserved. 新たに作成した各ビルドに対して、完全性を確認し、主要な機能性、安定性、および試験性を検証する自動化テストのセット。 ISTQB Glossary(https://glossary.istqb.org/jp/term/build-verification-test-2) Dr.Sumでは、RegressR2(計8万ケース)をBVTとして使用 ※実行するテストケースはサブセットでもOK BVT(Build Verification Test: ビルド検証テスト)

Reserved. Dr.Sumビルドジョブのビルドパラメータビルド対象のソースコード実行するBVTのテストケース

Reserved. Bitbucketへのビルド／BVT結果通知

Reserved. Bitbucketへのビルド／BVT結果通知 BVT成功→PR推奨条件ビルド成功→PR必須条件

Reserved. Bitbucketへのビルド／BVT結果通知 BVT成功→PR推奨条件ビルド成功→PR必須条件マージしたらビルドできない／テストが動かないを事前に防ぐ

page No. Copyright © 2021 WingArc1st Inc. All Rights Reserved.
BVTを全部流すと、 240時間かかるってよ

Reserved. テストに時間がかかる？よろしい、分散実行だ！・・・ 50ノードマルチ構成プロジェクトで実行ジョブを作成各ノードにはラベルを付与

Reserved.

Reserved. 全部流しても240時間→6時間弱まで高速化

Reserved. まとめ Jenkinsは重要な開発インフラ • 無いと開発が進まない Jenkinsはビルドだけではない • 自動テストのエントリーポイント • 分散実行インフラ自動テストは使い倒す！ • 使わないとすぐ「ガラクタ」になってしまう • 実行には人手はかからない

Reserved. Discordより質問です「私の周りには品質に重きを置く開発エンジニアがいないんですが、御社の開発チームがそういう考えに至った経緯などあれば教えてほしいです。」開発が『作る』ものに『品質』も含まれるのは前提として考えています。開発、QA両者が「ユーザーに価値ある製品を早く届ける」という同じゴールを向くことができれば自ずと見えてくるものと考えています。まずは開発がそういった意識を持つということは必要になってくるとは思いますが、「優先度を考えた場合、今本当に必要なテストケースなのか」「時間を使って修正すべき不具合なのか」の判断がフレキシブルにできる体制なのかという事が実務上は非常に重要です。例えばカバレッジや通過率だけにとらわれず「ユーザーがストレスなく利用できるか」を前提に開発と QAでコミュニケーションをとりながら目指す品質レベルに向かっていけるような体制を構築できればうまく回り出すのかなと思います。回答としては足りないかもしれないですが、「品質を確保する」という言葉が意味することが「テスト →バグチケットを起票→修正」を繰り返すことであり、バグはテストチームが出すものだという意識がなくなってくるといいですね。

Reserved. Discordより質問です「QAの方、ここまで開発と一緒に仕事をするのは相応のスキルも必要だと思いますが、大事にしているスキルセットやマインドセットを教えてほしいです。」新たな技術や製品を担当するので、とても大変な面はありますが、 QAもQA「エンジニア」なので、「エンジニア」としての日々のスキルアップや学習は必要なことと考えています。データベースやプログラミング言語などの資格取得や、製品知識を向上させるための時間を定期的に設けて、スキルアップための時間を確保するようにもしてます。

Reserved. Discordより質問です「QAが上流でぐいぐい押し上げる。開発は結合でサポートする。チーム一丸で品質を上流から作りこんでいくフェーズに入った時って、課題や関心はどういうものがありますか？」 QAの立場からすると、上流から作り込んでいくフェーズに入っていくことができてはいますが、まだまだ上流工程における貢献はできると考えています。プロトタイピングや仕様検討からQAが参加している要求もありますが、すべての要求でできているわけではありません。上流工程であるほど、「開発のエンジニア」か、「QAのエンジニア」かは関係なく、「エンジニア」としてその要求にどのように貢献できるかが勝負なので、この点についてQAとしてはまだまだスキルアップして貢献していけると考えています。

Reserved. Discordより質問です「上流にQAがグイグイ入っていこうとすると、他のプロダクトの QA業務に入っていく時間が無くて悩んだりしてますが、やはり、複数のプロダクトにQAさんが入るってことはないのでしょうか？」基本的には主軸となるプロダクトは決まっていますが、Dr.Sumと Datalizerは同時に開発をしているため、複数のプロダクトを担当するメンバーもします。複数のプロダクトを持つので時間としてはタイトではありますが、少しずつ複数のプロダクトを担当するメンバーが増えている状況となっています。

Reserved. Twitterより質問です「 RegressR2は、すぐにNGになるということですが、どれくらいの頻度（CI）で実行していますか？」開発者がサーバーに関するPull requestを出す前に実行してもらっています。NGになった場合は実装の修正をしたり、テスト期待値の修正も開発者が行います。実装途中でもBVTを実行して、早めに実装状態を確認したりもしています。 Pull requestマージ後は、適当な間隔で実行します。 Pull requestを出す時点でしっかり確認しているので、マージ後に NGが発生することは激減しました。

Reserved. Discordより質問です「開発とQAはそれぞれ何名くらいいるのでしょうか？」 Dr.Sum開発は14名。QAは5名となっています。この中には開発のプロダクトオーナーや開発リーダーも含まれます。参考までに、直近のバージョンであるDr.Sum 5.6で対応した要求の数は50以上ありました。

Reserved. Discordより質問です「要求のテストは開発中継続すると思うのですが、専属のQAがつくのですか？」いずれの要求でも、ロールとして「開発リーダー」「実装者」「QE」「QA」は存在します。「実装者」が「QE」を担うこともありますし、「QA」が「QE」を担うこともあります。「実装者」「QE」が別の開発メンバーが担当することもあります。

Reserved. Discordより質問(感想)です「要件が変わった時のテストケースの追加や修正で、設計のしなおしとか、何処に追加するかとか、全体で十分か判断しなきゃいけなかったりもありそう」おっしゃる通りです。要件や設計が変更となった場合、検証作業に影響を与えます。そのような状況をできるだけ陥らないためにプロトタイピングや仕様検討で多くの時間を割いています。ここでどのような検証を行うべきかや、既存のテスト資産を鑑みて追加すべき検証は何かを入念に議論して進めています。

Reserved. Discordより質問です「開発リーダーさんは、仕様決めと仕様レビュー以外ってしないのですか？（後は管理作業をされてたり？）」開発というコンテキストでいくと、実際のコードを書く以外のほぼすべての作業に関与します。仕様作成、UXのデザイン、システム設計、場合によっては詳細設計、実装方式やアルゴリズムの検討などです。もちろん主たる実装については各担当の凄腕エンジニアが行いますので、すべての要求に少しずつ絡んでいくことになるのですが、特に要求の実現が難しいとなったときに、こういう設計でこういう仕様なら要求を満たせるのではという、クリティカルポイントをなんとか解決できないか考える仕事です。あとは、製品戦略の策定や利用する技術要素の検討、マーケット動向から要求を作成。そこからチームのリソースを踏まえてベストな仕様や実装のアプローチを考えたりすることが主な仕事です。会社組織としての管理作業と、工程のプロマネ作業もありますがそこはできるだけ小さくなるようにメンバーに頼り切ることにしています！

Reserved. Discordより質問です「全体のテストアーキテクチャどんな感じかで、どう分担されているのか気になります。非機能要件もQAの方も見ているのかどうか。」各要件の機能検証に関してはテスト観点のテンプレートを使用して、網羅するようにしています。このテンプレートはこれまで発見されたの不具合のナレッジや、プロダクト特有の実装を反映したものとなっており、可能な限りこれまで発生した不具合が再発していないことを確認できる枠組みを用いています。非機能要件に関しては主にQAで測定を行い、測定結果を開発チームと考察し、プロダクトに反映する価値のある改善となっているかを検討するような形となっています。

Reserved. Discordより質問です「CIなどのパイプラインを担当するQAもいるのでしょうか。 SETが担当になるでしょうか。」テスト系の既存パイプラインの修正は主にQE(SET)が行います。ビルド関係のパイプラインは、開発者の担当です。なるべくジョブはパイプラインで作成し、そのスクリプトファイルをBitbucketで管理するようにして、Pull requestで変更するようにしています。

Reserved. Twitterより質問です「非機能検証（performanceやlong run）はどのようなツールを使用していますか？」 PerformanceはJavaAPIを使って測定して、測定結果をPowershellで CSVに加工後、Dr.SumにJavaAPIで取り込んでいます。 LongRunはJavaAPIで実行しますが、テストフレームワークとしては JUnitを使用しています。リソース消費状態の取得に関しては、Powershellから Get-Counterコマンドを使っています。

Reserved. Twitterより質問です「非機能の目標値は要求プロセスで設定していますか？」こちらはケースバイケースです。コンセプチュアルに「10倍を目指す」という形で走り出すこともあれば、実装上の理論値から目標値を定める場合もあります。要件上速度向上が求められてスタートする場合もあり、その場合は効率化できる処理を探してひたすら積み重ねたり、そもそものアルゴリズムに手を入れられないか検討します。プロセスとしては、開発上の目標値を要求プロセスである程度設定し、実際の実装や検証の結果に対して、実際導入する価値があるものかどうかを開発とQAで話しあって決定しているようなイメージとなります。

Reserved. Twitterより質問です「DrSumを、オンプレからクラウドにしたことによる、ツラミはありますか？（例えば、負荷が強い処理をしてそうなので、AWSの auto scallingとの相性とか）」まさにそこはこれからクラウドサービスとして伸ばしていく際にキーになっていく要素となります。 Dr.Sumのエンジンのコア部分はハードウェアリソース意識した作りになっていますので、EC2上では通常のハードウェアとは異なる挙動をしたり、解析が難しくなったりする場面もあります。 Dr.Sumのクラウドサービスはまだ開始したばかりであり、そもそも製品側がまずアジャストしなければならない部分も多いので、絶賛開発中となります。これからの主戦場になると思いますので頑張っていきたいです！

Reserved. Discordより質問です「本当にメンテナンスとかどうやってしているのだろうか？自動テストの結果管理やメンテナンスとかすごい時間かかりそう。（多分、その仕組もかなり考えられてるとは思いますが）」 BVT(RegressR2)に関しては、Pull request出す時点でOKになっていることが条件なので、その時点までに開発者とQEが協力して既存テストケースの修正も行います。最後にまとめて行うのではなく、Pull request(≒要求)毎に自動テストのメンテナンスを行うことで、ここの作業コストを抑えるようにしています。

Reserved. Discordより質問です「テスト環境のフレーキネスはどのように管理してますか？」 Confluence上にページを作って、そこでフレーキーなNGを管理しています。BVTがNGになった場合、その一覧に含まれているものであればその旨がわかるようにして、Pull requestを出しても良いという運用にしています。 NGになる原因としては、後片付けが不十分といったテスト実装自体の問題が多いので、分かり次第修正します。また、同じミスをなるべく繰り返さないように、テスト実行時のチェックポイントを共有しています。

Reserved. Twitterより質問です「CIで、RagressR2を分割、並列実行しているとのことですが、並列実行させるために、テストコードを実装時に気を付けていることはありますか？」テスト粒度、具体的には各テストの実行時間を最大でも15分程度に収めるように気をつけています。紹介したJenkinsでの分散実行方法では、テストの実行順番をコントロールできません。1時間かかるテストがあったとして、それが最後の方で実行開始されてしまうと、1ノードだけで1時間処理が行われてしまうので、結果的にテスト完了が遅くなってしまいます。暇になるノードを最後までなるべく作らないようにするのがポイントです。

Reserved. 質問コーナここまで！ありがとうございました！

Reserved. DEQIグループの使命感

Reserved. 開催日時：12月開催予定タイトル：開発エンジニアとQAエンジニアが語る夜（Datalizer編）～僕がいちばんDatalizerをうまく使えるんだ～出演予定：笹原、増井、石黒、伊藤、荒川、及川、坂口 connpass URL：TBD

Reserved. https://ninno-tech-fest.connpass.com/event/226029/

Reserved. https://www.scrumfestniigata.org/

Reserved. http://jasst.jp/index.html

Reserved. https://medium.com/wingarc https://medium.com/wingarc

WE ARE HIRING！検証技術やValueを提供できるテストエンジニアテストの自動化(SET)や継続的テストのデジタル化(SRE)を提供できるパイプラインエンジニア開発プロセスの促進(SPI)や品質文化を組織全体に推進できる QAエンジニア Software
Process & Quality Improvement Department まずはカジュアル面談から。 TwitterにDMください。

開発エンジニアとQAエンジニアが語る夜（Dr.Sum編）〜見せてもらおうか、Dr.Sumの品質...

開発エンジニアとQAエンジニアが語る夜（Dr.Sum編）〜見せてもらおうか、Dr.Sumの品質活動とやらを〜

More Decks by Yuki Sakaguchi

Other Decks in Technology

Featured

Transcript