「忍者式テストの定義が知りたい」という意見を観測しました。 実践者の一人として、現時点の理解を記録します。 簡単に言うと？ どういうときに向いている？ どうやって実施する？ 準備 最新のプロダクトをユーザー（の立場）で操作できる環境 手動テスト項目 毎日の作業時間（数分 〜 1時間） 嬉しさ 小さなテスト手順書から始められる 発見がある テスト手順に対して プロダクトに対して 新しいバグ バグを埋め込んでから発見するまでの時間が短い 何ではないの？ 歴史 その他の参考情報 名前 おまけ 簡単に言うと？ 忍者式テストは、手動テスト手法の１つです。 開発者が、日々のテスト実施を通して テスト項目 ユーザーとしての視点 テスターとしての視点 を育てていく手法です。 どういうときに向いている？ ユーザーインターフェースのテスト プロジェクトに参加したての時 プロダクトの目的、機能をよく知らない プ

MTBF（平均故障間隔）とかMTTR（平均修理時間）とか、世の中には品質をあらわすための指標が数多く存在するようですが「バグを発見してからプログラマーに伝わるまでの時間」という指標は、あるのかな？ わたしたちのチームは、これが圧倒的に早いです。 といっても、どこかと比較したことはないのだけど、どれくらい圧倒的に早いのか、最近のツイートに補足しながら説明します。 テスターが開発現場にいるときの場合 プログレスダイアログ関連のテスト中にクラッシュしたのでその場でプログラマー(←エース級)に見せたら「お見事！」て言われて（お見事！なんて初めて言われた…しかもエースに…）とログを取るエースの横で感動してたのだけど数時間後にはコミットされ今日はもう直ってた。バグは一瞬だけ光り輝く。— miwa (@miwa719) 2016年5月26日 テストしていると（はて、これはこういう仕様なのか、それともバグ

隣のチームのベテランプログラマーSさんとバグの調査（どの操作が引き金になってるのか）をしたんだけど、特定するまでの時間が（わたし一人でやるより）断然早くて素晴らしかったな。しかもSさん、いちいち悲鳴あげるから（ああ、こういうのがソフトウェアにとって嫌なのか）が分かって良かったです。— miwa (@miwa719) 2018年8月3日 これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作（入力）が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2 プログラマーに状況を説明する おかしな状態になる前に、どんな操作（入力）をしていたのか。たまたま、関係しそうな画面を４枚ほどキャプチャーしていたので、それを１枚ずつ見せ

探索的テストを含む「テスト」をチームで共有したときに、やってみたことを紹介します。キーワードはこの４つ。 ・テストの地図（今回はこれ！） ・ペアテスト ・テストの渡航履歴 ・朝会とテストの夕会 チームでテストを共有した話 「テストの地図」はテストチャーター（のようなもの）を想像してください。 つくりはじめるタイミングは、ざっくりしたユーザー要件と、大雑把な仕様が出てきて「これから○○という機能を作りはじめるよー」というくらいのときです（プログラマーが実装してからだと遅い）。「テストの地図」は、国境と国名と主要な都市くらいしかない、白地図のようなものから、はじまります。 「こんなものを作るんだよね？」 「ここはこんなふるまいをするのかな？」 「仮にユーザーがこういう使い方をするとして、どうなるのがいいんだろう？」 「これまでのデータの持ち方を変えたりする？」 「前にこんなバグ、あったよね」

先週の金曜日にこんなことがあった。 いつものように、あるストーリーをcloseするためのテストをしていたのだけど、確認している最中に、テスト対象のプロセスが突然終了してしまった。もうこれだけでNGなんだけど、このシステムは特に複雑でね、これまでも不具合の本質的な原因が”スコープ外”と言うのかな、わたしたちが開発している部分の外側にあることが少なくない。 でもまあ、システムを使うお客様からしてみればそんなことはどうでもよくて、やりたいことができないのは、大問題ですよね。 現象が発生した直後、プログラマーMさんに見てもらい必要なログを採取してもらったのだけど、午後もやっぱりおかしい。午前中に問題が発生したときと見た目の現象はほぼ同じなのだけど、プロセスは残っている。かと思えば、うまく動くときもあってね。これは厄介だな…。 周りを見渡したらMさんはいなくて、プログラマーSさんに午前中の状況も話し

