1. はじめに

2019年9月29日(日)に開催されたNaITE(長崎IT技術者会)の#33 UnitTest入門(ツイートまとめはこちら) のLT枠で「品質技術を知る、学ぶ、作る」を発表させていただきました。NaITEの勉強会は何回か参加していますが発表は初めてです。参加されたみなさまのお役に少しでも立てれば幸いです。

2. 資料

資料に記載したURLリンクが踏めないため以下に補足します。
p.4ほかアプリ実行時の消費電力チェックを自動化する検討
p.7 JaSST Tokyoのまとめ(8ページ目)¹
p.10 ソフトウェアの品質保証の本質～技法の変遷から学ぶ～
p.12 ソフトウェア品質シンポジウム2019
p.15ほか出典：バグだけが品質と考えていませんか？～つながる世界に向けてSQuaRE ベースに品質を考えよう！～
p.17 20年後のソフトウェアテストの話をしよう
p.17 builderscon tokyo 2019で「20年後のソフトウェアテストの話をしよう」を発表しました #builderscon
p.23 電圧電流などを測定し、データ出力できる高機能テスター「SD-WWC01」
p.28 mhama/M5StackHIDCtrlAltDel
p.28 M5Stackでコマンド操作
p.28 Universal Serial Bus (USB) HID Usage Tables
p.38 ソフトウェア品質保証入門
p.38 ソフトウェア品質保証の基本
p.38 ソフトウェア品質知識体系ガイド第2版

3. LTの補足

3.1 品質技術のマッピング例(学びの地図)

LTでも触れましたがNaITEはテストだけでなく開発や品質保証など様々なテーマで勉強会を開催されていて資料も126件あがっています(2019/10/6時点)。ぜひ資料を読んでみたり勉強会に足を運んでみてください。

3.2 実機デモ

デモは準備にちょっと時間がかかることと動画の再生は手持ちのモバイルルータが会場でうまく電波をつかめるか運任せなところがあるためテストベンチの現物を紹介するだけの予定でいたのですが、池田さんの4th長崎QDG紹介のあいだに準備が整い冒頭でデモをできました。

ただ、スピーカーから音声を出して再生中、一時停止中がわかるようにすればよかったとあとで気が付きました。改めてデモをする機会があれば改善したいです。

3.3 「品質技術を作る」で触れなかったもの

LTでは品質技術を開発する動機や背景を厚めに話したぶん開発の手順を割愛しています。といっても特別なことはなく、1)目標を立てる→2)目標達成の確認方法を確立する、と資料の9ページ目に書いた通りです。

3.3.1 目標設定

LTで取り上げた資源効率性ですがJIS X 25023:2018(ISO/IEC 25023:2016) システム及びソフトウェア製品の品質要求及び評価(SQuaRE)―システム及びソフトウェア製品の品質の測定 8.3.2 資源効率性の測定量を見てもじつは消費電力は載っていません。こういう時はほかの規格²を参照したり自前で定義することになります。自前で目標を立てるとこんな感じでしょうか。

項目	内容
品質目標	ふだんと同じ使い方をしたときにふだんと同程度の消費電力であること
判定方法	消費電力を測定し基準値と比較する
判定基準	N回測定を行いその平均値が基準値のX倍以内であること

「ふだんと同じ使い方」の中身も決める必要があります。

バッテリーを取り付けた状態 or 外した状態
有効化する通信モジュール(WiFi/LTE/Bluetooth)
画面の明るさ
スピーカー出力の音量
使用する充電器やケーブルの指定³
外部サービスの指定⁴
測定時の環境(室温、湿度)

今時点では基準を持っていないので先々例えば「N回測定しそのうち1回でも最大値が基準値のX倍を超えないこと」と基準が変わるかもしれません。NやXの値はひとまずN=10、X=1.1などと決めてテストベンチを仮組みし、実際に何回か測定して傾向が見えてきたら見直すと良いでしょう。

3.3.2 確認手段

目標にマッチした確認方法を設計、実装します。電力であれば以下のような項目を検討します。

瞬時値/積算値
電圧や電流の測定レンジ、分解能
計測時間の分解能(何秒ごとに測定するか)
測定値の取得方法

今回は動画をストリーミング受信しながら再生したり一時停止したりとダイナミックな動作を行いながらその時々の電力を測定するので市販のスマホ用充電チェッカーを使ってある瞬間の値を測定することとしました。もし確認したいことがスリープ中の微弱な消費電力であれば微弱な電流を検出できる電流センサを用いて所定時間の積算値を求めるなど、目的に合った方法を設計し実装します。

4. Unit TEST入門の感想

藤沢さんのUnit TEST入門のセッションです。

(1)Unit Testフレームワーク(JUnit)が使える言語(Java)でIDE(Eclipse)の支援があるとUnit Testがやりやすい。
(2)フレームワークがあってもUnit Testでテストできるように実装しないとテストするのは難しそう。
(3)仕様ベースでテスト設計を行い、次にカバレッジを満たすように足りないテストケースを補うと良さそう。
(4)ロジックをテストしたいとか、インターフェースをテストしたいとか、目的大事。

プログラムのチェックは実機で動かす⁵かprintf()でログを出すかデバッガで変数の値を変えるくらいはやったことがあるものの、というのも(1)の段階で敷居が高かったのですが、テストツールを作るときに触っているArduino IDE⁶にArduinoUnitというパッケージがあることがあとで調べて分かりました⁷⁸。

今までならUnit Testができると判明しても何をどうすれバインダーとなるのが、まずは仕様ベースでチェックすることを挙げて分岐のからむものはカバレッジを意識しながらテストを足せばよいとすでに分かっているので敷居が下がった感じがします。

5. おわりに

品質技術の開発はありものを調達していたり数十行のプログラムだったりして意外と難しくないと思っていただけたら嬉しいです。
8月～9月はMaker Faire Tokyo 2019、builderscon tokyo 2019、CEDEC 2019、ソフトウェア品質シンポジウム 2019、技術書典7とインプットの機会がたくさんあり、このタイミングで品質保証の話を整理してアウトプットする機会を得られて良かったです。
Unit Testの質問タイムや懇親会でお話ししたことで自分自身理解を深めることができました。

講師の藤沢さん、勉強会を開催されたNaITEの方々、参加されたみなさまにお礼を申し上げます。

1ページ当たりの表示数によってはページ番号がずれることがあります。 ↩
例えばパソコンのバッテリ動作時間であればJEITAバッテリ動作時間測定法があります。 ↩
よわよわな充電器や細いケーブルだとこれが原因で電流に制限がかかるので測定に対して十分な能力を持った機材が必要になります。 ↩
動画の再生であればコンテンツのビットレートやエンコード方式なども決めたいところです。 ↩
タイミングが関係するものはオシロで処理時間を見るとか、、、 ↩
Visual Studio Code + PlatformIOも試したことがありますがhoge.ino 1ファイルで足りるときはArduino IDEで十分で、、、 ↩
ArduinoUnit ↩
Unityでやる方法もあります→TDDによるマイコンのLチカ開発(1)、組込みCテストフレームワークUnityを導入してテストコード生産性をUp ↩