MasaoApril's Library.

Software Testingなネタを書いてみた。

テストチームとして工夫すること

 5年程前、所属していた開発課にテストチームが新設されたとき、私やメンバーが工夫したことを書いてみます。

テストチーム新設の話

 2009年度の日数が少なくなってきたころ、課の体制について当時の課長から「テストチームを新設する」と話があった。当時の私は、ある開発チーム内のテスターという立ち位置であったが、別の開発チームのテストを実施したり別の部署の製品をテストしていて、テスターとしてはやや異色の存在であった。

チーム編成

 当時の課長からは、「私がリーダ兼任するけど実質動く人は君なので、開発者が手に負えないテストはよろしくね!あと、派遣社員を2~3名をチームメンバーとしてJoinしますので、諸々面倒を見てくださいね!」

と、いうことで私+派遣社員3名(ベテランな方々)で色々動くことになった。

当時の課題

 私の課題は、下記3点であった。

1.本格的なテスト設計は誰もやっていない。
2.テストのノウハウの蓄積。
3.社員と派遣社員の壁。

課題に対して工夫したことは、以下です。

1.本格的なテスト設計は誰もやっていない。

 開発課の中では、テスト設計している方はほとんど聞いたことがありません。また、派遣社員も同じでした。まずは、私がテスト設計について学んで様々なプロジェクトでテスト仕様として書いて、これまでのテスト仕様(と呼べないもの)よりもテストがしやすいように少しずつ進めました。

2.テストのノウハウの蓄積

 私がテスト設計したものをテスト仕様にしますが、マインドマップで書いたものやメモをPDFなどのファイルとして残しておき、派遣社員の方にテスト仕様を説明するときに利用しました。また、インシデントレポートで「どうやってバグを見つけただろうか?」と朝のミーティングで少し議論しました。

3.社員と派遣社員の壁

 社員しか知らない開発情報がありますが、テスト実施する前に展開するとテスト実施時のリスクに対処できますし、派遣社員の方も優秀なベテランさんですのでアイディアを共有して、「我々はどう対処していくか?」を一緒になって考えていました。

テスト実施時や不具合調査時の「モニタリング」について

 私が組込機器でテストを実施する時や不具合を調査する時、神経を集中して着目していることは「モニタリング」です。電気的または機械的制御の機器は出力時間がミリ秒単位または秒単位の世界ですので、時系列の変化で結果を見てOK/NGを判断する必要があります。以下3点は、私が経験したことを差し障りのない内容で紹介します。

LED

 EthernetポートのLINK(ACT) LEDの消灯/点灯の状態を見ますが、特に点滅(消灯→点灯→消灯)の時間間隔を捉えます。私が異常を検知するときは、LEDがチカチカと点灯している状態か点滅(消灯→点灯→消灯)の時間間隔がバラバラな状態を認識した時です。一言で言うと、「いつもの点滅(消灯→点灯→消灯)と違う」です。

ラインモニタ

 RS-232/422/485のシリアル通信でラインモニタの装置を利用して、信号の出力をパソコン上に表示させます。特にTxD(送信データ)/RxD(受信データ)のON/OFF状態をタイミングチャートで見ますが、送信側と受信側で決まったやりとり(自分が「山!」と言い、相手は「川!」と返すといった合言葉のようなもの)をパターンとして頭の中に叩き込んで、いつもと違うパターンか否かを判断して、異常を検知します。

Wireshark

 最近はWiresharkが欠かせない状況で3-way handshakeを確認しますが、特に黒地や茶色地の箇所は異常なパケットとして表示されますので、フィルタをかけながら送信側と受信側のやりとりを手書きで図示して何が起こっているかを推測します。

用語における認識の違いから思うこと

用語における認識の違い

 開発業務で同僚や関連会社メンバーとの議論や社外技術コミュニティの方々との議論」を通じて感じていることですが、コンテキストが共有されていない状況で用語を使って議論すると、話がかみ合わないことが多々あります。 例えば、「テスト条件」です。

 各々のシチュエーションを以下書き出してみます。

私が社外技術コミュニティに参加する前

 テスト条件という言葉は知らない状態でしたが、当時のイメージは「テストの目的」「テストの環境(構成)」「テストの手順」「テスト結果の判断基準」の4要素でした。

JSTQB用語集を見たとき

 JSTQBのサイトにあるソフトウェアテスト標準用語集 日本語版では、下記のように記載されていました。

コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。」

 初めて上記の記載を見たとき、イメージができなかったです。原因は、自組織で聞いたことがない用語で、社内用語で該当しそうな用語が存在するか探してみたのですが、ありませんでした。

TwitterのTLで見たとき

 Togetterにまとめがありましたので、下記引用します。
 http://togetter.com/li/384359

 @akiyama924さん曰く、
「テスト(要求)分析フェーズのアウトプットで、テストすべき何か」「整理すると、テスト対象(テストオブジェクト)を分解してテストアイテムを見つけるんだけど、それだけではなく、テスト対象から離れて評価したいこともあるわけで、それらを総称してテスト条件と呼ぶのではないかと思います。それで、テスト条件≒テスト観点なのかなと。」

 「テストすべき何か」から、私は「テストを通じて確認したいこと」や「開発者が心配していること」をイメージしました。

Test.SSFのスキル基準

 ASTERのサイトにあるSSFに基づくテスト技術スキルフレームワーク スキル基準[Ver1.0]の8/15ページによると、
「第2階層:テスト詳細設計→第3階層:分析-7.テスト条件(確認項目)の設計」とあり、(粒度の大小はまちまちですが)確認項目から機能を確認する内容(例:データの送受信、ユーザ認証)のことと認識しました。

