こんにちは。QAエンジニアをしている、まーくー&くまねこです。
私たちはファームウェアテストの現場で知り合って十数年。ゆるっと縁(えにし)が続き、今に至ります。今回はそんな二人のゆるっとしたやりとりを通じて、ファームウェアテストの特徴や有効なテスト設計技法について、会話形式で紹介したいと思います。

自己紹介

まーくー
QA業界経験2x年のベテラン(おじさん)エンジニア。 複合機を中心にファームウェアのテストを15年以上、現在はWeb系のQAやこれまでのテスト経験を活かしQAコンサルなどに従事している。 人生初のブログに緊張し・・・くまねこさんを巻き込む(笑)

くまねこ
QA業界経験1x年のエンジニア。 まーくーさん同様、10年近く複合機を中心にファームウェアのテストを経験。現在はWeb系を中心にQA業務に従事。 まーくーさんに巻き込まれる(笑)
イラスト by くまねこ

それでは、二人のやりとりをお楽しみください。

ファームウェアって?

くまねこ:最近スマート農業ってニュースに出てきますけど、ドローンや衛星を使ってリモートでトラクターを動かしたり。ここでもファームウェアのテストってやってるんですかね?

まーくー:(ダジャレかな?)そうだね。専用のデバイスを動かしたりするのにファームウェアが入っているから、ファームウェアのテストはしているだろうね。

くまねこ:ふむふむ。改めて、ファームウェアの定義を確認したいです。

