MasaoApril's Library.

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

探索的テストモデル&FAQの正式版を公開しました@探索的テスト研究会

探索的テスト研究会よりお知らせ

 2016年3月8日(火)~9日(水)に開催された「ソフトウェアテストシンポジウム2016東京(JaSST'16 Tokyo)」のコミュニティブースで探索的テスト研究会より「探索的テストのモデル」と「探索的テストのFAQ」のβ版を出展しましたが、この度「探索的テストのモデル」と「探索的テストのFAQ」正式版をリリースしましたので、下記参照先にてお知らせします。

正式版:「探索的テストのモデル」&「探索的テストのFAQ」

謝辞

 「探索的テストのモデル」&「探索的テストのFAQ」正式版は、ソフトウェアテストシンポジウム2016東京(JaSST'16 Tokyo)のコミュニティに来場されたみなさまから頂いたフィードバックおよび探索的テスト研究会のメンバー各位のご支援によりリリースすることができました。この場をお借りし、お礼申し上げます。

さいごに

 みなさんからのご意見やご不明な点、議論したいことがありましたら、本blogのコメントに記入頂ければ幸いです。

2016年ふりかえり

 2016年も残り5分を切りましたので、簡単にふりかえります。

 今年は、社内の突発的な対応が多かったため、まとまった空き時間があまり無かったので社外活動は少なめでした。主な社外活動は以下です。

  • 探索的テスト研究会
    • JaSST'16東京のコミュニティブース出展し、探索的テストモデルとFAQのβ版を発表。
    • 探索的テストモデルとFAQに関する議論に参加。
  • 毎週1回blogを書くこと
    継続3年目となる11月まで続け、終結しました。
  • JaSST'16東海SIGでTEF東海魅力品質勉強会のワークショップに対するフィードバック
  • システムテスト自動化カンファレンス2015参加
  • IPA SEC主催&SEA関西共催:形式手法、形式仕様記述入門@大阪 ~厳密な記述と検証についてのワークショップ~に参加
  • JaSST'16東海に参加

社外活動は少ないですが、社内では調査依頼の対応や他部署メンバーの支援、炎上プロジェクトへテスターやQAとして参戦したりと、平日の活動時間を確保するのが困難な日々を送っていました。

 今後の課題は、自部署の製品で抱えている技術的負債を減らすためにテスト技術やレビュー技術の面からどうアプローチするかです。

と、いうことで来年もコツコツと工夫して、開発者が幸せな開発ができるように進めていきます。

3年間毎週1回記事を書いたことをふりかえる。

 細々と毎週1本の記事を書いてから3年経過しました。今回は、3年間のふりかえりをKPTで行います。

Keep

(Keep-1)毎週1回のペースで記事書きを3年間継続できたこと。

 当初は1年間に限定しようと考えていました。しかし、1年経過する頃に「まだ修行が足りぬ」という想いがあり、習慣へ繋げるために継続することを決めました。

(Keep-2)毎週1回記事を書くことで1週間の活動をふりかえることができたこと。

 記事を書く過程でキーワードを考えます。キーワード決める要素として1週間の業務内容で「直面した問題は何か?」「何を工夫したか?」「どのような効果があったか?」を思い出し、抽象化して書き出したときに(自然と)ふりかえりが終わっていました。

(Keep-3)シンポジウムやカンファレンスの内容で理解できなかったことを参考文献を調査することで、自分なりに咀嚼して理解したこと。

 記事を書くとき、書きにくいと実感することがあります。それは、自分が理解していないことが主な原因です。理解しなければ書き終えることができないので、先人の知恵に触れたり、自分で実践や試行して理解できるように進めたことで、復習するのと同じ効果が得られました。

(Keep-4)自分が考えていることを(多少は)理論的にまとめることができたこと。

 (Keep-3)の副産物になりますが、職場の同僚から質問されたとき、相手が理解できるようにロジックブランチを意識して図示したり、内容を分解して解説できるようになりました。また、TOCfEでの素振り効果が少し現れたことも考えられます。

(Keep-5)多忙な時期でも記事を書く時間を(なんとか)確保したこと。

 記事を毎週欠かさず書くためには、書く工数が必要です。私は、業務終了後の自由時間や週末の一定時間を利用し、カフェで下書きを書いたり記事を書く内容の整理を行いました。また、通勤路や休憩時間など隙間時間を利用し、事前にアイディアを固めました。

(Keep-6)ワークショップで参加者から寄せられた内容から分かったことをまとめ、気づいたことを表現できたこと。

 記事を書くときに多くの工数をかけ、マインドマップKJ法などで抽象と具象を行ったり来たりしながら、「本質は何か?」を見つけるようにしました。

Problem

(Problem-1)1つの記事が小ネタに留まったこと。

 毎週1本記事を書くことにしていましたので、1週間の時間内でできることに限られます。プロジェクトのトラブル解決で隙間時間や自由時間が確保しくにいこともあり、記事を1本書き上げる内容は小さなものになります。

(Problem-2)書籍を読む動が少ないため、知見が広がらないこと。

 私が悩み続けていることの1つですが、時間を作ることの大変さを実感しています。不具合対応などの突発的なタスクが発生すると、隙間時間や自由時間が減少して書籍を読む時間を確保することが困難になります。

Try

(Try-1)テーマを決めてシリーズとしてまとめること。

 同僚に技術的に教えやすいようにするためです。そのためには、体系化した内容をまとめ、ノウハウとして形にする必要があります。

(Try-2)工夫したことを体系化し、論文としてまとめること。

 (Try-1)に関連しますが、手段の1つとして考える必要があります。そのためには、部長や課長、同僚の理解が必要ですので、業務に寄与できることを考慮する必要があります。

(Try-3)英語で記事を書くこと。

 これまで書いた記事は、全て日本語です。しかし、世界中の方からフィードバックを頂けるようにするには、世界中の方が理解できる言語で発信することが必須です。そのためには、文法の復習から進めて世界中の方が理解できるように英文を書く練習する必要があります。

まとめ

 何かを継続して活動することで、自分や周辺で小さな変化があったと実感しています。その源泉は、職場の方々だけでなく、社外の技術コミュニティの方々からのご支援やご教授によるものが大きく、3年間記事を毎週1本書くことができました。ありがとうございました。

最後に

 今回をもちまして毎週1本記事を書くことを終了しますが、不定期に記事を書こうと思います。

TEF東海 魅力品質勉強会でユーザビリティテストを体験した話

 久々にTEF東海 魅力品質勉強会に参加しました。今回のテーマは、「ユーザビリティテストを実際にやってみよう」でした。大まかな流れと所感を書いてみます。

[1]ユーザビリティテストとは?

 製品のユーザーインターフェース(UI)の問題点を発見する手法のこと。

[2]ユーザビリティテストの大まかな流れ

1.目的の明確化
2.被験者の選定
3.タスクの設定
4.記録内容や記録方法の決定
5.タスク実施計画立案
6.ユーザビリティテストの実施

[3]ユーザビリティテストの実施

[3-1]ユーザビリティテストを実施するために必要な役割

 役割は、下記4種類です。また、具体的に何を実施するかをまとめました。

  • 進行者
    • 被験者にユーザビリティテストの目的や注意事項を説明し、実施するタスクを提示する。
    • 被験者の発話を促したり、操作に行き詰まって手が止まったときに対策する。
  • 記録者
    • 被験者が困っていることや発話を時系列に記録する。
  • 時間計測者
    • 被験者がタスクを開始してから完了するまでの時間を計測する。
    • 記録者の助手としての役割を持つこともある。
  • 被験者
    • 進行者から与えられたタスクを理解した上で実施する。
    • 操作するときに考えていることや思っていることを発話する。

[3-2]進め方

1.進行者が被験者にユーザビリティテストの目的や注意事項を説明し、実施するタスクを紙面で提示する。
2.被験者は、実施するタスクを理解する。紙面でタスクを提示されているときは、音読して理解を促進することもある。
3.進行者から被験者に不明点があるか否かを質問し、被験者がタスクを理解したことを確認した上でユーザビリティテスト開始の合図を出す。また、時間計測者は、時間計測を開始する。
4.被験者は、与えられたタスクを行う。また、記録者は被験者が困っていることや発話内容を経過時間と共に記録する。
5.被験者は、与えられたタスクが完了したと認識したら、「終わりました」と宣言する。時間計測者は、タスク終了時間を記録する。
6.進行者が被験者のタスクが完了しているかタスク実施結果を確認する。
7.進行者から被験者にユーザビリティテストの対象について、満足度を質問する。
8.進行者から被験者にユーザビリティテスト終了を伝える。(ねぎらいや謝礼を忘れないように!)

[4]所感

 今回は、あるWebサイトのユーザビリティテストを行い、目的達成までの操作感や分かりやすさを発話しながら、課題点を抽出することができました。発話するためには、被験者がリラックスできるように進行者側で自宅にいるような雰囲気を作ることが大切と感じました。また、以下の記事でも紹介しましたが、被験者との会話でリラックスした状態でユーザビリティテストを進めることも後日の分析時に課題や問題点が明確になりますので、生活感を出すことも必要だと感じました。

masaoapril.hatenablog.com

[5]お知らせ

 今回実施したユーザビリティテストは、2016/12/2(金)に愛知県刈谷市刈谷市総合文化センター アイリスで開催されるソフトウェアテストシンポジウム2016東海のSIG「体験!ユーザビリティテスト」で体験できます。ユーザビリティテストに興味を持ち、どんな感じか知りたい方は こちらのリンクから申込ください。
 また、テスト自動化に興味がある方は基調講演:「テスト自動化クロニクル」 辰巳 敬三(ASTER)特別講演:「システムテスト自動化の技法と事例紹介」小井土 亨(OSK) SIG:「現場におけるテスト自動化」(JaSST Tokai実行委員会)とテスト自動化についてDeepに学んだり議論できる場がありますので、興味がありましたら、こちらのリンクから申込ください。

【感想】Webセキュリティ担当者のための脆弱性診断スタートガイド

 組み込み機器もセキュリティについて考慮する時代なので、脆弱性診断について理解する目的で読んでみた。以下、感想を述べます。

書名

「Webセキュリティ担当者のための脆弱性診断スタートガイド 上野宣が教える情報漏えいを防ぐ技術」上野宣(著) 翔泳社(出版元)

 以下を参照。

http://www.shoeisha.co.jp/book/detail/9784798145624

目次

http://www.shoeisha.co.jp/book/detail/9784798145624#contentsから引用したものを下記に示します。

Chapter01 脆弱性診断とは
Chapter02 診断に必要なHTTPの基本
Chapter03 Webアプリケーションの脆弱性
Chapter04 脆弱性診断の流れ
Chapter05 実習環境とその準備
Chapter06 自動診断ツールによる脆弱性診断の実施
Chapter07 手動診断補助ツールによる脆弱性診断の実施
Chapter08 診断報告書の作成
Chapter09 関係法令とガイドライン

 Chapter01~05は基礎編で脆弱性診断に必要な知識、Chapter06~09は脆弱性診断の実例と注意することが記載されています。

感想

 Chapter02でURIのフォーマットやHTTPメッセージの構造について解説があり体系的に理解できるので、WiresharkでHTTPの内容を解釈する一助になり、過去にキャプチャしたpcapファイルを見て製品の挙動を深く理解したくなりました。
 Chapter03は、Webアプリケーションに対する攻撃のメカニズムが記載されており、セキュリティテストの手段のバリエーションが広がりそうです。
 Chapter06は、OWASP ZAPの設定や操作方法が解説されており、私が関わったプロジェクトで試行しましたがこなれていない部分があったので、次回以降のプロジェクトでどう実践するか使い倒そうと思います。

 本書に参考文献が紹介されていますので、読みつつ実践してノウハウを蓄積しようと思います。

テスト工数が削減されたときに工夫すること

 プロジェクトは、チーム内/チーム外(技術営業などの他部門メンバーや納品先のお客様)の状況によって、開発(設計)の工程で遅延が発生することがあります。製品をリリースする時期が契約により決められている場合、納期を延ばすことができないのでV字開発モデルの右側(テスト)の工数は減少します。
 テストチームはテスト工数が減少する状況に合わせ、何らかの工夫が必要となります。

複数のテストケースを1つにまとめる

 テスト実行手順が同一もしくは類似しているテストケースは、テスト実行前に設定する項目が1ヶ所のみ変更する内容であれば、設定する項目を「全てデフォルト」「複数の箇所を変更」に留める。

テスト結果からテストを打ち切る

 例えば確認したい機能を10件実施するとき、サンプリングで1~2件実施し、バグが見つからない場合は、残りの8~9件を実行するのをやめる。

最低限必要な機能のテストに絞る

 製品をリリースする時期が決められている場合、納品先のお客様が必ず使用する機能が把握できていれば、その機能のテストを重点的に行い、それ以外の機能は数件程度のテストを行う。

最後に

 上記は、リスクを残した状態でリリースするので、リスクが発生したときの体制やテストを実施しなかった機能をいつテストするか、プロジェクトで決める必要があります。

セキュリティテストを知るための情報源

 テストで発見したいリスクとして、「セキュリティ」があります。特に不具合でシステムが破壊されたり、機密情報が盗用されて顧客の信頼を失い、収益が無くなると企業として維持することは難しくなりますので、開発者もテスターもセキュリティについて知恵を身につける必要があります。

 私が担当するプロジェクトで「不具合をきっかけに悪用されるシーン」が金銭的損害が大きいというリストを考えました。そして、何に着目してどのようにテストを行うかを知る必要がありました。

そして、たどり着いたのが"OWASP(Open Web Application Security Project)"でした。

OWASP(Open Web Application Security Project)

 公式サイト:https://www.owasp.org/

上記は英語サイトですが、OWASP Japanローカルチャプターのサイトがあり(限定的ですが)日本語で情報収集できます。

OWASP Testing Guide

 私が最近参考にしているのは、"OWASP Testing Guide v4"です。書籍もありますが、OWASP Testing Guide v4(PDF版)OWASP Testing Guide v4(Wiki版)から内容を閲覧できます。
 なお、OWASP Testing Guide v3(日本語版)もありますが、内容が古いので参考程度に。

取り敢えず具体的な事を知りたい

 4.Web Application Penetration Testingに数多くの内容がありますので、必要なところだけ読んでみるとよいです。また、Appendix A: Testing Toolsの情報を確認するとよいです。私が関わったプロジェクトで、"OWASP ZAP"脆弱性診断を行い、脆弱性が内在しないか確認しました。

組織内の私の役割について

 私が関わってきた業務をふりかえると、様々な方とやりとりしていることに気づく。時間軸で組織の状況をみると、ビジネスや技術の変化によって、組織内外で集合離散したり新たなメンバーが参入したりと変化がある。私の立ち位置は微妙に変化しているが、役割については傾向がある。

 今回は、組織における私の役割について5点書いてみる。

[1]開発規模が大きい開発の時

 新規開発や複数組織に跨ぐ開発では、テストエンジニアとしてテスト仕様を書いたり、テスト仕様を設計する過程で仕様の欠陥を発見し、多くの開発メンバーにフィードバックしているので、『ツッコミ』兼『偵察隊』な役割である。
 開発の手戻りによるリスクを小さくすることをミッションとして行動している。

[2]開発規模が小さい開発の時

 開発者から要望があったり困ったりしたとき、成果物を仕込んだり、開発者の雑務を引き受けたりする『助手』な役割である。
 開発者のタスクでボトルネックになりそうなところを解消することをミッションとして行動している。

[3]市場不具合発生時

 プロジェクトマネージャや開発リーダから緊急の依頼が(内線電話や電子メールもしくは口頭で)入電される。不具合でシステムが停止してお客様が困っているため、不具合発生の原因究明と不具合修正対応(修正方法検討、修正、修正確認)を早急に行う必要があり即応性が問われるので、スクランブル発進する『空軍パイロット』な役割である。
 不具合再現環境の構築と不具合発生条件の絞り込みを目的とした探索的テスト実施をミッションとして行動している。

[4]他プロジェクト炎上時

 テスト進捗が大幅に遅延したりテスターが欠員してプロジェクトリスクが発生するとき、救難活動を行う『救難隊隊員』な役割である。
 「何が困っているか?」「ボトルネックになっているところは何か?」を特定するためにミーティングメモを探ったり、他プロジェクトメンバーからの話を聞いたりして、炎上阻止することをミッションとして行動している。

[5]他組織や他チームのエンジニアが私を頼って依頼される時

 テストエンジニアとしてのスキルもありますが、広範囲な(社内外の)情報収集を日頃から行っているため、技術的な質問に対する回答や開発機材のファームウェア書き込み、(鉛フリーの)はんだ付けや電気的配線といったハードウェア的な支援を行う『後方支援部隊隊員』な役割である。
 (組織内外の)依頼相手から困っていることや分からないことを特定し、問題解決の糸口という名のリソース提供をミッションとして行動している。

これからの私の役割は?

 以上5点は「(リスク)発生対応」の傾向が強く、これ以上酷い状況にならないように動いているが、同じ状況が続くと本来進めるべき(ビジネス上戦略的な)開発ができなくなるので、機会損失は増えてしまい、事業の成長面では良くない状況である。
 今後は、リスクの予兆をリスクが小さいうちに早期発見して処置する、もしくは正常な状態を維持することが必要と考える。そのためには、様々な欠陥や失敗から学び、同じ轍を踏まないための歯止めの技術が必要であるので、自他のノウハウを形式知として共有したのち、各自で自律して工夫ができる組織へ進める。

Nmapが7.30にバージョンアップ

 先日、Nmapの簡単な使い方を書きましたが、2016/9/29にVer.7.30がリリースされました。

masaoapril.hatenablog.com

 公式サイトのChange logから大きな変化としては、

  • 7~9月に提出された12のIPv6 OS(Windows/OS X)のfingerprintが統合され、OS検出の種類が増えた。
  • 7つのNSE scriptsが追加され、全体で541個のNSE scriptとなった。
  • パケットキャプチャドライバのNpcapが0.09から0.10r2にバージョンアップされ、いくつかバグ修正された。
  • DTLS, IPMI-RMCP, MQTT, PCWorx, ProConOS, and Tridium Foxの新サービスを検出することができる。
    が挙げられます。(細かい修正や追加は割愛)

「応答時間」の基準は何か?

 性能テストでISO25010の製品品質モデルの1つである主特性:性能効率性、副特性:時間効率性の妥当性を判断する材料として、システムの応答時間を計測して傾向をみますが、妥当と判断する基準は人によってバラバラだと思うことがあります。そこで、身近なシステムでの応答時間はどのような感じか書いてみようと思います。

性能効率性とは?

「明記された状態(条件)で使用する資源の量に関する性能の度合い」

JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)―システム及びソフトウェア品質モデルから引用。

性能効率性のの副特性:時間効率性とは?

製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間、並びにスループット速度が要求事項を満足する度合い。

JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)―システム及びソフトウェア品質モデルから引用。

