「DIは必ずしも善ではない」| Dependency injection is not a virtue by DHH
DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日本語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyのエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという（コードレビュー時のヒアリングによる）体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,
20年の歴史があるシステムにどう切り込む？ 出前館プロジェクトにおけるLINE QAチームの取り組み
LINEが定期的に開催する技術者向けミートアップ「LINE Developer Meetup」。71回目となる今回は「QA - 開発プロセス全般における品質向上」をテーマに開催しました。そこで開発3センター サービスQA室の鈴木里惇氏が出前館プロジェクトにおけるLINE QAチームの取り組みについて紹介しました。 出前館プロジェクトにおけるLINE QAチームの取り組み 鈴木里惇氏（以下、鈴木）：さっそくトークを始めたいと思います。今日は『出前館プロジェクトにおけるLINE QAチームの取り組み』という話をします。 まず簡単に自己紹介です。LINEの開発3センターサービスQA室に所属している鈴木里惇と言います。所属はQA1チームとQA4チームという2つのチームで、マネージャーをしています。 それぞれのチームの役割としては、QA1チームがLINEファミリーサービスを担当していて、QA4チーム
負荷テストの基本的な考え方と進め方(前編) - Qiita
本番前の負荷テストのお手伝いというお仕事が年に数回まわってきます。始めて負荷テストに取り組まれている方や単体での負荷テストしか経験のない方とお供すると勘違いや楽観的過ぎる計画になっていて修正をお願いさせていただくことがよくあります。 そこで、初心者向けに小生の経験から負荷テストのポイントをいくらかアドバイスしたいと思います。なお、小生は負荷テストの専門家ではないので、Qiitaに投稿されている専門家の方々の立派な記事もあわせて参考にしていただければと思います。 この記事で扱う負荷テストの定義 この記事では次の要件を対象とします。 システムテスト(総合テスト)の段階で行う負荷テスト。 分散ノードが十数台規模、データ量も数百GB程度までの中規模までのシステム。 基本はロードバランサで負荷分散するWebシステムでバックエンドにデータベースが控える構造であるが、一部C/Sもあり。 この記事で書くこ
負荷テストの基本的な考え方と進め方(後編) - Qiita
昨年早々に続きを書くつもりでしたが世の中そうはうまくいきませんね..。お待たせしてすみませんでした。 さて、前回は「シナリオ作成」のポイントまでを紹介しました。 後半は「シナリオプログラム作成のポイント」から「結果を踏まえて対策のポイント」までを一気に紹介します。 前回同様一応前置きですが、小生は負荷テストの専門家ではないので、Qiitaに投稿されている専門家の方々の立派な記事もあわせて参考にしていただければと思います。 この記事で扱う負荷テストの定義 この記事では次の要件を対象とします。 システムテスト(総合テスト)の段階で行う負荷テスト。 分散ノードが十数台規模、データ量も数百GB程度までの中規模までのシステム。 基本はロードバランサで負荷分散するWebシステムでバックエンドにデータベースが控える構造であるが、一部C/Sもあり。 この記事で書くこと 今回は6〜11を記載します。1〜5は
Agile Testing Condensed Japanese Edition
『Agile Testing Condensed』は、アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています。JanetとLisaは、読者が理解できるように、20年間のアジャイルテストの経験から知識を抽出して表現しました。 - テストとQAの専門家がアジャイルチームでどのように貢献するか - アジャイルサイクルにテスト活動をフィットさせるにはどうすればよいか - いつ、誰の責任で、様々なテスト活動を完了させるのか - テストエンジニアがアジャイル開発チームの他のメンバーと関わるにはどうすればよいか - デリバリーチームの全員が継続的なテストに参加するにはどうすればよいか - 視覚的なモデルを使ってテスト活動を計画するにはどうすればよいか - 短いイテレーションや継続的なデリバリーに対してテストが「追いつく」にはどうすればよいか - テストの有効性を評価し、継続的に改善
リスクベースドテストに使うプロダクトリスクについて｜Tsuyoshi Yumoto
リスクベースドテスト（Risk Based Testing）は、JSTQBのFLシラバスにも掲載されていますが、もう何年も前から、ソフトウェアテストの界隈では主流となる考え方になっています。 簡単にいうと、「テストってなんでも網羅すればよいってもんじゃないよね？たくさんやればいいってもんじゃないよね？」っていう考え方から、「じゃぁ、どこに注力するか？」っていうときに、開発者、QA、テスト担当者、経営者、顧客など、関係者みんなの合意をとりつけるための方法です。 多分、「どこかに注力して、どこかを捨てる」という発想はリスクベースドテストとか呼ばれるやり方が世の中に出てくる前から、私たちの多くが持っていて、何かしらやってきてました。そのやり方を合意を取り付けるところまで体系化して、名前をつけたのがリスクベースドテストの功績なんだと思います。 けど、実際は、書籍などで調べてもちょっとづつ言ってるこ
実践リスクベーステスト-PRISMAメソッド-というpdfを原著者から翻訳と公開に関して許可をとって。翻訳してみました - Qiita
実践リスクベーステスト-PRISMAメソッド-というpdfを原著者から翻訳と公開に関して許可をとって。翻訳してみましたテストQAエンジニアリスク管理 著:Drs. Erik P.W.M. van Veenendaal CISA/訳:藤原史和 システムテストフェーズに入る前のアクティビティつまり開発や単体、結合テストは遅延することはよくあることです。 その結果、システムテストフェーズにしわ寄せがゆき、大きなプレッシャーの中で実施しなければなりません。 しかし、テストをすること自体をやめたり、遅らせたり、ましてや手抜きテストなどできません。 さてあなたは、この状況をどう乗り切りますか？ 目次 1.イントロダクション 2.製品リスク管理 3.十分なテスト 4.テストフェーズにおける課題 5.製品の最重要部分を見つける 6.製品の最も悪い部分を見つける 7.PRISMAプロセス 8.PRISMAの
複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
Rails アプリケーションの不安定なテストを撲滅したい 〜system spec のデバッグ方法とテストを不安定にさせる要因〜
Rails アプリケーションの開発において、自分の変更に関係のないテストのせいで CI がコケるとストレスですよね？真っ先に直したくなりますよね？不安定なテストを直すのは大変な労力が要ると思ってませんか？実は、たいていのケースは簡単に再現確認ができるし、不安定になる要因もだいたい決まっているし、ログやスクリーンショットを見れば原因も簡単に特定できるんです！ そんなわけで、日頃不安定なテストを潰している身として知見みたいなものをまとめてみました。 今回利用した環境は次のとおりです。 rails 6.0.0 capybara 3.29.0 selenium-webdriver 3.142.4 rspec-rails 3.8.2 Google Chrome 77.0.3865.75 (headless で使用) ChromeDriver 77.0.3865.40 (f484704e052e0b5
ソフトウェアテストをガチの初歩から学ぶためのリンク集 - mhlyc -practice
この記事を書いている動機 Twitterである方が「ほとんど専門外だけどもっとテストのことを知りたい」みたいなことを書かれているのを見かけて、最初はその人に直接リプライしようかと思ったのですが、もしかしたらガチの初歩からテストの勉強したいって人は他にもいて、意外に需要あるのかも？と思ったのでブログとして書くことにしました。 目次はこちら。ガチの初心者の方でもわかるような資料を選んでいます。 この記事を書いている動機 テスト入門にちょうど良さそうなスライド（手前味噌含む） テストをやることになった新人が読むべき最初の記事 この3冊は必読。しかし最初から全てを読まなくてもいい 何はともあれ「第１章（導入部）」は絶対に読もう 「仕様書通り」だけがテストではない テストプロセスについて テスト観点 is 何 問題 テスターと開発現場 おわりに テスト入門にちょうど良さそうなスライド（手前味噌含む）
ieee829 - Google 検索
2020/03/27 · IEEE829のテスト計画書には、以下2つのドキュメントがあります。 ・マスターテスト計画（全体テスト計画書とも呼ばれ、プロジェクトの最初に作成するもの ...
品質管理とは？開発に役立つ使い方、トレンド記事やtips - Qiita
品質管理に関する情報が集まっています。現在68件の記事があります。また27人のユーザーが品質管理タグをフォローしています。
QAとは？開発に役立つ使い方、トレンド記事やtips - Qiita
QAに関する情報が集まっています。現在379件の記事があります。また105人のユーザーがQAタグをフォローしています。
小ネタ：欠陥の混入、テストレベル、工程の責務 - Qiita
1. はじめに 欠陥は後工程で摘出するほどコストが膨らむため早期に摘出するのが理想です。とはいえ欠陥の種類によって早期に見つけられるものや後工程で初めて顕在化するものがあります。例えばコンパイラのwarningや静的解析ツールで見つかる欠陥はコーディング～ビルドの工程で見つけられますがエラー処理の欠陥はエラーの状況を準備しシステム動作を行うことで見つかるかもしれません。 「この手の欠陥はこの工程で摘出する」という工程の責務を定義しようと思いJSTQB FLシラバス(Version 2018)を読んだところ「2.2 テストレベル」の節にテストレベルごとに整理されていました。そこで責務はシラバスをご参照いただくこととし、ここでは欠陥の混入やテストレベルの補足をします。 2. 欠陥の混入 ソフトウェアの信頼性(G.J.マイヤーズ、訳:有澤 誠)にソフトウェアの開発とは変換の繰り返しであることが説
仕様書をレビューしながら考えていること - Qiita
1. はじめに なにをどう考えながら仕様書をレビューしているかや欠陥を見つけるために拝借している先達の知見を挙げ、整理してみます。 2. 読み手の期待値 業務で作成するドキュメントには書き手と読み手が存在し1、高品質なドキュメントとは読み手にとって必要なことが簡潔かつ過不足なく書かれているドキュメントです。これは仕様書も一緒です。 仕様書の読み手にはプログラマやテストエンジニア、SQA、マニュアル作成者などがいますが、ここではプログラマとテストエンジニアにフォーカスします。 2.1 プログラマが欲しい仕様書 "プログラマ 欲しい 仕様書"でググると「プログラマが欲しい仕様書とは」というそのものズバリなタイトルの資料がヒットします。この資料はゲームプログラマ目線で記述されているのですが最低限必要な項目をp.31に列挙されていますので以下に引用します。 シナリオ 対象外 概要 詳細 未解決の問
QAチーム立ち上げ - Qiita
アーリー期の「スタートアップ」 企業や エクスパンションの「スタートアップ」 企業がある程度、組織として大きくなると、社内に 「QAチーム」 ビルディング構想が表面化します。 1.事業規模拡大による提供サービス品質保証（IPO計画する上でのサービス品質保証） 2.不具合レベル策定やリリース基準/リリース判定の計画 3.現状の不具合に対しての調査や不具合分析活動 4.社内の複数プロダクト一定の品質を担保やリリースフロー策定・改善 5.社内のエンジニアに対してQAの啓蒙活動 まず初めに 「組織構築」 や、「現状調査」、「人員確保」 から着手します。 ※開発・SRE・CSチームとの品質意識が大事になり、QAの一方通行が一番良くない。 「QAチームを構築」 することで何を事業品質として提供できるか。
テスト仕様書 - Qiita
単体テスト 結合テスト システムテスト（機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト（シナリオテスト） 運用テスト 現場（案件）によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト（Integration Test）以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者向けのテストの本いろいろ
サーバレス時代の負荷テスト戦略 / Load testing strategy for serverless
Device Farm を使ったスマホアプリの自動テスト
