匿名質問者回答ポイントなし

テスターは一般的にはあまりいないのでしょうか？

少し前からテスターをしています。
今の環境しか経験がなく一般的なことがよくわからないので聞きたいのですが
・テスターはチームまたは会社に１人はいるものなのでしょうか？(検索しても古い記事が多いので)
・テスターがいない場合は、プログラマがテストをしてそれがリリースになるということでしょうか？それかテスト駆動型開発はブラックボックステストは必要ないのでしょうか？

正直テスターの仕事はあまり好きではなく、なくせるものならなくしたいです。

ログインして回答する

ベストアンサー

匿名回答3号2015/10/23 16:02:27
>テスターは一般的にはあまりいないのでしょうか？

たくさんいますよ。
ソフトウェアの開発規模が小さかったり昔はプログラマがテストも行っていましたが
だんだんソフト開発の規模が大きくなり、開発と評価を分業で行うようになっています。
その場合、評価はソフトウェア開発の中から評価チームが分かれる場合や、品質保証で評価チームを持つ場合や
評価を社外に外注したり、第三者検証を委託したりとさまざまです。
某Ｓ社の携帯開発に参加した時は１フロア全体がテストチームでテスターの人だけで５０人以上いました。
ソフトウェアテストを専門に行う会社もありますし、テストを専門で行うテスト技術者の方もおられます。

少し前からテスターをしています。
今の環境しか経験がなく一般的なことがよくわからないので聞きたいのですが
>・テスターはチームまたは会社に１人はいるものなのでしょうか？(検索しても古い記事が多いので)

すごく小規模な開発案件（プログラマが１人～数名）であればプログラマがテストも手分けして行うということもありますが、
ある程度の規模になると専任でテストチームが作られます。

>・テスターがいない場合は、プログラマがテストをしてそれがリリースになるということでしょうか？

テストと言っても大きくわけてデバッグと評価があると思います。
開発者自身が動作を確認してバグをつぶしていくのがデバッグで、仕様を満たすよう動作を確認した後
バージョンをつけ社内リリースします。
そのバージョンに対しテストケースを用いてテストチームがテストを行うのが評価になります。評価を行い仕様通りに動くことを確認してエビデンス（評価結果）を記録して社外へのリリースとなります。
評価結果は最終的には検査成績書として成果物になり客先に納品されます。

仕様書を元に開発者は単体検査仕様書、結合試験仕様書、総合試験仕様書、・・・を作成し動作の確認を行った後
ソフトをリリースし、
評価チームは評価チームで仕様書を元にテスト観点からテストケースを作成し仕様通り動いているか評価を行います。
開発者と評価チームでやっていることは同じに見えますが、役割は違います。
（評価チームによってはあまりに不具合が多い場合は「評価に値せず」ということで評価をやめることもあります。
バグ出しと評価は違うのです）

＞正直テスターの仕事はあまり好きではなく、なくせるものならなくしたいです。

無くならないと思いますし、開発とはまた違う色々なスキルが必要になるので
勉強してみてはどうでしょうか。
例えば、以下で知らない言葉があればネットで検索してみて下さい。
- 基本の技法
同値分割法
境界値テスト
異常値・特異値分析
ドメイン分析テスト
機能リストに基づく単機能確認テスト
- White Box テスト
制御パステスト
制御フローテスト
データフローテスト
カバレッジ
モデルチェッキング
- 組合せテスト（デシジョンテーブル系）
デシジョンテーブル
原因結果グラフ
CFD技法(Cause Flow Diagram)
- 組合せテスト（直交表・AllPair系）
直交表
HAYST法
AllPair法
k-way
- 状態遷移系
状態遷移テスト
タイミングテスト
- ユーザ視点のテスト
ユースケーステスト
例外ユースケース
シナリオ
業務フロー
リスクベース
サンプリングテスト
ランダムテスト
探針テスト
ユーザストーリーテスト
- セキュリティテスト
欠陥仮説法
ファズテスト
- テスターの勘と経験
探索的テスト
エラー推測
- 統計的手法
信頼度成長曲線
- その他
スモークテスト
スラムダンクテスト
Wモデル
アドホックテスト
モンキーテスト
全数テスト

>それかテスト駆動型開発はブラックボックステストは必要ないのでしょうか？