まーくー:「機器内部に固定的に組み込まれ、内部のハードウェアと密接に結びついており、通常の使用や操作では原則として内容の変更を行わないことから、ハードウェアに性質が近いソフトウェアとして “firm” (堅い、固定の)という語が当てられている。」とIT用語辞典は言っている(引用:IT用語辞典e-Wordsファームウェア【firmware】

くまねこ:複合機のテストをしていた時に「ファームアップデート」とか「ファームバージョン」とか、よく「ファーム」って言葉使ってたけど、「ファーム」は固いって意味から来ていたんですね。

ファームウェアテストの特徴

まーくー:(小声で)みんなファームを感じる♪ファームを求めてwow oh!ファームウェアのテストについて、君は知りたくないか~い?

くまねこ:何か言いました?

まーくー:いや。。。(久しぶりにファームの話をしたらテンションが上がってしまった(^^;))ファームウェアをテストしていた時に「これって特徴的だなぁ」って思っていた所はあるかい?

くまねこ:なんと言ってもハードウェアを動かすところ、でしょうか。例えば、複合機やデジカメにもファームウェアが内蔵されていますよね。

まーくー:うん。複合機だと、出力する用紙の給紙元トレイや、設定したカラーモードでの出力、カメラだったら、シャッターのスピードとか絞り、レンズのフォーカスを合わせる制御もファームウェアの仕事なんだよ。実際にファームウェアをテストするとなると、ファームウェアと連動してハードウェアが動作するタイミングや内部構造の理解も重要だね。

複合機のテスト経験が長かったから複合機を例に出すと・・・複合機が印刷するのって思ったより凄い制御なんだよ。紙の搬送と画像を作るのは別々に制御しているうえに、紙が送られるタイミングとドラムに作った画像をピッタリ合わせる必要があるんだ。

また、紙の搬送路の何処まで行ったら印刷したってカウントするのか(センサーが感知するのか)なんていうのもあるし、複雑なデバイスの動きをファームウェアが制御しているんだ。

だから、ファームウェアをテストするには、デバイスの内部構造や動作のタイミングを理解していないとテストできないのさ。

くまねこ:なるほど…実際にハードを動かすとなると、ハード操作・動作、チェック(目視)もする必要あるし、時間がかかりますよね。Webとかネイティブのアプリとは違って、PCやスマホで完結しないところも特徴って感じます!

ログの取り方も特徴の一つですよね。ターミナルソフトを使ってデバイスに接続したりするし。Webアプリなら、サーバやブラウザのログとかなんだけど。。。

まーくー:ログ出力用の基盤を付けて、基盤とPCをシリアルケーブルやUSBで接続してコンソール操作でログ取得したり、デバイスのOSに合わせてコマンド覚えたり!これも特徴的な部分と言えるね。

くまねこ:あと時間がかかるテストが多かった気がします。例えば、大量印刷(複合機)、連続撮影(デジカメ)等の耐久系のテストは時間がかかりますよね。 あと、省電力・スリープなどの状態をキーにしたテストが重要なのも特徴だと思います。デバイスの状態とイベント(状態を遷移させるきっかけ)を理解してテストを考えないと、余計な工数を使ってしまうこともありますよね。けど・・狙った状態を作ってテストするのは大変でした(゚д゚)

まーくー:それ以外の特徴だと、連携して動作させるデバイスが多いことが挙げられるね。 デジタル一眼レフカメラでは、本体、レンズ、フラッシュ、レリーズ、etc…あるし、

プロダクション複合機だと本体以外のオプションが豊富で、フルオプション構成で連結するとなんと10メートル以上になっちゃう!オプション構成ごとのテストも必要になってくる。

💡 複合機オプション構成についてのあれこれ(まーくー&くまねこ調べ)
・代表的なオプション類
給紙オプション、製本機、インサーター、紙折り機、フィニッシャー、スタッカー、天地・小口トリマー、パンチユニット、etc…

他にも、用紙サイズや用紙種類もワンサカあって、組み合わせが多いのよ。

💡 用紙についてのあれこれ(まーくー&くまねこ調べ)
・用紙サイズで代表的なもの:
(国内系)A3、A4、A5、B4、B5、etc… (海外系)LTR、11×17、Statement、Legal、Exective、12×18、13×19、etc…
・用紙種類で代表的なもの:
 薄紙、厚紙、普通紙、コート紙、光沢紙、エンボス紙、etc…
本当はまだまだいろいろあるんですけど・・・

くまねこ:組み合わせると倍々ゲームでテスト項目が増加していくーΣ(🐼ノ)ノキャー

まーくー:そうなんだよ。ファームウェアに限らないけれど、特に時間の管理(削減)・配分(状態遷移・耐久系など時間がかかるテストに時間を割く)が重要になってくるね。

ファームウェアテストに有効なテスト設計技法って?

まーくー:ファームウェアのテストはとにかく組合せが多いから、組み合わせテスト技法で項目数を削減していたね。 連携デバイス間の設定値の変換テストを担当したことがあったんだけど、全項目やろうとすると項目が爆発しちゃうんだ。例えば組み合わせたい因子が10あって、それぞれ3水準と仮定しても3の10乗・・・59,049通り。

くまねこ:1分で1項目やっても6人月以上かかる!!!全部テストできるかーい!

まーくー:もっとも全ての因子が3水準じゃないとか、因子間の禁則もあって単純計算できないけど、それでも膨大なことには変わりない…なので、2因子間網羅に注目した直交表やPairWise法を使って項目削減してたんだ。試しにPictMasterで10因子3水準の直交表を作ったら27通りで済んだ。網羅率は下がるけど、効率よくテストするには必要な技法だよね。

くまねこ:闇雲に項目を減らすんじゃなく、統計的に証明されたテスト設計技法を用いて、削減することが重要なんですよね!

【PictMaster使用例】

①「パラメーター」欄に組み合わせたい因子(10因子)、「値の並び」欄にそれぞれの水準(3水準)を記入

②実行ボタンを押すと、組み合わせ結果が出力される! (「環境設定」で生成方法:直交表、直交表:サイズ優先を設定)

※下記は出力結果を成形したものです。

※直交表含む組み合わせテストについてはこちらの記事が詳しいです♪  「組み合わせテストの設計について、HAYST法を勉強してみた結果

くまねこ:おおっ、良い感じになりましたね \🐼/

まーくー:組み合わせテストについてはここまでにして…次は状態のテストについて。

複合機のテストをする際、さっき話した「待機状態」「節電状態」「スリープ状態」の他にも「複合機」って言うだけあって、コピー、プリンター、スキャナー、ネットワーク機能、文書管理機能が「複合」されているので、それぞれの稼働中なんていう状態も当然考慮に入れなくてはならないんだよね。

くまねこ:当時は状態遷移図と遷移表を作って状態遷移テストしてましたよね。

まーくー:うん。「デバイスの状態」「イベント」を開発資料から抜け漏れなく読み取るのが大事なんだ。例として下のような状態遷移テストを作ってみたよ。どうよ?

※状態遷移テストについてはこちらの記事が詳しいです♪ 「幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト

くまねこ:おおっ、良い感じですね!でもまーくーさん、上の図ですけど・・・逆向き矢印のイベントってあるんじゃないですか?表もハイフンのところは本当に何も起きないで良いんですかぁ???(大事とか言ってたのに・・・)

まーくー:(うぐっ)くまねこさんが気付くか試してみたんだよ。ははは。繰り返しになるけど実際「状態」も「イベント」も多岐にわたるので、それらを漏らさず開発資料から読み取る事が重要だよ!

くまねこ:(疑いの目)でも、図や表にすることで状態やイベントが整理できて良いですよね。抜け漏れが一目瞭然!例えば節電状態の時にイベント①が起きたらどうなるの?とかの気づきを得られたり、状態に対する網羅度が明確になりますね。そのままテストケース化しても良いし、ファームウェアのテストではうってつけのテスト設計技法ですよね。

まーくー:そ、それが言いたいわけさ!あと、時間が無いときは探索的テストも有効だよね!今回は書けないけど、次回くまねこさんが詳細をブログ書いてくれるかな(無茶ぶり?(笑))

くまねこ:はいっ!

まとめ

まーくー:さて、そろそろまとめに入ろうか。ファームウェアテストの特徴としてはどんなものがあった?

くまねこ:こんな感じでしょうか。

【ファームウェアテストの特徴】
・内部構造や動作のタイミングを理解していないとテストができない
・特定の状態を作り出すテストがあるが、状態を作るのは結構大変
・耐久系のテストが必須で、かつ時間がかかる
・連携するデバイスなど外部要素も多く組み合わせが膨大になる

まーくー:そうだね。ファームウェアテストは時間がかかるテストも多いから、効率的なテストのためにテスト設計技法を駆使してテスト設計して、どうしても時間がかかるテストにも時間をかけられるようにすることが大事なんだ。

くまねこ:有効なテスト設計技法として、

【有効なテスト設計技法】
・組み合わせテスト技法
・状態遷移テスト

などを使って、効率的に、効果的にテストすることが大事なんですね!

まーくー:そう。デバイスを理解する力と有効なテスト設計技法を、今後もゆるっと磨いていこう♪

くまねこ:は~い 🐼>

(おまけ)ファームウェアテスターの習性?:ゆるっとエピソード

まーくー:ファームウェアテストを担当すると、色々と普段の生活の中で職業病?みたいなゆるゆるエピソードが生まれます(笑)

💡 100円ショップの工具に見とれる?
ファームウェアのバージョンアップの時とか、デバイスの開梱作業なんかで、ファームウェアテスターはドライバーを使う機会が結構あるんです。100円ショップは意外にドライバーの品ぞろえが豊富で、例えば長~いやつは「あの奥のネジ取るのに使えるな」とか、極端に小さいやつは「あの隙間のネジに使えそう」とか、精細ドライバーは「ばねの向こうの小さいネジに便利だな」とか見入ってしまう!100円ショップ行くたびに工具コーナーをウロウロしてました(笑)

くまねこ:みなさんいつも工具持ってましたもんね(笑)

まーくー:他にもこんなことがあったなぁ…

💡 家電量販店でニヤニヤ?
家電量販店とか行くと、自分がテストした製品が無いかな?なんて探してしまう!デジカメなんか実際に触れるので、あのテストが実ってここにいるのねって嬉しくなったなぁ。プロダクション複合機を担当していたころはビジネス街のコピー屋さんなんか覗いて「おっ、あるある」なんてニヤニヤしたりしてました(笑)

くまねこ:確かに、自分が担当した製品を実際に見かけると、ニヤニヤしてしまいますよね。

まーくー:あと、苦労話もいくつか…

💡 再現テストが大変!
テストの最終盤とかに100台中1台だけ!みたいなインシデントが発生したりするとテストチームに再現の依頼が来るけど、すご~く再現させるのが大変!でも1万台出荷するようなデバイスだと単純計算で100台で1台⇒10,000台で100台で発生しちゃう可能性があるから。障害チケットを見ながら、それこそ内部構造や仕組みについて有識者に確認したり、資料を調べたりしながら、可能な限りイメージを膨らませて、凄く必死になって再現を試みる!再現したときは😢ちょちょぎれる!

くまねこ:わかります!ハードウェアの動きも関係するから、同じ手順を踏んでもタイミング等でなかなか再現しない現象を再現できた時は、不思議な達成感が湧きあがりますよね!

まーくー:ほかにも大変だったのが・・・

💡 力仕事が多い!!!
複合機なんて数百kgあるデバイスがトラックで運ばれてきて、それを設置するなんてことも良くやったよね。3~4人で声かけあってトラックから荷降ろして、ハンドパレットトラックで移動してとか!

くまねこ:そうですね…怪我しないようにみんなで力を合わせたのも、良い思い出です。

<🐼>  
_|________   
〇  〇 三  

まーくー:これは苦労話ではないんだけど・・・

💡 デバイスはファームウェアテスターの命!
デジタル一眼レフカメラのテストをしていた時に、地震が起こったことがあって。みんな一斉に机の下に避難したんだ。そんな緊急事態に一番高価なデバイスでテストしていたメンバーを筆頭にみんなデバイスを抱えて机の下に避難したんだよね。デバイスは凄ーく大事だから。

くまねこ:さすがです!

まーくー:そうだね。「あの夜、直交表で夢見たみたいに、俺は生きていきたい。だからもっと早く、もっともっと効率化できるまで、俺たちはテストしつづけていかなければ、Wooooooooh!」って感じだね!

くまねこ:Yeeeeeeeeeeaaaaaaaaaah! \🐼/

まーくー:じゃ…そろそろ次回予告をして終わりにしようか。 次回のまーくー&くまねこさんは?

くまねこ:次回は…
・まーくー、JSTQB ALTM受験で撃沈(予定)?(未定)
・くまねこさん、探索的テストについて考える!(仮) の2本で~す

二人:最後まで読んでいただき、ありがとうございました♪ 次回もまた見てねー 🐻ノシ 🐼ノシ

🐻ゆるっと♪シリーズ🐼

第1話 ゆるっと♪ファームウェアテストよもやま話
第2話 ゆるっと♪学び直し!アジャイルソフトウェア開発技術者検定試験
第3話 ゆるっと♪どうやってる?探索的テストの世界!
第4話 ゆるっと♪学び直し! [書籍]基本から学ぶソフトウェアテスト!
第5話 ゆるっと♪学び直し![書籍] 基本から学ぶソフトウェアテスト!②
   ~あきらめてしまわないでね 難しさ感じても~
第6話 ゆるっと♪学び直し![書籍] 基本から学ぶソフトウェアテスト!➂
   ~きっとそこに信じていた、バグ管理の姿があるはずさ♪~

SHARE

  • facebook
  • twitter

SQRIPTER

AGEST Engineers

AGEST

記事一覧

AGESTのエンジニアが情報発信してます!
AGESTのサービスやソリューションのお問い合わせページはこちらです。

株式会社AGEST

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST