クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果

ウイングアーク１ｓｔ株式会社
SVFパッケージ統括部品質保証グループ
伊藤潤平
技術本部 BI品質統括部
加藤大受
クオリティゲートの通過判断として
品質特性を利用した受入テストの
導入と効果
SQiP 2017

Copyright © 2017 WingArc1st Inc. All Rights Reserved. 1
会社概要

会社概要
 商号：ウイングアーク１ｓｔ株式会社 (WingArc1st Inc.)
 所在地：〒150-0031 東京都渋谷区桜丘町20-1 渋谷インフォスタワー
 創業：2004年3月
 資本金：2億円
 事業内容：ツール・ミドルウエア製品の開発・販売、導入支援・保守サポートサービスの提供
 従業員数：連結520人／単体416人（2016年3月1日現在）
 売上高：連結売上高142億8,300万円（うち単体売上高:120億5,800万円）
連結営業利益38億1,400万円（営業利益率:26.7 ％）
連結EBITDA56億2,800万円（2016年2月期）
 取引金融機関：みずほ銀行三菱東京ＵＦＪ銀行三井住友銀行三井住友信託銀行
会社情報
 文雅科信息技术（上海）有限公司
地址：上海市黄浦区淮海中路398号博银国际大厦15阶DE1室邮编： 200020
 文雅科信息技术（大连）有限公司
地址：大连市西岗区中山路147号森茂大厦20F 邮编： 116011
 WingArc Singapore Pte. Ltd.
20 Collyer Quay #23-01, Singapore 049319
グループ会社
本社オフィス（渋谷インフォスタワー）
WingArc Singapore Pte. Ltd.
シンガポールオフィス

Copyright © 2017 WingArc1st Inc. All Rights Reserved.
3
主要ソフトウェア製品ラインナップ
“数字”が見える、次の一手が打てる
エンドユーザー志向で開発されたシェアNo.1の帳票ツール
帳票基盤ソリューション
集計・分析プラットフォーム
エンドユーザー志向に開発された
高生産性な帳票デザインツールです
情報活用ダッシュボード
ビジネスを加速する、現場改革BI

帳票ソフトウェア製品情報
エンドユーザー志向で開発されたシェアNo.1の帳票ツール
帳票基盤ソリューション
出典：ミック経済研究所
ミドルウェアパッケージソフトの市場展望 2016年度版
帳票運用製品出荷金額（メーカー出荷）
2015年度出荷金額ベース
国内シェアNo.1
導入実績 19,669社
最新お客様事例
※ 19,669社にはSPAの導入実績37社を含みます。
※累積社数（2017年2月末現在）
46.8%
A社
18.9%
B社
10.8%
C社
10%
D社1.8%
その他
11.7％
導入実績 94社
※累積社数（2017年2月末現在）

アジェンダ
①当社における品質保証プロセス
②課題解決への取り組み
③受入テストの導入計画
④プロジェクトへの適用
⑤適用結果
⑥まとめ（効果と今後の課題）

アジェンダ
⑤適用結果

品質保証部門の役割
評価の役割
当社の品質保証部門では開発部門の生産性を支
援するため、開発プロジェクトに積極的に参加
し、統合テスト以降の数多くの評価作業を実施
する役割を持っている。
検査の役割
品質を保証するための品質分析を行い、製品検
査を実施する役割を持っている。

ステージ制
 当社の品質保証プロセスではテストレベルを「ステージ」と
呼び、開発工程とテスト工程で用語を分けている
 開発部門による統合テストのフェーズをαステージと定義し、
β1、β2、β3で行う評価作業を品質保証部門が実施
β1
stag
e
α
stage
β3
stag
e
RC
stag
e
β2
stag
e
QA Evaluation Process

品質要求をMTPに定義
品質要求として品質目標を品質副特性ベースで
詳細にマッピングして定義
LTP（LevelTestPlan）にてテストレベル毎の品
質目標を実現するためのテストタイプを選択し
て定義
β1
ステージ
β2
ステージ
β3
ステージ
RC
ステージ
JIS X 25010を
使用したGQM
手法を活用
ISO/IEC/IEEE
29119を活用し
た品質計画を作
成

品質特性の割り当て
品質目標
テストタイプ
品質分析
品質特性を割り当
てた目標を定義
品質特性毎のテス
トタイプを作成
品質特性毎の品質
分析ができる
全体的な
指標となる

アジェンダ
⑤適用結果

課題と課題解決への取り組み
開発工程
テスト工程
コンポーネントテスト
統合テスト
システム
テスト
顧客受入
テスト
 一般的な開発プロジェクト
 当社独自の受入テストを導入したプロジェクト
1Q 2Q 3Q 4Q
開発工程
テスト工程
コンポーネントテスト
統合テスト
システム
テスト
顧客受入
テスト
1Q 2Q 3Q 4Q
工程移行判断
(Exit Criteria)
工程開始判断
(Entrance
Criteria)

アジェンダ
⑤適用結果

