Q&A
https://testing.googleblog.com/2010/12/test-sizes.html
このような考え方もあります。
単体テストと結合テストを区別するのではなく、取り扱うデータによって大中小と分けるというものです。
単体だシステムだと言わず、自動化できるテストは自動化したらいいと思いますし、できないところは目視すればいいと思います。
なるべく自動化できるところを増やしていくのが良いでしょうね。
よくテストケースをエクセルに書いて、スクリーンショットのエビデンスを貼るという作業に対し「時代遅れだ」という主張を目にします。
では、現代のソフトウェア開発ではどのようにテストが行われているのでしょうか。
テストは単体テスト→結合テスト→システムテストの順で行われるかと思います。
「テストコードを書くべき」との主張も見かけますが、テストコードがかけるのは関数ごとだと考えており、それだと結合テスト、システムテストに対して書くことはできないのでは？と考えています。
現代のソフトウェア開発におけるスタンダードなテストの手法を教えていただきたいです。
追記
打った文章がなぜかおかしくなっているので編集。
回答2件
0
ベストアンサー
現場やプロジェクト次第ではないでしょうか。
テストによって何を担保したいかはプロジェクト次第なので、それによって成果物が決まります。
時代が決めるわけではありません。
投稿2021/02/09 07:11
総合スコア80875
回答ありがとうございます。
それはそうなのですが、エクセルテストケース作成→エビデンススクショ貼り付け以外にどのようなテストの進め方があるのか知りたかったのです。
同意します。
まあ、1開発者の立場でテスト自動化をするしないを決めれないですね。
_begさんがPM等の上位の立場になればまた違ってきますが。
これだけだと申し訳ないので、参考になりそうなページを貼っておきます。
https://thinkit.co.jp/article/14064
https://qiita.com/yutachaos/items/857472c7d3c65d3cf316
>どのようなテストの進め方があるのか知りたかったのです。
回答をよく読んでほしいのですが、手法から考えるべきではないです。
「そのテストで何を担保したいか」によって「どういうテスト結果を成果物とするか」が決まります。
「どんなものがあるか」だけなら調べれば出てくる範囲ではないでしょうか。むしろ自身で考えてみても良いのでは。
既に言及されてますが、あなたがPMの立場なら、どういうテスト結果を成果物としたら、客先に納められますか？
検索して出てこないのは業務レベルの話だからだと推察されます。内々で使ってる仕組みは外には出ませんね。
プロジェクトによって違うので、具体的な情報はネットでは得られないでしょうし。
開発手法によってもきっと変わってきますよ。
ウォータフォールかアジャイルかテスト駆動etc.
> kainaさん
参考記事をありがとうございます。
> m.ts10806さん
確かにそうですね。地道に考えてみます。銀の弾丸のようなものを考えていたのが間違いだったのだと思います。
その言葉を恥ずかしながら知らなかったのですが、探してみるとこんな記事もあるくらいで。
https://ja.m.wikipedia.org/wiki/%E9%8A%80%E3%81%AE%E5%BC%BE%E3%81%AA%E3%81%A9%E3%81%AA%E3%81%84
そうなのですが、「時代遅れだ！」と言われ、「一体どんな素晴らしい方法があるんだろう」と期待してしまいましたね。ありがとうございました。
むしろその言った人に「じゃあそちらではどんな方法を用いてますか」と聞くのが吉ですね。
結局は要件を満たしていることを担保できる成果物になっているかどうかが本質なので、期待してるほどの内容にはならないかなと。
手動部分を減らすとか、あくまで「単体」として後のテストの比重を大きくするとか、プロジェクトによって工夫している部分になるかと思います。
とても参考になりました。ありがとうございます。
プロジェクトにあったテスト方法を模索してみます。
0
ソフトウェアのバグはゼロになることはありません。ある程度減ってきたら良しとするしかないのです。
ソフトウェアのテストの自動化、テストプログラムの自動生成などで新しい技術は出てきています。しかし、そのような技術は全てソフトウェアです。従って、その結果を無条件で信頼することはできません。なぜなら自動化技術そのものにもバグがあるからです。
ソフトウェア開発といっても、種類は非常に多いです。ソフトウェアスタックの下から考えれば、ファームウェア、デバイスドライバなどのハード系、OS、コンパイラなどの基本ソフト、多くの人が使う商用アプリケーション、注文されて作る顧客アプリは造りが全く違います。また、組み込みソフトはまた違います。開発手法やテスト手法の点ではOSSもまた違います。
テストの種類とテストプログラムの作成／収集とテスト結果の管理は別物ですので、それぞれ説明します。
テストの種類は単体テスト、モジュールテスト、部品テスト、統合テストなどですが、それぞれの呼び方は、ソフト開発の種類によってさまざまです。また、ソフトのバージョンアップの場合にはリグレッションテストが必須です。
テストプログラム(TP)を誰が設計し、どうやって作成したり収集したりするかはかなり変化してきました。
昔は、ソフトウェア開発部門がTPを作成していましたが、その後開発部門が作成した仕様書を元にテスト部門がTPを作成する手法が導入されました。また、出荷したソフトが利用者先で発生した障害を起こすプログラムを収集することも始まりました。かなり前から、仕様書に基づいてTPを自動生成するTPジェネレータも使われています。
注文アプリの場合には、顧客用件と契約内容に応じてテスト仕様書を作成してテストします。
テスト結果の評価と管理は今でも難しい問題です。
テストの結果NGが出た場合、それがテスト対象プログラムの障害なのか、それともテストプログラムに間違いがあるためなのかが問題になることが起きるからです。長い間使われてきたTP(枯れたTP)の場合はこの問題は起きにくいです。
以下の三種類の障害(バグ)は原因を突き止めたり対策をたてるのが非常に難しいですし、自動化もあまり役に立ちません。こういうのに遭遇したときは、経験のある人間に頼るしかないです。
- 再現性が低い障害：数ヶ月に一度起こるが，同じ条件で実行しても再現しない
- デバッガが使えない障害：障害が起こるが、デバッガ配下では問題なく動作する
- バグを修正したことによる障害：アプリには間違いがあるが、OS等の障害のおかげで思うように動作していた。OS等の障害を修正した結果動作しなくなった。
投稿2021/02/10 05:05
総合スコア24670
あなたの回答
tips
プレビュー
