ABテストツールは「数打ちゃ当たる」を機械化するためのツールではない - 絶倫ファクトリー
タイトルが全てなんですけどね。 以下のような記事を見つけまして。 駄文：ABテストがモノづくりを破壊する | nekokak's blog いろいろと突っ込みどころはあるんですが、まず最初の「ABテストとは何か」が間違ってるんですよね。 ABテストって簡単に言うと２つ以上ある選択肢のうち一番良い結果を出すことのできるものを見つける事ですね。 もしこの記事を書いた方の組織がABテストをこのように捉えているなら、そりゃモノづくりもクソもあったもんじゃないよなと思います。 ABテストって、単に複数のクリエイティブから良いものを見つけ出す手法じゃないんです。 仮説を検証する行為なんです。テストなんですから。 単に複数のクリエイティブから良いものを見つけ出すなら、クリエイティブのパーツを機械的に作って、何千何万パターンと試せばいい。逆に言えば２つやそこらのパターン試しても意味ないです。数少なすぎ。
プログラミングの入り口として自動テストは有効か - マンガ・ロジスティクス・エフ
毎週、Twitter SpacesとDiscordで交互にテスト自動化の話をしながらランチを食べる会というのをやってるんだけど、この中でプログラミング経験の無いテスターが自動テストを覚えるのはプログラミングの技術を学ぶ上で有効かという議題が盛り上がった。 その場で出た意見は次のようなもので、概ねハードルが高いという意見で共通していたと思う。 自動テストは開発技術を転用したものなので、普通に開発スキルが無いと厳しい 自動テストだけ覚えてもプロダクトの品質向上には寄与しないことが多い 自動テストライブラリのシンタックスを覚えただけでは足りず、一般的なプログラミングスキルは当然必要になる 初めてのプログラミングの対象がブラウザなのはつらそう 自動テストはマイクロサービスとして捉えたほうが良い 以下は自分の意見。 モチベーションの重要さ プログラミング経験が全く無い人が、自動テストからプログラミン
次第に腐るテストコード - Fly me to the Luna
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
エンジニアがもつべきは「思いやり」ではないだろうか - とある元ＳＥの思考を探る
最近、常々思うことがあります。 Webエンジニアに必要なのは、思いやりなのではないだろうかと。 エンジニアはつねに改善するように常日頃から心がけることが必要な職業です。だからこそ、エクストリームプログラミングやスクラムといった手法が考案され、実行されているのだと思います。 スクラムのふりかえりには、KPTといってよかったこと（Keep）、問題点（Problem）、改善したいこと（Try）を振り返ります。社会人１年目が習うPDCAサイクルを回すといったことに近い事象でしょう。 その中で、今日は、思いやりにかかわるWebエンジニアがやるべき３つのことを述べたいと思います。 １．テスト エンジニアはテストを書きます。これは、昨今は当たり前となっていることです。「テスト書いてないとかお前それ@t_wadaの前でも言えんの」などと言われるこのご時世。テストのないシステムは、自ら破滅へ向かいたいのかと
誰からも頼まれていないのにコードを書く機会を作り続ける秘訣 - Qiita
2020年のゴールデンウィークを、黙々とコードを書いて過ごした。仕事でコードを書く必要性が皆無な職種だが、それでもコードを書き続けることで仕事での重大な局面を何度も切り抜けてきたし、色々と得してるんじゃないかと思ってる。 ふと、現場での経験に恵まれず、才能を発揮できていないプログラマがいたら、この「誰からも頼まれていないのにコードを書く機会を作り続ける秘訣」は役に立つんじゃないかと思ったので、ちょっと書いてみようと思う。 1.自分が使うものを作る 10年ぐらい前にプログラムのコンテストに出てトイレを探すサービスを作ったことがあった。当時に一緒になったメンバーが街でトイレを探す機会が多いからと考えたサービスだ。このサービスを作ったことで、賞もいただけたし、手を出さなかったけど、アプリへの広告掲載などの話もあった。ただ、機能追加を続けるのは２年が限界だった。どうも自分にはトイレを探す才能が備わ
#TestingFrameworkMeeting に参加しました（１） - テスティングフレームワークの歴史 - @ledsun blog
参加した時のメモです。 t-wadaさん Testing Framwork Meeting テスティングフレームワークの歴史 http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。 有史以前 make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。 JUnit Kent BeckがJUnitを書いた。 1994 SUnit 1997 JUnit プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。 テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。 自動テス
私がコードを書くときテストは書かない | κeenのHappy Hacκing Blog
ちょっとポエムというか自分語りを。会社の同期と話してて少し刺激されたので。あとはソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama｜noteにも刺激されて。 発端は同期が最近は何か書いてもイケてなくて後で丸っと書き直すことが多くてつらい、という話を始めたこと。 自分は、そんなの普通だろと返した。少なくとも自分の中では当たり前だった。 ふと考えてみたらそうじゃない人も沢山いる気がした。当たり前じゃない人に、自分の当たり前を喋ってみたら面白そうということで自分がコードを書くときにやることを語る。 コードを書き始めた時点では仕様は完全には固まっていない。アプリケーションの構成とかは決まってるけど、ソフトウェアの中身はほとんど何も決まっていない。 まずは手を着けやすそうな所から始める。最初は必ずHello Worldから。そしてmainの中にPoCを書いてイメージを掴
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
テスト環境のユーザーをキャラ立ちさせる - Konifar's WIP
今仕事で作ってる『Taptrip』はまだテストを書けていないので、テスト環境で手動で動作確認をしています。これが結構めんどくさいです。 ただ、そうは言ってもテストコードでカバーしきれない部分もあるでしょうし、手動で確認するフローは当分残るんじゃないかと思うんですよね。つまりめんどくさくてもやるしかないわけです。 どうせやるなら何か工夫できないかなぁと思いまして、1年くらい前に工夫の一環として テストユーザーを作り込んでみたら想像以上にいい感じだったので、どんな雰囲気になるのかまとめてみます。 結論を先に言ってしまうと、 テストユーザーを美人とアニメキャラにして作り込んでみたらテスト環境を触るのが楽しくなったよというハックです。自動化みたいな技術的な工夫は一切出てこないです。すみません。 テストっぽくないユーザーを作る テストユーザーの名前が 『テスト01』とかだと見ていても楽しくないので、
TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba
今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね？」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善
DevOps時代のテスト要求分析 - Test Automation
はじめに こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。 qiita.com ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。 DevOps時代のテスト要求分析は難しい DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。 （理由１）ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する （理由２）開発中にシステムのアーキテクチャ設計が変化する このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性に
プログラマーも手動テストしようぜ 〜 忍者式テストのすすめ 〜 - Qiita
はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
テストというのは、ソースコードの冗長化だと思う - きしだのHatena
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト自動化のルンバ効果 - テストウフ
https://ubiteku.oinker.me/2015/11/17/tdd%E5%86%8D%E8%80%83-6-%E3%83%86%E3%82%B9%E3%83%88%E5%AE%B9%E6%98%93%E6%80%A7-%E2%89%A0-%E8%89%AF%E3%81%84%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3/
https://ubiteku.oinker.me/2015/07/27/why-most-unit-testing-is-waste/