応答時間の一例

FeliCaの場合

 Sonyのサイトによると、データの読み書き:約0.1秒(=約100ms)。

オフィス居室への電子鍵の解錠時間(※私感)

 毎朝、ICカードを受信部に当てて、機械的に解錠されるまでの時間は、500~3000ms。

AT(オートマチックトランスミッション)車でアクセルを踏み込んでからキックダウンされるまでの時間(※私感)

 1300ccのハッチバック車(MAZDA車)で、1500~3000ms程度。

応答時間が遅いと判断する要素は何か?

 例えば1000回同じ操作を行って500ms±100msで動作するが、200msに1回の割合で割り込み処理があるとき、1000回同じ操作を行うと1000ms±200msで動作する。

 と数値化できればよいですが、急いでいるときに動作が遅れたときに不快に感じる(イライラする)こととが上手く結びつかないときがあり、私自身モヤモヤしています。

Nmapを使ってみた

 近年、組み込み機器に通信機能が標準装備され、他の機器やサービスに接続することが増えていると実感しています。また、JaSST'16 Tokyoの基調講演でもJeepのハッキングの話がありました。組み込み機器でもハッキングによって悪用されないことを確認することが求められます。
 今回は、Ethernetで通信する機器に対し、Nmap(Network Mapper)を利用し、脆弱性を診断してみます。