テスト駆動型開発は開発手法であって、デバッグの中では有効ですが、評価は必要です。そのためテスト駆動開発であってもブラックボックステストは（評価として）必要になります。
テスト駆動型開発の場合、ソースを組んだ後、テストケースを組むより、テストケースを組んだ後、それがパスするようにコードを組んだほうがプログラマのモチベーションが上がるというのが主な利点です。
他に、最初に仕様に基づきテストケースを組むときに仕様レベルのバグに気が付くとか、設計段階前での構造上の問題に早く気が付くとか、常にテストケースが存在するためリファクタリングが行いやすいとか、ソース変更に対するデグレが見つかりやすいとか、CIでテスト自動化できるとか色々利点はありますが、あくまでもソフト開発上の利点です。

製品レベルでの評価は仕様を満たしてTDDなどのデバッグが終わってバージョンがついて社内リリースされてから始まります。
テスト駆動型開発だから評価は不要ということはないですね。TDDは内部仕様に基づいて行うのでホワイトボックステストにあたりますが、仕様から導かれるブラックボックステストも当然必要です。

仕様の勘違い・解釈違いというのは良くある話で、開発者以外の人が製品仕様を元に検査を行うブラックボックステストはとても有効です。
開発者が仕様を勘違いしている場合、開発者が作ったテストケースも勘違いした仕様で作るためバグが見つからないわけです。
カバレッジや信頼度成長曲線や不具合の対応状況も最終的な客先リリースの判断には必要となります。

その他の回答

匿名回答1号2015/10/21 04:51:52

一般的には
・テスターは開発プロセスにもよるが，必要な時期と必要でない時期に大きく分かれる．このため，会社によっていたりいなかったり，常勤だったり非常勤だったりは分かれる
(・開発者自身によるテストは欠陥を見逃しである
・「テスト駆動開発」はプログラミングをスムーズに進めるためにうまくいく基準を用意するもので，バグを見つけ出すものではない)私の理解が甘いままで回答してしまいました．下の議論には関係ないため撤回します．
ということがいえます．

あくまで私の経験ですが，臨時でテスターをやったことがあります．
その時は途中からバグも見つからなくなってきて，他の仕事も兼業し始めたのでリリース前に抜け，「大したことできなかったな…」と思いましたが，そこそこのヒット商品になりました．
ところが，次の製品のリリースの際に臨時のテスターが見つからず，私も正社員になっていたので手伝えずという感じで開発者のテストのみでリリースしたところ，重大な不具合が見つかってリコールになってしまいました．
この経験で，テスターがそこまで貢献していないように見えて必要だということを思い知りました．

また，最終的にテスターによってテストされるということを考慮すると，製品を作る際や企画するさいにも役立つと思います．
もちろん，ずっとテスターをやるというのはなかなか難しいのですが，少なくともその経験は有意義だと私は思います．
- 4件のコメントを見る
- 匿名回答2号 2015/10/21 19:55:47
  
  ＞・開発者自身によるテストは欠陥を見逃しである
  ＞・「テスト駆動開発」はプログラミングをスムーズに進めるためにうまくいく基準を用意するもので，バグを見つけ出すものではない
  
  おや？分かってないままで書いてない？
  テスト駆動開発のどこに、「プログラミングをスムーズに進めるためにうまくいく基準を用意するもの」なんてことが書かれていましたか？
- 匿名回答1号 2015/10/21 22:27:52
  
  では蛇足でしたので当該部分は撤回いたします．
- 匿名回答1号 2015/10/21 22:40:59
  
  もっとも，あなた自身がこの記述のどこが具体的な問題かを述べていない以上，実のある訂正にはなっていませんが．「テスト駆動開発が」「テスターの仕事とどう違うか」ということを，簡潔に教条的でない形で説明することはできますか？
- 匿名回答1号 2015/10/21 23:55:51
  
  一応，削除されたコメントも見てしまい，その意見そのものには同意していますので，改めて上記の質問の答えをお待ちしております．もともとの質問者の方にも役立つと思います．

匿名回答2号2015/10/21 06:36:59

日本における「テスター」なんて、たとえばGoogleにおける「プロのテスト技術者」とは全くの別物。平たく言えば出来の悪い「紛い物」なことがほとんど。

テストから見えてくるグーグルのソフトウェア開発

だから日本は遅れてるんだとは言いたくはないけどね。
テストと言っても様々なんだけど、日本企業は色んな意味で40年ほど遅れてるから。

