Hamata log

[2018-06-16]思いつきで開設したものの、続くのかどうか・・・

ETwest2018に行ってきてみずのりさんの講演を聞いてきた話

Jasst関西の話をまだ全部書いてないのですが、大雨のなかETwestに行ってきました。

目当ては以下のカンファレンスです。

 

「なぜ組込みシステムにおけるテストは難しいのか」

水野 昇幸氏(株式会社Codeer ソリューションエンジニアリングマネージャ)

http://www.jasa.or.jp/etwest/conference2018/confpage-hu05.html

資料公開されたのでURL追記しておきます(2018/08/11)

https://www.slideshare.net/NoriyukiMizuno/etwest2018

 

時間をかけてレポート書いてもそんなに熟成している感じがしないので、今回は逆にささっと感想書いて聞き取ったメモをそのまま貼り付けてみようかなと思います。

 

[感想]

  • アーキテクチャ」と表現するのがいいのかわからないが、受けが良いときもある、というのは少々泥臭い香りがしましたが、名を捨てて実を取るというか、結果にコミットする的な姿勢なのかな、と思いました。プロとしては重要ですよね
  • どうして○○できないの?という言い訳が出た時、言い訳には内在している問題が含まれているので整理してうまく解決すると改善につながる、という話はなるほどと思いました。このあたりはTOCの考え方(UDE→DE)的なものも感じました。
  • 正直なところ、コスト感が大とか効果感が薄いというのは割と心理的な話だったり、マネージメント系の話なので、設計でなんとかなるのかなぁ、と思いつつ聞いていたのですが、モデリングなどして見えるようにできるんだよ、見えるようになれば見積もりいつもやってるんだからできるでしょ、というのは新鮮な印象がありました。
  • 2つのアーキテクチャ(テストシステムアーキテクチャとテストスイートアーキテクチャ)ですが、私はテスト寄りなこともあって、せいぜいテストスイートアーキテクチャ(それもきちんと意識できているかは疑問)的なものしか頭になかったのですが、設計を拡張する形でテストシステムアーキテクチャを考えれば攻めどころがわかりやすくなる、というのはなるほどなと思いました。このあたりもボトルネックを攻めるということでTOC的な風味を感じました。
  • あとは自分がこの内容をどう活かすかだけど・・・・

以下はメモ。あまり整理されてないので読みにくいでしょうが、無いよりマシという程度に。(悪天候で行けなかった、という人に役立てばいいのですが、伝わるかどうか・・・。)

 

「なぜ組み込みシステムにおけるテストおよびテスト自動化は難しいのか」

 

イントロ

  • タイトルに「自動化」を直前で追加した
  • Codeerブースで自動化ツールご紹介しています
  • https://www.codeer.co.jp/
  • 組み込みテストは難しいとよく言われるが、それを整理して改善の一助にしたい
  • 組み込みといっても幅が広いので直接解決にならないかもだけど、ヒントになれば
  • 終了後にCodeerブースでテストに関するご相談受け付けます

自己紹介

  • 現在はCodeerに在籍しつつ、個人でも要件定義やソフトウェアテストの支援をしている
  • 北海道メインですが、日本中あちこち行ってます
  • テスト設計コンテストというのがあってそれで優勝しました
  • ソフトウェアテスト関連、TOC(Theory of Constraints)関連でけっこう発表実績あります

テストが難しい

  • 「テストをより効果的にせよ」「自動化を推進せよ」「コストダウンせよ」と上から言われたら?
  • 言い訳が出がち
  • でも言い訳をうまく整理すれば課題が見えてくるかも
  • どんな言い訳が出る?
  • システムが複雑
  • どこテストしていいのかわからない・・・などなど
  • 集めて分類してみると以下のようなものになりそう
  1. 対象がそもそも複雑
  2. ツールにコストがかかる
  3. テスト実施の難しさに対処できない
  4. 効果を感じることができない、効果感うすい

実際のところ何が難しい?

  • 話が噛み合わないことがある。人によって「組み込み」と言ってもいろいろ
  • これも整理してみた
  • 今までに無いものを達成しないといけないというパターン
    どうやってテストしたらいいのかわからないという問題
  • 多数のインターフェースが存在するというパターン
    システムが複雑でテストが大変という問題
  • システムはなんとか開発できているのだが、派生と改良したようなシチュエーションで、多彩なパラメータに対して安定性が求められるパターン
    要求されるレベルの信頼性を検証するとなると開発に対してテストのコストが見合わないという問題

