読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

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

Nmapを使ってみた

Security 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画面の色の見え方を確認する方法

color vision Usability UI

 組み込み機器開発であっても、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色覚)

所感

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

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

Test Process TestDesign

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

どのような状況か?

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

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

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

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

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

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

何を確認するか?

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

最後に

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

発信すること

Post Idea

 技術系コミュニティやワークショップに参加し始めてから6年経ち多くのことを学びましたが、「発信」することは進化するためのきっかけとなると思います。何故なのか2点考えてみました。

思考の整理

 発信する人がいるということは、受信する人がいます。受信する人に何を伝えたいか?を理解できる形に表現する必要があります。発信する材料を分類したり因果関係を洗い出し、情報を整理します。私がやっていることは、マインドマップKJ法+ロジックブランチの合わせ技です。

フィードバック

 受信する人から応答が返ってくることがありますが、肯定的/否定的な意見や考えや知見から何らかのギャップを認識することになり、次なる「発信」する内容(意見、考え、反論、分かったことなど)を整理して発信し、より洗練された「発信」する内容へ進化しますので、新たな気付きやヒントが得られ、よりよい知見が蓄積されます。
 また、専門家が発信する人に引き寄せられ、フィードバックから得られるものが多くなりますので、技術の進化が促進されます。

最後に

 発信する媒体はblogでもTwitterFacebook、勉強会での発表など様々あり、発信コストは小さくなりましたので、アイディアレベルな内容でも発信すると何らかのフィードバックがあるかもしれません。

身近な作業をPFDで書いてみよう

PFD

 私が所属する開発課では月例の公式ミーティングがありますが、1点悩みがありました。それは、ミーティング当日、若手がミーティング運営時にやるべき作業(「プロジェクタを準備」「情報展開用資料をノートパソコンにコピー」「課長に議事録の査読を依頼」)を忘れ、月例の公式ミーティングの進行の遅延や中断が発生してミーティングの運営に支障がありました。
 解決策を検討しているとき、PFD(Process Flow Diagram)で表現し、作業内容とアウトプットのつながりを若手と共に確認すると、やるべき作業を忘れずにミーティングの運営が円滑に進むと仮設を立てました。

 以下、月例の公式ミーティングの進め方をPFDで表記した後、何の効果があったかを簡単にまとめます。

1.PFDとは?

 PFDはProcess Flow Diagramのこと。成果物とプロセスをDFDのルールに従い表現します。

2.PFDの書き方。

 四角:成果物、円:プロセスで表現し、下図のように[プロセスへ入力する成果物]→【プロセス】→[プロセスから出力する成果物]と表記する。(※制御工学を学んだ方は、ブロック線図を思い出すと理解が進むと思います)

f:id:MasaoApril:20160828220751j:plain

 詳細は、下記を参照下さい。
ソフトウェアエンジニアのための“硬派”のブログ

3.月例の公式ミーティングの進め方をPFDで表記する。

 作業内容と必要な機材やドキュメントを挙げ、因果関係を確認して、下記のようにまとめました。

f:id:MasaoApril:20160828220752j:plain

4.月例の公式ミーティングの進め方PDFで表記したものをメンバーに展開した後。

 月例の公式ミーティングは当番制でしたので、当番になったときに入社1年目の若手と共にPFDで表記したもの(印刷物)を見ながらフォローしたところ、やるべき作業を全て完了した状態でトラブル無く月例の公式ミーティングを運営することができました。また、PFDで表記したもの(ファイル)をファイルサーバに格納してメンバーに展開したら、1ヶ月後に追加のプロセスや成果物が追記され、やるべき作業を忘れることが減少しました。

5.最後に。

 PFDを書くときに因果関係を確認してから、メンバーに説明するとメンバーが理解しやすくなり、認識合わせなどのいったコミュニケーションコストが減少しましたので、様々な場面で応用するとよいと思います。

毎回決まったことを自動化しよう

TestAutomation

 出社直後、Windowsなパソコンの電源スイッチを入れてログインしてからメールソフトを起動してプロジェクト関係のファイルを開いたり、グループウェアや社内システムのWeb画面を開くことなど、毎回決まったことをやるだけでも面倒だと感じることがあります。

 そのような状況下、システムテスト自動化カンファレンス2014の「Test Automation Patterns 2014 冬コレ!」の11枚目のスライドにあった『LAZY AUTOMATOR(怠け者は最高のテスト自動化エンジニアに)』を思い出しました。