Nmapとは?

 Nmap リファレンスガイドによると、

「Nmap (“Network Mapper”)は、ネットワーク調査およびセキュリティ監査を行うためのオープンソースのツールである。」

 大雑把に言うと、ポートスキャンや脆弱性診断ができるツールです。

インストール方法(Windowsの場合)

 Nmapのダウンロードページから安定版は"Latest stable release self-installer"のリンク、開発版は"Latest development release self-installer"のリンクからダウンロードし、ダウンロードしたexeファイルを実行する。

使い方

 192.168.0.1~192.168.0.254の機器に対し、ポートスキャンとpop3-bruteを実行する例を以下に示します。

  1. スタートメニューから"Nmap - Zenmap GUI"を実行する。
    20160925225620
  2. メニューの「スキャンプロファイル」から「スキャンプロファイルの新規作成またはコマンド入力」を選択する。
    20160925225621
  3. タブの「スキャンプロファイル」にある「スキャンプロファイル名」のテキストボックスに任意の名前を入力する。
    20160925225622
  4. タブの「スキャン」にある「ターゲット」のテキストボックスににIPアドレスを入力する。(例えば、192.168.0.1~192.168.0.254の範囲は、192.168.0.1-254と入力する。)
    20160925225623
  5. タブの「スクリプティング」の"pop3-brute"にチェックボックスを入れ、「変更を保存」ボタンを押下する。
    20160925225624
  6. 「スキャン」ボタンを押下し、結果が出るまで待つ。
    20160925225625

