- ベストアンサー
テスト仕様書について
lawsonの回答
- lawson
- ベストアンサー率44% (29/65)
単体テストですか？ 単体テストなら、プログラマが作成したほうが よいと思います。 時間がない時は、詳細設計書を印刷して、 記述の該当箇所に番号をつけて、テスト結果にも 番号をつけてリンクさせます。 １つの記述に対して、数ケースをテストしても よいし、1ケースでもよいでしょう。 詳細設計書に書かれていることはすべて、確認した ということですね。 そして、加えてコード書いた本人ならではの ここは重点的に確認すべきだと思うことについて 簡単な箇条書きのテストケースと、テスト結果を 残します。 「テスト仕様書を残す」ということにうるさくない 現場で、使えるやりかたです。 質問者さんの現場でできるかどうかは知りませんが。 これならＡさんも自分の書いた設計書の記述内容が すべてテストで網羅されているので、文句のつけようがないですね。 それで、不具合があるなら、そもそも、Ａさんの 設計書に不備があったことになりますので。 ただし、だからといって責任逃れをするという ことではないです。 気づいた問題点は報告して、設計の改善、実装、 テストをすべきです。Ａさんも神様ではないので ミスをするときもあります。 以上です。
関連するQ&A
- ソフト開発に関する仕様書の書き方は？
ある携帯を用いたシステム開発における仕様書を作ってくれと会社の上司から依頼されました。 当方、プログラム経験は少々ですがあります。 （といっても、MS-DOS時代のC、エクセルVBAでのツール作りくらいですが・・） よって、具体的な仕様書をおこしたことはありません。 一口に仕様書といっても、システムの種類や内容などによって、いろいろあると思うのですが、何か具体的な仕様書フォームとかあれば、ぜひ欲しいです。 どういった項目が必要なのかがわからず、何から手をつけて良いかが、わからないもので・・ ちなみに、仕様書を作成する側（SEと呼ばれる立場？）は、開発する環境（使用するハードやソフト）、開発言語、使用するDB、開発するための規則なども細々と決めなければならない（仕様書に盛り込む必要がある）のでしょうか？ プログラミングは、外部のソフトベンダーに依頼するそうなのですが、そうなると仕様書がしっかり書かれていないとマズいような気がしています・・ しかし、どこまでのことを仕様書を作成する側がやらなければならないかも、ちょっとわからないんです。 また、仕様書を作成する業務＝システム設計またはプログラム設計と考えてもよろしいのでしょうか？
- ベストアンサー
- その他([技術者向] コンピューター)
- 設計書～テストまでの勉強法を教えて下さい
お世話になります。 開発手順の一連作業を勉強したいと思います。 設計書作成、プログラム作成、テスト仕様書作成、テスト などの開発作業です。 自分で機能を考えて設計からテストまでやろうと思いましたが、 良い機能が思いつかないので勉強が進みません。 また、セミナー受講も考えましたが、開催日がほとんど平日のため 難しいです。 それでも実際に仕様書を設計し、プログラム作成して、テストを 実施するような勉強方法はあるでしょうか。 よろしくお願いします。
- 締切済み
- その他([技術者向] コンピューター)
- SEの「上流工程の実務経験」とは具体的にどういったものか
SEの「上流工程の実務経験」とは具体的にどういったものか ■質問 「上流工程の実務経験があります」 SEとして、この言葉を職務経歴書に記載したり、胸を張って言えるのは、具体的にどういった経験をしてきた方だと思いますか？ エンジニア経験者様にご意見をお聞きしたいです。 ●詳細 私はSEで、現在転職活動をしております。 転職活動にあたり、自身が「上流工程を経験してきた」と言っていいものか迷っています。 といいますのも、所属しているのは小さい独立系ソフトハウスで短納期の小規模案件が多く、上流工程といっても次のような経験しかないからです。 1. お客さんと仕様打ち合わせ 受託開発などで仕様書が既にある場合は、矛盾点などを発注元と調整 2. 必要に応じて機能仕様書、仕様提案書などを作成 求められない場合は作成しない 3. 実装 詳細設計書はソースから生成。先に設計書は作成しない 4. テスト、納品、サポート 1.2.が基本設計、3.が詳細設計にあたるのかな？と思いましたが、世間一般では ・基本仕様書作成 → 基本設計 ・詳細設計書作成 → 詳細設計 というように考えられていると感じました。 以上のような状況で、実務経験有りと言っていいものか自信を持てません。 ぜひ、ご意見をお聞きできればと思いました。 よろしくお願いいたします。
- ベストアンサー
- 転職
- 「テスト仕様書」の運用について ・どういう手法として知られているか
業務系のソフトウェアを開発・販売・保守している会社にいます。 今回、プログラム開発の過程に「テスト仕様書」というものが導入されることになりました。 通常、プログラマレベルでのプログラムの作成→担当SEもしくはその他の人がそれを検収の上ユーザに納入、という流れを取っています。 （ここにいう「作成」「納入」というのはシステム全体を納入するといったことではなく、例えば数十以上の実行ファイル等でできあがっているシステム全体のうち、実行ファイルを1コ追加する、といった単体レベルの話です。） 「テスト仕様書」の運用方法なのですが、 (1)通常の仕様書と同時に、あるいは少し遅れたタイミングでプログラマに渡す。 (2)稼働中のユーザと同じ動作環境のもとで、ごく限られた条件と、その条件によって出てくる予定の出力結果が提示してある。…帳票などでは範囲を広く指定すれば大量の出力結果が得られるわけですが、例えば「得意先は○○、商品は○○」の場合は「金額は○○円」と出てくる筈、というふうにごく一部だけが示してある。 (3)テスト結果をプログラム作成の終了と同時に、場合によっては途上で担当SEなどに早めに提出する。 …というものです。 趣旨としては、 (1)「テスト仕様書」の添付により、もともとの仕様書の不備を明らかにしやすくなり、かつ、プログラマの仕様の理解における勘違いを早めに正す。 殊に、誤解を招きやすい仕様の箇所に重点を置くと効果を発揮する。 (2)作成されたプログラムの本検収に取り掛かる前に一部でもテスト結果を早めに得ておくことで、検収やそれ以後の作業の迅速化を図る。（おもむろに取り掛かった本検収でプログラムの不備が初めて明らかになるより、ごく一部のテスト結果をちらっと見るだけでそれが間違いであることが分かればすぐに修正を依頼することができる。） (3)一部のテスト結果が正しければ全体も正しいという蓋然性が高まるので、プログラムの品質の向上に繋がる。 …というものです。 趣旨は良く分かりますし、特に「一部だけを早めに摘み食いする」という(2)の着眼点というのは面白いと思います。また、「得られるべき結果」を予測しておくための労力（言い換えれば「テスト仕様書」を作成するための時間)はかかりますが、あるべき出力結果を考えるというのはどのみち後でしなければならないことなので全体としての工数は変わらないという考えもあるようです。 …こういった手法は既に良く知られ、何かの名前が付いているものなのでしょうか。 書店で立ち読みなどをして文献を探したのですが（笑）、該当すると思われるものはありませんでした。 手法としての名前や、何か参考資料の在り処等を教えて頂ければと思います。
- ベストアンサー
- SE・インフラ・Webエンジニア
- 仕様書について
ある開発会社がパッケージプログラムを作成して、ソースを提供してもらい （但し、開発会社からは仕様書の提供はありません。） こちらがそれを各ユーザーにセットアップします。 そしてその各顧客の要求通りにプログラムを修正して提供している わけですが（主に帳票レイアウトの変更） その変更内容を記述する仕様書を作成するのですが、これを一般的に 何仕様書というのでしょうか？あまりこのパターンは経験したこと ありません。大体基本設計仕様書とかがあってそれを修正したもの がプログラマーに提供されるもので。インターネットで調べても出てきません。どうか教えてください。
- 締切済み
- その他([技術者向] コンピューター)
- 単体テストのテストケースの考え方(あげかた)について
単体テストのテストケースの考え方(あげかた)について 最近、プログラム(java)をはじめたものです。 単体テストを行ううえで、 まず、テスト仕様書の作成を行う(正確にいえば詳細設計段階でやりますが…)と思いますが、 そのテストケースのあげかたはどういう着眼点であげればよいのでしょうか？ 単体テストは、詳細設計に対してのテストだと思いますので、 基本的には、詳細設計で作成いたフローチャートの分岐をすべてのケース通るような仕様書を作成しています。 ただ、このやり方だと、問題があるような気がするのです。 たとえば、javaでMapを使用していて、 入力値が、値が固定のMap(例：1,2,3)に入っていればtrue、入っていなければfalseという処理があるとき、 フローチャートでは、trueかfalseかの２パターンしかなく、 実際のコードの記述もget(入力値)で、あるかないかだけ判断するため、２パターンです。 しかし、実際は、固定Mapの値1,2,3,とそれ以外という選択肢があるとおもうのですが、 こういう場合は、１、２、３、それ以外の４パターンのテストを行うべきでしょうか？ それとも、Mapにあるかないかだけの部分なので、trueの時とfalseの時の２パターンでいいのでしょうか？
- ベストアンサー
- その他（プログラミング・開発）
- プログラムのテスト仕様書で使えるCMSについて
お世話になります。 今まではExcelでテスト仕様書を作成してテストを行っています。 ネット上でテスト仕様書の内容を追加、修正、削除ができるようなCMSを探していますが・・・ プログラムのテスト工程をやりとりできるような使い方ができるCMSはあるのでしょうか。 例えば下記のような表が作成出来て、みんなで更新ができるみたいな 番号 | テスト項目 | テスト結果 | ステータス | 担当者 | 備考 -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | 知識不足ですみませんがプログラム開発時で使えるCMSがあったら教えて下さい。 宜しくお願いします。
- 締切済み
- オープンソース
- ソフトウェア開発の流れ
ソフトウェア開発の流れについて知りたいのですが、あるサイトには、(1)要求分析(2)概要設計(3)詳細設計(4)プログラミング(5)テスト(6)実施 とありますが、基本設計とかっていうのはどこにあてはまりますか？また、基本的に(1)～(6)の流れが一般的な開発の流れなんでしょうか？ 宜しくお願いしますσ(^^)
- ベストアンサー
- その他(ソフトウェア)
- プログラミング経験のないSEのキャリアアップについて
こんにちは。僕はSEのキャリアアップについて少し悩みがあって、 みなさんのご意見をお聞きしたいと思います。 ■現状 男性、27歳、現在あるIT会社に勤めています。入社3年目。 設計-開発-テスト-運用 という流れから見れば、僕の仕事は「テスト」です。ユーザーに近い立場でのテストで、プログラムはあまり触りません。 僕はコンピュータが好きで、この業界で働き続きたいと思います。自分は中国人であるため、将来日本語と中国語を両方活用でるなブリッジSEになりたいんです->まだ遠い話です。 ■悩み 本格な開発・プログラミングの経験がないため、今後キャリアアップはどう設計すればよいか分かりません。 周りの友達は、ほとんど【開発 → 内部設計 → 外部設計】というキャリアだそうです。それはIT業界での「王道」ではないか思います。つまり、みんなは本格的なプログラミング経験があります。 しかし僕の場合は、 入社時JAVAの研修が2ヶ月間。自習でVBAを少々。 会社に入ってから、いきなり「テスト」になってしましました。開発の部署に異動しようとしても、開発の仕事はほとんどアウトソーシングで、自社にはなさそうです。 現場で、仕事の効率を上げるために時には200行ぐらいの自作ツールを開発します。（自分だけが使うため） その程度です。 ほかの人と比べたら、僕は本格的なプログラミングの経験が足りないのです。 僕は一生ずっとプログラミングをするつもりはありません。しかしまったく経験ないままで大丈夫かどうか、不安します。 ■質問 １．IT業界で働いている皆さんは、皆プログラミングの経験がありますか。 ２．SEのキャリアアップの視点から見れば、プログラミングは必須ですか。 ３．僕は二つの道を考えています。 A 現在の部署、仕事を維持して、そのまま成長していく。 B プログラミング経験できる部署あるいは会社にいって、本格なプログラミングを経験します。２、３年後、また現在の仕事に戻る、あるいは他の仕事をします。 経験の浅い僕は、この二つの道がどちらがよいか分かりません。 皆さんのご意見をお伺いしたいと思います。 以上、ありがとうございます。
- ベストアンサー
- SE・インフラ・Webエンジニア
- 単体テスト、結合テスト、テスト仕様はどこまで詰め込む？
今、テスト仕様書を作成しており、 みなさまのご意見が伺えたらと思って書き込みさせていただきました。 単体テスト、結合テストの仕様書を作っているのですが、 パターン数がやはりべらぼうに多いので、どこまでで 割り切るかで悩んでいます。 考えれば考えるほどパターン数は出てくるのですが、 それらを作る工数、テストする工数を考えると、 う～ん・・・という感じです。 １００％バグのないシステムを作ることは不可能で、 そのコストは∞とされていますが、可能な限りそうしたいのは やまやまですが。 ある本には顧客が７０％を望んでいるなら開発としては７１％を達成できたらよく、それ以上を求めることは技術者のエゴと書いてありました。 確かにまずされない操作のテストパターンを大量に生成する時間があったら、クライアントはユーザビリティを上げるなどして欲しいはずです。 でも７０％ってどうやって決めたらいいのでしょう？ 何でもいいので皆さんどうされているか、アドバイスいただけたら幸いです。
- ベストアンサー
- その他（プログラミング・開発）
お礼
遅くなりましたがありがとうございます。 結局私が作成する事になりました。 時間はあるので、勉強もかねてじっくりやりたいと思います。