→原典:LAZY AUTOMATOR@TestAutomationPatterns

 今回は、(小ネタかつ拙作ですが...)「ログイン後にOutlookを起動したい」を自動化してみました。

材料(Windows7(64bit版)の場合)

 以下3点を事前に仕込んでおきます。

  • UWSCをインストールする。
  • 普段使用しているエディタ(例えばサクラエディタなど)をインストールする。
  • 自動化したいネタ(「ログイン後にOutlookを起動したい」「任意のファイルを開いておきたい」など)を具象化する。

1.UWSCの拡張子".uws"の関連付けする。

 ".uws"のファイルで右クリックメニューで出てくる「プログラムから開く...」で"UWSC.exe"を指定して、".uws"のファイルをダブルクリック後にUWSCが動作できるように設定する。

2.Outlookの本体の場所を確認。

 Office2010かつWindows7(64bit版)の場合は、下記です。

"C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXE"

3.UWSCスクリプトを書く。

ID_Outlook =exec("C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXE")

上記スクリプトを任意のファイル名で保存します。
→例:"StartUp.uws"

4,Windowsのスタートアップフォルダに前項の3.で作成した".uws"ファイルのショートカットをコピーする。

 Windows7(64bit版)の場合、スタートアップフォルダは下記です。
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"

5.ログアウト後または再起動後にログインして、Outlookが起動するか確認する。

マインドマップの実例

Mindmap

 何年か前にテスト仕様の改善(テスト目的や意図の明確化やテスト条件をMECEで再検討など)を行うとき、マインドマップブレーンストーミングを行いますが、国内で参考になる資料は、書籍:マインドマップから始めるソフトウェアテスト 著:池田暁、鈴木三紀夫 出版:技術評論社(※絶版のようです)、スライド:JaSST'08 Tokyo 論文・事例発表 ソフトウエアテスト分析の方法 -HAYST法とマインドマップをつかって- 永田 敦(ソニー)NPO法人 ソフトウェアテスト技術振興協会(ASTER:Association of Software Test EngineeRing)が主催する「テスト設計コンテスト」の過去の資料があり、実践するときの一助になりました。

 あれから何年か経ち、海外の実例が知りたくなり、あるサイトに目が留まりました。それは、UKの"The Ministry of Testing"のMindMapsです。内容は、下記に示すカテゴリ別にリンクが貼ってあり、各サイトを参照する形になっています。

  • Mobile
  • Manual Testing
  • Test Management
  • Exploratory Testing
  • SBTM
  • Security
  • MindMaps for Tools
  • General
  • Testing Techniques
  • MinMap blogs
  • Tools
  • Books

 個々を紹介しませんが、気になったものを見ると何らかのヒントになると思います。

テストエンジニアとしての土台

Skill Development

 開発の中でテストを考えるとき、学んだことのベースを活用していることが多々あります。テスト技術を進化させ、開発にフィードバックするためには様々な学の基礎を固める必要があります。組み込み機器開発の場合はどうなのか、まとめてみます。

ドメイン共通

 組み込みシステムに限らず、どのドメインでも必要なものを以下に示します。

英語

 情報収集手段として、IEEE/ISO/IECの規格やIETFなどの標準仕様を把握したり、世界中の技術動向を知ることです。日本語でも情報収集はできますが、翻訳されたものは数年後という場合や永遠に無いこともあるため、技術的にハンディキャップがあります。また、製品が海外展開されるときは海外のエンジニアやお客様とコミュニケーションすることもありますので、コミュニケーション手段としては必要になります。

数学

 (その他あると思いますが)以下4点が挙げられます。

 「函数」は、入力と出力の関係を考えるときに概念として必要です。「集合論」は、境界値分析や同値分割で必須です。「論理学」は、デジションテーブルを圧縮するときに必要な考え方です。「統計学」は、メトリクスを取るときに必要です。

学生実験/授業レポート

 理工系学部の方は必須科目でお馴染みですが、開発者に上手く伝わるインシデントレポートを作成するときに活かされます。特に「現象の記録」「データ整理」「考察」は、インシデントレポートを作成するときにノウハウとして蓄積されているとよいです。