所感

 開発中の製品にNmapを実行していると、必要以上にポートを開けていないかを確認したり、ある程度脆弱性の対策している把握できました。Nmapを使用すればするほど、私自身セキュリティに関し知らないことが多いと実感したため、JPCERT/CC(Japan Computer Emergency Response Team Coordination Center)を起点にセキュリティ関係情報のアンテナを張ってみます。

簡易的にGUI画面の色の見え方を確認する方法

 組み込み機器開発であっても、Webブラウザやアプリケーションソフトでネットワークなどの設定を行うことが増えています。テスターが機能テストでバグを発見するだけでなく、非機能テストで使用性について妥当か否かを確認することも求められています。開発しているシステムがどのように利用されるかを考えたとき、Webブラウザやアプリケーションソフトで設定画面の見え方、特に色がどのように感じられるのか、確認する場面があります。今回は、簡易的ですが実践した内容をまとめます。

色覚とは?

 外界には可視光線があり、波長が400~800nmの光のうち色を感じる3種類の錐体細胞(赤色に反応:L錐体、緑色に反応:M錐体、青色に反応:S錐体)があります。例えば、虹を見たときに赤色/橙色/黄色/緑色/水色/青色/紫色の7色を知覚します。

色覚異常とは?

 特定の色が区別できないこと。主に3種類あります。

  • Protanope(1型2色覚)
    L錐体が異常:赤色と緑色は、茶色の濃淡として知覚する。
  • Deuteranope(2型2色覚)
    M錐体が異常:赤色と緑色は、濃淡が認識できない茶色として知覚する。
  • Tritanope(3型2色覚)
    S錐体が異常:黄色と赤色が赤色として知覚し、緑色と青色が青色として知覚する。

