自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
「直交表」とは
直交表とは 直交表は一部実施にもかかわらず、高次交互作用の評価を断念することで少ない実験で要因効果を知るためのツールです。 工業実験の成果を上げるためにはより多くの因子を扱う事が有効ですが、原理的には掛け算で実験数が増えてしまいます。そこですべての組み合わせを評価せず、一部の組み合わせを実験して統計的に要因効果を評価するために直交表が使われます。戦後日本の製造業発展は直交表の効果と言う人もいるほど効果的な手法で、二水準系、三水準系など多くの種類があります。 ◆ 効率的な実験手順とは 【連載記事紹介】 ◆ 直交表の解説記事 ◆ 直交表のセミナー紹介
直交表とオールペア法の並行運用 によるソフトウェアテスト
直交表とオールペア法の並行運用 によるソフトウェアテスト 手法と強さ、因子、水準の 選択ガイドライン 五味 弘 辻村 浩 小池 宏道 須田 健二 OKI OKI OKI 群馬高専 JaSST’14 Tokyo 2 内容 1．はじめに(組合せテストの概要) 因子と水準の抽出 組合せとテスト回数 これまでの組合せテスト 2．直交表 定義 ソフトウェアテストへの適用 直交表生成ツールGalois 3．オールペア法 定義（カバリングアレイ） オールペア法ツール PICT 4．直交表とオールペア法の比較 因子や水準の制限 テスト回数、網羅率、網羅効率 5．直交表とオールペア法の使用のコツ 因子と水準の抽出、強さや手法の決定 事例紹介 既存の組合せテストからの移行 評価 6. おわりに 3 はじめに（組合せテストの概要） ¡ ソフトウェアテストにおける組合せテスト l 主にブラックボックステストで
複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
うちのチームのプログラマーはなぜテストがうまいのか - CAT GETTING OUT OF A BAG
うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日１時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。— miwa (@miwa719) 2019年6月24日 医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム（うちのチーム）のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…（素晴らしい）と思うことが多々あります。 うちのチームのプログラマーはなぜテスト
メルカリWeb版のUIテスト自動化で目指している世界と、そのために作った Selenium Grid・Zalenium 環境 on Azure Kubernetes Service(AKS) | メルカリエンジニアリング
メルカリWeb版のUIテスト自動化で目指している世界と、そのために作った Selenium Grid・Zalenium 環境 on Azure Kubernetes Service(AKS) メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の 根本 征 です。 私は普段、テスト自動化・CI / CD 改善・その他社内の生産性を上げるための自動化を行っています。 今回は、最近私たちが行なっているメルカリWeb版のUIテスト自動化と、その自動テスト環境についてご紹介したいと思います。 メルカリWeb版のUIテスト自動化について UI自動テスト環境に関する課題 Selenium Grid を Azure Kubernetes Service(AKS) 上で構築する Zaleniumを試す Azure Kubernetes Service(AKS)で受け
フロントエンドでTDDを実践する（理論編） - Qiita
この記事は リクルートライフスタイル Advent Calendar 2018 8日目の記事です。 2018/12/10更新：続編で フロントエンドでTDDを実践する（react-testing-libraryを使った実践編）を書きました。 はじめに 自分のフロントエンドチームでは、TDDでの開発フローを実施することでフロントエンド開発の課題に向き合っていきます。 今回は、一般的に難しいとされるフロントエンドでのテストについて、どんな方針でテストを書けばいいかについて書いてみたいと思います。 フロントエンド開発の課題 プロジェクトによりますが、テストに関連するものでは以下のようなものが挙げられます。 実装する仕様について、プロジェクト内でどう認識合わせするか？ 開発工程のリライアビリティをどう担保するか？ テストの精度、粒度をどう考えるか？（クロスブラウザ、ユーザーの操作等の副作用、コスト
世界基準の認定資格「ISTQB テスト自動化エンジニア認定資格」をゲットしました！ | メルカリエンジニアリング
ロンドンは歴史豊富で、町並みの綺麗な所です！ こんにちは。メルカリのAutomation & QAグループ（通称：AQA）でAutomationエンジニアをぶりぶりしている@gloriaです。現在、私は主にiOSアプリの自動化を担当しています（詳細はtadashi0713によるこちらの記事をご覧ください）。 私は先月、ロンドンで開催された「ISTQB Advanced Level – Test Automation Engineer Certification」のトレーニングコースに参加しました。 ＊ なお、この記事は、@gloriaの原文（英語）を意訳しております。原文はこの記事の下部にありますのであわせてお楽しみください。 ISTQBとは？ この認定テストはISTQB Foundation Levelの延長線上にあるもので、ソフトウェアテストと品質保証の国際的なガイドラインを提供するも
ソフトウェアテストのカレンダー | Advent Calendar 2016 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
テスト自動化あれこれ - bluebird
ソフトウェアテスト Advent Calendar 2016 - Qiitaの9日目エントリーです。 qiita.com エラーが「自動的に」増殖するのがDevOps To make error is human. To propagate error to all server in automatic way is #devops.— DevOps Borat (@DEVOPS_BORAT) 2011年2月26日 継続的デリバリーの核心は、フィードバックのサイクルを素早く回すことにありますが、それはユニットテストのカバレッジが十分になければ不可能です。 A/Bテスト、オートスケール、カナリヤテスト、Blue-Green Deploymentなど、DevOpsを推進する上での各種プラクティスは、いずれも、プロダクトの品質が安定していることを前提としています。品質が安定していない状態でリリ
QAアーキテクチャの設計による�説明責任の高いテスト・品質保証
テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
ソフトウェアテストについて勉強したい欲が出てきた人が見ると役に立つものまとめ - テストウフ
この記事はソフトウェアテスト Advent Calendar 2016 – Qiitaの21日目です。 前の投稿はmiwakai – QiitaさんによるSquashTMことはじめ。 – Qiitaでした。 お疲れさまです。@yoshikiitoです。 たまに会社の後輩とかから「どうやって勉強してるんですか？」と聞かれることがあります。今回はいい機会なので、自分が見てためになったもの、普段見ているものなど、ソフトウェアテストについて勉強しようと思ったときにオススメなリソースと見方・探し方あたりについてご紹介しようと思います。 ※情報収集してそうな美人画像をぱくたそから持ってきましたが、本文の内容とは関係ありません。 本題の前に簡単に自己紹介 業界の有名人じゃないので、本題に入る前に簡単に自己紹介しておきたいと思います。 興味ない方は飛ばして下に行ってください。 伊藤由貴といいます。本名です
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「
E2EテストをPhantomJSから、Puppeteer + Headless Chromeへ移行しました - LCL Engineers' Blog
Webエンジニアの森脇です。LCLでは、以前より「Capybara + PhantomJS」でE2Eテストを行っていましたが、「Puppeteer + Headless Chrome」へ変更しました。 元々は、軽くPuppeteerを触ってみるだけのつもりでしたが、できが良く本格的にE2Eテストへ導入することにしました。 本記事では、変更の経緯や、PuppeteerでE2Eテストを実装する上でのTIPSを紹介します。なお、Capybara + PhantomJSを利用したE2Eテストは、以下の記事でご紹介しております。 techblog.lclco.com 変更の経緯 PhantomJSは古めのWebkitをベースにしているため、一部のCSSがうまく適用されず、Headless Chromeへ移行を以前より考えていました。そんな中、PhantomJSの開発が終了したこともあり、移行すること
JavaScriptユニットテストの理想と現実
Talk at 関西Node学園 梅田キャンパス 1時限目 https://nodejs.connpass.com/event/82614/
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト自動化研究会の『システムテスト自動化 標準ガイド』を15倍あなたの力にする話一覧
概説 テスト分析
60分でわかった気になるISO29119 #wacate
[pdf]システム及びソフトウェア品質の見える化、確保及び向上のためのガイド