「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった >>303
すげー大変じゃん
仕様を定義するやつも
小数点いくつで四捨五入なのか切り捨てなのか全部考えないと
でもそんなことしなくてもプログラムって動くし
んでこういうのって会社で一旦やるって定義されちゃうと全部やらないといけなくなっちゃう
でも大半は必要ない >>304
>・自動化Scriptの作成コストはでかい
それは正しいが、テスト自動化の作成/修正コストは
総合>>結合>>単体テストの関係になる
(必要な構成、モジュールが総合テストに近づくほど増えて影響範囲がどうしても増えるので)
>・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか?
総合/結合テストの自動化はバグを発見するのが目的ではなく
既存機能が壊れてないを確認するために使うんだぞ?
勘違いしてる人が要るかもしれんが、総合/結合テストでバグが頻発すると
テストが失敗した原因の調査〜修正の作業に無視できない工数がかかるから、
作成コストが少ない単体テストが整備出来てなきゃ宝の持ち腐れだぞ
>・そんなに何度も単体テストしないし
それは単純にサボってるだけ
継続的デリバリーとか継続的インテグレーションっていうスタンスで立つ場合
CIツール、例えばJenkins辺りで構築する場合
ソースをコミットしたタイミングで、コード解析、自動ユニットテスト、ビルドまで一連でやるようにする
だから一番動かすのはむしろ単体テストになる
https://www.techmatrix.co.jp/product/cisolution/service/index.html
https://tracpath.com/works/devops/continuous-integration/
>・かけたコストに対するリターンが小さそう?
んな事ない
上記の例も合わせてリターンは大きい 自演成りすましかとも思ったが本物だった
幼稚過ぎるやろ >>307
自動テストは単体が一番作るの大変だと思うけどなw
結合や総合はモジュールや機材のセッティングは大変だけど
作るのは簡単やろ
だってUWSCで画面のボタンをポチって押すだけやろ
少なくとも俺はそんなイメージだけど? >>309
>作るのは簡単やろ
>だってUWSCで画面のボタンをポチって押すだけやろ
それは考えが甘すぎだわwwwwwwwwww
それだと操作しかしてないやん
UI周りの自動テストを実装する場合
・テストシナリオ(どういう操作をするのか)
・テストの判定基準
(想定通りの画面に遷移しているのか、表示されるメッセージが正しいか、データ登録が絡むならその結果も正しいのかなど)
・テスト結果の判別方法
(これはテストシナリオによって変わってくる、登録データをそのまま引っ張り出すならDB接続して想定値との乖離が無いかチェックする
ものによっては画面キャプチャで画像差分を見るってやり方もあるけど個人的には好きじゃない)
最低でもこの辺を意識して作らんといかんから、
そんな画面ポチポチ終わりーでいかんぞ…・…
特にUIの自動化は変更に弱い認識だから、本当に最後の最後で実装しないと地獄を見るし >>307
単体テストのモジュールってさ
上流で変更があると枝葉って変更じゃなくて消滅と生成のが多くない?
そうなると実ははじめの一回目しか実は見てないんじゃない?って俺は思っちゃうんだよね
枝葉をくっつける本流の方が間違ってるときってそれそもそも自動化以前にテストやっとるのかと?
俺は単体テストの自動化テストはヒット数(実際にバグを捕まえた数)は少ないと思ってる
苦労した割には Ruby on Rails のRSpec で有名な、ソニックガーデンの伊藤淳一とか、
Serverspec の作者・宮下剛輔とか、有名
YouTube で有名な、雑食系エンジニア・KENTA は、
初心者のRailsポートフォリオに、CircleCI まで入れれば、有利と言ってるし
有名は人は皆、BDD の鬼! >>312
単体テストでバグの発見数は正直重要じゃないな
というかそんなん集計とるか?
普通は単体テストが成功してからコミットするし、テストコード無しでコミットしようとしたらプログラマー〆るだろ
……というか仕様変更の度に関数が消滅と生成が起きるって
それはどっちかと言うとプロジェクトの問題では……? >>311
総合や結合の結果の判別なんか
ログの最後の出力がCompleteだったぐらいでええやろ
機材がクソってるのにログにCompleteって出てるならそれってテストScriptのせいじゃなくてそもそもログ出力腐ってるやろ? >>314
きっちりメソッドが分けられず
他の機能と融合してるから
変更が多いんやろ
普通は上流の変更があったら枝葉のメソッドは生成と消滅が多い >>306
そこは仕様によるし、あと責務の分割とかそういう発想でプログラムを組めばいい
超簡単な例として、電卓を上げるぞ
win10の電卓を叩くと
10/3 = 3.3333333333333333333333333333333
20/3 = 6.6666666666666666666666666666667
っていう感じで小数点31桁で出てくる
この結果から以下の仕様が読み取れる
・計算した結果が無限小数の場合、小数点は31桁まで表示する
・小数点31桁目は四捨五入して表示する
っていう仕様が予測できる
と言う事は、最低限の実装方針としては以下のようにすると、楽に単体テストが実装できる
・計算ロジック側は小数点31桁よりも大きい桁数でユニットテストは判定すれば良い、単体テストは可能だし、変更も簡単にチェックできる
・画面表示をする際に小数点31桁として出力するように四捨五入するメソッドを実装してかませればいい、このメソッドも単体テストが可能になる
ようは必ずしもすべての計算結果の小数点桁を指定する必要は無い、基本的には余裕のある実装にしておけば早々壊れない >>315
それはテストツールによるとしか言えん
ちゃんとしたGUIテストツール使って、シナリオも確認してるのであれば
もちろんばログレベルの確認で良い
ただUWSCって名前が出たからついな
あれは自動操作用の目的だし、そもそも今開発止まってるから使うべきツールではない >>314
テストコードコミットしたらぶっ殺すわw 仕事しろと 複数の下流工程を管理する際、テストコードの無い成果物を渡されても、そのソフトウェアモジュールを製品に組み込んでもいいのか判断に困る。
そもそも、単体テストが済んでいるということは、そのソフトウェアモジュールはテスト仕様の範囲では正しく動くことが保証されているわけだ。
だから、完璧な単体テストさえ行っておけば、完璧なモジュールを組み合わせて完璧な製品が出来上がるから、理論上完璧な単体テストができれば結合試験すらいらないんじゃないなって思う。(流石に大胆発言か?)
※顧客満足のチェックまでは無理だが。
※ここで言う完璧なモジュールというのは組み合わせれば理想な製品ができるモジュールのこと。(前提条件がシュールすぎる?)
まぁ、現実的に人が設計をする以上、仮に一つ一つのモジュールがテスト仕様書を満たしたところで組み合わせても上手くいく保証はないから結合テストもやるんだが...。
単体テストについては、こんなイメージだな。 プロならテストコード書かなくても動くコード書くのが普通
単体テスト書くことが目的化してしまってるのがマナー講師と呼ばれる所以 >>321
単体テストは時間の無駄だから
単体テストのテストコード見て判断する木偶の坊が管理してるとかそのプロジェクト破綻してるだろwwwwwwwwwwww
大局を見ろよ、設計として正しいかどうかで判断しろ、単体テストのテストコード見てどうするんだバカwwwwwwwwwwwwwww
wwwwwwwwwwwwwwww笑い死にさせる気かwwwwwwwwwwwwwww なんか、さっそく、あぼーんされている奴が沸いてるんだけど。
ごめんね。俺のブラウザだと、NGが共有されるから、読めないや。 「単体テストのコードがあるな、よし!」とか言ってるのかwwwwwww
wwwwwww現場猫かよバカがwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwww >>324
見てるくせにwwwwwNG解除してみてるくせにwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwハゲワロwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwww お前ら笑いの才能だけはあるよなwwwwwwwwww
wwwwwwwwwすげーわ単体テストのテストコード見て管理した気になってるとかwwwwwwww
wwwwwwwwww次元が違うわwwwwwwwwwwww >>328
ロクなテストしてないな、やっぱ単体テスト無駄だわ、そのテストなくても問題ない
いいよなーオープンソースは気楽でよー、人件費なんて無限に湧いて出るようなもんだもんなー
お前のようなアホが実績欲しさに無駄なコード書いてくれるもんなーいいなーうらやましいなー
無駄なテストコード書いて時間つぶして居られるなんて幸せものだなー 無駄なコードでも大変だから仕事した気になれるんだろうなーやりがいはありそうだよねーwwwww
wwwwwwww一銭の価値もないけどwwwwwwwwwwwwww お前ら授業中に真面目にノート取って先生に褒められて勉強できる気になってそうwwwwww >>328
有名どころのテストコードを見たことが無かったけど、思ったより普通だった。
でも、まぁ、勉強になる。 >>329
>ロクなテストしてないな、やっぱ単体テスト無駄だわ、そのテストなくても問題ない
「この単体テストは無駄、不要」っていう判断を下すには以下を知って無きゃいけない
・テスト対象のコード仕様
・テストコードの内容
先に言っておくが、無駄なテストコードっていうのはもちろん存在するぜ
テストカバレッジを水増しするようなコードとかな
あんたは3分足らずで言語仕様も異なる二つのフレームワークのソースを見て
コードの仕様とテストコードを理解して文句を付けてるわけだ
いやー、すごいすごい、単体テスト不要派なのにめちゃくちゃ詳しいんですねー
あ、ちなみにだけどさ『2020年』のWeb調査で
次に学ぶべきWebフレームワークの人気ランキングで
Djangoは3位、Springは7位につけてるぐらい人気があるフレームワークなんで
https://info.hackerrank.com/rs/487-WAY-049/images/HackerRank-2020-Developer-Skills-Report.pdf PythonのテストフレームワークでPyTestっていうのがあるんだけど
サンプルコードが少ないっていう問題があるんだが
その時はPyTestのgithubを見ると良い
https://github.com/pytest-dev/pytest/tree/master/testing
なんとPytestはPytestでテストしてるから、これを読み込むのが一番良かった
何より分かりやすい 日本では、この2人がBDD の鬼!
Ruby on Rails のRSpec で有名な、ソニックガーデンの伊藤淳一は、
RSpec の本、Everyday Rails も翻訳してるし、
Serverspec の作者・宮下剛輔も、有名 結局オープンソースとか有名プロジェクトは
単体テストを行うのは最低限の常識レベルになってるんだな あ、もちろん単体テストを自動テストするって話ね
手動だったら単体テストやってるなんてこと外部からわからないから当然かw 手動テストの問題はコストがかかること
人海戦術でやるという発想でコスト意識がないのだろう
だいたいこういう所は客が金を出してる。つまり自分の懐は傷まないw
コストがかかる手動テストのプロジェクトでのコスト削減の発想はテストが必要なることをやらないこと
ソースコードを修正するとテストが必要になる。つまり極力ソースコードを修正しない。
こういうところは未だにIEじゃないと対応してませんとかやってる。
作って検証ができないからユーザビリティも悪い Google map
https://github.com/googlemaps/android-maps-utils/blob/master/library/src/test/java/com/google/maps/android/PolyUtilTest.java#L7
調べると事例なんて腐るほどあるな。
ただ、いまいち自動化という言葉の意味がわからない(ただの無知)。
有償のテストツールを使ったことないけど...自動化とは言えど、テストコードを記述してビルドして実行することには変わりがないのだろう?
無知故の疑問だが、自動化と非自動化の差って何だ? >>342
「ちゃんとテストしたのか?」
・自動化
「はい、ここにテストした内容が書いてあります。これを実行しました。
テストに通ったことはテストの実行結果から判断できます。
もう一回やってみろって?コマンドを実行するだけですのですぐ終わります。」
・非自動化
「はい、ここにテストした証拠のスクショがあります。手順通りに実行してOKっぽかったからチェックを入れました。
テストに通ったかどうか?手順通りにやりましたよ!スクショがあるんだから信じてください。
もう一回やってみろって?全部ですか!?何時間、いえ何日かかると思ってるんですか!」 >>344
あなたがもう一回実行すればいい
あなたもすぐにテストを実行したというエビデンスを作ることができる >>345
じゃあ、作業未完了だね
納品物にエビデンスって書いてあるじゃん >>346
実行した姿をビデオカメラに写しておけばいいだけでは?
このテスト、私が実行しましたってwww
それ以外に何が欲しいんですかねぇ エビデンスが要求される粒度のテストのためにエビデンス生成フレームワーク作っとくと便利よ もちろん1番大事なのは自動テストの性質に合わせたエビデンスの形態を定義して、客に受け入れさせる営業力だが 日曜だから市場で買ったカニの出汁を濃縮してるわ、冷凍してとっとくんだ
これがホントのカニdense >>349
テスト自動化のほうが安くなります。
手動で作業したらその分時間がかかります。
スクショとったらその分時間がかかります。
しかもそのとったスクショ、あなた全部検収するんですか?
みたいにいえばOK
金と手間がかかる問題を客に押し付ければ意見は通る UIの自動テストはスクショもログ+スクショ自動生成までやってくれるから
本当にエクセルに張り付ける作業は不要なんだよな
スクショ張り付け作業をこれやらされる新人はマジで悲惨 しまいにゃ手動でやれば、バグがあって金がかかろうとも、丁寧な作業をしてると客を騙しはじめるのだろうな ていうか自動化にエビデンス入ってねぇのかよ
客に出せるレポートなんか出んだろフツー エビデンスは手作業で取るもの。自動で撮って誰が確認するというんだ?
客はエビデンスがあることを見てるだけで内容までは確認しないものだぞ
エビデンス撮った本人が、よくわからんが、まあバグっぽくない画面で動いてるからヨシ!ってやって
やっとエビデンスの意味があるというものだろう ログが正しく動いてることを証明するエビデンスが必要
そのエビデンスが正しいことを証明するエビデンスが必要
さらにそのエビデンスが正しい・・・ >>357
ログはたんなる実行結果に過ぎないから正しく動く証明にはなることはないよ
ログを正しく動く証明にするには方法は2つ
1. ログを取った担当者が、それをみて判断する
2. ログを取った人と別の人が担当者が、それをみて判断する
どちらが判断するにしても、正しい答えを知らなければ正しく動くと証明することはできない
だから上の方で言っていた正しい答えなんか事前にわかるわけ無いだろ!それっぽい値ならそれでいいだろ!
なんてのは問題外なわけ。正しく動く証明をしてないわけだから
スクショなんかも、取ったってそれみて後から検証なんかしないでしょ?
今からスクショみてバグが表示されてないか見ますなんてしないでしょ?
あれは仕事サボってないかとかいう作業完了報告書だったり、なにか問題が
起きたときにちゃんとやったのかという責任追及をするための道具に過ぎないよ
かろうじてバグがあったという証明ができるぐらい。正しく動く証明ではなくバグが有ったという証明ね
まあつまりログとっただけでは何の証明にもならないって話
ログと正しい答えを目視で比較する vs コンピュータでログを自動的に比較する(それが自動テスト)の違いよ
人力で比較してりゃ時間もかかるしミスもある。何もいいことはないね ログって言葉が独り歩きしてるけど
基本的に自動テストって
・想定通り動いた=OK出力(グリーン)
・想定通り動いていない=NG出力(レッド)
の2観点しかない
自動テストは結果判定もしてるから、実行だけ成功=OKには絶対にならん
(そんなテストを実装してたらぶっ殺されるわ)
で、自動テストのログが当てにならないっていう人って
無意識に以下のパターンを想定してるんだよね
・想定通りに動いて無いにも関わらず、OK出力(グリーン)が出ている可能性がある
つまりテスト側の不具合を懸念して、それでバグを取りこぼす危険性を考えているわけだ
結論的に言うと、そういうのはテスト作り方の問題になるし
発生するとのは相当なレアケースになる
というかこれが頻発してるなら、自動テスト組んだプログラマはクビにしろ
正しくOK/NGが判定できない自動テストならそりゃテストになってねえ
万が一、このレアケース発生しても修正をすればいいだけの話で、クリティカルな問題に発展する事はほぼ無い
(むしろ人間によるチェックの方が、判定の曖昧さ、ミス隠し、スクショ偽造とか色々やってくるから個人的に信頼出来ん) >>361
ログ出力のテストって何?
ログの話は「ログ見て人力で目視比較してそれっぽい値ならOK」ってやつでしょ
ログに出力した後に人力比較があるんだよ >>363
ログ出力だって機能の一つなんだからテストするでしょ?
ちゃんと指定通りのフォーマットで出てるかどうか?
日時、種別、内容などなどね
しないの? するわけねえわwwwユーザと関係ないだろうがバカがwwwww 何のためのテストだよwwwwww
意味のないテストやって尺稼ぎしてんじゃねえぞ経営者目線で仕事しろ ユーザと関係ないところで一生懸命頑張っても誰も認めねえからな
売上に一ミリも寄与しないこと頑張ってどうするんだwwwwwwwww
wwwwユーザから目をそらすために関係ないこと頑張ってるんだろwwwwww
パソコンが好きなだけじゃ会社は成り立たねえんだよwwwwwwwww >>364
> ログ出力だって機能の一つなんだからテストするでしょ?
わざとかもしれないけど(笑)話がすり替わってる
ログ出力機能のテストの話じゃなくて
○○機能のテストをするとき、その機能の結果をログに出力して
その出力を目視で人力比較してテストするのはアホという話をしてる 単体テストのテストコード書くほうが100倍アホだからwwwwww
wwwwwwwそこんとこ忘れんといてよwwwwwwwwwwwwww 自動テストでも実行結果をログに出力できるわけで
コンピュータで「比較」までやるか、人力で「比較」するか
誰が「比較」するのか?が違う所なんだよね なんかよくわからないところに噛み付いてるのでスルー これの話だからな
289 自分:デフォルトの名無しさん[sage] 投稿日:2020/09/26(土) 20:50:49.34 ID:c/9EiqGf [4/8]
単体テスト(自動テスト)で正しい値と比較 vs 目視確認でそれっぽい値かどうかチェック
って話だったの忘れたのかな?w
291 返信:デフォルトの名無しさん[] 投稿日:2020/09/26(土) 20:52:18.62 ID:IgGP+BQU [29/30]
>>289
結局最後に頼れるのは人間の目だからな
何のために目が付いてるか考えろ
ログを見るためだろうが 関数の入力仕様と出力仕様が明確なら
ログ出力関数のテストは簡単
でもログ出力関数を使う処理が正しくログ出力してるかどうかのテストはそう簡単ではない
なぜならログ出力の正しさを判定するためにはログ出力以外の結果は正しいということが事前にわかってなければいけないから
つまりログ出力だけでは処理の正しさを証明することは出来ない
テストで「正しいと証明できる」という考え自体がある種の幻想 このスレ見てると一体どういう自動テストを実装してて
どういうログを流してるのか本当に気になるわ
そんな突き抜けバグ(不具合起きてるのに何故か正常終了扱いになってる状態)を抱えた自動テストばっかり使ってるの?
本当にどういう自動テストを想定してるのか分からん
まさかログに値だけ出して、後でその値が正しいのか人間がチェックしてるのか?
それ自動テストじゃなくて、ただの自動実行だよ
テストっていうならグリーン/レッド判定まで実装してなきゃ使いもんにならん > 本当にどういう自動テストを想定してるのか分からん
> まさかログに値だけ出して、後でその値が正しいのか人間がチェックしてるのか?
ログに値だけだして〜って言ってる人は、自動テストしてないよ
ログに値だけだして目視確認する手動テストでいいって言ってる
なぜなら正しい結果がわからないから
これ↓ね。こいつの言ってる意味がわからんと思うけど、意味不明だと俺も思うw
28 名前:デフォルトの名無しさん[sage] 投稿日:2020/09/23(水) 20:17:23.00 ID:cCwBtdaA [9/11]
テストと言いつつできるのは計算過程と処理結果を残すだけだと思ってるよ俺は
長年考えた結果
正しい値なんてのは実は物理的に誰も知りえないということを理解した
なのでテストで重視するのは俺は組んだコードのエビデンスの方
どんな処理書いてどんなログ出したか
自動テストは結局同じやつが作ってる以上同じ不具合入ってるだろうなって思ってるw そろそろレス古事記に構うのをやめようか…
テストはバカだという証明はできるけど、いくら指摘しても修正しない限りバカはバカのままだし エビデンスとはテストを端折らずに実行しましたと言う証拠であって
動作の正しさやテスト手順の正しさを証明する証拠ではない
エビデンスという名の作業ログ 自社開発ならエビデンスは要らんよ
しょせん対外的な作業証明でしかないからな
それよりテストコード、テスト可能なコードを書いてくれや 細かいことで揉めるから、
>>1のような提案をする空気だけは読めるバカが出世して管理職になんだな。この業界は >>378
そのとおり
バグっている場合は、そのバグの様子をスクショしてるだろうからバグがあるというエビデンスにはなるだろう
しかしバグがないというエビデンスにはならない。これは自動テストでも同じだが、大きな違いは
バグってないというスクショをとっても、正しくテストを実行したというエビデンスにはならないという点
スクショ取るだけではテストケースは書いてあっても、そのテストどおりにテストをしたという証拠にはならない
最終結果だけでなく一連の動作を動画で撮影してるならまだわかるが、間違って手順でテストしたかもしれない
つまりエビデンスというのは(手順が間違ってるかもしれないけど)ちゃんと作業しましたという意味にしかならない
どういう手順でテストを実行したかという記録が含まれていない
自動テストの場合は最終結果だけでなくどういう手順でテストを実行したかが記録されている。
必要なら再実行もできる。だからこれこそが本当のエビデンスになる。 スクショには正しい手順でテストを実行したかが記録されていないのだから
作業をしましたという報告でしかない。
バグのスクショは意味があるが、正しく動きましたというスクショは必要ない
だからこれは本来この項目をテストOKでしたとチェックリストにチェックつけるだけで十分
チェックリストにOKでしたというチェックをつければ十分なことに
スクショを必要とするのは、単に作業者の報告を信用してないという意味でしかない 単体テスト書いとけば改修しても自動で既存機能が壊れてないことが確認できる
ゆえに機能の改修を心置きなくできる
テストがないと気軽に既存機能に手を入れるわけにはいかなくなる
(あたりまえ) 自動テストがないと手動テストをしないといけない
それは膨大な作業量となる
だからバグのないコードを書け、作ったら改修はするな!と叫ぶ
バグがあったときのことまで考えてない
仕様に変更があったときのことまで考えてない
一旦書いたら終わりという前提でいるやつがいる そのほうがビジネスとしては美味しんだ
テクニカルな面で優れた手法がビジネスでも優れた手法であるとは限らない >>385
単にビジネスが下手なだけだろ?
内部は楽をして、外部に対してこんなに頑張ってるんですよーってアピールすればいいだけ
外部に頑張りをアピールするために、実際に内部でも無駄に頑張る必要はない >>382
>バグのスクショは意味があるが、正しく動きましたというスクショは必要ない
正しく動いてたと思っていたものに後から不具合が見つかった場合
前回テスト時のスクショがあると調査が効率的にできる
それは自動でも手動でも同じ
>スクショを必要とするのは、単に作業者の報告を信用してないという意味でしかない
個人への信用に依存したシステムはミスがあれば個人を責めることになるのですぐブラック化する
典型的なマネジメント能力不足の例 > 正しく動いてたと思っていたものに後から不具合が見つかった場合
> 前回テスト時のスクショがあると調査が効率的にできる
不具合があると既に分かった後の話ですよね?
スクショがあると、どう効率的に調査できるんですか? >>387
> 個人への信用に依存したシステムはミスがあれば個人を責めることになるのですぐブラック化する
だから自動テストでコードにするんですよね。他の人がテスト内容をレビューできるように
スクショだと、実際どういう手順でテストしたのかが記録されてないから
ちゃんとテストしてないだろ!って個人を責めることにつながる 手動テストで問題なのが、前やったときのテストと完全に同じ状態が作れないということ
作業の順番でも状態が変わってくるから前後にやったテストによって成功したり失敗したりする
だから改めて同じと思った手順でテストしたら失敗することがある
スクショを取っていても「お前この前ちゃんとやってなかっただろ!」と責められる >>388
自分で考えて
>>389
自動か手動かには関係ない
自動化したUIテストでスクショ取らないのかな? >>391
UIテストってわざわざ書いたってことは
それ以外には当てはまらないって自覚してるのかなw 自動化したUIのテストでスクショを撮るというのはおかしな表現で
"テスト"を自動化していれば、当然自動的にテストされるわけよ
スクショはいらない
>>391が言ってることのほんとうの意味は
UIのスクショを自動で撮っているだけで
UIのテストは人が目で見てやってる手動テストだろう?
それとも違うんか? UIのテストを人が目で見ず本当に自動化してるんか? でもいい感じにお高いツールはUIテスト時のスクショも自動で撮ってくれるからねw
ないからっていらないやいって悔し涙流さなくていいぜ 別に高くなくても取ってくれるやろw
論点はそこじゃない
取った後どうするのかだろ 高いツール使ってるんだぜ悔しいだろ
みたいな意味かな? >>395
撮ったあとどうするもこうするもお高いツールはクリックすればすぐ見れるんだよ
手動でエクセルに貼る作業とかないから ただ・・・
(実はあんまり手間減らないんだけどな) 自動化は人間が楽をするために自動化してるだけなんだからログでもスクショでも何でも良いけど、テスト結果がグリーンであってもエビデンスは人間の目で検証しないとダメだよ。自動化の利点は、手動テストやってる要員や係るリソースを他のことに回せるってだけ。 自動テストがプログラマの自己満と言われる所以はテストパターンを無限に作成できるからだよ。sumAtoFで引数を6個取るなら0,0,0,0,0,0から9,9,9,9,9,9の範囲や、マイナス値とか小数点とかnull値を含めていくらでもテストパターンが作れる。しかも再実施も簡単。手動テストじゃそうはいかないからね。 >>400
手動テストでもテストパターンは無限に作れると思うが?w >>399
> テスト結果がグリーンであってもエビデンスは人間の目で検証しないとダメだよ。
え?なんで?愛情がどうとかどうでもいい話だよw >>399
あ、初めて自動化したときだけエビデンスの検証してねってこと。次の改修では追加・変更したテストパターンのエビデンスを検証する。それ以外の既存のテストパターンは結果がグリーンであればそれでデグレとしての証明は担保できてると思うよ >>403
PGした人がテストパターンも作ってたら同じ不具合が混入する可能性があるでしょ