Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15 ※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています P17 概説テスト分析 http://www.slideshare.net/takashiyamasaki378/ss-55384920 P29 システム/
2022年9月9日にこんなツイートをしたところ、 ソフトウェアテストの書籍・資料について、こういうマップを作ってみたい。「QA関連」でできるといいんだけど、縦軸が定まらない。 一番繰り返し読んでいるドリル本をサンプルにしてみたけど、テスト分析自体がすでに初級じゃない気もするから、色付けも難しい。うーん。 誰か一緒にやりません？ｗ pic.twitter.com/R0lVJhcpkD— Kazu SUZUKI (@kz_suzuki) 2022年9月9日 「一緒にやってもいいよ～」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました！ みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。 ということで、以下に公開します！ docs.google.com 「閲覧者（コメント可）」というアクセス権を設定しています
開発者向けのテストの本いろいろ
なんかおすすめなテスト本ないですかねえ？ と、某所で（テストをメインの業務にするのではなく）普通に開発をされている方に聞かれたので、 プログラミングは普通にできる テストについては学んだことはない とはいえテストエンジニアになるわけではなく、開発者としてテストが知りたい という人向けに、2021年現在で普通に入手できる本をいくつか挙げてみます。
スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど？ まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか？ というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ
■参考 ・JSTQB ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 ・業務でも活用できるソフトウェアテストの7原則 ・Agile Testingのエッセンス ・TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング ・テスト駆動開発 ・BDDとATDD ・The BDD Books - Discovery (Japanese Edition) ・リーダブルテストコード ・テストコードにはテストの意図を込めよう ・組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） ・質とスピード（2022春版、質疑応答用資料付き） ・【翻訳記事】テストに対する考え方「Testing Manifesto」 ・マネジメント向けアジャイル開発概要 ・The Software Testing Ice Cream Cone ・Goo
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
2021年版、サーバーレスのテスト手法を考える / Serverless Testing 2021
動画はこちら https://twitter.com/_kensh/status/1468951162053607424?s=20 サーバーレスはサクっと作れるのは良いけれどテストやデバッグが大変だって思うことはないでしょうか？ 難しさの理由としてプログラミングコードのテストだけでなく、サービスを統合した結合部分の設定、分散するコンポーネントの関係性、同期だけでなく非同期的に動作するイベントドリブンなコンポーネントのテストの方法論が浸透していない事にあるのではないでしょうか。このセッションでは実践的なサーバーレスのテスト手法やテストにおける注意点やチップスを含めてお届けします。
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。（2023年6月現在） ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
アジャイル・DevOps時代の テストと品質保証 （完全版） / Testing and Quality Assurance in Agile and DevOps Era
この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか？ 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた
テスト駆動開発：実はそれは設計技術です
テスト駆動開発（TDD）は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか？失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは本当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演
テストを書くか書かないかの状況判断 / Deciding whether to write tests - DeNA Tech Talk
2014/12/09 に DeNA 社内勉強会にお招きいただいて話した内容です
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...Amazon Web Services Japan17.1K views•66 slides
書評 『Agile Testing Condensed Japanese Edition』 〜アジャイルテストの一冊目として最適〜｜hgsgtk
Janet GregoryとLisa Crispinによる2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています！ Janet氏とLisa氏といえばAgile Testing DaysのYouTubeチャネルでも頻繁に登場しAgile Testingについてわかりやすい解説をしてくださってる 本書は訳者まえがきにあるが、著者たちの3冊の本（『Agile Testing: A Practical Guide for Testers and Agile Teams』、『More Agile Testing: Learning Journeys for the Whole Team』そして『Agile Testing Condensed: A Brief Introduction』
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
優れたテストスイートの4本の柱を学ぶ - 「単体テストの考え方、使い方」を読んだ - $shibayu36->blog;
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;に引き続き、ソフトウェアテストの知識について言語化を進めたいと考え、「単体テストの考え方、使い方」を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon この本では優れたテストスイートの4本の柱を「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」「保守しやすさ」と定義し、これらの観点で優れたテストスイートを作る方法について教えてくれる。またこの4つの柱はトレードオフの関係にあるため、単体テスト・統合テスト・E2Eテストがそれぞれどの観点を重視すべきかなどについても言語化してくれている。 自分はこの本は非常に勉強になった。なぜなら単体テスト・統合テストの指針が明快に記述されていて理解しやすく、また
学習者が、「どの資料が、どんなレベルで、どのトピックについて言及しているか」をざっくり把握できること。
ソフトウェアテスト読書マップ
ABCEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAF
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！ - ブロッコリーのブログ
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
実行環境依存のコードに対してテストを書く考え方
社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat
テストでのデータベース単位の捉えかた - 日々常々
データベース（に限らずあらゆる永続化リソース）を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat - ブロッコリーのブログ
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
Microsoft Azure、わざと障害を発生させてサービスの耐障害性を鍛える「Azure Chaos Studio」発表
マイクロソフトは、Microsoft Azure上で人為的に障害や性能低下などを発生させることで、アプリケーションの耐障害性を確認し改善できる、いわゆるカオスエンジニアリングを実現する新サービス「Azure Chaos Studio」をプレビュー版として発表しました。 カオスエンジニアリングはもともと、動画配信サービスのNetflixがAWS上で稼働する同社のサービスの耐障害性を高めるために作り出した方法論です。2012年には人為的に障害をシミュレーションするツール「Chaos Monkey」をオープンソースで公開しています。 参考：サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 このChaos Monkeyの名称などから、こうした障害のシミュレーションを用いる手法を「カオスエンジニアリング」と呼ぶよう
private 関数にもテストを書きたいとき
「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を
should i test private methods?
大企業向けビジネスの信頼を支えるために半年かけてゼロからユニットテストを充実させたら、開発者も幸せになった 工夫5選 - MonotaRO Tech Blog
初めまして、購買ソリューショングループ 運用・機能改善チームの稗田です。当社では自社で運営しているECサイト(モノタロウドットコム)から直接商品をご購入いただく他に、他社の購買システムと連携して商品をご購入いただくシステム(大企業連携システム)があります。こちらの大企業連携システムには多くのバッチ処理があるのですが、これまで自動テストがありませんでした。今回はバッチ処理の障害をきっかけに短期間でユニットテストを充実させるためにした工夫や学んだことをお話しします。 ユニットテストを作らなければいけないと思ったきっかけ 障害発生 担当システムやチームの状況 チームの1人として感じたこと お客様やステークホルダーの信頼を取り戻すために ユニットテストを短期間で作成するためにやった工夫 工夫1: 外部協力会社の力を借りる 工夫2: 課題や目的、ルールをドキュメントで共有する 工夫3: リファレンス
【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。
2021年度・2022年度 リクルート エンジニアコース新人研修の講義資料です
こんにちは。AutifyのSET(Software Engineer in Test) 、末村(@tsueeemura)です。 皆さん、E2Eテストしてますか？以前はほぼSelenium一択みたいなところがありましたが、最近はPuppeteerやCypress、TestCafeなどいろいろなフレームワークがあり、ついつい目移りしてしまいますね！ さて、どのフレームワークを使うにせよ、E2Eテストを書く上で共通で意識しないといけない重要なファクターがいくつか存在します。 その一つが ロケータ です。操作や検証の対象となる要素を指定するためのキーのことです。 ロケータにはCSSセレクタやXPathが利用でき、idやclass、name といった属性を利用するのが一般的です。 今回はこのロケータについての話を書こうと思います。 ロケータとは 要素を一意に指定できさえすればロケータに使うものは何で
AWSのフルマネージド型サービスを使ったソフトウェアの開発でローカル開発端末からアクセスキーの漏洩を防ぐためのテスト方法 | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 本記事の想定読者 本記事ではフルマネージド型サービス=IAMを使ってアクセス制御を行うサービスと置き換えられます、これらを一切使わない開発(ALB, EC2, RDSのみなど)をしている方は対象外です 本記事はAWS上にソフトウェアを構築する開発者(主にバックエンドエンジニア)や開発環境を提供するプラットフォーマーを想定読者としています Typ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリ負荷試験ガイド - withgod's blog
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
有志と #ソフトウェアテスト読書マップ を作りました！ - ソフトウェアの品質を学びまくる
「スタートアップだからテストを書かない」は正しいか - An Epicurean
リーダブルテストコード / #vstat
なぜ自動テストの導入は失敗するのか？ - プログラマーの脳みそ
ソフトウェアテスト入門 / 2022-08-30 software testing
フロントエンドテストプラクティス in open 8
ユニットテストのガイドラインを作成しました | メルカリエンジニアリング
テスト、正常系から書くか異常系から書くか - hitode909の日記
テストの説明に安易に「正しく」とか書かない - Object.create(null)
決済チームがテストコードを書く際に気を付けていること - UPSIDER Techblog
Fate/Grand Orderにおける大規模なデータベース移行と負荷試験
ソフトウェアテスト読書マップ - Google ドライブ
Should I Test Private Methods?
A/Bテスト概論 / Introduction of ABTesting
なぜE2Eテストでidを使うべきではないのか ｜Autifyブログ
ameblo.jp/kanon7811
trafficnews.jp
www.nitori-net.jp
www.scsk.jp
trafficnews.jp
pentanews.net