質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.61%

  • データ構造

    46questions

    データ構造とは、データの集まりをコンピュータの中で効果的に扱うために、一定の形式に系統立てて格納する形式を指します。(配列/連想配列/木構造など)

仕様書がないシステムの仕様を把握する方法

解決済

回答 9

投稿

  • 評価
  • クリップ 11
  • VIEW 8,485

tmak1000

score 24

仕様書が存在していないプロジェクトに参加して、システムの仕様を把握するのに苦労しています。

実際の現場に入って2か月目の新人です。

特に、テストデータを用意する場合に、どのようにすれば、正しくデータを構成できるのかいつも悩んでいます。

ソースをすべて読んで、処理を追うことでしか仕様の把握をすることはできないのでしょうか。

システム全体の仕様を仕様書なしで把握する効率的な方法があれば、教えていただきたいと思います。

よろしくお願いいたします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 9

checkベストアンサー

+9

既にほかの方からの回答にもある通り
「今動いているものが正」として考えていいと思います。

 私が実際に設計書が存在しない(あるいは大人の事情で公開できない)PJに参画した時には、
↓のような施策を実施していました。

1.今回のテストシナリオではA機能とB機能を使用する
2.A機能とB機能をテストシナリオに基づいた動作検証し、現状の動作を整理する。
3.(可能であれば)2.の動作をもとにテストデータ作成する。
4.業務有識者に、2.3.の結果を持参し、現在のアプリVer.とデータでテスト続行していいかどうかの確認実施。
5.4.で課題発覚した場合、アプリ修正依頼ORデータ修正ORテストシナリオ修正し、4.に戻る
6.テスト消化

 
ソースをすべて読んで、処理を追うことでしか仕様の把握をすることはできないのでしょうか。 
 ソース解析は非常に時間がかかります。
 業務全体をある程度把握した上で、発生した障害の検証をする場合には有用でしょうが、まずは業務理解が先決と考えます。
 
システム全体の仕様を仕様書なしで把握する効率的な方法があれば、教えていただきたいと思います。 
 業務フロー、処理フローをみながら、とにかくアプリをたたきましょう。
 テスト消化に追われてその暇もないということであれば、とにかくテストをこなしてアプリと仲良くなりましょう。
 そのうち、「なんでここはこうなってるんだっけ?」という部分が出てきますので、業務有識者に確認しましょう。
 そうすればいつのまにか全体の動きがわかってきます。

業務有識者は往々にして多忙であることが多く、聞くタイミングも少ないでしょうから
タイミングを逸しないことと、簡潔に質問できる準備をしておくといいと思います。

頑張ってください。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/18 18:47

    ARADDIOさんがPJに参画した時のテスト消化フローが凄く参考になりました。

    また、今までアプリを動作させてフローを考える割合が、ソースを読むよりも少なかったとも思います。可能な限りアプリをたたいて、業務への疑問を整理してみます。

    キャンセル

+3

・テストデータについて
残念ながら仕様書を基にテストデータを作るため、正しいテストデータなんて作りようがありません。
また、ソースコードを基にテストデータを、作る事もできません。なぜなら目の前にあるソースコードが正しいかどうかは仕様書に基づくからです、仕様書を完全再現したソースコードがあるなら、そもそも仕様書がないなんて事はあり得ません。

・仕様の効率的理解について
結局のところ、システムにはユーザーがいます。ユーザーの意図が仕様になります。
ユーザーの正しい使い方を正常動作として把握し、あとは自身で例外的な使用方法について検証するしかないと思います。疑問に思ったところを一覧にして、先輩等に確認するといいかもしれないですね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

経験2ヶ月という事を考慮すれば、
ソースからフローチャート起こしてみるのが最善策。
  • 一つ一つ処理を把握しながら読む
  • 頭にあるものを紙に書く
という事がポイント。
そうすると、データの流れを把握しやすくなって、
処理を完了迄持っていくのに、どういうデータを準備すればよいか見えてくるはずです。

あと、今実装されているものが「正しい仕様」
割りきってしまって良いと思いますよ。
だいたい仕様書のないプロジェクト(仕様書がっても)は、
現実装を正規の仕様としていますので。

