タグ

テストに関するmasakielastic2のブックマーク (34)

  • 開発者視点のテストとユーザ視点のテストの違いについて|Tsuyoshi Yumoto

    この原稿は、2009年6月に発売された、システム開発ジャーナルvol10の特集「特集1 困ったら読む! 困る前に読む! 今すぐ使える エンジニアのためのソフトウェアテスト術」の総論(最初のまえがきみたいなもの)の後半部分として執筆したものです。この特集は私が豆蔵に在籍していたころに、大西さんと私で企画したもので、多くのイケてる技術者の方々にお願いして各パートを執筆してもらったものです。以下が目次です。 総論 ソフトウェアテストの現状と知っておくべきこと Part1 独立したテストチームとしてのテスト計画・テスト設計仕様 テストをスムーズに行う?管理者のための“段取り”術 品質を向上させるためのインシデントレポートの書き方 テストツールの活用 自動化できる/できないの判断のコツ Part2 開発者による開発者のためのDeveloper Testing OSSのツールを使って静的テストを自動化

    開発者視点のテストとユーザ視点のテストの違いについて|Tsuyoshi Yumoto
  • Test Doubles - Fakes, Mocks and Stubs.

  • モダンなテスト管理プロセスのためにテスト管理ツール3つを比較検討したはなし | メルカリエンジニアリング

    こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。 テスト自動化をすすめるにあたり、効率のよいテストを作るために、既存のテストケースについて調べる機会がありました。その過程で現状のQAプロセスも確認したのですが、以下のようなテストケース管理の課題があることがわかりました。 それぞれのテストエンジニアが、それぞれの方法で、それぞれのテストケースを管理しているため、ナレッジが横につながりにくい。 共有されているリグレッションテスト項目の更新が追いついておらず、情報が古くて使いにくい。 人数が増えてきて、ふりかえりや改善がやりにくい。 1については、現在、職能横断的なチーム構成になっているため、プロジェクトやプロダクトに集中できる環境である反面、それぞれのチームにいるQAエンジニアどうしのつながりが薄れてしまうことが原因に感じ

    モダンなテスト管理プロセスのためにテスト管理ツール3つを比較検討したはなし | メルカリエンジニアリング
  • メルカリのQAでTPI NEXT®をちょっと導入してみた話 | mercan (メルカン)

    こんにちは。メルカリQAチームの米山です。 今日はQAチームで現在進めている活動の一つ、「TPI NEXT®」に沿ったプロセス改善の話をしてみたいと思います。 メルカリのQAチーム どんなことをやっているのか QAチームのメンバーは現在9名。検証対象は日版のアプリは勿論、US版アプリ、WEB版、CSツールなど様々です。メルカリでは、アプリの機能ごとに開発チームが別れており、QAメンバーがそれぞれのチームに所属し、各々の案件を担当しています。 メルカリのQAチームについては、こちらの記事でも紹介していますので、ぜひご参照ください。 mercan.mercari.com TPI NEXT®とは? TPIはTest Process Improvementの略で、オランダのSogeti社で開発されたプロセス改善の手法です。主に欧米の企業で数多く活用された実績があるそうです。昨年日語訳された書籍

    メルカリのQAでTPI NEXT®をちょっと導入してみた話 | mercan (メルカン)
  • テストできないコードをE2Eテストを使ってリファクタリングしよう

    ユニットテストがしにくい状態となってるコードをTestiumを使ったE2Eテストを書いてリファクタリングしてみる話です。 例えば、以下のようなjQueryで書いたコードは外(テストコード)から取り出すポイントがないので、ユニットテストを書くのは難しいと思います。(そもそもViewのコードなので) 特定のバージョンでの変更点を簡単に確認できるよう、 「Aの列のラジオボタンを選ぶと同じ行より一つ下にあるBの列のラジオボタンを自動で選ぶ」 という補助機能 $(document).ready(function () { // seq: シーケンス番号 $.each(["new_version", "old_version"], function () { $("input[name='" + this + "']").each(function (idx, elem) { if (idx == 0

    テストできないコードをE2Eテストを使ってリファクタリングしよう
  • 「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD

    数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか? 私が何かを見逃したのでしょうか? 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト

    「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
  • Uncle Bobのリトル・モッカー | POSTD

    interface Authorizer { public Boolean authorize(String username, String password); } public class DummyAuthorizer implements Authorizer { public Boolean authorize(String username, String password) { return null; } } こっちは「ダミー」です。 ダミーはどういった場合に使うのですか? 実際に使用されるかどうかに関係なく、プログラムを進める時です。 例えば? テストですね。実際に使われることはありませんが、何かしらの引数を渡す必要があります。 例を見せていただけますか? はい。 public class System { public System(Authorizer author

    Uncle Bobのリトル・モッカー | POSTD
  • テスト自動化の3つの目的とROIの必要性、定義

    テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載です。 連載目次 はじめに:連載について 連載を担当しますテスト自動化研究会(STAR)の太田健一郎と申します。連載では、読者の皆さまがテスト自動化の導入理由や効果の測定をROI(return on investment、投資利益率、投資収益率、投資回収率)という観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを数回にわたって解説させていただきます。 連載の流れは以下の通りです。 テスト自動化とROI ROIの試算式の構成要素と試算式 ROIの試算式の詳細と実際 連載の対象読者は以下を想定しています。 テスト自動化を推進するエンジニア テスト自動化の定性的な効果は理解しているが、定量的な説明がうまくできないエンジニア 連載で取り上

    テスト自動化の3つの目的とROIの必要性、定義
  • Web APIを利用するiOSアプリのテスト技法 - cockscomblog?

    もう先週ですが、表題のタイトルで「Consumer Service Engineer MeetUp Vol.1 ~iOS編~」という会でお話しさせていただきました。 このようなタイトルの発表にした理由についてですが、はてなとしてお話しするということで、ちょっと硬派な方に振ってみました。結果としては良いバランスだったのではないでしょうか。 発表資料を掲載します。 また以下に発表の概略を書いておきました。ご参考ください。 前提 このMeet Upの主旨が「コンシューマ向けのWEBサービス(アプリ)の企画・開発・運営をしている会社によるエンジニア向けの講演、パネルディスカッション、懇親会を含めたMeetUpです!」となっていましたので、それではWebサービスとアプリを繋ぐWeb APIについて、それを利用するiOSアプリについて考えます。Web APIというのは古くて新しい話題で、いまや専らJS

    Web APIを利用するiOSアプリのテスト技法 - cockscomblog?
  • ユニットテスト改善ガイド | DevelopersIO

    先日、日Javaユーザグループ(JJUG)主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション(以下、CI)の導入は必要不可欠と考えられています。とはいえ、どんな組織(チーム)でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか?。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失

    ユニットテスト改善ガイド | DevelopersIO
  • 状態ではなく、振る舞いをモックせよ

    TL;DR GOOS『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト(依存オブジェクト、隣接オブジェクト)はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら

    状態ではなく、振る舞いをモックせよ
  • ユニットテストの基礎 | Remote TestKit

    ソフトウェア開発の現場で広く実施されているユニットテストについて、その目的、メリット・デメリットを踏まえた効果的な実施方法について学習します。 1. ユニットテストとは ユニットテスト(単体テスト)は広い意味で使われるようになっている言葉です。 まず、伝統的には、ユニットテストはテストレベルのひとつであり、「個々のユニットを対象とするテスト」としばしば定義されます(例えばJSTQB用語集[JSTQB-glossary.V2.0.J02])。なお、ここでいうユニットとはソフトウェアの最小構成単位を指します。例えば、ソースコードが対象であればC言語等では関数が、JavaC++等ではクラスが一般的にユニットに該当します。詳しくは後述しますが、そうした関数やクラスを一つ一つ検証していくのが伝統的なユニットテストです。 一方、他の定義として、開発者テストやアジャイル開発の分野では、ユニットテストと

    ユニットテストの基礎 | Remote TestKit
  • 『PhantomJSを使ったスマホサイトテストの自動化(前編)』

    1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。 みなさんこんにちは! スマホ版Ameba担当の川口です。 ちょうど一年前、同じようにJavaScriptを使ったテスト手法について記事を書かせていただいたのですが、今回も懲りずにまた同じようなテーマで再登場いたしました。 JavaScriptのテスト手法 さて、スマホ版Amebaの全面リニューアルから早くも1年経ったのですが、今回はそんなスマホ版Amebaで日々自動テストツールとして活躍してもらっているPhantomJSを紹介させていただきます。 長い記事になるため、今回は前編・後編に分けて以下のような構成でお送りいたします。 ●前編 ・Phanto

    『PhantomJSを使ったスマホサイトテストの自動化(前編)』
  • GitHub - webdriverio/webdriverio: Next-gen browser and mobile automation test framework for Node.js

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - webdriverio/webdriverio: Next-gen browser and mobile automation test framework for Node.js
  • Introduction | Frisby

    Frisby makes REST API testing easy, fast, and fun. Frisby.js comes loaded with many built-in tools for the most common things you need to test for to ensure your REST API is working as it should, and returning the correct properties, values, and types. When you need something custom, Frisby.js also provides an easy way to customize and extend assertions to make your job easier, with less repetitiv

    Introduction | Frisby
  • アジャイルチームのテスターと開発者の協力関係を改善するには

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    アジャイルチームのテスターと開発者の協力関係を改善するには
  • JavaScript Unit Test Why? What? How?

    第38回HTML5とか勉強会「Webアプリ×テスト最新事情」の発表資料です。 https://html5j.cloudfoundry.com/event/sd38

    JavaScript Unit Test Why? What? How?
  • Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT
    masakielastic2
    masakielastic2 2013/03/13
    何をテストすべきであるかという目的の観点からプライベートメソッドが不要であるのことの説明およびリファクタリングのすすめ。
  • ASTER テストツールガイド改訂WG(Test Tool Guide Working Group)

    HOME > 事業内容 > テストツールガイド改訂WG(Test Tool Guide Working Group) テストツールガイド改訂WG(Test Tool Guide Working Group) 特定非営利活動法人 ソフトウェアテスト技術振興協会(以下、NPO法人ASTERと表記する)では、「テストツールまるわかりガイド」Version 2.0.0を、2020年9月末日に公開しました。 2012年、NPO法人ASTER テストツールWGにて、「テストツールまるわかりガイド(入門編)」Version 1.0.0(以下、Version 1.0.0と表記する)が公開されました。この公開から年月が経過したことを受け、読者が最新の情報を入手できるよう、改訂を行い、公開するものです。 「テストツールまるわかりガイド」Version 2.0.0では、プロプライエタリのテストツール(企業が販売

  • テスト設計の自動化(1)組み合わせテスト支援ツール

    10月公開の特集「テスト実装・実行の自動化」では、主に単体テストとGUIテストに焦点を当て、テストの実装や実行の自動化について解説しました。これらはテスト自動化の分野ではかなり成熟してきているものです。 今回からは、テスト実装・実行に比べてまだ発展途上である分野について、今後の展望も交えながら解説していきます。以下ではまず、「テスト設計の自動化」について紹介していきましょう。 6種類のテスト設計自動化ツール ソフトウエアテストのプロセスは、(1)テスト計画/管理、(2)テスト分析、(3)テスト設計、(4)テスト実装、(5)テスト実行、(6)テスト結果の評価、の六つのアクティビティーに分けることができます。今回対象とするテスト設計は、テスト分析によって洗い出されたテスト条件を、漏れがなく、かつ無駄のないテストケースへと落とし込んでいく作業を意味します。 テスト設計を自動化するツールは、その用

    テスト設計の自動化(1)組み合わせテスト支援ツール