紹介文 :
業務システムの受託開発において、要件定義工程の成果物として業務フロー図が作成される。業務フロー図には、業務全体の流れに沿ってシステム化する範囲と作業概要が記述される。その記述内容に基づき、発注者と開発者とで合意形成が行われ、設計工程やテスト工程の成果物が作成される。
業務フロー図をテスト工程の入力成果物として利用するとき、実務中に実行される業務シナリオがすべて記述されておらず、十分なテストを設計できないことが多い。典型的な業務フロー図では、基本シナリオ（業務目的を達成できる代表的なシナリオ）は記述されるが、代替シナリオ（業務目的を達成できる基本シナリオ以外のシナリオ）/例外シナリオ（業務目的を達成できないシナリオ）の記述が一部に留まっている。
業務フロー図に記述されない代替/例外シナリオを表現するため、状態遷移図/表を利用する方法がある。状態遷移図/表は、複数の業務に紐づく代替/例外シナリオを簡潔に表現できる。
しかし、業務システムの受託開発においては、設計工程でもテスト工程でも状態遷移図/表が作成されず、十分なテストを設計できたか検証するのが困難になるという課題がある。
本論文では、業務フロー図および各業務を詳細化した設計書から状態遷移を抽出し、業務フロー図に記載されていない代替/例外シナリオを補完してテストするためのテスト設計手法およびその適用事例について報告する。

紹介文 :
探索的テストは、バグの摘出効率が優れており、品質向上や生産性向上を目指す多くの組織に注目・活用されている。
しかし、システムの受託開発を行う業者における、探索的テストの採用事例は少ない。
探索的テストは、事前にテストケースを作成しないため、テストの総量や実施範囲が不透明であり、テスト管理が難しいことが原因の1つと考えられる。
そこで、受託開発におけるテスト管理に求められる要件を明確にすべく、JSTQB Foundation Levelシラバス「5. テストのマネジメント」に記載の6つのカテゴリに着目し、これらのカテゴリごとに、探索的テスト導入時の問題点を整理し、改善目標を定義した。
本発表では、テストをセッションと呼ばれる時間の枠で管理する「Session-based Test Management」を活用することで、定義した改善目標を満たしながら、探索的テストを実施する方法を検討し、実際の開発現場で適用した結果を紹介する。

紹介文 :
ソフトウェア開発の定量的な品質管理では、プログラムコード行数あたりのバグ摘出数・テスト数といった指標を使うことが多い。昨今は業務パッケージソフトウェアの利用などでプログラムコードを直接書かないプロジェクトが増え、プログラムコード行数を用いた指標を利用することが難しくなってきている。また上限・下限値といった水準値を定めて指標値を評価するが、
統計的に意味のある類似したプロジェクトの情報の入手が前提となっている。昨今は技術の多様化が進んでいるため類似したプロジェクトを見つけるのが厳しくなっており、この点からもプログラムコード行数を用いた指標を利用することが難しい。そこで本論文ではテストプロセスを対象とした、プログラムコード行数を用いない品質分析技術を提案する。
また現代のビジネスにとってソフトウェアの重要性は増しており、 その開発を高速に行うことが市場に求められている 。迅速に提供できたとしても ソフトウェアの品質が悪ければ提供価値が下がるため品質管理の重要性は変わらない 。品質を保ちつつ品質管理にかかる作業は高速であることも求められている。プロジェクトでは次のフェーズに進んで良いか判断するために、各フェーズの終了時に品質を 確認するクオリティゲートを設定することがよくあるそのための品質報告 情報のとりまとめや、次のフェーズに進んで良いか判定している期間がソフトウェア開発を停滞させてしまうことがある 。この点に品質管理を高速にするための改善余地があると考え、解決するための手法を提案する。
定量的な品質管理は開発中に日々行うことが理想ではあるが、実現できているプロジェクトは多くはない。そこで日々の品質管理のために何を確認しているのかヒアリングを行った。 その結果、テスト観点に対してテストを網羅的に実施できているかと、すり抜けバグの 発生状況の確認を行っていることが多かった。この 2 つを定量的に確認できるような品質分析技術として整理し、無理なく品質管理を日々行うことで開発速度を落とさない品質管理 手法を策定した。
本論文では2 章で解決したい課題を明確にし、3章で改善策の提案を行い、4章で提案手法の適用結果を紹介し、 5 章で今後の展開を述べる

紹介文 :
ソフトウェア開発を成功に導くために、技術者の能力の均質化や底上げ、開発プロジェクト内での共通認識の醸成を目的として、開発標準などのドキュメントを作成している企業は非常に多い。しかし、ソフトウェア開発プロジェクトは複雑であるため、開発標準に記すべきノウハウは多岐にわたる。そのため開発標準が重厚長大なドキュメント群となってしまうことが多い。多くの技術者は多忙な開発の中で重厚長大な開発標準を読むこととなり、大変な苦労を感じている。結果として開発標準は技術者から「役に立たない」・「読みたくない」といった評価を受けることがある。また、ソフトウェア開発に関する技術やテクニックは、常に進化しており、開発標準も進化に追従していかなければない。しかし、重厚長大なドキュメントを修正するには、執筆やレビューの工数が負担となり、迅速な改善が難しい。その結果、開発標準に記されているノウハウが、時代遅れとなってしまうことも珍しくなく、技術者からの評価がより悪化してしまう。開発標準が、ユーザである技術者から見て魅力のないドキュメントとなってしまうと、目的であった技術者の能力向上や、共通認識の醸成がうまく進まず、ソフトウェア開発プロジェクトが失敗に終わってしまうことがある。そこで我々は、オープンソースソフトウェアの開発技術・文化を、組織などの閉じたコミュニティで実践するインナーソース開発のノウハウを、開発標準の作成に適用し、このような問題を解決した。本発表では、これらの経験に基づくノウハウや、考え方を紹介する。

紹介文 :
ビジネスの変化が急速に進む現代では、システム開発の工期短縮が強く求められている。
システム開発においてテストが要する工数は5割を超えるとも言われており、テストプロセスの改善は急務である。
多くの開発現場では、未だにスクリプトテストが主流であり、テストケース表などのドキュメント作成に必要な工数が重い負担となっている。
一方、探索的テストは、欠陥摘出効率の高いテスト技法として知られているが、スクリプトテストと異なり、テストケース表などのテストの詳細な内容を示したドキュメントを作成しないため、第三者に対してテストの十分性を説明することが難しい。

そこで我々は、探索的テストを応用した新たなテスト手法「SONAR Testing」を開発した。
SONAR Testingはテスト観点をベースとしたテストチャーターを用いることで、観点に対して網羅的なテストを計画できる。
また、テスターの行動を、画面遷移図やシーケンス図といったモデルに変換・可視化するツールを作ることで、レビューを通じて観点に対して十分なテストが実施されたかを確認できる。

本発表では、SONAR Testingの思想や運用方法、作成したツールの概要、および試行適用の結果を報告する。