運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
テストエンジニアの視点で読み解く「発注者ビューガイドライン」 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
良いバグレポートの書き方 - hogehogeなSEの日々
バグレポートには「わかりやすさ」が求められます。 改修担当者がそのレポートを見るだけで、バグの調査に入れるのが理想です。 しかし、このレポートの日本語が意味不明であったり、必要な情報が抜け落ちていたりすることは多いです。改修担当者がそんなレポート受け取ってしまうと まず意味不明なレポートを読解する作業から始めますので 調査によけいな時間がかかってしまいます。 ある程度の規模の試験チームを持った場合、わかりやすいレポートの書き方を理解できない試験者がどうしてもでてきます。そんな人は、何回バグレポートを書きなおさせても、毎回 最初は意味不明なレポート提出してきます。 毎回 書き直しを要求するのも不毛な作業ですので、その対策として次のようなテンプレートを用意したことがあります。(実際は他にも項目があるのですが…） (1) 期待した結果 (2) 期待に反した結果 (3) 再現手順 このテンプレに沿
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？
バグレポートに関する問題はどこでも起きている 本記事は、バグの修正依頼として作成されるバグ票（バグレポート）を対象としています。プログラマが自身でデバッグを一通り終えた後で、テストを専門とするテストエンジニアにそのプログラムをテストしてもらい、その際に検出されたバグを報告してもらうための文書がバグレポートです。独立した部門でテストを実施している会社では、このような形態とバグレポートによる修正依頼が一般的だと思います。 本連載は、テストエンジニア向けに、バグ修正のプロセスにおいて非常に重要でありながら、あまり注目されていないバグレポートのあるべき姿をさぐってみたいと思います。 早速ですが、プログラマとテストエンジニアの間でこのようなやりとりがあるのを見たことはありませんか？ テストエンジニアとプログラマの間でこんなやりとりが起こっていませんか？ 開発進捗会議にて プロジェクトリーダ： Aさん
プロジェクト管理 - バグレポートの書き方 - Qiita
バグを正しく管理していく上で、バグレポートを正しく書くことは必要不可欠です。 バグを直してもらうために、バグレポートを登録することになりますが、このレポートが意味不明なものでは目も当てられません。 どのようなバグが見つかり、どのように直すべきなのかが簡潔に過不足なく記述されている必要があります。意味不明なレポートは開発を混乱させます。 たとえ自分で登録して直すことになるバグであったとしてもレポートは正しく記述すべきです。なぜなら、あとから必要が生じてレポートを見たときに、ソースコードに対してどんな変更を行ったのかがわからなくなってしますからです。 チームで開発しているなら、当然、他のメンバーを困惑させる要因となります。正しいバグレポートを書くことで不要なトラブルを避け、開発の生産性を向上させることができます。 漠然とした以下のようなバグレポートを書かない 日本語としておかしい レポート内容
プログラマに優しいバグレポートの書き方
10. • 分かりやすい要約 • 前提条件 • 時間・ユーザ（キャラクター）名 • 起きた現象の詳細 • 証拠 • 詳しい再現手順 • カテゴリ • 重要度・優先度
[Think IT] 第4回：アジャイルにおけるドキュメント作成ポイント (1/3)
【楽々デブドックを書こう！】手法別開発ドキュメントの書き方 第4回：アジャイルにおけるドキュメント作成ポイント 著者：ウルシステムズ 深谷 勇次 公開日：2008/02/28（木） 開発の現場「受託型アジャイルモデル」 最終回の今回はアジャイルモデルにおける開発ドキュメントを作成する上での重要なポイントを解説していきます。アジャイルモデルはソフトウェアの要件を最初にすべて決めるのではなく、開発を進めながら顧客の要望に柔軟に対応していくのが特徴です。そのため、顧客と開発業者が1つのチームとして、同じ場所で作業をすることが推奨されます。仕様決定者が常時プロジェクトに滞在しているため、要件の獲得や仕様の確認作業をスムーズに進めることが可能です。 しかし現実には請負という契約形態に縛られて、事前に要件の大枠を決めなければならなかったり、顧客と開発業者が別の場所で作業せざるを得なかったりするものです
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
開発の現場：サンプルデータダウンロード
本ページにあるサンプルおよび関連データに基づくいかなる運用結果についても、著者や出版社などのいずれもいっさいの責任を負いません。
設計書仕様書テンプレート PocketDOC | 株式会社イーイノベーション
弊社サービスをご利用頂き、誠に有り難うございます。 ドキュメントのダウンロード件数が2007年5月の開設以来300000件を突破しました！ 今度ともご愛顧の程よろしくお願いいたします。 PocketDOC(ポケットドック)とはシステム開発に必要な設計書や仕様書などのドキュメントやテンプレートはもちろんのこと、 議事録、納品・検収書、近年話題になっている個人情報に関しての取扱管理表などの ドキュメントやテンプレートも提供しています。 実際に弊社のプロジェクトで使用されているため精度も高く、カスタマイズなしでも利用可能なほどです。 上流工程から下流工程まで広い範囲をサポートしているので、 必要なテンプレートだけをダウンロードして利用することも可能です。 ドキュメントやテンプレートのファイル形式はWord(doc形式)やExcel(xls形式)です。 ダウンロード後、すぐにお使いいただけるように
)
スクラム (ソフトウェア開発) - Wikipedia
複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくア
品質管理・進捗管理に質問表を活用する - 現場のためのソフトウェア開発プロセス - たかのり日記
「要件や仕様が正しく伝わっているか？」ということを把握するのは難しい、と感じます。 自分は当たり前に思っていても、相手はそうでない 打ち合わせで説明したつもりが、相手には意図した通り伝わっていなかった 仕様書はレビューしたけど、理解が違っていることに、受入になってから気付いた などなど、問題の事例を挙げたら、キリがないでしょう。 要件定義のやり方や、レビューのやり方で、ある程度は改善できるモノの、大抵の場合、問題に気付くのは試験や受入段階になってから。 それがプロジェクトの遅延や失敗に繋がることにもなります。 アジャイルなら、早期に問題に気付ける、というのはあるかもしれませんが、それでも手戻りが多ければ、イテレーションはうまく回らなくなるでしょう。 そのような状況に対し、質問表（Q&A表）を分析すると、プロジェクトの傾向が良く分かると感じ出しています。 現在、こんな感じで、質問表の分析を行
基礎から学ぶソフトウエア・テスト（2）
テストといってもいろいろある サッカーからの教訓で，テストは開発メンバー全員の仕事と書きましたが，それぞれのメンバーが行わなければならないテストは一言ではくくることができないくらい，いろいろな種類があります。 では実際にテストはどのようなことをどんな順序で行っていくのでしょうか。その疑問に答えてくれるものの一つが，開発工程とテストとの関係を表す「Vモデル」です（図2[拡大表示]）。Vモデルでは，開発工程に対応した形でテストの種類を決めています。 テストに工程を設けるのは，テスト対象への視点を整理することでテストが混乱しないようにするためです。例えば，メソッドのパラメータの組み合わせパターンのテストと，システムとしての使い勝手を評価するためのテストでは，テスト担当も違えば，テスト環境やテスト実施方法も違います。また，工程を分けてより早くテストを始めることで，問題の切り分けを楽にするという意味
アプリケーションテストの概略
はじめに 当初設計した以上のアクセスが集中してシステムがダウンをしたとか、設備を増強したり更新したことによるシステム障害事故というニュースは、多くの方が見聞きしていると思う。記憶に残る事例としては2005年11月1日の東京証券取引所のシステムダウン、2007年5月27日と2008年9月14日のANAのシステムダウン等がある。これらの多くの障害は性能テストが不十分であるか、適切なテストが行われなかったことによる。 ソフトウェアのテストと一言でいっても、システム構成や規模等でテスト技法には様々な方法がある。その全てを紹介するには無理があるので、ここでは、ソフトウェアの品質を保証するテスト方法の概略と、「アプリケーションの性能テストツール」を紹介する。 １．ソフトウェアの品質 ソフトウェアの品質とは、ソフトウェアが要求された効果を発揮するために必要なすべての特性を意味し、ISO／IEC 912
一般的なソフトウエアテスト手順を教えてください。…
一般的なソフトウエアテスト手順を教えてください。 ある資格試験問題の回答では 「単体テスト⇒結合テスト⇒システムテスト⇒運用テスト」 と書いてありました。 またある参考書には 「ソフトウエア単体テスト（開発者）⇒ソフトウエア結合テスト（開発者）⇒ソフトウエア適格性確認テスト（開発者）⇒システム結合テスト（開発者・ユーザ）⇒システム適格性確認テスト（開発者・ユーザ）⇒受け入れテスト（ユーザ）⇒運用テスト（ユーザ・実稼働環境で）」 と詳しく書いてありました。 また、私の経験上は 「単体テスト（開発者）⇒結合テスト（開発者）⇒運用テスト（開発者が現地のテスト系統で）⇒システム検証（ユーザが現地のテスト系統で運用テスト仕様書を元に行う）」 です。 言い回しはいろいろあるのでしょうけど、 単なる言い回しの違いだけではないような気がします。 これは状況に応じて様々なパターンがあるということでしょうか？
テストフェーズ
ソフトウエアのテストは、一般的に、次のフェーズからなります。 単体テスト 結合テスト システムテスト 運用テスト １．単体テスト 単体テストとは、UT、Unit Testを意味しますが、何をUnitと見なすかは、プロジェクトによって異なります。最小はメソッド単位（場合によってはその中のブロック内）で、さらにクラス単位、画面単位のいずれかになります。単体といってもある程度は結合した状態で行うことがあり、プロジェクトによって何を指すかは微妙に違います。画面の場合、１クラスから成っている場合もあれば、複数クラスから成っている場合もあります。 Webアプリケーションで１画面という場合、次の３つのテストが絡んでくるので、どのように区分けをするか注意が必要です。 1.初期表示 前のページから渡されるパラメータやセッションその他の情報によって同じサーブレットもしくはJSPでも表示が異なってきます。 2.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Think IT] 第1回：なぜバグ管理システムを使うのか？ (1/3)
「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは
ゲームを作っていく過程を描いてる漫画などで、「Aバグが～」というものが出てきたのですが、実際にゲームを作るときに「Aバグ」という単語は... - Yahoo!知恵袋
バックログとはどういう意味ですか？ - ○バックログ【backlog】開発待ち状態にあるソフトウェアのこと。原語は「処理されず... - Yahoo!知恵袋
SAP(R/3)アドオン開発の勘所:仕様変更をなくす ４ 課題管理表