パーフェクトソフトウエア

作者: ジェラルド M ワインバーグ
出版社/メーカー: 日経BP社
発売日: 2013/08/28
メディア: Kindle版
この商品を含むブログ (6件) を見る

http://d.hatena.ne.jp/JavaBlack/20150926/p1

1件のコメントを見る
匿名回答3号 2015/10/23 21:39:14

ろくな職場で働いていなかったんですね。

匿名回答3号2015/10/23 15:19:19

http://jasst.jp/
JaSSTソフトウェアテストシンポジウム
各地で開催されているので、近くであればいってみるといいですよ。
http://wacate.jp/
若手エンジニア向けワークショップWACATE　というテストの勉強会もあるので参加可能であれば参加してみると勉強になると思います。

JSTQB認定テスト技術者資格
http://jstqb.jp/
という世界的な資格もあるのでとってみてはどうでしょうか。勉強用の資料もサイトで交換されているので参考になると思います。（用語集見るだけでも役に立つかも知れません。用語など社内の方言が多いですから、他社の人と話す時困ることがあります）
JSTQB 運営委員会委員長西康晴先生のTwitterをフォローするだけで色々参考になるかも知れません。
https://twitter.com/yasuharunishi

匿名回答4号2015/10/23 20:15:33

>テスターは一般的にはあまりいないのでしょうか？
>今の環境しか経験がなく一般的なことがよくわからないので聞きたいのですが
>テスターはチームまたは会社に１人はいるものなのでしょうか？
｢一般的な状況｣はなくて、企業や業務内容でも全く事情が変わると思います。
金融関係や宇宙開発などでシステムを新規に開発する場合では、そのテスターになり得る実力を発揮出来る人物やチームをテスターに任じるでしょう。しかし、小修正などの場合ならばそのプロジェクト開始時にテスト仕様も決まるでしょうから、専任のテスターを任じるということはないでしょう。
基本のシステムの原型が一応稼働していて、それをベースにカスタマイズする程度の場合も、テスターを別人に充てることもあまりないでしょう。そのような業務を主とする企業では、専任のテスターを養成し組織的に継続させるのは難しいから、開発チーム内で何らかの対策を講じるのが普通に行われる方法だと思います。
下のような開発をする場合には、机上で点検検討するだけではとても実用にはならないから、実機を色々の場面で繰り返しテストしてデータを収集解析するテスト専門チームは編成されていると思います。
http://www.mitsubishielectric.co.jp/news/2015/1014-b.html?cid=rss

>テスターがいない場合は、プログラマがテストをしてそれがリリースになるということでしょうか？それかテスト駆動型開発はブラックボックステストは必要ないのでしょうか？
開発仕様そのものの不備や欠落を問題にしないのであれば、TDDでしっかりやるとほとんどの場合うまくいくでしょう。テストチームを作り、専任テスターを任命してやらせても、どの期間でどれだけ成果が出せるのかが危ぶまれるのなら、実務上、テスターを配するのは妥当なやり方ではないでしょう。　そのシステムである範囲では問題ないと認定できればリリースして問題ないでしょう。　どのような開発体制や検証方法をとっているかに関係なくて、｢実務の期間、コスト｣と｢発生するリスク｣の総合判断でしょう。
広く販売する一般製品に組み込むものでも欠陥は皆無ではないです。顧客毎のシステムでは、問題が発生し対策が見つかれば、放置した場合のリスクとの兼ね合いを考えて、改修するという方式で十分であるケースが多いでしょう。　その程度にまでの完成度が開発チーム内で確認出来るように開発方法やリリース基準を定めている企業が多いと思います。

