モッククラスを使うべきか否か - 日々常々
元ネタ: モッククラス、下から見るか？横から見るか？ モッククラスを使うべきか否か、というネタを拾ったので書いてみます。これまでにモックについて殆ど書いてないことに気づいて驚きつつ。 Short Answer 「モックに何をさせたいの？」 質問に質問で返すなという感じですが、モックに何をさせたいか答えてみれば、モックを使うべきか否かはだいたい決まるよなーと思うのです。 モックは道具で、使うことで何かを改善するものです。 「このことをテストしたいから、モックをこう使う。」という文脈なく使用すると、無用な複雑性を作り込むことになります。 モックの使用は負債なので、十二分に利益を見込める場合にのみ使用するものだと思っています。 これはモックに限った話ではなく、何かを便利にするために道具を追加する際は必ず付いて回るトレードオフです。 Short Answer 露払い 使うべきか否か どちらでも差が
ゆもつよメソッドを勝手に語る夕べ｜鈴木三紀夫（@mkoszk）
２０１９年１月１６日（水）１９時に開催しました「ゆもつよメソッドを勝手に語る夕べ」の原稿をリライトしたものです。 目次１．はじめに ２．ゆもつよメソッドの特徴 ３．ゆもつよメソッドのプロセス ３－１．ゆもつよメソッドのプロセスとアクティビティ ３－２．テスト分析とテスト設計の違い ３－３．テスト分析のアウトプット ３－４．テスト設計のアウトプット ４．ゆもつよメソッドのテスト分析 ４－１．テストタイプの特定 ４－２．フィーチャ ４－３．論理的機能構造 ４－４．テストカテゴリ ４－５．テスト条件 ４－６．テスト分析マトリクス１．はじめに語る夕べシリーズについて 喫茶店や居酒屋などで話されている事柄をオープンの場で話します。登壇している２人の私的な会話に、皆さんを巻き込む感じです。セミナー講師が受講生に向かって理解させるというスタイルではなく、登壇者が勝手に喋りますので、ぐたぐた過ぎて、参加者
JUnitを使った単体テストの効率が50％アップ！ ありがちな失敗例とその対策のカギを握るツール「Jtest」
みなさん、単体テストは実施していますか？ そして、問題なく運用できていますか？――単体テストとは、テスティングフレームワークを使ったテストプログラムのことです。本稿ではJavaの開発でよく使用される、オープンソースのテスティングフレームワーク「JUnit」を用いた単体テストの失敗例と、それを回避するためのコツをお伝えします。さらに商用ツールである「Jtest」の「単体テストアシスタント」機能を活用して、テストをより効率的に実施するための方法も紹介します。 Java対応静的解析・単体テストツール「Jtest」 はじめに Javaの開発では、多くのプロジェクトでオープンソースのテスティングフレームワーク「JUnit」が使われています。テスティングフレームワークを使った単体テストのメリットは、テストコードを一度作成することで同じ条件のテストを繰り返し実行でき、結果の確認を自動で行えることです。
15-skills-every-software-tester-should-master-in-2017
According to Jerry (Gerald) Weinberg, a renowned computer scientist and testing expert, “If you are not learning something new each day, you are not testing”. Well, this statement holds true especially when the technology, agile and devops methodologies are advancing rapidly while accelerated development and continuous deployments are getting more complex, making testing a critical activity. This
QAチームが誕生！？ QA Meetup 2018 イベントレポート
今年の3月、株式会社ビズリーチに、最初のQA（Quality Assurance）として入社した 江川（@EgaSaQA）です。 現在はHRMOS採用管理事業部のプロダクト開発部に所属しています。 ひとりぼっちのQAチーム ビズリーチの開発体制はエンジニアとデザイナーを合わせて、およそ300人。 それに対してに対してQA1人。 つまり立ち上げメンバーです。 現在の状況と目指すQAの姿 弊社では、エンジニアがテストもするため、QAは必要なかったのですが、サービスを利用する方が多くなりプロダクトも増えていく中、 もっと品質を重視していこうということで立ち上げに至りました。 立ち上げですから、いろんなものを整備しなくてはなりません。 (QAフロー、アノマリーの分析、短期対策、長期対策…) HRMOSのQAチームは、目指しているQAのあり方を各事業部にも広める活動をしています。 自分たちでやり方を
自分のコードを嫌いにならない、そのためにやるべきこと
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。最終回である今回は、power-assertの開発やテストに対する考え方などを聞いた。 （前回から続く） 自社製品を開発しようとワークフローエディターを自作して得たJavaScriptのスキルセットは、ぼくの大きな財産になりました。ワークフローエディターはかなり複雑なソフトウエアなので、テストコードなしでは開発は困難です。そこでJavaScriptのテストについてもいろいろ調べてみました。しかし、JavaScriptのテストの仕組みは当時はまだ全然発達しておらず、ほぼ手探り状態でした。 201
JSTQB 1章 テストの基礎 - テストエンジニアの備忘録だよっ
■基本用語 ・エラー、誤り：人間の動作の誤りを指す ・バグ、欠陥、フォールト：故障を引き起こすコンポーネントやシステムの欠陥を指す ・故障：コンポーネントやシステムが期待される結果とならないことを指す ・インシデント：障害のことで、原因がバグによるものだけに限らず調査が必要とされるようなイベントを指す ・テストアイテム：テスト対象。IEEE829では関連するドキュメントとしてテストアイテム送付レポートが標準化されている ・テストベース：テストの根拠となる要求仕様書などのドキュメントを指す ・テストケース：テストの為に入力値、実行前の状態、予想結果、実行後の状態を定義したもの ・テスト条件：コンポーネントやシステムで1つ以上のテストケースによって検証できるアイテムやイベントを指す ・テストスイート：関連するテストケースの集まりを指す ・テスト手順：テストを実行する為の手順 ・テスト環境：テス
JaSST'18 Tokyo 基調講演「Advances in Continuous Integration Testing at Google」 #JaSST - ブロッコリーのブログ
はじめに 先日、JaSST'18 Tokyoに参加しました。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo FLAKYの内容が今はっきりした！#JaSST— ブロッコリー (@nihonbuson) 2018年3月8日 と書い（てしまっ）たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。 Micco氏のお話 John Micco氏（以下、Micco）の話は、以下の3回聞きました。 ICST基調講演(2017年) JaSST'18 Tokyo基調講演 JaSST'18 Tokyoチュートリアル それぞれのタイミングで、特にFlakyの話の理解度が変わっていったので、Flakyを中心にMiccoのお話をお伝えします。 今回は基調講演の話について書きます。 チュートリアルはどこまでブログでお伝えして良いか分からないので、Micco本人に確
JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ
はじめに この記事はJaSST'18 Tokyo（ソフトウェアテストシンポジウム）のパネルセッションを書いたものです。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo 自己紹介 バックグラウンドが違い、コンテキストが違うことがある そこで自己紹介時に、どれくらいの頻度でDeployしているのか、どれくらいの頻度でリリースしているのかを踏まえて話してほしい。 荻野 恒太郎（以下、荻野） 楽天 テスト自動化とDevOpsのマネージャをしている。 デプロイは毎日数十回実施 1週間に数回リリースしている 天野 祐介（以下、天野） サイボウズ kintoneの開発チームに所属 エンジニアが10数名、QAなどを含めると30名ぐらいのチーム 2015年にチームリーダーになった 今はスクラムマスター中心 最近、WaterFallからAgile開発に変更していっている 今は1イテレー
JaSST '18 Tokyo - Web.JaSSTのセッション実況まとめ
http://www.jasst.jp/symposium/jasst18tokyo.html 2018年3月7~8日 に開催された JaSST '18 Tokyo の A2) WEBテストのセッションの実況まとめです。
The Practical Test Pyramid
The "Test Pyramid" is a metaphor that tells us to group software tests into buckets of different granularity. It also gives an idea of how many tests we should have in each of these groups. Although the concept of the Test Pyramid has been around for a while, teams still struggle to put it into practice properly. This article revisits the original concept of the Test Pyramid and shows how you can
品質保証の歴史学 at「リリカルの質問全部答えます」 #リリカルの質問 / History of quality assurance
2018年1月9日にあった「リリカルの質問全部答えます」というイベントに参加して聞いた品質保証の歴史学に関する内容をスライドにまとめました。 ・イベント告知ページ https://connpass.com/event/74455/ ・ツイートまとめ https://togetter.com/li/1188522 ・リリカルさんが用意していた質問集 http://mhlyc.hatenablog.com/entry/2018/01/09/181952 ・参考資料『日本におけるソフトウェアプロセス改善の歴史的意義と今 後の展開』（SQuBOK Review Vol.1に掲載） http://www.juse.or.jp/sqip/squbok/squbok_review.html
「GebとSpockではじめるシステムテスト自動化」
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
市場バグを引き起こした優秀なデータたち - ボドゲを愛するテスト屋さん
※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20：UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/
idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
The Rise of Test Impact Analysis
Test Impact Analysis (TIA) is a modern way of speeding up the test automation phase of a build. It works by analyzing the call-graph of the source code to work out which tests should be run after a change to production code. Microsoft has done some extensive work on this approach, but it's also possible for development teams to implement something useful quite cheaply. 22 August 2017 Paul Hammant
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Quality Engineering in DevOps | mabl Library
Test process improvement starting from the problem awareness of team members using tpi next
Advances in Continuous Integration Testing at Google
自動テストの品質とテストパターン
