いきなり計画はNG、ソフトウエアテストの注意点
ソフトウエアテストで最初に実施するプロセスが「テスト計画」だ。よくあるアンチパターンが、最初にスケジュールを作ってしまうというもの。テストは積み上げで計画を立てないと、品質低下や納期遅延のリスクが高まる。あるSIベンダーの若手社員「ワカテくん」もテスト計画の進め方の落とし穴に陥ったようだ。 ワカテ：ソフトウエアテストの最初は計画とのことなので、早速スケジュール表を作ってみました。 センパイ：いきなりスケジュールを作ったんだ。それは結構危ないなあ。どうやってテスト設計やテスト実行の実施期間を決めたの？ ワカテ：リリース日が6カ月後だったので、そこから逆算してテスト設計を2カ月、テスト実行を2カ月としました。過去のプロジェクトもそのくらいだったので。 センパイ：本当にその期間内で終わるという裏付けはあるかな。テストが期間内に終わらないと、ボロボロの品質でリリースすることになったり、納期に間に合
ASTER-ASTER 技術セミナー
特定非営利活動法人 ソフトウェアテスト技術振興協会では、「ASTERセミナー標準テキスト」を、2018年9月1日に公開しました。 「ASTERセミナー標準テキスト」は、ソフトウェアテストの教育時に活用いただけるプレゼンテキストです。PowerPointファイル形式で提供しますので、人材育成に活用ただければ幸いです。ただし、有償のセミナーでご活用いただく場合は、活用後、どこでどのような活用がされたかの情報をNPO法人ASTER（ ）へご連絡ください。無償の勉強会や社内勉強会などでの利用は自由ですし事後報告も不要です。 特定非営利活動法人 ソフトウェアテスト技術振興協会（ASTER）は、初心者向けのテストエンジニア研修のテキストを2018年9月1日に公開しました。本テキストは、利用ライセンスに基づいて頂ければ、無償でオープンな勉強会のみならず、社内のクローズドな研修や、社外向けの有償のセミナー
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
世界基準の認定資格「ISTQB テスト自動化エンジニア認定資格」をゲットしました！ | メルカリエンジニアリング
ロンドンは歴史豊富で、町並みの綺麗な所です！ こんにちは。メルカリのAutomation & QAグループ（通称：AQA）でAutomationエンジニアをぶりぶりしている@gloriaです。現在、私は主にiOSアプリの自動化を担当しています（詳細はtadashi0713によるこちらの記事をご覧ください）。 私は先月、ロンドンで開催された「ISTQB Advanced Level – Test Automation Engineer Certification」のトレーニングコースに参加しました。 ＊ なお、この記事は、@gloriaの原文（英語）を意訳しております。原文はこの記事の下部にありますのであわせてお楽しみください。 ISTQBとは？ この認定テストはISTQB Foundation Levelの延長線上にあるもので、ソフトウェアテストと品質保証の国際的なガイドラインを提供するも
「Testing Java Microservices」の雑多な感想とConsumer Driven Contractについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Microservices固有のテストについて、ManningのTesting Java Microservicesを読んでそのまとめとその他雑多な感想、参考としたツール・発表などを書き連ねてみました。この書籍はMEPA(執筆中の書籍)でV13によります。現時点ではすべての章が執筆しているようでまた各部修正も入っている可能性があるのでご注意ください。 また、元々社内で書いたものをベースにしているのでかなり雑なのはあらかじめご承知ください。 Testing Java Microservices Chapter1 概要説明だけなの
GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ
はじめに FLAKYの内容が今はっきりした！#JaSST— broccoli (@nihonbuson) 2018年3月8日 と書い（てしまっ）たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。 JaSST'18 Tokyoについては以下のページを参照してください。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo お知らせ この記事の内容を4/11に発表しました！ nihonbuson.hatenadiary.jp 発表スライドはこちら speakerdeck.com 目次 はじめに お知らせ 目次 Micco氏のお話 ICSTでの話 基調講演「Advances in Continuous Integration Testing at Google」 講演資料 テスト文化について (3ページ付近) 回帰テスト (4ページ付近) Mil
TPI NEXT入門
ISO/IEC/IEEE 29119 Software testing 勉強会 第2回 Part 2 Test Processes
テスト計画の立て方 - Qiita
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
第4回 ブラックボックステスト | gihyo.jp
はじめに ソフトウェアテストのテクニックについて紹介する本連載ですが、今回もテストケースの作成に使えるテクニックを紹介します。限られた時間、予算の中でテストを行う際には、パターンを漏れなくダブりなく分析し、網羅性を確保しつつ効率よくテストケースを作成できるかがポイントになります。今回は、前回（第3回）のホワイトボックステストに続き、もう1つの代表的なテストケース作成技法「ブラックボックステスト」について紹介します。 ブラックボックステストとは？ ブラックボックステストとは、テスト対象の「仕様」に基づいたテストケースの作成技法です。 前回紹介した「ホワイトボックステスト」が、テスト対象の内部の「構造」、たとえばソースコードのロジックに着目してテストケースを作成するのに対し、ブラックボックステストでは、テスト対象を「中の見えない箱（ブラックボックス）」としてとらえてテストケースを作成します
Web画面自動テストフレームワーク「Geb」の紹介 - astamuse Lab
どうも、えいやです。 今回の弊社技術ブログを担当させていただきます。 会社では主に、ゴロゴロしたり、Asamuse.comのバックエンドのJavaを書いたり、AstaID.comのバックエンドとフロントエンドをJavaやJavaScriptで実装したり、他のWebアプリをたまにメンテしていたりしています。 その他には、 GitやJenkins、Redmine、テストフレームワーク、ビルドシステムなどを連動させた開発業務のフローを設計・導入したり fluentdで集めた弊社Webサービスのアクセスログを、Elasticsearchに集約・解析する仕組みを設計、導入、維持したり 解析したアクセスログをサービスとしてコンテンツにフィードバックさせる仕組みを作ったり 発明者や出願人となっている法人の名前を、適当な文字列処理と判定アルゴリズムを書いて名寄せしたり （9割がた趣味として）弊社のサービス
InfoQ: あなたがやっているのはテスティングかチェッキングか？
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
ブラウザテストをサクサク自動化するためのGeb実践入門 #jjug_ccc
JJUG CCC Spring 2016 での発表資料です。
JGiven で 100% Pure Java BDD（導入編） - Qiita
この記事は、Java Advent Calendar 2016 の 14 日目の記事です。 13 日目の記事は、tkxlab さんの「データベースを簡単にーJavaSEでもオブジェクト指向データベース（JPA）を」 でした。 15 日目は、kokuzawa さんの「HttpURLConnectionで嵌った話」です。 はじめに まず、JGiven を使用する動機について軽く述べます。 使い方を知りたいだけの方は、この「はじめに」を読み飛ばして、「JGiven が救う」から読んでください。 BDD したい ソフトウェアの開発者であるわたしたちは、当然 JUnit とかを使ってユニットテストを書いています。 しかし、以下のような課題があります。 テストの対象範囲が揃わない ユニットのテスト以外にも、機能のテストなども書きたいです。 しかし、それらを全部 JUnit で書くと、JUnit で実行
【SQiP2016】楽天のアジャイル開発とメトリクス事例
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
「自動家は見た！ 〜自動化の現場の真実〜」-システムテスト自動化カンファレンス2015「.reviewrc(おいしが)」発表枠 #stac2015
「自動家は見た！ 〜自動化の現場の真実〜」-システムテスト自動化カンファレンス2015「.reviewrc(おいしが)」発表枠 #stac2015 システムテスト自動化カンファレンス2015 (2015/12/13) の発表枠「.reviewrc(おいしが)」名義で発表した資料に「ボツ稿」を加えたものです。(時間:50分) 「.reviewrc(おいしが)」一連の資料： 1.コレ 2.「自動家は見た�～自動化の現場の真実～ SIDE：マネージャ」http://www.slideshare.net/NoriyukiMizuno/stac-2015-side 公式サイト : https://4deb81d081862e256eb240be7c.doorkeeper.jp/events/34145
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://aster.or.jp/business/contest/doc/2019_OPEN_V1.0.0.pdf
テスト駆動開発入門
https://ubiteku.oinker.me/2015/12/03/tdd%E5%86%8D%E8%80%83-7-%E3%83%86%E3%82%B9%E3%83%88%E3%81%AF%E3%81%A9%E3%81%93%E3%81%BE%E3%81%A7%E6%9B%B8%E3%81%91%E3%81%B0%E8%89%AF%E3%81%84%E3%81%AE%E3%81%8B%EF%BC%9F/
【CEDEC2017】「龍が如く」が毎年発売される理由の一端はここにある？ 開発者の帰宅後に、動いていないPCとPS4で自動プレイテストを実施
組織にテストを書く文化を根付かせる戦略と戦術