受入テストの導入
α
Stage
β1
Stage
β2
Stage
β3
Stage
RC
Stage
β1受入
β2受入
β3受入

 受入テストのテストケース
品質特性 β1テストタイプテストタイプの選出テストケースの抽出
機能適合性
性能効率性
互換性
使用性
信頼性
セキュリティ
保守性
移植性
Test type
ATest type
B
Test type
CTest type
D
Test type
E
Test type
F
Test type
A
Test type
C
Test type
F
20% from Test type
A
5% from Test type C
5% from Test type F
網羅性のある品質特性を
カバーするテストタイプ
を選出
テストケースを
5～20%で抽出

 受入テストのクライテリア
品質特性 β1テストタイプクライテリア
機能適合性正常系 90%パス
準正常系 85%パス
深刻度Major以上のバグ3件以下
性能効率性過去バージョンと比べ105%以内
ただし100msの差は許容範囲
互換性
使用性
信頼性
セキュリティ深刻度Critical以上0件
保守性
移植性
品質特性を活用したテストの
パス率や深刻度別の不具合数
による定量分析
不具合の摘出傾向等
による定性分析
Test type
A
Test type
C
Test type
F

 当社の品質保証プロセスでは計画時に最終成果物に対する機
能適合性の割合を7割未満と決めている。
品質特性の割合
機能適合性その他
品質要件は品質特
性を網羅的に定義
しているため、機
能適合性以外の品
質特性も確保する
必要がある
特にβ2やβ3ス
テージでは弱
点強化を含む
信頼性の成熟
性や、性能効
率性の確保が
重要である
一般的には機能適
合性に偏りがち

アジェンダ
⑤適用結果

適応したプロジェクト
受入テストのプロジェクトへの導入事例として、
当社製品の帳票電子活用製品である「SPA」の
開発プロジェクトを紹介

SPA9.2 SPA9.3
マイナー
バージョン
アップ
派生開発ではあったが、バージョンアップに伴う
アーキテクチャの変更があったため
新規開発部分の規模が大きい

 テスト戦略
β1ステージ
既存部分の機能と
非機能のテスト
β2ステージ
新機能を含む全
機能の機能と非
機能のテスト
β3ステージ
全体的な
システムテスト
アーキテクチャーの変更があったため既存機能部分を先行で
開発されるので母体品質を確保した上で、新機能の品質を確
保する。
性能面ではアーキテクチャの変更に影響なく前バージョンと
比較して性能劣化していないこと。

最終成果物の品質目標の一部
品質特性副特性品質目標テストタイプ
機能適合
性
機能完
全性
ユーザー要望がすべて実装され、機能すること機能要件確認テスト
リリース確認テスト
機能正
確性
要望機能が実装され正しく動作すること
タブレットにて限定機能が正しく動作すること
製品統合によるインストーラーの修正にて、問題が
発生しないこと
既存機能テスト
新機能テスト
国際化テスト
インストーラーテス
ト
機能適
切性
マイナンバー制度、e-文書法、電子帳簿保存法に関
する機能が法律に対応された機能になっていること
文書のライフサイクル(JIS Z 6016)の規格に対応さ
れた機能になっていること
シナリオテスト
信頼性成熟性過去バージョン機能が新バージョンにて動作し機能
のデグレードが発生していないこと
リグレッションテス
ト
可用性一定期間のロードテストを実施しシステム全体が安
定していること
ロードテスト
障害許
容性
障害発生時にアプリケーションが致命的な状態に陥
らないこと
強制エラーテスト
回復性障害発生時のリカバリー動作が適切であることリカバリーテスト
一つの品質目標に対して複数のテ
ストタイプが設定されている場合
は、テストレベル毎に実施するテ
ストタイプを計画的に分けてLTP
に記載している

品質副特性ベースの品質目標
品質特性副特性品質目標テストタイプ
性能効率
性
時間効
率性
既存機能の測定において、過去バージョンとサーバー
レスポンスタイムをと比較し劣化がなく性能目標を満
たしていること
検索においてUIのアーキテクチャ変更による表示速度
が過去バージョンとターンアラウンドタイムを比較し
劣化がないこと
新機能において性能目標を満たしていること
パフォーマンステ
スト
資源効
率性
スレッド/メモリー/ハンドルリーク等の不当なハード
ウェアリソースの異常なハードウェア/OSリソースの
消費がないこと
マシンリソースに負荷をかけた状態での動作に問題が
ないこと
負荷テスト
容量満
足性
一定の環境下において、一定時間内に指定された検索
リクエスト数や文書検索データ作成量が達成できるこ
と。Middleレンジサーバーで大量データをアーカイブ
し、目標量を格納でき操作可能であること
サイジングテスト
キャパシティテス
ト
時間効率性や資源効率性のテストタイプは全テス
トレベルのLTPで計画を立て、受入テストのクラ
イテリアは最終的に目標を達成するようなテスト
運用にしている。