各々のシチュエーションからの認識

 「テスト条件」という用語だけでも、認識しているものは多種多様でお互いに思い描いているものは違うので、(自組織でも組織間でも)思い描いているものを共有しているかお互いに確認し合うことは大切だなと痛感しています。
 例えば、開発vsテストの対立構造は、小さな認識の違いが徐々に拡大して、お互いに理解し合うことが困難になった結果、心理的に壁を作り関係修復不能に陥ることも1つの要因と思います。

認識の違いを埋めるもの

 開発業務では、開発者と議論するときに「ポンチ絵」や「UMLに近いもの」を描いて、「私は○○と捉えているけど、□□さんはどんな捉え方ですか?」と質問して、認識の違いは何かを把握するようにしています。
 2015年夏に京都でTOCfEの認定プログラムに参加したときに「クラウド」を描きましたが、対立事項が何かを整理して、何が妨げになっているかを把握すると、認識の違いをどのように埋めるか考えるきっかけになりました。

さいごに

 相手が理解しやすいように表現するためには、様々なジャンルに興味を持って触れることだと思いました。最近の私は、殺伐とした生活になりがちなので、ある程度の気持ちの余裕が必要かもしれません...

30 Day Testing Challenge, Are You In?

 海外のTestingな世界ではどのような話題があるか気になるので、Ministory of TestingのTwitterアカウントをフォローしていますが、6/30(木)のGMT時間の投稿"30 Day Testing Challenge, Are You In"は、Testing力を高めるきっかけになると思いますので、気になったところを紹介してみます。

ざっくりとした内容

 7/1から30日間、30+1のことにチャレンジしよう!そして、自分の進捗具合をMinistory of Testingのコミュニティでシェアしよう!

 具体的な内容は、下記を参照してください。

http://www.ministryoftesting.com/2016/06/30-day-testing-challenge/

私が気に入ったチャレンジ内容

 30+1あるうちの3つを以下、紹介します。

Day13 "FIND A USER EXPERIENCE PROBLEM"

 私の現場だけだと思いますが、「過去の製品の開発資産を流用すればいいでしょ?」という仕様があり、私は「時代は変化しているのに、○年前の仕様のままで大丈夫?」というツッコミを入れることがありました。詳細は書けませんが、「製品のあるべき姿ってどのようなものだろう?」と開発者の方と議論して、仕様を改善したことがありました。

Day22 "PAIR TEST WITH SOMEONE"

 他のテスターさんが考えていることや着目点で新たな発見することがありますので、機会があればあれこれ議論しながらテストするとよいと思います。

Day30 "GIVE SOMEONE POSITIVE FEEDBACK"

 私の経験談ですが、開発者が機能追加でソースコードを書いていたので、こっそり該当部分を印刷して、ペンでデジションテーブルを書いたら、if文の判定が間違えていることに気づいたので、仕様について質問する形で聞いてみたら、ソースコードの誤りに気づき、1時間後には修正が終わっていました。また、私がペンで書いたデジションテーブルを渡したら、追加のホワイトボックステストを行って、テスト報告をしていました。

所感

 チャレンジすることをリストアップして、プロジェクトの状況に合わせて小さな工夫をしてみると、徐々に楽しくなるかなと。

※毎週1回blogを書いているのも、チャレンジの1つです。

不具合の原因を見つけること

 普段の私は、開発課でテストエンジニアとして仕様や設計の妥当性を確認する業務を遂行していますが、市場で不具合が発生したときに不具合再現するよう、開発者から依頼されることが時々あります。

 ふと不具合再現したときをふりかえると、不具合原因の手がかりを見つけるまでの時間が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技術の適用
  • つなぐための標準化、規約への関与
    • テストのための仕組みも標準に取り込む
    • テスターからの積極的な提言が必要
  • 組織的な取り組み
    • テスターの専門化や専門性強化
    • デベロッパーとテスターの役割分担の追求(デベロッパーのテスト、QAのテスト)
  • テスト環境、標準化検証環境の整備
    • テストラボ
    • コンフォマンステスト
  • テストのエコシステム
    • オープンイノベーション的テスト連携モデル
    • サービスを構成する他サービスのテスト情報の共有
  • 複数レベルのテストベッドが必要
    • バイ
    • 会社
    • 産業セグメント
    • 政府
  • プロダクトラインの知識が必要
  • ユーザが接続する方法は様々
  • 色んなものを組み合わせてテストする
  • 変化を受け入れて楽しむ

所感

 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)本セッションで行ったユーザビリティテスト

 仕様は、以下の通り。

  1. 備品
    • USB書画カメラ(用途:スマホ操作の指の動きを把握)
    • 仕切り
    • ノートパソコン
    • プロジェクタ
  2. 対象アプリ チラシ閲覧アプリ@スマートフォン
  3. シナリオ
    (新聞を購読していないので)近所のスーパーの折り込みチラシが入手しにくい状況であった。
  4. タスク
    • 近所のチラシが届くようにしてください。
    • 操作時間は、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系:アセスメント関係
(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:ツールを勉強しよう!

(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点です。

  1. キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。
  2. キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。
  3. ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。

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点を見いだしました。

「感情」

 例えば、オンラインゲームで課金したのにバグが原因でレアアイテムが入手できないことや株取引中に異常な取引データが発生して損したといった機会損失を発端とした「悔しい」があったり、画像データが消失したことで過去の思い出が一気に無くなったときの「悲しみ」があります。

次回

 これまでの話を統括しようと思います。