ストレスを溜めすぎないよう頑張ってください。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/18 18:50

    フローチャートを描いてみたら、データの流れが把握しやすくなりましたありがとうございます。

    キャンセル

+1

可能な限り現場を好意的に捉えれば、TDD開発してて要件定義のような文書しかないだけかも
その場合テストコードが存在すると思いますので既に必要なデータが準備されているかもしれませんし、無くてもそこやバージョン管理のログから必要なものが推し量れるかもしれません。

もしウォーターフォール型で仕様書が無いとなると、システムの規模にもよりますが絶望的かも…
先輩に確認しながら時間を掛けて吸収していくしかないんじゃないでしょうか?
仮に「そう有るべき」から発見した不具合を指摘したとしても、作った人個々にPMと合意したローカルルールがあったりしたら意見対立待ったなし(それでも仕事なので報告と確認はしなきゃいけないんですが)ですし、新人だときついですね…。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

非常に厄介な状況ですね…

既に皆様がご回答くださっている通りなのですが、誤解を恐れずにざっくりとした表現の仕方をすると
  • 「仕様書」は、システムのあるべき姿(何が正しいか)についてクライアントと合意した内容=「定規」
  • 「テスト」とは、システムの実際の挙動が「定規」からズレていないことを確かめる作業
なので、「定規」である「仕様書」がなければ、そもそもテストをする意味がなくなってしまう訳です。

とはいえプロジェクトが発足した以上、何としてでもタスクを遂行してゆく必要があるので…
(言葉で書くとゴチャゴチャして分かりにくいですが)

まず、以下のような点について再確認してください。
  • プロジェクトの目的は何ですか?「品質向上」それとも「機能追加/改善」ですか?
  • テストのどの工程のデータ作りを想定していますか?「単体/連結/総合」

仕様書がない以上、「現在稼働しているシステム」が正解(仕様書に記載されているはずの内容に最も近い)とみなして作業を進める、つまり『現新比較』の結果を拠り所とするしかありません。

対象のシステムがどのようなものか分からないと具体的な回答は無理なので、以下はWebベースの業務システムを想定して記載します。

もし「品質向上」(=潜在的なバグの洗い出し)が目的なのであれば、現新比較しても無意味です。
その場合には、もう一度、業務フローやシステムの入力データとなる帳票類を分析して、十分なバリエーションのテストデータを作成するとともに、それらのデータに対して期待される結果が得られるかを、エンドユーザに確認してもらうしかありません。

「機能追加/改善」が目的なら、ソースの「分岐」部分に着目し、実装時点で境界値とみなされていた値を洗い出します。
そして境界値と考えられる値を中心に、業務上の要件も考慮して十分な量のテストデータを作成し、追加/修正対象の機能以外については変更のないことを現新比較によって確かめながら、手を加える部分の新しい仕様に従って細かいテストを実施します。

うまくまとめられませんでそたが…少しでもご参考になれば幸いです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

そのような仕様書のない現場というの非常に多いです。

納品してから仕様書を書くなんてこともあります。

さて、把握する方法ですが、ご自分の受け持っている範囲内の分岐を把握し、これは何をする処理なのかを考えます。
次に、明らかにおかしい値と絶対通る値でテストします。
不安でしたら全パターンテストをお勧めします

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/18 12:58

    ありがとうございます。

    実際に動かす際に
     ・分岐の把握
     ・明らかにおかしい値と絶対通る値でテスト
     ・可能ならば全パターンテスト 
    を重視して進めて行きます。

    キャンセル

+1

システムの規模にもよるかもしれませんが、
2か月の新人でそういう現場とは厳しいですね。
先輩や上司の言葉(専門用語など)がすでにわからなかったりな状況だったりしますか?
しかし応援したくなっちゃいますね。

みなさんが回答されていることの繰り返しになるかもしれませんが、
システム全体仕様を手っ取り早く把握するには、いろんなパターンで「実際に動かす」です。
ただ細かい動作はソースを見るしかないと思います。
あと技術者としては微妙ですが「詳しい人に教えてもらう」が最強です。

ご参考までに「教えてもらう」の立ち回りを書いておきます。
1.わからないことや確認したいことを一覧にする
一般的に言うとQA一覧でしょうか。
有識者に毎回聞くとそのたびに相手の作業が中断してしまうためです。

