発信すること
技術系コミュニティやワークショップに参加し始めてから6年経ち多くのことを学びましたが、「発信」することは進化するためのきっかけとなると思います。何故なのか2点考えてみました。
思考の整理
発信する人がいるということは、受信する人がいます。受信する人に何を伝えたいか？を理解できる形に表現する必要があります。発信する材料を分類したり因果関係を洗い出し、情報を整理します。私がやっていることは、マインドマップ＋KJ法＋ロジックブランチの合わせ技です。
フィードバック
受信する人から応答が返ってくることがありますが、肯定的/否定的な意見や考えや知見から何らかのギャップを認識することになり、次なる「発信」する内容(意見、考え、反論、分かったことなど)を整理して発信し、より洗練された「発信」する内容へ進化しますので、新たな気付きやヒントが得られ、よりよい知見が蓄積されます。
また、専門家が発信する人に引き寄せられ、フィードバックから得られるものが多くなりますので、技術の進化が促進されます。
最後に
発信する媒体はblogでもTwitterやFacebook、勉強会での発表など様々あり、発信コストは小さくなりましたので、アイディアレベルな内容でも発信すると何らかのフィードバックがあるかもしれません。
身近な作業をPFDで書いてみよう
私が所属する開発課では月例の公式ミーティングがありますが、1点悩みがありました。それは、ミーティング当日、若手がミーティング運営時にやるべき作業(「プロジェクタを準備」「情報展開用資料をノートパソコンにコピー」「課長に議事録の査読を依頼」)を忘れ、月例の公式ミーティングの進行の遅延や中断が発生してミーティングの運営に支障がありました。
解決策を検討しているとき、PFD(Process Flow Diagram)で表現し、作業内容とアウトプットのつながりを若手と共に確認すると、やるべき作業を忘れずにミーティングの運営が円滑に進むと仮設を立てました。
以下、月例の公式ミーティングの進め方をPFDで表記した後、何の効果があったかを簡単にまとめます。
1.PFDとは？
PFDはProcess Flow Diagramのこと。成果物とプロセスをDFDのルールに従い表現します。
2.PFDの書き方。
四角：成果物、円：プロセスで表現し、下図のように［プロセスへ入力する成果物］→【プロセス】→［プロセスから出力する成果物］と表記する。(※制御工学を学んだ方は、ブロック線図を思い出すと理解が進むと思います)
詳細は、下記を参照下さい。
ソフトウェアエンジニアのための“硬派”のブログ
3.月例の公式ミーティングの進め方をPFDで表記する。
作業内容と必要な機材やドキュメントを挙げ、因果関係を確認して、下記のようにまとめました。
4.月例の公式ミーティングの進め方PDFで表記したものをメンバーに展開した後。
月例の公式ミーティングは当番制でしたので、当番になったときに入社1年目の若手と共にPFDで表記したもの(印刷物)を見ながらフォローしたところ、やるべき作業を全て完了した状態でトラブル無く月例の公式ミーティングを運営することができました。また、PFDで表記したもの(ファイル)をファイルサーバに格納してメンバーに展開したら、1ヶ月後に追加のプロセスや成果物が追記され、やるべき作業を忘れることが減少しました。
5.最後に。
PFDを書くときに因果関係を確認してから、メンバーに説明するとメンバーが理解しやすくなり、認識合わせなどのいったコミュニケーションコストが減少しましたので、様々な場面で応用するとよいと思います。
毎回決まったことを自動化しよう
出社直後、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が起動するか確認する。
マインドマップの実例
何年か前にテスト仕様の改善(テスト目的や意図の明確化やテスト条件を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
個々を紹介しませんが、気になったものを見ると何らかのヒントになると思います。
テストエンジニアとしての土台
開発の中でテストを考えるとき、学んだことのベースを活用していることが多々あります。テスト技術を進化させ、開発にフィードバックするためには様々な学の基礎を固める必要があります。組み込み機器開発の場合はどうなのか、まとめてみます。
ドメイン共通
組み込みシステムに限らず、どのドメインでも必要なものを以下に示します。
英語
情報収集手段として、IEEE/ISO/IECの規格やIETFなどの標準仕様を把握したり、世界中の技術動向を知ることです。日本語でも情報収集はできますが、翻訳されたものは数年後という場合や永遠に無いこともあるため、技術的にハンディキャップがあります。また、製品が海外展開されるときは海外のエンジニアやお客様とコミュニケーションすることもありますので、コミュニケーション手段としては必要になります。
数学
(その他あると思いますが)以下4点が挙げられます。
「函数」は、入力と出力の関係を考えるときに概念として必要です。「集合論」は、境界値分析や同値分割で必須です。「論理学」は、デジションテーブルを圧縮するときに必要な考え方です。「統計学」は、メトリクスを取るときに必要です。
学生実験/授業レポート
理工系学部の方は必須科目でお馴染みですが、開発者に上手く伝わるインシデントレポートを作成するときに活かされます。特に「現象の記録」「データ整理」「考察」は、インシデントレポートを作成するときにノウハウとして蓄積されているとよいです。
組み込みシステム
組み込みシステムで必要になりそうなものを以下に示します。
電気工学/電子工学
「電気回路」で過渡現象による電圧低下時の不具合を見つけたり、「電子回路」や「ディジタル回路」でセンサの挙動を知り、テスト結果の判断に利用します。また、「ディジタル回路」で論理回路を設計するときにカルノー図を書きますが、デジションテーブルを圧縮するときに応用できます。
通信工学/無線工学
OSI参照モデルの第1層(物理層)～第2層(データリンク層)を知った上でハードウェアを考慮すると、ハードウェア故障時のふるまいがどうなっていればよいか検討しやすくなります。
情報工学
ハードウェア絡みのソフトウェアアーキテクチャを理解するときの一助になります。
さいごに
テスト設計で数学に助けられた面が大きいので、高校数学や大学数学を復習すると吉。
組織運営で大切なこと
様々なチームメンバーや関係者とお話する機会がありました。他組織から自組織メンバーに入った方々と自組織の良さについての話題があり、気づいたことがありましたので組織運営で大切なことをまとめてみます。
(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.社員と派遣社員の壁
社員しか知らない開発情報がありますが、テスト実施する前に展開するとテスト実施時のリスクに対処できますし、派遣社員の方も優秀なベテランさんですのでアイディアを共有して、「我々はどう対処していくか？」を一緒になって考えていました。
テスト実施時や不具合調査時の「モニタリング」について
私が組込機器でテストを実施する時や不具合を調査する時、神経を集中して着目していることは「モニタリング」です。電気的または機械的制御の機器は出力時間がミリ秒単位または秒単位の世界ですので、時系列の変化で結果を見て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技術の適用 - つなぐための標準化、規約への関与
- テストのための仕組みも標準に取り込む
- テスターからの積極的な提言が必要
- 組織的な取り組み
- テスト環境、標準化検証環境の整備
- テストラボ
- コンフォマンステスト
- テストのエコシステム
- オープンイノベーション的テスト連携モデル
- サービスを構成する他サービスのテスト情報の共有
- 複数レベルのテストベッドが必要
- デバイス
- 会社
- 産業セグメント
- 政府
- プロダクトラインの知識が必要
- ユーザが接続する方法は様々
- 色んなものを組み合わせてテストする
- 変化を受け入れて楽しむ
所感
IoTやIndustrie4.0という言葉が自組織でも浸透しつつあるが、同時に市場でバグが発生したときに被る損害(健康面、金銭面、時間面)のインパクトは強く広範囲になりつつあると実感しています。これまでの開発資産を流用して機能追加の開発を行いますが、ビジネスや生活スタイルの変化やリスクを何も考えずに開発資産を流用した場合、特定の使い方で機能が損なわれて快適に利用できるどころか害になることを目にしています。
ソフトウェアのアーキテクチャは時代に合わせて変化する必要がありますが、テストも同様にテストアーキテクチャを変化する必要があります。これまで先人が作成したテスト仕様を今の自分だったらどう考え、どうテストするかを見直すと3年先のテストをどう工夫するか楽しみながら進められると思います。
テストに留まらず、開発技術やビジネスの知識、法律や心理学といった学問などの知見を広げることが必要だなと思います。まずは、放送大学を視聴してみるのもアリかなと。