>正直テスターの仕事はあまり好きではなく、なくせるものならなくしたいです。
好きかどうかで仕事をされては、企業として困ります。どうも好きになれないのでほどほどのテストをする担当者にテストを任せたのでは、企業としてテストをさせる意味はないです。
～～～～～～～～～～
ブラックボックステスト＝テスト対象の｢テスト仕様｣に基づいて、テスト対象の｢内部の構造を見知らない｣状態で、｢中の見えない箱(ブラックボックス)｣として、ハードや全体は問題外にして、｢入力を各様に変えてテスト対象がどう出力を返すか｣をチェックする作業ばかりやっていると、疲労するのかもしれません。好きになれないのもわかります。
ただ技術者に開発や設計をしてもらう場合、実力のある人物a、何とかやれるかなぁレベルの人物b、まだとても一部さえも任せることができない人物cがいると、リーダや分担責任者にはaを配し、チーム内メンバーとしてbを配し、cにはコード書きやデバッグ、システムテストの作業をやらせるということはあるでしょう。cがそうした作業をする中でも、自分の時間を使って自分が独自に勉強し、コードが読める・コードを書ける・仕様を展開できるのようになったり、過去にチーム内で蓄積されているモジュールやらシステムの特徴・長短をある程度理解してくると、bのような仕事もやらせてもらえる可能性は出て来ると思います。　知識や実力がないのを｢指導がないから、教えてもらってないから、勉強時間がなくて、そうした機会がないから｣と云っていると、設計や開発の仕事をやらせてもらえる可能性はとても低くなると思います。
工業製品の抜き取り検査や製品の安全性試験、電磁波試験、温度試験、強度試験、耐久性試験などでも、とても大切な仕事です。　多くのヒトはそこに意義を見出し、真剣に誇りをもって取り組んでいます。　どうにも好きになれないのであれば、異動を申し出るか、転職するしかないでしょう。　その場合、本人の持っている実力や就業・勤務面から見た特性で、異動の先、転職の先は判断しようとすると思います。

匿名回答5号2015/10/24 14:00:35

【質問への回答】

テスターは一般的にはあまりいないのでしょうか？
⇒いるところには、たくさんいますよ。

・テスターはチームまたは会社に１人はいるものなのでしょうか？(検索しても古い記事が多いので)
⇒状況によりいる場合もいない場合もあります。一人が兼任している場合も散見されます。
　理想的にはテスターがいた方が良いに決まっています。

・テスターがいない場合は、プログラマがテストをしてそれがリリースになるということでしょうか？
⇒そうなってしまいますが、それは絶対に避けたい事ですね。

それかテスト駆動型開発はブラックボックステストは必要ないのでしょうか？
⇒ブラックボックステストは、しないよりはした方が良いです。

正直テスターの仕事はあまり好きではなく、なくせるものならなくしたいです。
⇒匿名質問者さんが「評価より設計に携わりたい」と希望を出してみたら良いと思いますよ。
　評価も設計も、経験してみないと分からない事がたくさんありますからね。
　但し、世の中からテスターの仕事を無くすのは「NG判定」です。製品の品質が下がります。

【私の意見】

理想的な開発組織は、設計チームと評価チームが独立しています。

設計チームは、要求を製品に実装し、設計通りに動くかどうかテストします。
評価チームは、要求のテストを作成して、要求通りに動くかどうかテストします。

つまり、本来評価チームは、どのように設計されたか全く分からない製品をテストするべきなのです。
設計と評価を分ける一番の目的は「設計者がテストしても見つからないバグを、設計に携わっていない第三者がテストを行う事で見つける事」です。だからテスターはとても大事な存在なんです。

匿名質問者
2015/10/24 19:52:14

私がやっているのはデバッグ＋テストで、デバッグが嫌いなのだとわかりました。

開発者がデバッグをせずにテストに回すので何度も修正依頼を出さねばならすそのたびに１からテストし直すことに疲弊していました。

また、自分が開発してテスターを通さずリリースした案件は細かいバグしか出なかったのでやろうと思えば(＋テスト駆動型開発にすれば)テスターはいなくていいのかと思っていましたが、テスターは必要というのはみなさん一致するみたいですね。

テスト自体は嫌いではないので勉強してみようと思います。

・テスターの仕事とは本来どのようなものなのか

・どうしたら開発者がデバッグしてくれるのか

・今の環境は、業務プロセス？が古い？変？なようなのでどうしたら改善できるのか

勉強して考えたいと思います。

ご回答ありがとうございました。

その他の回答を読む

この質問へのコメント

匿名回答3号2015/10/24 21:56:35

>・どうしたら開発者がデバッグしてくれるのか
>・今の環境は、業務プロセス？が古い？変？なようなのでどうしたら改善できるのか