午前中に見つかったクリティカルな問題が、お昼休み前には原因が分かり一安心。 会話(問題が起きる前にどんなことをしていたか)とログでだいたいのことは分かるんだなあ。これって品質特性で言うところの「保守性(解析性)が高い」ということだよね？すばらしいなあ。 午後になって、対応してくれたプログラマSさんに「もう原因が分かっちゃったんですねー。早くてびっくりした。すごーい！」と言ったらSさん、 隣でmiwaさんがテストしながら「あ…」て言ったでしょう。気になって(コーディングする手を止めて)miwaさんの画面を見たらあれ(深刻な状態)ですからねー。その場でログとらせてもらってすぐに見れたからですよ！ なんだかわたしまでほめられた気分。うれしいな。 今回のケースは”テスターが問題を検出してからプログラマに伝わるまでの時間”がゼロでした。世の中にはこんなメトリクスがあるのかどうかわからないけど、とにか

先日、ある機能をテストしていたときの話。 いつもなら瞬時に画像が表示されるのに、今日は5秒くらい待たされる。おかしいな？と思い、別の画像で試してみるとすぐに表示された。どちらも表示自体には問題ない。画像に依存してるのかなあ…（もしかしたらそういうものかもしれない）と思ったのだけど、担当のプログラマOさんに見てもらう。 「確かに遅いですね。チケットあげちゃってください」 結論から言ってしまうと、作り方に問題があるということが分かった。（雑すぎる説明だな。大抵の場合はそうよね。） ええと、表示するときに「無駄な処理」をしてるっぽかった。 わたしはね、Oさんが問題の画像を別のテスト環境にコピーして、確認していたのを知ってる。（テスト環境に依存しているのかを切り分けるためだと思う） それから、その画像の内部的な構成を調べて、同じような画像を作っていたのも知ってる。（その遅い画像だけに起こる特有の問

普段なにげなくしている「テスト」 しっかりと学んでいる機会がなかったので、「ソフトウェアテスト」の古典として 長く使われている基本的な技法やテストの哲学について語られているJ・マイヤーズの名著、 『ソフトウェア・テストの技法 第2版』を読みました。 本著は米国で1979年に出版され、その翌年には日本で翻訳版が出版されました。 その後本日まで長い間語り継がれてきました。 JUnitなどのツールを紹介した本、その時のテスト技法について紹介する本は 雨後の筍のようにあります。ですが、 「そもそもテストとはなにか」 「テストをする際のエンジニアとして抑えておくべき姿勢・哲学はなにか」 という根本的な問に対して答えを出している書籍だからこそ、 時勢に流されずに長い間読まれてきた書籍なのかなと思いました。 Amazonのレビューを読んでいただいても、確かに翻訳に少し違和感があると言われれば有ります。

ソフトウェアテスト #2 Advent Calendar 2018 - Qiita 24日目の記事です。 qiita.com はじめに 医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。うち１５年くらいはプログラマー、現在はテスターとして日々奮闘中です。 私は開発現場で感じるちょっとした『違和感』を大切にしています。風邪のひきはじめに「なんとなくだるい」「鼻がツンとする」「喉が痛い」「寒気がする」というような違和感を感じた時、症状がひどくならないよう行動を変えるのではないでしょうか。それと同じようにソフトウェア開発の現場で感じる違和感も『注目すべきシグナル』と捉え、活動のきっかけにしています。 この記事では 何を見て違和感をつかまえているのか 違和感をつかまえやすくする工夫 違和感をつかまえたあとのこと 違和感をつかまえるために知っておくと良いこと について記載

「アジャイルなプロセスでやっています」といった台詞はよく聞く。しかしテストの重要性や方法論について力説してくれる人は多くない。 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践) 作者: Janet Gregory,Lisa Crispin,榊原彰,増田聡,山腰直樹,石橋正章出版社/メーカー: 翔泳社発売日: 2009/11/28メディア: 大型本購入: 3人 クリック: 142回この商品を含むブログ (53件) を見る これを機に体系的に勉強してみようと手に取った一冊。内容以前に4,800円という価格と一部の翻訳にやや難があるように感じた。誰かもう少し安く読み易い本を出してくれないだろうか。エキスパートな先輩によれば「名著」だそうですが。 この本の特徴は冒頭の p. xxvi より テスト実施とテスト

# -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================

最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が