不具合の原因を見つけること
普段の私は、開発課でテストエンジニアとして仕様や設計の妥当性を確認する業務を遂行していますが、市場で不具合が発生したときに不具合再現するよう、開発者から依頼されることが時々あります。
ふと不具合再現したときをふりかえると、不具合原因の手がかりを見つけるまでの時間が1～2時間後であり、どうやったら不具合原因の手がかりを短時間で察知できたのか、要因を少し考えてみようと思います。
不具合情報を入手した直後
開発リーダから、不具合に関連した情報を電子メールで展開されます。受け取った情報から、不具合発生時の環境を裏紙で図解し、必要な機材を10分程度で列挙します。必要な機材をかき集めながら、構成や設定内容を頭の中で大まかなテストケースとして具象化します。
不具合発生時の環境を構築しているとき
不具合再現の手順を洗い出すため、あらゆる操作やシステムの入出力の候補を2～3列挙します。同時に手順の流れを頭の中でシミュレーションします。
不具合発生手順を洗い出しているとき
一連の操作を行い、システムの出力を監視していて「あれ？」と感じたときに手を止め、手順を巻き戻して再現できるか確認します。なお、「あれ？」と感じているときは、システムが停止して何らかの損失(金銭、時間、安全のいずれか)が発生して、不快な感情が出たときです。
不具合再現後
インシデントレポートをまとめる要領で、開発者に報告するためのメモを作成して、開発者の目の前で不具合を再現して、開発者と不具合のメカニズムを解明するために、さらに不具合再現を進めます。
開発課に所属しているテストエンジニアの役割
「見えないものを見えるようにする」ことが重要かなと思います。
「ルビィのぼうけん」を読んでみた
2016年5月に翔泳社から発売された「ルビィのぼうけん」がネット上で話題になっていたので、購入して読んでみました。
内容はまだ読んでいない方もいらっしゃると思いますので伏せますが、「コードは出てこないプログラミングの絵本」ということで、大人な方も楽しめる内容です。
私が学んだことを以下に書いてみます。
(1)段取りを決める
プロジェクトを進めるためには、ゴールを明確にすると共にゴールまでの過程を図(例:PFD)で可視化してメンバーと共有できるようにすることです。
(2)要求が抽象的だと実現したいことができない
ざっくりな要求では目的を果たせなくなります。要求から目的が分かれば、要求を実現するための手段を検討できるので、分析の切り口を変えたり分類して本質を捉えられるようにします。
(3)タスクを実行できる段階まで分解＆論理的に組み立てる
(1)や(2)が実現できるように本質的なところ(素材)まで分解して、目的を果たすための段取りや確認することが明確になり、プロジェクトのゴールへ向かって進めることができます。
(4)条件を明確にする
世の中、一方向ではなく枝分かれしたり、繰り返したり、飛んだり、戻ったりします。目的を果たためには、段取りの途中に判断することが必要なことがありますので、○○の場合は□□を行うというように条件を挙げます。挙げた条件は、デジションテーブルで表現してMECEを確認することも大切です。
(5)再現できるように形にする
同じ入力を処理をして同じものを出力するためには、再現性が必要です。そのためには、アルゴリズムとして第3者に伝えることが求められます。ドキュメントを作成する目的の1つは、誤りなく再現できることですので、再現が必要なものを見極めて書き残すことは大切です。
(6)数学の集合論や論理学を学ぶ
ソフトウェアは、数学なんだなと改めて思いました。私がデジションテーブルを書き始めたとき、条件の抜けが多々ありました。何故、条件の抜けがあるのか原因を考えたとき、「条件を洗い出すときにベン図で書くと条件の抜けがみえるのでは？」「論理回路の授業のときに真理値表をたくさん書いて理解を進めていたなぁ...」ということに気付き、大学時代に授業で使用した集合論や論理学の教科書とデジタル回路設計の教科書を読み直し、業務でデジションテーブルを何度も書いたら、条件の抜けに気づくことができました。
数学に限らず、大学で学んだ学問を業務で応用できると、楽しくなると実感しました。
最後に
久々に夢中になって読んだ書籍でした。業務で課題を見つけたら、解決するための手段が世の中にどれだけあるかを知り、社外勉強会や自学で素振りをガンガンにやってみて気付きを得て、課題を解決できるかチャレンジすることで業務の幅が広がったと実感しています。学びの楽しさを若手からベテランのメンバー伝えることも開発課に所属している私の役割かもしれません。
書籍に戻りますが、本書のサイトも楽しいですが、原書：Hello Rubyのサイトのコンテンツが知的好奇心をくすぐるので、時間があるときに見てみようと思います。
JaSST'16東京(4)「時代の変遷と共に変わるテスト ～IoT世界に求められるテスト～」
2016/3/8(火)～9(水)に開催されたソフトウェアテストシンポジウム'16東京(JaSST'16 Tokyo)に参加しました。私が参加したセッションの内容で印象に残ったことを数回に分けて書いていますが、今回が最終回です。
クロージングパネル「時代の変遷と共に変わるテスト ～IoT世界に求められるテスト～」
(0)セッションの資料
http://jasst.jp/symposium/jasst16tokyo/report.html#closing
(1)IoTの定義
インターネット上のサービスと接続されたデバイスあるいは相互接続されたデバイスによって実現されるサービス。
(2)Jeepハッキング
Hackerが3G回線からECUに接続し、内部コマンドで車内制御ができる。
※補足：WIREDの記事
HACKERS REMOTELY KILL A JEEP ON THE HIGHWAY - WITH ME IN IT
(3)各立ち位置のIoTの課題
- クラウド
- 様々なサプライチェーンと繋がる。
- クローズなネットワークから広がっていく。
- 想定外を排除できるか。
- エンタープライズ
- 繋がるから繋がった上で何するか？
- テスト対象の見極め。
- ビジネス視点での評価。
- デバイス
- IoTを支える個の十分性の保証。
- 何をどうテストするか？
- 他をチェックする境界線は？
- 外側の不安：得体の知れないものの脅威、大量データ。
- 内側の不安：個人情報のデータの扱い、隠蔽対象、システムライフサイクルを超過した使用、どこにでも置かれている、帯域の限界。
(4)課題(脅威)に対して我々ができること
- 自分の持ち分のところでやる。
- 繋がる相手を信用しない。
- 仕様通りのデータが来ない前提で。
- 脆弱性：本質はバグなので、バグをなくすこと。
- 弱みを晒さない。
- リスク高い使われ方を防ぐ「サーキットブレーカ」の役割を設計から検討する。
(5)課題解決のために
- テスターが持つべきスキル/素養
- テスト技術の研究成果の活用
Componet-based Testing技術の適用 - つなぐための標準化、規約への関与
- テストのための仕組みも標準に取り込む
- テスターからの積極的な提言が必要
- 組織的な取り組み
- テスト環境、標準化検証環境の整備
- テストラボ
- コンフォマンステスト
- テストのエコシステム
- オープンイノベーション的テスト連携モデル
- サービスを構成する他サービスのテスト情報の共有
- 複数レベルのテストベッドが必要
- デバイス
- 会社
- 産業セグメント
- 政府
- プロダクトラインの知識が必要
- ユーザが接続する方法は様々
- 色んなものを組み合わせてテストする
- 変化を受け入れて楽しむ
所感
IoTやIndustrie4.0という言葉が自組織でも浸透しつつあるが、同時に市場でバグが発生したときに被る損害(健康面、金銭面、時間面)のインパクトは強く広範囲になりつつあると実感しています。これまでの開発資産を流用して機能追加の開発を行いますが、ビジネスや生活スタイルの変化やリスクを何も考えずに開発資産を流用した場合、特定の使い方で機能が損なわれて快適に利用できるどころか害になることを目にしています。
ソフトウェアのアーキテクチャは時代に合わせて変化する必要がありますが、テストも同様にテストアーキテクチャを変化する必要があります。これまで先人が作成したテスト仕様を今の自分だったらどう考え、どうテストするかを見直すと3年先のテストをどう工夫するか楽しみながら進められると思います。
テストに留まらず、開発技術やビジネスの知識、法律や心理学といった学問などの知見を広げることが必要だなと思います。まずは、放送大学を視聴してみるのもアリかなと。
JaSST'16東京(3)「UX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSST」
2016/3/8(火)～9(水)に開催されたソフトウェアテストシンポジウム'16東京(JaSST'16 Tokyo)に参加しました。私が参加したセッションの内容で印象に残ったことを数回に分けて書いてみます。
JaSST'16 Tokyo 企画セッション:「UX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSST」
(0)セッションの資料
http://jasst.jp/symposium/jasst16tokyo/report.html#plan9
(1)ユーザビリティテストの基本
- 作業課題(※)を提示して、実行過程を横で観察するだけ。
※例：ECサイトで好みの商品を1つ購入してください。 - 被験者は、思考発話(思ったことを口に出すこと)しながらタスクを実行してもらう。
理由：発話が無いと認知のプロセスが分からないため。
(2)ユーザテストの観察ポイント
- 効果
ユーザが実現まで到達できるか？ - 効率
ユーザがなるべく遠回りせずにタスクを完了できるか？ - 満足度
文字が読みづらいか？
(3)ユーザビリティラボ(UXラボ)
- 従来の環境
- マジックミラーがある大がかりな部屋。
- 4週間の工数で200万をかけ、専門家による分厚い報告書で重厚に分析されている。
- 「これで十分」な環境
- 部屋の片隅で十分。
- 身近な道具(高価な機材が無くても手作りでOK)で十分。
- 手軽に分析(専門的な手法を駆使しなくてもよい)で十分。
(4)本セッションで行ったユーザビリティテスト
仕様は、以下の通り。
- 備品
- USB書画カメラ(用途：スマホ操作の指の動きを把握)
- 仕切り
- ノートパソコン
- プロジェクタ
- 対象アプリ チラシ閲覧アプリ＠スマートフォン
- シナリオ
(新聞を購読していないので)近所のスーパーの折り込みチラシが入手しにくい状況であった。 - タスク
- 近所のチラシが届くようにしてください。
- 操作時間は、10分程度とする。
(5)進行時の配慮
ユーザビリティテストを行うときに、以下のような配慮があるよい。
- 「○○さんではなく、アプリユーザとしてみてます」とユーザビリティを行うときの前提として説明する。
- 被験者がリラックスしてユーザビリティテストができるよう、進行者がインタラクティブに質問や会話したりするとよい。
- 「普段と同じようにスマホを操作してください」
- 「操作に戸惑っていても気になさらないでください」
- 「チラシをめくってみてどうでした？」
- 「アプリ評価はいくつつけますか？」
- 「この後、アプリを使いますか？それとも削除しますか？」
(6)おわりに
- 発話と行動を観察して、問題をみつける。
- ユーザテストは、測定するだけ。
- 上記2点の後、Learn→Buildで解決案を考えたら、もう一度ユーザテストして、問題が解決できたか検証する。
所感
ユーザビリティテストは、業務で経験したことがないですが、地域の勉強会コミュニティで試行したことがあります。勉強会メンバー同士でユーザビリティテストを行ったとき、思考発話が円滑にできる方とそうでない方で二分しました(※私は思考発話が円滑にできなかったです)。当時をふりかえると、普段とは違う環境で多少の緊張があり思考発話するときの障害になっており、思考発話しやすいように進行者が被験者に発話を促すことが課題でした。雑談して被験者がリラックスでき、何を感じているかを引き出すようなトーク力が必要だなと思いました。
また、書画カメラを利用するとビデオカメラでやや大がかりにセッティングしなくても、パソコン上でモニタリングや録画できるので準備が容易かつ低コストで実験環境が構築できるので、業務で試行して開発の上流工程に改善のフィードバックできるような気がしました。
JaSST'16東京(2)「テストプロセス改善技術から探るテストの改善とは」
2016/3/8(火)～9(水)に開催されたソフトウェアテストシンポジウム'16東京(JaSST'16 Tokyo)に参加しました。私が参加したセッションの内容で印象に残ったことを数回に分けて書いてみます。
JaSST'16 Tokyo 企画セッション:「テストプロセス改善技術から探るテストの改善とは」
(0)セッションの資料
下記、JaSST'16東京のサイトに掲載されています。
http://jasst.jp/symposium/jasst16tokyo/report.html#plan2
(1)テスト改善技術比較
(1-1)TMMi
- 成熟度モデル。
- 未達成のところが可視化できること。
(1-2)TPI Next
- 自己評価と自己評価に基づく自己改善であり、プロセスだけを評価するのではない。
- 16のキーエリアを評価。
- プロセスではない。
- 3つのグループ
- ステークホルダーとの関係
- テスト管理
- テスト業務の専門性
- チェックポイントの塗りつぶし状況から改善の計画が立てられる。
(1-3)ISO33063
- アセスメントモデル
- ISO29119-2
- 対象プロセス
- プロセスに対して当てはまっているか？
- ISO/IEC33020
- プロセス測定方法
- ISO33000系:アセスメント関係
- WTO/TBT協定
- 技術障壁があってはならない
(1-4)TQM
- JIS9005を参考に...
- すべての質を上げる(お客さんだけでなく組織も)
- 明日から少しずつ改善(工夫)
- ベストプラクティスをみんなで取り組む
- おかしさをパターン化する
(2)議論：テスト改善技術の導入
- プロセスだけじゃダメ。
- ○○の達成度やキーエリアを定義してみる。が、あるものを利用すると楽かも。
最後の最後でカスタマイズすると、各々の組織のTPI NEXTになるのでは？ - ISO33063は、アセスメントするのみ。
どうするかは別。 - TMMi
進め方は各組織で違う - CMMIはプロセス？
(3)安達氏からの分析
- モデル自体が難しい
TPI NEXT：チェックリストに回答するところからやってみては？ - 反対派
- プロセス標準化にコンセンサスできるのが大切。
- 尖ると開発などと上手くいかない。
- 自分たちが何に困るかを共有するのが大切
- 手法や手段より、問題に着目すべき
- 困ったときに考える
困っていることを認識し、環境をつくると勝手に改善する(場作り)。 - モチベーションがない
- 他プロセスとのつながりが？
所感
私が本セッションに参加した目的は、テストプロセス改善の考え方やアプローチはどのようなものがあるか知るためです。製造業系な企業だとTQMが親和性がありそうですが、TMMiやTPI Next、ISO33063で開発現場で実践できそうなところがあると思います。
知見のポインタとして、勉強会コミュニティやワークショップでslideshare(例えば、テストプロセス改善モデルの最新動向(山崎氏＠第14回SPIトワイライトフォーラム)やTPI NEXT ざっくり概要(池田氏＠長崎IT技術者会 第7回勉強会)、TPI NEXT入門(井芹氏＠WACATE2015冬)、)の資料がまとめられていますので、概要を理解しつつ、文献にあたってみようと思います。
その前に、「困った、どうしよう･･･。」という方が開発チーム内外でみつけることが必要ですが...
JaSST'16東京(1)「Software Test Challenges in IoT devices(IoTデバイスにおけるソフトウェアテストの課題)」
2016/3/8(火)～9(水)に開催されたソフトウェアテストシンポジウム'16東京(JaSST'16 Tokyo)に参加しました。私が参加したセッションの内容で印象に残ったことを数回に分けて書いてみます。
基調講演「Software Test Challenges in IoT devices(IoTデバイスにおけるソフトウェアテストの課題)」Jon Hagar(Grand Software Testing)
(1)Pattern1:モデルベーステスト
- UML
UTPの拡張 - 適用が進んでいる分野
電気通信/金融/自動車/航空宇宙 - 自動テストと組み合わせる
- ハードウェアテストする前にモデルでテスト
全部で無いがかなり自動テストできる
(2)Pattern2:数学ベース
- データ分析
数学が必要 - サンプルの問題(Androidの場合)
- 市場のセグメント
- アプリは動くはずだが、違うデバイスでもテストするか？
- ルータ、通信チャンネル、プロトコルを組み合わせるとものすごい量になる。
- Statistical Math Tool：ツールを勉強しよう！
- 組み合わせテスト:PICTなど
- 実験計画法:Taguchi method
- Fazzテスト
- 統計的サンプリング:ビッグデータの専門家の学習ツール
- ブラックボックステスト:境界値/ドメイン分析
(3)Pattern3:スキルや経験ベーステスト
- 探索的テスト
- 後援者が直感でテスト:テスターが知っているパターン
- 仮説を立てる→実験計画
- 性能テストも探索的テスト
- クリエイティブなテスト
- Attack:ソフトウェアの型紙/デザインパターン
- 探索的テストは、ハードウェアテストにも使える
- IoTでの探索的テスト
- 素早いフィードバック
- サンプリング:"Exploratory Software Testing"にもアタックパターンがある
(4)Pattern4:標準ベーステスト
- IEEE1012-2012
- ISO29119
- OMG UTP
(5)これから
- IoTが進化すると、アタックパターンも変わる。
- Seruity and Privacy
Jeepのハッキング - The Current Security Situaltion
- 議会でも問題に
- セキュリティ問題
- 359のうち、88が高リスクの問題
- Security Errors
- セキュリティアタック
- プライバシー:セキュリティとは違う
- 解釈によっては、個人情報をアクセス
- Testing Option for Connectivity
- ミスから学ぶ
- 対応を早くする
- すぐに修正:数分や数日の世界
所感
世界的トレンドや技術の進化により、製品の取り巻く世界が変化する。これまで、CPM(Copy&Paste Modify)法でテスト仕様として通じていたが、今となっては弾の無駄遣いで無力化する。日々、開発技術もテスト技術も進化が必要だと思う。3～10年先の世界を想像しつつ、技術書から得られた知見から開発現場でじわじわと試行して、得られた結果から次に工夫することを思考することを続けよう。
ピクサー展を通じて思ったこと
「トイ・ストーリー」など映画の制作過程で描かれていた展示物を鑑賞して思ったことは、ソフトウェアテストやレビューに応用できそうなネタがあることです。具体的には下記3点です。
- キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。
- キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。
- ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。
1.キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。
私がテスト分析するときは、テスト実行のイメージが具象化するまで、製品と製品の周りの世界を裏紙にポンチ絵で描いては捨ててを繰り返しています。通信機能を有するソフトウェアの場合、送信と受信のやりとりをハンドシェイクのように描いて、開発者にソフトウェアで実現したいことを確認しています。後々、テスト条件で抜けや誤りが無いよう、テスト実行して確認したいことを満たせるようなテスト仕様へブラッシュアップします。
2.キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。
外部仕様に記載されていることを「○○であること」とコピー&ペーストして内容を少し変えただけのテスト仕様にするのではなく、たとえば機能Zの設定Aと設定Bのパラメータが連動しているので、設定Aが変化したとき設定Bがどう変化して、機能Zはどうふるまうのか、外部仕様の要素を分解して要素間の関係を確認してから、機能αと機能Zの関係を確認しています。
3.ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。
外部仕様でお客様の利用シーンが上手く描けていないだけでなく、誤っていたり、機能として意味がなかったりするので、1.のポンチ絵をフローにしてから「機能Zは、□□のふるまいをして、ユーザーは△△という出力を提供しますか？」といった質問を繰り返しながら、開発工程の早い段階で欠陥を発見するようにしています。
さいごに
自分の興味あるものや過去に学問として学んだこと、趣味といった自分の活動から、ソフトウェアテストに限らず開発全般で応用できることがありますので、ソフトウェアテスト(開発全般)が楽しくないと嘆くよりは一味工夫してみて、ソフトウェアテスト(開発全般)が楽になったりミスが減ったりして、やってみてよかったと感じることも大切だなと思いました。
「探索的テストで工夫したこと」(5)総括
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分けて書きましたが、今回が最後です。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
masaoapril.hatenablog.com
masaoapril.hatenablog.com
全体像(再掲)
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
総括
探索的テストで具体的に行っていることをステークホルダに理解頂くため、1枚絵で表現できないか2年程検討を重ねました。1枚絵を描いてみると、自分が考えていることが俯瞰できるので、「独自に工夫していること」「工夫の余地があるところ」「上手く表現できないこと」が明確になったので、さらに工夫すべきことや自分が弱いところが何か明らかになったと思います。
1枚絵を描くことは、探索的テストに限らずスクリプトテストや開発全体で明日以降に工夫することもできますので、技術の棚卸しに最適です。
一言で探索的テストと言うが...
これまでのソフトウェアテストシンポジウム(JaSST:Japan Symposium on Software Testing)で探索的テストに関する発表がありますが、各々で取り組まれている探索的テストは私が1枚絵で描いたものと違うところもあるし、共通するところもあるかもしれません。製品の分野も異なるし、開発の背景も千差万別ですから様々な形があると思います。各々の違いを認めながら、開発で工夫できることを切磋琢磨できればと思いますので、忌憚のないご意見を頂ければ幸いです。
「探索的テストで工夫したこと」(4)探索的テスト実施後：学習
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
masaoapril.hatenablog.com
[3]探索的テスト実施後：学習
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
合否判定基準
合否判定基準となるのは、「製品のあるべき姿」がベースになります。例えば、製品やサービスがあることで人やモノの流れ、社会システムにどう変化するかを企画書からくみ取ったり、仕様を検討しているエンジニアが思い描いているものを聞いてみたりします。また、バグが発生することにより人やモノの流れ、もしくは社会システムにどのような影響があるか、想像します。
「製品のあるべき姿」と前回の探索的テスト実施中：観測で得た情報から、テスト実行結果がOKかNGかを総合的に判断します。
問題点
当時、「過去の経験知」「損失」「感情」が絡み合って具象化したものが問題点であると考えていました。前述の3点の他に要素があると思いますが、その要素が何か言語化できないため、モヤモヤしているところです。
「過去の経験知」
バグの発生原因やプロジェクトの失敗事例を挙げましたが、一言で言えば苦い経験です。製造業のメーカーで安全衛生教育として定期的に実施しているKYT(危険予知トレーニング)の絵(「何の危険がありますか？」「このあと、作業者はどうなると思いますか？」)をイメージしていました。
「損失」
過去のプロジェクトや航空会社の搭乗システムが止まってフライトができないような社会的なニュースから、何の損失があるか考えたときに「時間」「金銭」「健康」の3点を見いだしました。
「感情」
例えば、オンラインゲームで課金したのにバグが原因でレアアイテムが入手できないことや株取引中に異常な取引データが発生して損したといった機会損失を発端とした「悔しい」があったり、画像データが消失したことで過去の思い出が一気に無くなったときの「悲しみ」があります。
次回
これまでの話を統括しようと思います。
「探索的テストで工夫したこと」(3)探索的テスト実施中：観測
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
[2]探索的テスト実施中：観測
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
探索する目的や手段や探索するスコープ
前回の探索的テスト実施前：情報収集で収集した情報や過去のテストで分かったことを踏まえ、テストで何を知りたいか、知るためにどのような手段を講じるか、現時点での(プロジェクトで確保している)工数でどの範囲でテストを行うかを勘案し、探索する目的や手段や探索するスコープを決めます。
データ出力
テスト実施中に着目するデータをいくつか決めておきます。開発している製品やサービスによって異なりますが、Wiresharkで取得したパケットデータ(TCP/IPなど)の特定部分の変化を観測したりします。アプリケーションソフトでは、バイナリデータとして画像も観測します。
物理的出力
組み込みシステムでは電気的出力として、視覚的なもの：Ethernet PortのLEDの点灯/消灯の時間間隔、聴覚的なもの：電気的スイッチのリレー音(例：車のウィンカーのカチカチ音)の時間間隔や音の大きさ、触覚的なもの：マイコンチップや電源回路から発せられる熱といった人間の五感(センサ)として観測しています。
普段の生活の中で観測した出力をどう研ぎ澄ませるか？
電車通勤では、自動改札機でICカードを読取り部にかざしますが、ICカードと読取り部の距離を5mm余分に離したり近づけたりすることを試し、自動改札機のふるまいを見ることもよいでしょう。また、会社のセキュリティエリアでICカードの社員証をかざし、解錠音が聞こえてからドアノブのレバーを下げるまでの時間を200ms間隔で変えてみて、ドアノブのレバーが完全に下がるか感じてみるのもよいです。
次回
[3]ET実施後について、詳細を説明する予定です。
「探索的テストで工夫したこと」(2)探索的テスト実施前：情報収集
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
前回書いたこと
[1]探索的テスト実施前：情報収集
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
何故、ET実施前に情報収集を行うのか？
私だけかもしれませんが、テスト対象で不具合が隠れていると思われる機能を絞り込み、どのような手段でテストを行うか頭の中で検討するためです。また、漠然とテストしたところ、不具合を見つけることができなかったことがありましたので、「テスト対象の怪しいところは何か？」を明確にしたいと考え、「怪しいところ」に繋がる情報を収集したら、不具合が見つかるだろうと考えました。
初めに取り組んだこと
当時、インシデントレポートを多く読んでいなかったのですが、 ソフトウェアテスト293の鉄則の『鉄則055：報告の内容でテストをした“人”がわかる』を読んだ後、「発見したバグは何故修正しないといけないか？」という理由が明確なインシデントレポートを探して読んだら、「テスト対象やシステムのあるべき姿は何かを考えることができるのでは？」と考え、これまで関わったプロジェクトや同僚が関わった過去プロジェクトのインシデントレポートを印刷して読み込みました。
インシデントを何件か読んでいくうちに...
スクリプトテストを実施しながら、「バグが存在することでユーザが困ることは何か？」「どのような手段で、ユーザが困ることを見つけることができるのだろうか？」と思い始め、テスト対象に関する仕様書(要求仕様、製品仕様、テスト仕様)や過去プロジェクトのインシデントレポートを参考情報として、読み漁りました。
読み漁った後...
スクリプトテストで疲れたので、少しリフレッシュしようとペットボトルのお茶を飲んでいたとき、(「そういえば...」と)デジャブを感じるバグが何件かあることに気付きました。バグの傾向をつかみ、インシデントレポートから新たなテストケースを頭の中や裏紙に書きながらテストケースを思いついたので、試しにテストを実施してみたら、偶然バグを発見することができました。
開発者に状況を話したところ、開発者から「それはバグですね。インシデントレポートを書いて、私に送ってもらえますか？」ということで、少しずつですがバグのにおいを感じるようになりました。
次回
[2]ET実施中について、詳細を説明する予定です。
「探索的テストで工夫したこと」(1)全体像
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」の発表を行いました。これからの議論が発展することを願い、当時私が考えていたことを書き記します。
ライトニングトークス「探索的テストで工夫したこと」の以前に考えていたこと
私が考えていたことのベースになりますので、下記に掲載します。
masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
ライトニングトークス資料
全体像は、下記になります。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
図を書いた目的
探索的テストにおける私のイメージを第3者が共有しやすい形で表現し、探索的テストがad hocではなく、状況を考慮した(高度な)考えと行動であることを示したいため。また、テストを極めることは易しくないことを経営層やプロジェクトマネージャに伝え、製品品質に対するテストチームやQA組織が寄与するために考えていることを説明するため。
全体像からの概要
イメージは、探索的テストで多種多様の情報と人の五感をテスター自身が吸収しながら、テストをグルグル実施しているものです。時間軸は、1分から1時間単位でプロジェクトの状況によってまちまちです。
次回
[1]ET実施前について、詳細を説明する予定です。
【速報】State of Testing 2016の調査レポートが公開されました
"State of Testing Survey 2016"の調査レポート(英語)が先ほど公開されました。2016年1月にアンケートの回答を募集していましたが、世界中の1000名を超える方から回答されたそうです。
調査レポートは、こちらからご覧ください。
〆