2.自分なりの理解をMy資料にする
処理の概要から詳細まで自分なりに理解したことを資料にします。
何を聞けばよいのかがわかってくることもあります。

3.認識合わせと疑問点の解消
有識者に時間を取ってもらいましょう。
作成したMy資料とわからない点の一覧を使って打合せをします。
目的は以下です。
・自分の理解で正しいかを確認する
・現時点で出てきた疑問点を解消する。

おそらく最終的にはあなたに仕様書を作ってもらいたいのではないかな?と思います。
頑張ってください。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/18 12:57

    回答ありがとうございます。
     ・実際に動かす。
     ・QA一覧作成、My資料を作成して詳しい人に疑問点を聞く。
     ・最終的に仕様書作成を目的としてみる。
    を実践してみたいと思います。



     

    キャンセル

0

ソースを読んで理解をしてテストをするのは正直、お勧めできません。
ソースよりも任されているテスト作業範囲の業務理解と業務データの流れ、データのCRUDについて知るのが優先だと思います。
これは業務サイドや現場の先輩に少しづつでも時間を取ってもらい教えてもらうべきだと思いますし、教えるべきとも思います。
誤っているソースをベースにテストケースを作ってもテストにはなりません。
ケアレスミスだけでなく条件すらソースから漏れている場合もあります。
結果としてテストも二度手間になりますし品質面でも問題がある進め方だと感じます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

まず、対象とするシステムにUIがあるのなら使いまくること。対象が何者なのかもわからずコードを見ても無駄。かならず間違う。
もし、ネットワーク関係の機器みたいにシステム仕様書がなければ、どういうことをやっているのか調査する。操作マニュアルとかぐらいはあるでしょう。なければつかっている人に聞く。
システムをBlackBoxとしてIN-OUTを把握していくのです。
イメージとして、OSSをHACKする場合も、何のOSSか把握してからコードを見ますが、それと同じです。
そう!システムをHACKするのです。
その後、ラッキーにもコードがあれば、動かしたときのことを思い出してコードを見ていきます。
最悪の場合、ネットワークの口から通信内容を把握して、動作を類推して、制御プログラムを作ることも可能です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.61%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

  • 解決済

    Fatal error: Possible integer overflow

    PHP構文の記述において整数入力をしていたところ、Fatal errorが出てしまいました。 システムエラー内容は「Possible integer overflow」と書い

  • 解決済

    Elasticsearchのriversプラグインとは?

    Elasticsearchでriversといういろいろなプラグイン群が ありますが、これらは何なのでしょうか? 良ければ教えて下さい。

  • 解決済

    デュアルブートについて

    ubuntuとwindows10のデュアルブートしました。 でも、PC起動時にubuntuの背景紫色(GRUB?)が出てきます。 自分が思っていたのはwindowsのboot画

  • 受付中

    ECサイトの設定内容はどうやってコピーできますか?

    前提・実現したいこと ローカルにあるECサイトのテスト環境をMacでつくっていて、サイト自体はコピーできましたが設定内容はコピーできていません。おそらくデータベースをコピーす

  • 解決済

    handsontableでセル内の計算を行いたい

    前提・実現したいこと handsontableを使用して行の計算を行いたい。 「ここ」と「ココ」の計算結果を「実績」に入れたいんです。 columnSummaryの書き方がイ

  • 解決済

    Node.jsのSocketioのListenとexpressのListenの違い

    Node.jsでは SocketioのListenと expressのListen が有りますが、それぞれどう違うのでしょうか? セキュリティについて検証したいのですが、ど

  • 受付中

    DBMSの機能について

    この問題ではfが正解なのですが、なぜなのかわかりません。 教えてください。

  • 解決済

    Pythonとjsのプログラムの通信について

    前提・実現したいこと 下記Githubに掲載されているclmtrackrについて,example/emotion_detection.htmlを実行した時に画面表示されるhappy

同じタグがついた質問を見る

  • データ構造

    46questions

    データ構造とは、データの集まりをコンピュータの中で効果的に扱うために、一定の形式に系統立てて格納する形式を指します。(配列/連想配列/木構造など)