SQuBok(R)分類検索
22 件の資料が見つかりました。
ダウンロード数: 2703回
年度 : 2005年   分科会 : 第5分科会「テスト」
紹介文 :
単体テストを実施することによる、効果と注意点について述べられています。成功事例が2つデータで示されているので非常に参考になるでしょう。 また、負荷が増大する部分についても丁寧な議論がされており、実際に、単体テストを改善しようとしている人にとって貴重な論文となっています。
ダウンロード数: 2481回
年度 : 2005年   分科会 : 第5分科会「テスト」
紹介文 :
ISO 9126などの品質特性を、実際の現場でどのように使えばいいのかの一方策が提案されています。通常は外部品質特性のみ着目されがちですが、内部品質特性も使用されており、開発する立場が考えねばならないことも組み込まれています。 使用する際は、プロジェクトごとに品質特性の捉え方は異なるので、チェック項目と特性のリンクを再考し、チェックリストの補足も、プロジェクトにあった形にすると、より使いやすいものになります。
ダウンロード数: 1476回
紹介文 :
仕様書のレビューをする際のレビューの観点を何にするかは,しばしば議論されている.本論文では,結論として,たとえそれを書いた設計者であっても,機能仕様書を作った後に思考をリセットしてテストエンジニアの視点(懐疑的な観点)を持ってレビューを行えば,効果的な結果を得られたことを示している.逆に,テストエンジニアが機能仕様書を書いても,設計者が書いたものと同様な欠陥を出していることを実験で示しているのが面白い.レビューの観点について考えさせられる論文である
ダウンロード数: 1339回
紹介文 :
要求仕様書の品質を上げるための施策を3つ提案している.一つはWモデルの考えで,要求仕様書とテスト設計書を同時作成し,テスト設計書から要求仕様書にフィードバックをかけるとうもの.もう一つは,仕様書にハイパーテキストを使って,仕様書間の矛盾を発見しやすくしたもの.最後は,記載漏れを防ぐためのチェックリストを提案している.
ダウンロード数: 629回
紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。 限られた期間でデグレードの確認が必要な場合にお勧めです。
ダウンロード数: 429回
紹介文 :
「開発の上流文書の質が良くないと下流のテストがタイヘンになる、だったらテストエンジニアが上流から関わってはどうか」というところから出発した報告です。テストエンジニアの視点は設計者や開発者とは異なることを利用し、テストで発見されるべきバグを要求仕様書の段階で見つける試みです。 設計・開発とテスト担当者が別のチームであるプロジェクトなどには、有効な考え方です。
ダウンロード数: 387回
年度 : 2013年   分科会 :
紹介文 :
開発工程にて用いられるW字モデルを品質保証部門における検査プロセスに適用させ、検査プロセスのプロセス改善に取り組んだ事例を紹介しています。品質保証工程において機能仕様書に記載される機能に対する検査観点をまとめた検査観点表をW字モデルにおける上流工程で作成することにより機能仕様の不備やテスト項目の不足を洗出しバグ摘出数の向上とバグ修正工数の短縮につなげています。
ダウンロード数: 385回
年度 : 2012年   分科会 :
紹介文 :
市場での故障の低減を目指して、過去10年の故障を分析と問題点を明らかにしました。 それを整理して、テスト観点知識ベースの構築を行い、テスト設計に活用することで、テスト観点と項目の強化を行いました。 その分析から整理、解決策の検討からテスト設計への反映に対する取組みについて述べています。
ダウンロード数: 345回
年度 : 2013年   分科会 :
紹介文 :
エンジン制御器(コントローラ)開発においてモデルベース開発(MBD)を導入することにより開発期間の短縮は実現できましたが開発プロセス後半の開発効率の低下は改善できなかったことからMBDの開発プロセスを見直しを行い、ソフトウェア構造と制御対象(プラント)に着目し、シミュレーションを用いるテスト駆動開発を取り入れたプロセス改善方法について提案しています。発表内容はエンジン制御に特化していますが、他の制御機器にも適用できる開発プロセスだと思います。
ダウンロード数: 330回
紹介文 :
効率的かつ効果的なテストを行うためには、テストアーキテクチャの設計が重要なポイントです。 そこで、発想を整理するマインドマップを使ってテスト観点を抽出し、その観点の整理方法とともに、テストプロセスを提案したのが、この論文です。 提案する手法は、実際にソフトウェアテスト技術振興協会(ASTER)の「テスト設計コンテスト」に出場して効果を検証したものです。
ダウンロード数: 256回
年度 : 2013年   分科会 :
紹介文 :
組込システムの利便性等をより良くするために製品のヒューマンマシンインタフェース(HMI)に対するユーザビリティの向上を図るためのHMI設計・評価プロセスを提案しています。システムアーキテクチャ設計プロセスにおいてHMI品質メトリックを設定し定量的に評価することにより開発プロセスにおける設計課題を共有化し手戻りの削減やユーザビリティの向上が図れると共にメトリックを蓄積することでHMI品質に対する総合診断が可能になると想定されています。
ダウンロード数: 249回
年度 : 2013年   分科会 :
紹介文 :
インシデントレポート(バグレポート)は、今日のソフトウェア開発を行なっている多くの組織で利用されているが、何かしら問題を引き起こしている組織も多いのではないだろうか。本報告では、バグレポートが引き起こしている問題に関する調査をインターネットやイベントで行ない、現場ではどのような問題があるか報告している。また、アンケート結果から問題を回避するためのアンチパターンの一部を作成方針を報告している。
ダウンロード数: 238回
紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。
ダウンロード数: 228回
年度 : 2004年   分科会 : 第7分科会「テスト」
紹介文 :
単体テストに関するプロセス品質状況を5レベルで評価する自己診断チェックリスト、および、そのレベルにおいて次に改善すべきプロセスをまとめています。しばしば属人的な単体テストのプロセスについて、簡易に現状を把握する方法として参考になります。
ダウンロード数: 218回
紹介文 :
テストの効率化を目的にSW-CMMに含まれるキープラクティス(KP)を テスト観点で解釈し成熟度レベル順に整理した研究。TPI (Test Process Improvement)を参照し、SW-CMMユーザー組織に分かりやすい連続表現的な整理を目指した。CMMIでの連続表現に比べ幅色い、キープロセスエリア(KPA)からプラクティスが集められており、テスト専門チームでの改善を検討する際に参考になる。
ダウンロード数: 218回
年度 : 2012年   分科会 :
紹介文 :
テストの実施状況を把握するのは何のためでしょうか。テストに関わる者の立場が違えば、必要とする情報も異なります。 本発表では、テスト管理者・テスト実施者・ソフトウェア開発者が、それぞれどんな情報が必要かを整理し、テスト管理上で有効な分析ビューを定義した事例をしています。
ダウンロード数: 199回
年度 : 2013年   分科会 :
紹介文 :
テストケースの削減や休日・深夜残業という手を使わずに、進捗の遅れに対処する方法を紹介しています。ボトルネックにおける効率向上や、CCPMバッファ管理グラフによる視覚化など、期間を短縮するための汎用的なテクニックは、現場に導入しやすいでしょう。
ダウンロード数: 150回
紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。
ダウンロード数: 135回
年度 : 2013年   分科会 :
紹介文 :
大規模なパッケージソフトウェアの開発における、テスト用のデータベースのデータ品質保証をテーマとしています。開発環境やテスト環境の運用に関心が有る方に、特にお薦めです。 研究対象の開発やテスト環境の規模が数値で具体的に示され、また、改善前の問題や実施結果が判りやすくまとめられています。大規模開発の経験はないが今後取り組もうとされているに方も、読み進めやすい内容になっています。
ダウンロード数: 108回
紹介文 :
本論文では、派生開発において高リスクな不具合を早期に検出しやすくするため、従来のリスクベースドテストよりも軽量なテスト手法を提案している。 具体的には、新旧ソフトウェア間における機能群単位でのテストケース数の変化割合および不具合の検出数からテスト実施の優先度を付ける手法(LightTest-Prioritization Method,LTP-Method)である。これらの情報はプロジェクト情報として揃う情報であるため、テスト実施のために新規で揃える必要がない。これらの情報を説明変数として重回帰分析を行い、高リスク不具合の潜在期待値を機能群ごとに導き出すことで、テスト実施の優先度をつける。 本手法は従来のリスクベースドテストよりも導入しやすくなるため、高リスクな不具合を早期に検出できることが見込まれる。
  

1

2
↑