このままでよいの?

  • 組み合わせテストや結合テストで停滞してませんか?
    見込みより大幅に遅延する
  • テストで妥協してませんか?
    大量過ぎ、手間かかりすぎということで妥協する。「代表的なパラメータで大丈夫でしょ・・・」
    効果が感じられないテストだとなおさら妥協してしまいがち
    でも後で不具合が出てギャフンとなる
  • 全部はテストできないので辛い問題。マネージャー視点だと手間かかる=札束飛んでいく、ということでもある
  • どうやって対応しているか聞いてみた
  1. オフショア(同量の作業を安く上げる)
  2. 探索的テスト(同じ手間でより多くの効果を得る)
  • 現状で十分って人もいるかもしれない
  • でもずーっとそれで大丈夫?
  • リリースサイクルはどんどん短く
  • 繰り返しの負担感がだんだん重く
  • となると妥協発生しやすくなっていく・・・

世界的な潮流

  • Googleは420万の独立したテストを1日あたり1億5000万回実行している(Jasst’18 Tokyo基調講演)
  • Facebookは100人体制で開発していて2週間おきにリリース、ユーザーは100万人。マニュアルのプロセスはスケールしないため自動化ナシはありえないと断言、10%のエンジニアが自動化に従事(ICST2018)
  • これらはWEB業界の巨人の話ではあるけれど、組み込みでも同じ方に風が吹いている。どこかでマニュアルテストはありえない、となるところがやってくるはず。
  • なので組み込み業界でも効率的、自動的な仕組みが必要
  • 実際にエリクソンなどもそちらに変化してきている。日本だけ今のままマニュアルテストで許されるのか??

提案の方向性

  • 演者の経験として、サブシステムからなるシステムの一番問題のある箇所だけをツール入れて効率化したらそれをきっかけに良い方に回りだした(手間が減る→浮いた手間で自動化→テスト実施量増えて不具合減)ということがあった。なので一部だけに導入する、というやり方でも効果はある。
  • また、組み込みとはいえ普通は操作用のツールが存在するのでそれを自動するというようなアプローチが考えられる。
  • 結果判断は人力、としても結構効果が出たりする
  • ただ、それとは系統の違う課題もある(=テストの手間の問題ではなくて、テストの効果が薄い、という問題)
  • その場合はテストケースの量ではなくて質的な改善が必要になる
  • どちらから着手するか、は皆さん次第だが、整理して分けるだけで渾然一体となっているときに比べて行動しやすくなるのでは?

2つのアーキテクチャ


テストシステムの改善(テストシステムアーキテクチャ

  • テストの手間を減らすためにはテストシステムを考慮した改善が必要
  • 例えばシステムの設計時にはほぼ必ずモジュール分けやインターフェースを検討するための絵(モデル)を描いているはず
  • これを拡張してテスト実行ツールやテスト環境も含めて描いて検討しましょう、という話
  • 時間さえ確保できれば現状の延長にある話なのでできるはず
  • 記法としてはUTP(UML Testing Profile, https://www.omg.org/spec/UTP/About-UTP/ )なんてのがあります
  • 例えばテスト設計コンテストの題材のカラオケシステム
  • どこまでテストするのかを考える、作り込む必要がある
  • SUT(System under Test)としてカラオケシステム、周辺のテストコンポーネントとしてリモコンのシミュレータとか、ログ確認ツールとか、楽曲DB制御ツールとかとか。これらを書きながらテスト環境の構成をかんがえていき、テストシステムを設計する
  • 絵を書くと見積もりができるはず(普段システムエンジニアはそうやって見積もりをしているので同じようにすればできる)
  • 見積もりができればコスト感や効果感も判断がしやすくなるはず

テストスイート(=テストケースの集合)の改善(テストスイートアーキテクチャ

  • テストケースを表すアーキテクチャ
  • テストケースの意図
  • テストケースで保証できる範囲の説明など
    を表す構造。テスト設計コンテストで提案されているものはだいたいテストスイートアーキテクチャと言えるのではないか
  • 例えばテストカタマリー
  • テストベース(仕様書)から導かれるものがあったり
  • そうではないが必要なテストをまとめてグルーピングしたり
  • テスト対象の機能によってパラメータがどのくらいあるかなどを整理して考えられる
  • 階層的な表現も可能
  • テストケースの構造を示しながらここで何を保証するのかと言うモデルを表現できる
  • 他の例
  • VSTeP
    http://qualab.jp/vstep/
  • TestAspect
    http://aster.or.jp/workshops/insta2018/img/InSTA2018-Proposal_for_Enhancing_UTP2_with_Test_Aspects.pd
  • テストスイートアーキテクチャを導入することで
  • 俯瞰しやすい
  • 段階的に思考過程を表現できてレビューしやすい
  • 類似プロダクトにも応用しやすくなる

更に両者をくみあわせてみた

  • テストシステムの構造をUTPで記述
  • テストケースをTestAspectで記述
  • ○○のシステム(ツール)が用意できるとこのテストケース群が実行できる、というようなことがわかりやすくなる
  • コストをUTP使って見積もって、効果をTestAspectで見積もる、なんてことができるようになる
  • テスト環境をテストシステムアーキテクチャ、各段階のテスト内容をテストスイートアーキテクチャで考えると便利。試作段階ごとに考えたり、というようなことが容易に。

まとめ