本来のテスターの仕事でなく、デバッグの手伝い（いわゆるデバッガー）もされているようですね。
BTS(バグトラッキングシステム）やバグ管理票を使ってバグを開発者に報告していると思いますが、可能であれば職場で提案して、「本来ならこのバグはどのテストで見つからないといけないか」という欄を設けると良いと思います。
http://www.itmedia.co.jp/im/articles/1111/07/news202.html

リンク先はW型開発ですが、単純なウォーターフォール型V字型開発の例でいうと
[①要件定義]→[②外部設計]→[③内部設計]－－－－＋
　　　　↓　　　　　　↓　　　　　　↓　　　　　｜
[⑥受入テスト]←[⑤結合テスト]←[④単体テスト]←＋

上記のような形で開発とテストが対応します。
通常、①～⑤までが開発（①：SE　②～⑤：プログラマ　（④～⑤プログラマ or ソフトチームテスター）)
⑥が評価チームになると思います。
本来⑥で出てはいけない④の単体テストで見つかるレベルのバグがあったとしたら、開発チームが単体テストをさぼってるとしか言いようがないですよね。
⑥の受入れテストレベルで、④の単体テストや⑤の結合テストで見つかるべきバグがでていることを
バグ管理票を集計してデータとして見える化して社内に問題提議してみてはどうでしょうか。
そうすれば開発者のデバッグも進むでしょう。
社内的にそこらへんの役割分担（責任分担）が明確化されていないように見えます。
匿名回答3号2015/10/24 22:07:59

あるいは

[①要件定義]→[②外部設計]→[③内部設計]－－－－＋
　　　　↓　　　　　　↓　　　　　　↓　　　　　｜
[⑥受入テスト]←－－－－－－－－－－－－－－－－＋

となっていたり

[①要件定義]→(コーディング)－－－－－ー－－－－＋
　　　　↓　　　　　　　　　　　　　　　　　　　｜
[⑥受入テスト]←－－－－－－－－－－－－－－－－＋

となっているのかも知れませんね。テストを行うためには仕様が必要（単体テストを行うためには内部設計、結合テストを行うためには外部設計が必要）ですから。
上記のようなパターンは受入れテストまでいかないとバグが見つからず、しかもその修正がデグレを産みさらに受入れテストで別なバグが見つかり・・・とリグレッションテスト（回帰テスト）を延々と繰り返すデスマーチへ至る道です。
匿名回答3号2015/10/24 22:33:36

まあ、「こういうんじゃいけない」「せめて単体テストはやらないと」「でもコード書いた後、自分の書いたものが正しいか確認するコード書くなんて面倒」ということから
「じゃあ、先にテストケース書いて、それに合うようにコード書いたら、テストケース書くのもコーディング見たいで楽だ」「テストケースが最初全部赤なのが段々青に変わるのでテストやっててもモチベーションがあがる」
というので生まれたのが「テスト駆動開発(TDD)」なんですけどね。
元々開発者はテストが嫌いなんです。面倒くさいから。

>また、自分が開発してテスターを通さずリリースした案件は細かいバグしか出なかったのでやろうと思えば(＋テスト駆動型開発にすれば)テスターはいなくていいのかと思っていましたが、

TDDで行えば最低限単体テストは済んでいますからソフトの品質は（単体テストも行わない場合に比べて）各段に良くなります。
また、全てのコードがテストされるので、一部の修正が他のバグを引き起こすデグレ（デグレード）を防ぐことができます。一か所づつ単体テストを行った場合は最初はうまく動いていても後の方の修正で実は最初の頃の単体テストが影響を受けて動かなくなっているということもあります。

社内的に開発者へTDDの導入を進めるのも良いかも知れませんね。
匿名質問者2015/10/31 01:23:19

匿名回答３号さん
コメントありがとうございます。とてもわかりやすく参考になります。
>「本来ならこのバグはどのテストで見つからないといけないか」という欄を設ける
>バグ管理票を集計してデータとして見える化して社内に問題提議してみてはどうでしょうか。
これすぐにでもやり始めます！
過去のドキュメントが少なく仕様は開発者に聞かないと分からない状況なので、開発者の立場が強くて、あんまり強く言えないんですが数字出せばその上の人も説得できそうです。
デグレには本当に悩まされてるので、TDD導入検討するために勉強し始めました。
気持よく仕事出来るようにいろいろ勉強して改善していきたいと思います。
本当に為になるアドバイスありがとうございました。うちの会社に来て相談のっていただきたいくらいです…。

テスターは一般的にはあまりいないのでしょうか？

ベストアンサー

匿名回答3号2015/10/23 16:02:27

その他の回答