色覚異常をシミュレーションする方法

 Stanford UniversityDr. DoughertyDr. Wadeが開発したVischeckThe National Institutes of Health(NIH)の元職員 Wayne Rasbandが開発したImageJ(Image Processing Analysis in Java)を利用します。

  1. http://www.vischeck.com/downloads/からVischeckJ1.0をダウンロードします。
  2. ImageJダウンロードページからImageJ本体をダウンロードします。
  3. ImageJ本体をインストールします。(Windows版は、ダウンロードしたzip形式のファイルを任意のドライブに解凍する。)
  4. ダウンロードしたVischeckJ1.0のzipファイルを展開し、展開後に生成されたVischeckJ1のディレクトリを丸ごとImageJ本体のインストール先にあるpluginsのディレクトリにコピーします。
  5. 色覚異常をシミュレーションしたいアプリケーションを立ち上げ、確認したい画面のスクリーンショットを撮ります。
    Original Application
  6. ImageJを起動し、ImageJのEditメニューからPasteを選択し(もしくはCtrl+V)、スクリーンショットを撮った画像を貼ります。
  7. ImageJのPluginsメニューから"Vischeck Panel"を選択し、Vischeckのウィンドウを表示します。
    Vischeck Panel
  8. "Protanope"/"Deuteranope"/"Tritanope"のボタンを押下すると、それぞれ「1型2色覚」「2型2色覚」「3型2色覚」をシミュレーションした画像が表示されます。
    • 1型2色覚
      Protanope(1型2色覚)
    • 2型2色覚
      Deuteranope(2型2色覚)
    • 3型2色覚
      Tritanope(3型2色覚)

