テストを育てるためにテスト管理ツール「TestRail」を使ってみた
テストケースの管理は、テスト自動化云々の前になんとかしておきたいところ。テストケースはExcel管理することが経験上多いですが、世の中にはもっと便利なものがあるだろうと思い、ブラウザベースでテスト管理できる「TestRail」を試してみました。さてさて、Excelを超えるのでしょうか？ 超えてみろ！ なぜテスト管理が重要なのか テストケースの管理について、以下のような課題を多く経験しました。 テストケースの追加や更新、その後の整理が難しい。行のコピペミスやマージ漏れ、同時更新でおかしくなったりファイルが壊れたり。マスタとなるテストケースをバージョン管理しながら育てていきたい。 トラッキング情報を書き込みにくい。Excelのセルには表示限界がある。「5/31 藤原 XXXXX追加」とか書くのがとても面倒くさい。 過去のケースを検索しにくい。ファイル・フォルダに行って、過去の日付のケースを開い
第21回 テスト駆動開発（1） まずテストを書こう | gihyo.jp
こうして必要な情報を調べてみるとBMIや肥満度に性別や年齢は必要ないのが分かります。そのとき、開発者は立ち止まって考えます。例えば、「必要ないので、実装は取りやめようか？」「しかし次回作成するUIには、性別を反映したい」「ここは今後のアプリケーションの発展の可能性を考慮して、残す方向で進めよう」といったように考えます。このように、ごく近い将来利用する要素であれば、先回りして実装しておくのも許容できます。しかし、利用する予定がないのであれば、きっぱり削除しましょう。必要になってから実装する（YAGNI]）というXP（エクストリーム・プログラミング）の原則です。 テストコードの作成と、目的のコードの作成 それでは、個人情報コンテナクラスをテストするコードを書いてみます。この段階で個人情報コンテナクラスそのものは、入力を受け付けますが中身は空っぽです。このような状態のコードを「スケルトンコ
『なぜエラーが医療事故を減らすのか』はスゴ本
「バグを排除しようと圧力をかけると、バグが報告されないプロジェクトになる」 この寸言は、よく忘れられる。シックス・シグマや日経ナントカに染まった管理者が、バグを目の敵にし、バグゼロの号令をかける。不具合が表面化すると、たまたまそこに詳しいだけの担当を犯人扱いし、なぜなぜ分析を強要し、ccメールや全体会議で晒し者にする。 なぜなぜ分析とは、「なぜそれが起きたのか？」「その原因の原因は？」と、原因を幾重にも掘り下げる手法のこと。5段階も遡及すると、たいてい「私の不注意でした」となり、対策は「意識を入れ替える」という小学校の学級目標になる。反面、もっと深刻な「仕様変更が電話口で伝えられていた」とか「アジャイルの名のもとにテストが省略されていた」などは放置される（なぜなら、「人」を原因にしたいから）。 こんな冗談みたいな施策を続けていくと、スケープゴートになった人はどんどん心をすり減らし、不具合の
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
Infratasterでリバースプロキシのテストをする - クックパッド開発者ブログ
インフラ部の荒井（@ryot_a_rai）です。この記事ではインフラの振る舞いテストのツールであるInfratasterを使ってリバースプロキシの設定のテストをしてみたいと思います。 Infratasterとは Infratasterはインフラの振る舞いをテストするフレームワークで、RSpecのテストヘルパとして機能します。例えば、 特定のヘッダ付きのHTTPリクエストを送信した時にあるレスポンスヘッダが返ってくることをテストする Capybaraを使って実際のWebブラウザ上での挙動をテストする MySQLのSHOW VARIABLESの結果をテストする といったことが可能になります。 細かい概要についてはこちらのスライドやREADMEをご覧ください。 Serverspecとの違い インフラのテストといえばServerspecが有名かと思いますが、InfratasterはServersp
イマドキのExcelスクショの撮り方
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
Test Yourself - テストを書くと何がどう変わるか
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
実践 Selenium WebDriver
本書は、Seleniumの導入と構成の仕方、テストの書き方について、包括的に解説する書籍です。IE、Firefox、Chrome、Safariなどのブラウザに対応するWebDriverの機能から、iOSとAndroidアプリケーションのテスト、さらにUIテストツールのPageObjectパターンまで、サンプルコードを使って具体的に説明します。日本語版では玉川紘子氏による「CI（継続的インテグレーション）ツールの活用」を付録として追加。WebアプリケーションのUIテストを自動化したい技術者必携の一冊です。 訳者まえがき はじめに 1章 WebDriverとWebElementの紹介 1.1 Seleniumの歴史 1.1.1 Selenium 1、別名Selenium Remote Control、別名 Selenium RC 1.1.2 Selenium 2、別名Selenium WebD
テストエンジニアの品格 #automatornight
http://madoguchi100.connpass.com/event/8204/ で発表したスライドですRead less
テスト自動化ROI試算式の構成要素と5つの例。そしてCBAとは何か
表の「手動テストの運用コスト」「自動テストの開発コスト」「自動テストの運用コスト」は各単位時間当たりのコストと実行時間を積み上げていけば、算出できます。 「欠陥コスト」の扱いが問題 表の「テストで間接的に発生するコスト」で○が付いている「欠陥コスト」は「本番環境での欠陥に対する予想対応コスト」なので、発生する欠陥の頻度や重要度によって異なります。自動化された後の運用コストの値は、同一の「規模」「特性」を持ったソフトウェアからのベンチマークで計ることが多いですが、正確な予想値を見積もるのが困難な場合があります。障害の数がどれだけ減るかは、この「欠陥コスト」をはじめ、さまざまな変動要素が絡むためです。このため、簡易的なテストの運用改善に完結したROI試算では「欠陥コスト」は使用しない場合もあります。 また後述しますが、手動テストを自動化する場合、手動テストを行う人員が、別のアプリケーションのテ
Appleの新言語「Swift」を使ったテスト駆動開発と、機能の紹介｜CyberZ 公式エンジニアブログ
CyberZ 公式エンジニアブログ アドテクや最新のテクノロジーについて情報発信していきます ブログトップ 記事一覧 画像一覧 怠惰のすゝめ。Do･･･ » Appleの新言語「Swift」を使ったテスト駆動開発と、機能の紹介 2014-06-05 14:20:52NEW ! テーマ：ブログ 新言語「Swift」とは新プログラミング「Swift」は、先日のWWDCで突如として発表された、Appleの作った新プログラミング言語です。Objective-Cに比べてモダンな文法が盛り込まれていたり(どことなくScalaやC#に似ていたり)、速度が早くなっている特徴があります。 Xcodeとの親和性の高い連携も示唆されており、今後広まっていく可能性が十分にあると思います。FizzBuzzとはFizzBuzzとは、プログラミングの課題などでよく出される問題で、1から順番に数字のループを行い、3の倍数
テスト自動化の3つの目的とROIの必要性、定義
テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載です。 連載目次 はじめに：本連載について 本連載を担当しますテスト自動化研究会（STAR）の太田健一郎と申します。本連載では、読者の皆さまがテスト自動化の導入理由や効果の測定をROI（return on investment、投資利益率、投資収益率、投資回収率）という観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを数回にわたって解説させていただきます。 連載の流れは以下の通りです。 テスト自動化とROI ROIの試算式の構成要素と試算式 ROIの試算式の詳細と実際 本連載の対象読者は以下を想定しています。 テスト自動化を推進するエンジニア テスト自動化の定性的な効果は理解しているが、定量的な説明がうまくできないエンジニア 本連載で取り上
ユニットテストを書こう！ - Qiita
ソフトウェアエンジニアにとって、ユニットテストは重要です。僕はなるべくユニットテストを書くようにしており、ソフトウェアエンジニアはもっとユニットテストを書くべきだ、と考えています。ここで言及している「ユニットテスト」は、単なる「テストコードによる自動化」全体を指すのではなく、「テストから見えてくるグーグルのソフトウェア開発」で登場した用語である「Sテスト」を指します。 「テストから見えてくるグーグルのソフトウェア開発」では、テストコードが対象とするプロダクションコード(製品コード)の規模、S、M、Lとサイズごとに分類しています。 「Sテスト」とは、テスト対象のクラスのみを対象にしたテストを行うことを目的としています。テスト対象以外のクラスの処理は、積極的にモックを多用することで、テスト対象のクラスの振る舞いを確認します。 Sテストは主に品質向上に寄与すると「テストから見えてくるグーグルのソ
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
第２回 全ての組み合わせを考えると膨大になる
十分なテストをしたのにバグが見つかる---。「想定外」としか言いようのない事態があると思います。そのような事態に陥らないためにはどうしたらよいでしょうか。 すぐに思いつくのは、再発防止策として同じようなバグを検出できるテストパターンを追加することです。もちろんこれは有効ですが、こうした対策は「経験から予測できる不具合に対するテスト」にすぎません。未経験の不具合は常に「想定外」のものとして見落としてしまう可能性があります。つまり、「同じようなバグを検出できるテストを増やす」という対策は本質的な解決策にはなっていないのです。 想定外を想定できるわけはありません。いったいどうすればよいのでしょうか。開発者の方にはなじみが薄いかもしれませんが、「品質工学」と呼ばれている方法論があり、これが一つの解決策を与えてくれます。もちろん“銀の弾丸”はありませんから全ての問題を解決できませんが、経験や知識によ
イチから分かる、テスト自動化とSelenium | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム
今日は、テスト自動化と、ブラウザ自動テストツールSeleniumについて、知らない方でも分かるようイチから解説したスライドを作ったのでご紹介します。 このスライドは、2014年2月28日に開催された「Enterprise × HTML5 Conference」の発表スライドに、時間の関係で省略した多数の未発表ページを加えたものです。 イチから分かる解説についてはこれで終わりですが、せっかくですのでスライドの見どころをご紹介しましょう。
CI（継続的インテグレーション）サービスまとめ・14個！ - atskimura-memo
CIって？ CIはContinuous Integration（継続的インテグレーション）の略です。 継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。 不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。 ちなみに、ソフトウェア開発手法のひとつである「エクストリームプログラミング」では、継続的インテグレー
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