組み込みシステム

 組み込みシステムで必要になりそうなものを以下に示します。

電気工学/電子工学

 「電気回路」で過渡現象による電圧低下時の不具合を見つけたり、「電子回路」や「ディジタル回路」でセンサの挙動を知り、テスト結果の判断に利用します。また、「ディジタル回路」で論理回路を設計するときにカルノー図を書きますが、デジションテーブルを圧縮するときに応用できます。

通信工学/無線工学

 OSI参照モデルの第1層(物理層)~第2層(データリンク層)を知った上でハードウェアを考慮すると、ハードウェア故障時のふるまいがどうなっていればよいか検討しやすくなります。

情報工学

 ハードウェア絡みのソフトウェアアーキテクチャを理解するときの一助になります。

さいごに

 テスト設計で数学に助けられた面が大きいので、高校数学や大学数学を復習すると吉。

組織運営で大切なこと

Management

 様々なチームメンバーや関係者とお話する機会がありました。他組織から自組織メンバーに入った方々と自組織の良さについての話題があり、気づいたことがありましたので組織運営で大切なことをまとめてみます。

(1)雰囲気

(1-1)チーム内外の会話が活発

  • 他組織では会話が無い。
  • 懇親会が他組織より多い。

 普段からチーム内外のメンバーと話しやすい状況を作ると、リスク発生しそうなときに迅速に対処できるので、リスク回避が容易になります。また、課題を解決するためのヒントが得られることもあり、ノウハウが蓄積されたり浸透されます。

(1-2) 困ったときに相談に乗ってもらえる

  • 分からないことは、親切に解説したり一緒に考えたりする。
  • トラブル発生時に対応できるメンバーがいる。

 困っていることを放置すると何らかの形でボトルネックとなり、プロジェクトが遅延したり、1つの困っていることが他の困っていることと絡まって問題解決が難しくなりますので、問題の芽が小さいうちにできる限り対処することが大切です。また、心理的負担が軽減されますので、メンタル面が悪化するのを防ぎます。

(1-3)ケンカがほとんど無い

 前述にも繋がりますが、困ったときに話しやすい状況はメンバー間の敬意や信頼があることで成立します。ケンカがあるということは、メンバー間の敬意や信頼が失われているので、リスク回避も問題解決もメンタル面が悪化します。

(2)組織管理者の対応

(2-1)緊急の対応時

 何らかの問題が発生し、状況の確認と問題解決のためにタスクの調整や交渉、認識合わせを緊急で対処する必要があります。電子メールではなく直接相手とFace to Faceで対処することで、リスク回避やリスク悪化を防止することになり、問題のボトルネックが解消されます。

(2-2)フォローの徹底

  • チームリーダに対し、残業時間の状況を確認する。
  • タスク負荷の調整を行う。

 過去、プロジェクトが多忙な状態またはプロジェクトのタスクの負荷が高い状態が続いて体調を崩すことがあり、プロジェクトを進める上でボトルネックになることがあります。また、休職が発生すると想定以上に組織内でプロジェクトの調整やメンバーの追加タスク発生により、組織としては時間やコストの損失がありますので、一部のメンバーにタスクの過負荷がないかモニタリングして、リスクが発生しないようにします。

(2-3)意見や提案を聞き、あるべき姿を議論する。

 プロジェクトでの問題点や課題に対し意見交換や提案することができる環境は、組織管理者やメンバーとの信頼があることが必須です。意見や提案は、問題解決するためのヒントや候補になりますし、あるべき姿を共有するために必要ですので、意見や提案を潰すことは論外です。

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

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

テストチーム新設の話

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

チーム編成

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

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

当時の課題

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

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

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

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

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

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

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

3.社員と派遣社員の壁

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

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

Monitoring

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

LED

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

ラインモニタ

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

Wireshark

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

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

Perception

用語における認識の違い

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

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

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

 テスト条件という言葉は知らない状態でしたが、当時のイメージは「テストの目的」「テストの環境(構成)」「テストの手順」「テスト結果の判断基準」の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?

30 Day Testing Challenge Ministry of Testing

 海外の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つです。