所感

 開発中のアプリケーションソフトで実施しましたが、数色で構成されているシンプルな画面でしたので、色の区別が困難なものはありませんでした。
 今後は、様々な特性を持った方々が利用しやすいシステムとは何か、あるべき姿について様々な関係者と議論し、製品開発に寄与しようと思います。

テストに必要な知識を獲得するには?

 今回は、テストに必要な知識をどう獲得するか、どのような道筋で進めているかモヤモヤしているので、過去のプロジェクトを思い出しながら書き出してみます。

どのような状況か?

 普段は保有している知識+αで開発製品のテスト業務を行っているが、1~2年に1度の割合でドメインが異なる製品のテストを担当することがあります。開発者は、数多くの詳細設計を限られた人数で行う状況なので、テスト仕様まで手が回らないことが多々あります。また、テスト技術に特化したメンバーは私以外にいないため、ドメインが異なっていてもテスト仕様としてテスト実行できるようにする必要があります。

ドメインが異なる製品で初めにやったこと

 ドメインを理解するために下記を問いかけながら、具象化しました。

  • 製品の用途は何か?
  • 製品を取り巻くステークホルダは誰か?
  • 各ステークホルダのリスクは何か?

 初めに製品はお客様が抱える問題を解決する道具ですので、「何の問題があり、解決するための手段として製品はどう振る舞うのか?」をポンチ絵で描きながら用途を具象化します。
 次に「製品を利用する側」「製品を購入(投資)する側」「製品を開発する側」「製品を開発するためにマネジメントする側」「製品を開発するために投資する側」と製品と周りに関わる方々を挙げ、製品と周りの繋がりを明確化します。
 最後に「製品と周りの繋がりから、損失が発生する要因」を過去の失敗事例(市場不具合対応など)を参考にして、想定されるリスクを挙げます。

 上記の過程で分からないことは、開発者や開発リーダに聞いたり、検索サイトで関連しそうな情報(規格や業界組織、業界標準など)を得て、理解を進めます。

何を確認するか?

 先述の「製品と周りの繋がりから、損失が発生する要因」を見つけるため、ISO25010の製品品質特性や自組織で蓄積された市場不具合の教訓をベースに、「損失が発生する要因」を知るための手段を挙げます。また、過去のテスト仕様からテストの目的を読み取れるものがあれば利用します。

最後に

 これまで経験した製品ドメインで原理・原則や思考の足跡を多少でも整理すると、異なる製品ドメインでも応用が利くことがありますので、これまでやったことの棚卸しを時々行うとよいと思います。