- 締切済み
システムエンジニアの皆様に質問です。
システムエンジニアの皆様に質問です。 こんにちは。今年の4月から入社した者です。 客先に常駐し始めたのは8月下旬からです。 その客先で現在、基本設計書を見ながら単体テストの仕様書を作っているのですが、その基本設計書が分からなすぎて困っています。 自分がその案件に関わってまだ数日しか経ってないのもあるのですが、システムについて理解出来ずテストケースもろくに作れないのが現状です。 基本設計書見ても何やっているのか分からなくて、テスト仕様書自体の作り方も分からなくて、そのプログラムがどこで動いているのか分からなくて、このプログラムは何の目的で作られているのか分からない状態で上の人間から、仕様書に関しては3日で作れと言われたけどもう5日も経ってしまって自分はやっばりIT企業には向いていなかったのかなーと最近思うようになってきました。 分からないことが分からない状態で作業が進まず、時間だけが過ぎていくことが多いです。皆さんは分からないことが分からない時はどうしていますか?
- みんなの回答 (4)
- 専門家の回答
みんなの回答
- hue2011
- ベストアンサー率38% (2801/7250)
基本設計書を見ながら単体テストの仕様書をつくるなんておかしいでしょう。 単体テストというのは、プログラムが動作するときに、機能単位で、仕様書通りの動作をするかどうかを確かめるものであって、詳細設計書がなくてできるものではありません。 基本設計書というのは、全体をどう作っていきたいか、どういう機能を配置したものにするのか、ということを決めるものであって、まだプログラムなんて書かないころにつくるものです。 だから基本設計書で単体テストの書類なんか作れるわけがないのです。 あなたは見るものを間違えて目的の資料を作ろうとしているのです。 あなたがこの書き込みをしただけで、私はそういう指摘をしています。 大体この文章のままの表現でリーダーや上司に「わたしは何か方法を間違っているでしょうか」と質問したら、もっとクリアに明確に教えてもらえるはずです。 自転車に乗ろうとしているのに自動車のマニュアルを見たりしても何もできません。
- notnot
- ベストアンサー率47% (4900/10358)
単体テスト仕様というのは、プログラムが仕様通りに出来ているかのテストなので、基本設計書を見るので無く、プログラム仕様書(プログラム設計書)を見て作成します。 ドキュメント化をちゃんと行っていない(意図的にドキュメントを減らしている場合も含む)場合で、プログラム仕様書が無い場合は、しょうがないので、基本設計書から作る事になるのでしょうが、プログラム設計と同様のことをやり直すことになります。 (基本設計書があるだけまだましと言える。ちゃんとしたものである場合ですが) なので、プログラム設計が出来るスキルが必要です。 自分にスキルが無いことをやらされているわけで、これだけでは、向いているのか向いていないのかの判断は難しいです。 >皆さんは分からないことが分からない時はどうしていますか? 自分でよく考えても分からないときは、上司に聞きます。スキルの無いことは出来ません。
- Gletscher
- ベストアンサー率23% (1525/6504)
システムエンジニアとゆうのは入社したての新人がするものでは無いですが、あなたの会社ではそうなんですか? 普通はソフトウェアエンジニアの上の立場になるので、ソフトウェアエンジニアを10年、15年経験した優秀な人が選抜されてリーダーになり、システムエンジニアへと抜擢されていきます。 ですからシステムエンジニアで仕様書の書き方が分からないとゆうのはあり得ないですね。 それに、普通は次のような工程で進めると思いますよ。 1. 要件定義 要件定義書(要求仕様書) ↓ 2. 外部設計 外部仕様書 ↓ 3. 内部設計 内部仕様書 ↓ 4. プログラム設計 プログラム設計書 ↓ 5. テスト テスト仕様書(テストケース) 基本仕様書とゆうのは要求仕様書の事でしょうか? または、要求仕様書を受けて作った基本構成図のことだと思いますが、そこから試験仕様書を作るのは無理でしょう。 外部仕様書から作るのが普通ですよ。だから分からないんじゃないでしょうか?
- aokii
- ベストアンサー率23% (5210/22062)
分からないことが分からない時は諦めます。 ちなみに、基本設計書の通りに動くかどうかをテストすれば、単体テストの仕様書はできあがりますが、基本設計書の通りに動くかどうかをテストする方法が解らないのは、人の作った文書は理解しずらいからです。諦めずに、ゆっくり2週間ほど読んでも解らない場合は、書いた人の文書が良くない可能性が高いです。