テストレベルとテストタイプのマッピング
品質特性 β1ステージ β2ステージ β3ステージ R C ステージ
機能適合性
性能効率性
互換性
使用性
信頼性
セキュリティ
保守性
移植性
既存機能テスト
新機能テストシナリオテスト
リリース確認テスト既存機能テストインストーラテスト
機能要件確認テスト
パフォーマンステストパフォーマンステストパフォーマンステスト
負荷テスト負荷テスト負荷テスト
サイジングテスト
キャパシティテスト
共存テスト相互運用テスト
互換性テスト
適切度認識性テスト
マニュアルテスト
運用操作性テスト
ユーザーエラー防止性テスト
リグレッションテストリグレッションテスト
最終リグレッションテストロードテストロードテストロードテスト
強制エラー・リカバリーテスト
セキュリティテストセキュリティテスト
OSS確認テスト
ログ妥当性テスト
プラットフォームテスト
インストールテスト
マイグレーションテスト
最終メディア確認テスト
国際化テスト
互換性テスト
β1ステージで既存
部分の機能と非機
能の評価を実施
β2ステージは新機
能を含む全機能の
機能と非機能の評
価を実施
β3ステージでは全
体的なシステムテ
ストの評価を実施

受入テスト計画の例（ β2ステージ受入テスト計画書）
概要
全機能について機能及び非機能検証を行い、検証が開始できる品質であるかを確認する
テストタイプクライテリア抽出率
新機能テスト正常系 90%パス
準正常 85%パス
Critical以上0件
20%
既存機能テスト正常系 95%パス
準正常 90%パス
Critical以上0件
15%
弱点分析テストバグなし -
強制エラー、リカバリーテスト Critical以上0件 10%
セキュリティテスト Critical以上0件 13%
ログ妥当性テスト Critical以上0件 15%
パフォーマンステスト β1受入と比べ101%以内
過去バージョンと比べ105%以内
ただし100msの差は許容範囲とする
20%
負荷テストメモリリークや不適切なハードウェアリソー
スの利用がないこと
48時間連続稼動すること
10%

アジェンダ
⑤適用結果

適応結果

適応結果
• 基本となる既存機能の不具合が多発し、受入テストに不合
格になった。
• β1ステージをαステージとし開発部門内で品質を高めても
らった。
• QAチームはβ2ステージを「β1+2ステージ」とし、β2ス
テージ内でβ1の予定していたテストを実施

適応結果
• 新機能において深刻度の高い不具合が発生し不合格となった。
• 再受入テストでは新機能テストで新たな不具合が1件見つかり不合格
となった。
• しかし受入テスト期間中のローカルビルドで即時対応されたため、対
応スピードの速さから条件付き合格とした。また、条件部分のテスト
は正式ビルド時に実施され、修正箇所と影響範囲のテストを行い、不
具合がないことで合格とした。

適応結果
• 時間効率性のパフォーマンステストと資源効率性の負荷
テストにおいてクライテリアを満たせなかった。
• 開発部門のメンバーも含めて工数を性能面に費やすこと
で、再受入テストで合格した。

アジェンダ
⑤適用結果

受入テスト導入の効果
 β1受入テスト
開発テストの不足が原因で基本となる
既存機能の不具合が多発
品質保証部門に製品がリリースされる前に開発部門内で
品質を高めてもらう対策ができた。（クオリティゲート
がExit Criteriaだった場合はスケジュール遅延のリスクに
なる可能性があった。）
β1の既存機能の品質が上がったことにより、β1で予定し
ていたテストタイプをβ2で消化することが可能だった。
（テストにかかる工数が削減できるメリットがある。）

 β1+2受入テスト
受入テストを2回実行し、2回目は条件付き合格ではあるも
のの、新機能において深刻度の高い不具合が出た
新機能のテストケースを増やして品質を向上する対策が
できた。
条件付き合格のような基準を決めて、品質確保とスケ
ジュールのバランスをとることができた。

 β3受入テスト
時間効率性のパフォーマンステストと資源効率性の負荷テ
ストにおいてクライテリアを満たせなかった。
開発部門のメンバーも含めて工数を性能面に費やすことで
品質を向上する対策ができた。

 最終的に
Entrance Criteriaとして受入テストを実施
することにより問題を把握することができ
る（ステージ内のテスト作業をスムーズに
進めることができる。）
最終成果物は品質特性を網羅した品質目標
が実現できているため、製品をリリース後
も致命的な流出不具合は出ていない。

今後の課題
受入テストに合格しない問題
品質保証部門からクオリティエンジニアを開発部門にアサイン
開発内での品質が向上する
自動テストが多数実行される
開発内での品質ゲートを設置する
ことにより品質が見える化する

今後の課題
開発内で実施したテストのエビデンスを
品質保証部門によるテスト工程でのインプットとなる
定量データにする
最終的にこの取り組みは開発メンバーへの品質教育となる
品質確保のためのシ
ミュレーション
効果的にテストレベル毎
の受入テストが合格
品質の確保とスケジュー
ル通りのデリバリー
全体の品質改善となるメリットになる

クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果
ご清聴ありがとうございました

クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果

クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果

Ähnlich wie クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果 (20)