Hamata log

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

Redmine.Tokyoを聞いてみた

Redmine.Tokyoの第15回勉強会を聞いてみました。

東京に行かずともYoutubeライブでリモート視聴できるとは便利ですね。

redmine-tokyo.connpass.com

資料は順次Upされるようですし、以下もあるのでごくごく簡単に感想だけ書いてみます。

www.youtube.com

まずは新バージョン(4.0)。まもなくリリースのようです。

新しいリンク書式が導入されたり、プレビューが便利になったりするようで期待です。

ただ、プラグイン類はおそらく動かなくなりそうなのでそのへんの検証は充分時間をかけないとダメかな。

あとはプラグイン類のお話をたくさん聞けました。お世話になってます。
それからLTでは

Ankosoft Redmine Jenkins SVN ALM PMS | redmine.tokyo 第15回勉強会発表資料

の話が興味深かったです。早速週明けにでも同僚と相談して実装できないか検討開始しようかなーと思いました。

 

すごい短文になってしまったけど、まぁいいか・・・。

 

JaSST関西’18に行ってきた話(招待講演編)

招待講演「ニューノーマル時代のテストエンジニアへの"food for thought" ~ ソフトウェアテストの60年を振り返り、ニューノーマルの背景を考える ~」

http://jasst.jp/symposium/jasst18kansai/details.html#S4

講演資料:https://www.slideshare.net/Bugler/food-for-thought-jasst18-kansai

 

JaSST関西終わってからいつまで放置しとんねん、と言われそうですがはてなブログから「お前、最近ブログ書いてないな」と言われたことなので書いてみます。(公式のレポートページがまだなのでセフセフとしておこう)

でも講演資料公開されているのでそっち見ればいいような・・・。まぁ自分の復習ということで書いていこう。他人のことは気にしない・・・。

 

演者の辰巳さんは富士通に入社してソフトウェア検査に従事し、最近定年されてなお、テストに関して探求を続けている、ということです。すごいですね。私なら定年したらすぐ遊び回ってしまいそう・・・。

 

講演タイトルの「ニューノーマル」ですが、これは以前ならば考えられなかったことが当たり前の状態になるということを意味する言葉だそうです。で、ソフトウェア関係の「ニューノーマル」としては「ソフトウェア開発のニューノーマル」というエッセイ(Michael Sowers, The New Normal for Software Development and Testing, Better Software Magazine, 2017)があり、ここでニューノーマル時代のソフトウェア開発技術の特徴として以下が挙げられているそうです。

 

(1) 開発とテストはチームスポーツ

(2) データとアナリティクスの役割の増加

(3) テストと開発の協調(TestDev)の考え方の拡大

(4) 全て継続(Continuous everything)は全て自動化すること

(5) 稼働中テスト(Testing in production)は珍しいことではない

(6) より深いスキルセットが必須

(7) 自動化の拡大

(8) チーム全体の責任

(9) ほぼリアルタイムな測定やメトリクスが可能

(10) リスクの許容範囲の変化

 

なんというか自分の置かれた環境が全然ニューノーマルじゃないな、というのをひしひしと感じます。

もう一つ紹介されたキーワードが「DX」「デジタルトランスフォーメーション」です。これは最近よく聞くようになりましたが、いまいちよくわかっていなかったのですが、講演資料にあるようにいくつかの形態?のようなものがあるようです。

 

そんなわけで講演の内容としては、こういった流れにどう対応すればいいのかというところを明らかにするために歴史からなにか学べないか、というような視点で進んでいきます。

ソフトウェアの歴史を追っていくと、登場したのが1950年代、60年代に台頭し、70年代には富を創造するようになり、80年代でパソコンとして個人の手にわたり、90年代の.comを経て2000年代にはソーシャルネット、そして現在のCloud、ビッグデータと変遷していきます。しかしながら演者の調べによると、これらの流れとテスト技法の進展になにか関係があるかというと見いだせない、というのが現時点での結論、とのことでした。(だからと言って意味がない、ということではないと個人的には思っています)

 

ではテストのニューノーマルというのはなんですか、という話が次に来るのですが、最近の動向として、テスト工程は時間がかかるので、そこをなんとかしようという動機でいろいろな試みがされているようです。計画>実装>ビルド>テスト>リリース>デプロイ>運用という流れのなかで、狭義のテスト工程からその左右に広がっていくということで、シフトライトテストやシフトレフトテストという潮流を紹介されていました。

 

シフトレフトというのは狭義のテスト工程よりももっと早く(フローの左側で)テスト活動する、というもので、発想的にはWモデル同様とのことでした。当然コンポーネントが揃わないので、そのあたりをカバーするための仮想化やAPI活用、というあたりがポイントになってきます。もう一方のシフトライトテストは本番稼働中の環境などでのテストのことで、様々ありますがA/Bテストなども含まれるようです。テストと言ってもちょっと違う毛色ですね。(そりゃまぁ本番環境で仕様ベースのテストとかやってる場合じゃないだろという話ですが)運用性とか、ビジネスの方向性を常に検証し続ける、という感じでしょうか。

 

まとめとしてはとにかく変化を察知して素早い対応を、ということと、あとは様々の分野の技術なり発想を広げてテストをより良くしていきましょう、ということでした。ニューノーマルとはいえ、画期的なものが突然生まれるのではなく、そこに至るまでのベース技術があって花開いている、ということなので、さまざまな分野の技術のアイデアを活用できるのでは、ということでした。

 

日々の業務からするととんでもなく置いていかれてるな、と感じましたが時々はこういった情報に接してないといけないな、と思いました。(感想書くのが3ヶ月後じゃおそすぎですが)

 一応Jasstの感想もこれで終わりですね。例年だと次に参加するのはRedmineOsakaとかですが今年はどうなるかな・・・??

JaSST関西’18に行ってきた話(セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」編)

セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」

http://www.jasst.jp/symposium/jasst18kansai/details.html#S3A-3

 

JaSST の話題もいい加減古くなってしまいましたが、あまり気にせずに続けたいと思います。(まだ公式のレポートページもできてないことなので)

セッション3A-3は「お互いが納得感を得られるソフトウェアテスト思考の因子」ということで、特定の技法や技術というよりは考え方や心構え的な話でした。けっこう普段感じているようなことと同じようなシチュエーションが出てきてドキリとさせられるエピソードなども結構あったように思いました。Jasstは基本的にテスト設計やテストアーキテクチャを志向している講演が多い印象なのですが、こと関西(って関西しか参加経験ないですけど)においては結構テストマネジメントな話題もちょいちょいある感じですね。

講演者の杉本さんは現在京セラドキュメントソリューションズにお勤めで、その前はソフト開発会社でテスト業務の受託などもされていたそうです。なので、メーカーと請負の双方の立場を経験されていることになります。

講演の背景として、ネットワーク化が進み、また製品も単に提供されるだけではなくて、サービスやソリューションの一部になるということが年々増えており、システム同士がさらに上位のシステムを構成するというシステムズエンジニアリングなんてことが言われるようになっているという状況があります。ここで演者は問いかけます。「システムとシステム、モノとモノのつながりを論じる前に人と人のつながりはどうなっていますか?」と。

意外と価値観や意識の差があるままコミュニケーションしてませんか、というわけです。そのあたり、納得してコミュニケーションすることが必要だよね、という趣旨でどういうような要素があるのか、ということをお話する、という趣旨の講演でした。

 

というわけでステークホルダーとの関係構築に必要なスキルや心構えについて話が進んでいきます。一例として欧米やインドの話が出てきて、日本に比べるとより低コンテキスト、言われていることはきっちりやるけれど、それ以上は・・・。というようなエピソードが語られます。このあたり、別にどちらがいいというわけではありませんが、少なくとも日本風のコミュニケーションを期待していると痛い目には遭うので、そのあたり納得ずくでコミュニケーションしないと、というのはそのとおりだな、と感じました。

話はそういったコミュニケーションに必要な資質、というところになっていきます。このあたり内容の性格上、なかなか明確に言葉で定義するのが難しいこともあってか、事例に関しても

  • センスのない例
    • 会話中に関係のない話をして何の話かわからなくなる
    • アウトプットがインプットに完全に依存している
  • センスのある例
    • 御用聞き的な働き
      (=不足している部分を見つけ出す、ってことですかね?)
    • ステークホルダー間のつなぎ
    • 想像力
    • 仮説思考、水平思考
      (=これは課題にあたったときに止まってしまわないということかな?)

というような感じで少々エモい感じの表現になってます。

そして最後に出てくるのが『ゴッドハンド資質』なるもの。私の場合、テストでゴッドハンドと聞いて思い出すのはこれだったりします。

テスト設計コンテスト2013 関西地域予選 招待講演 - YouTube(28分55秒のくだり)
https://www.youtube.com/watch?v=zhIk9G7S1Ok&t=28m55s

といっても別にdisっているつもりはありません。一方で実感としてはわかります。何をやってもスジのいい人、というのはいてはります。ゴッドハンドにしてもスジのいい人にしてもその影にはそれなりの理屈なり何なりがあってある種必然的にうまくいっているわけですが、外側から見ている人にそれがすべてわかるかというとそれはまた別の話でして、十分に発達した科学は魔法と見分けが・・・というアレでしょうか。そんなわけで、そういったものを集めて分析する上で仮に「ゴッドハンド」とラベリングして貯めておく、コレクションする、くらいの感覚で捉えるのがいいのかな、と思いました。少なくとも『よーし、ウチでもゴッドハンドを育成しよう!』というのは私には無理だし、社内の他の人がやるにしても成功しない気がします。仮にできたとしても職人的になるでしょうから育成スピード的に見合わないのかなーとか。

 

話はもう少し具体的になっていって、今度は実際にテストエンジニアに必要な資質を

ヒアリングしてみた、という話題になります。出てくるキーワードは 

  • 論理的、批判的
  • 多能工(他人の領域にも踏み込んでいく)
  • 理論的、理想思考(若手の場合、という条件がついていました)
  • 論理的、現実思考(マネージメント層の場合、という条件がついていました)
  • テストエンジニアに大丈夫と言ってほしい
    • テストの一般化
    • 客観的事実の積み上げ
  • 設計者の後追いでないテスト
    • 独立した観点(ロバスト性、と言われていましたが、外乱に強い、というのとはちょっとニュアンスが違う気がします)

 という感じでした。一部独特な言葉づかいなところがありましたが、例えば「理論的、理想思考」というのはToBe志向(~であるべき)ということかな?逆に「論理的、現実思考」というのはAsIsとまでは言わないまでも、よく言われる地に足のついた、という感じでしょうか。

同じくテストの一般化、というのは多分、ですが「世間で言われているスタンダードなどに照らして妥当であることを説明してほしい」、みたいな感じでしょうかね。割とよく聞かれますよね「それってお前理論ちゃうんか?標準とか、なんかないの?」みたいな感じで。わかります。

 

さて、そんな理想に近づくにはどうすればいいのでしょうか。

演者は、テストエンジニアと開発者はやりとりしているようで、実はテストエンジニアから開発者へは指摘なり要求ばかりの1wayな関係ではないか、と指摘します。なので、それにとどまらない多様なoutputを開発者に提供することで、この一方通行を改善してコミュニケーションをよくできるのでは、と言うわけです。例えばテスト手法とか問題の切り分け方などでそういったことができるのではないか、ということでした。これも感覚的にはよくわかります。「開発者にナメられないようによく勉強しましょう」とか、「一目おかれるテストエンジニアになれ」みたいなことでいいのかな?問題はどうやったらそうなれるか、わかんないってことですけども。このあたりは簡単な答えはないのでしょう、きっと。あとは自らパイロット運用して背中で語る、とかアウェーに身をおいて常に鍛える、などのことをおっしゃっていました。逆に上司への要望としては「上げた技術力に応えてほしい」「知識ではなくてアイデアを示してほしい」というようなことを挙げられていました。

 

全体的に課題を共有する、という感じでしたので、「よーしこれでわかったぞ」という感はないのですが、だからといって講演として良くないわけではなく、なかなか共感するところが多かったです。

「メーカーの人は作業が少なくなるのはいくら少なくなってもなーんにも言わないんですけどね、請負になると”稼働”の問題があってまた全然違うんですよねー」とかいうエピソードもワタシ的には “Exactly.(そのとおりでございます)” としか言えないし、(あるべき姿なのかどうかはさておき)非常によく分かるところです。どちらかというと講演というよりは懇親会でオフレコ話を聞かせてもらうといいのかもしれないな、とか思いました(笑)

 

 

JaSST関西’18に行ってきた話(セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」編)

もう記憶が遠のきまくりですが、JaSSTの話の続きです・・・。

 

セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」

http://www.jasst.jp/symposium/jasst18kansai/details.html#S3B-2

参考:https://www.veriserve.co.jp/event_seminar/2018/jasst_2018_kansai.html

 

3B-2ということで、並行セッションの2コマ目は設計セッションから選択してみました。(クロージングのときに実行委員の方から設計セッションと管理セッションの分類にはそれほど深い意味はない、と暴露されてしまいましたが・・・)

 

このセッションでは設計は設計でも「不具合分析」からのテストの「補強」です。

これは結構私の業務上で時々ある話でして、どんな流れでこういうパターンになるかというと、まず思うように品質が上がっていかない状況で開発の後半で思わぬ不具合に遭遇します。そうなると、「こんなのが出るってことは他にもチェックが甘いところがあるんじゃないか?補強を考えてくれ」ということになります。なるのですが当然内容をどうする、という段で今現在漏れがあるので、今のテストの延長ではちょっと、ということになって何か不足している観点なり切り口をどこからから入手できないか?と悩むのが次のステップ。そしてそうそう自分たちの抜けが意識できるわけもないので壁にあたると。で、なんとか手近なものからということで、例えば下流工程から指摘をくらっている不具合を分析して先回りできないか、みたいな話になるという感じで不具合分析に追われた経験持ちの私です。

なので結構このコマ興味ありまして、選択してみた次第です。

 ですが、「ロジックツリー」が少々独特でした。ロジックツリーというとものごとをMECEに枝分かれさせて分解していくやつを思い浮かべると思うのですが、この講演でいうロジックツリーというのはNGTのことでした。NGTというのはNotation for Generic Testingの略で電通大のにしさんの提唱しているVSTeP(Viewpoint-based Software Test Engineering Process)で使用する記法ですね。

お、じゃぁこの不具合分析はVSTePでやるのかな、と思ったのですが、どうも聞いていると記法を利用する、というスタイルのようです。でもとっつきやすさという意味ではそのほうがいいかもしれないな、と思いました。(とはいえNGTに親しんでいないので、この後の説明の理解に難儀しましたが)

(講演資料が今のところ公開されていないので、文章だけではちょっと伝わらないかもと思いつつ続けます・・・。)

 

そして何をツリー化するのかというと不具合の要素、ということでした。これがまたなかなか曖昧な感じですが、例えば

 

「バックグラウンドへ遷移したアプリに30秒以内に復帰した際に、再生コントロールが正しく動作しない」

 

という不具合だと「バックグラウンド遷移」「再生コントロールが正しく動作しない」「30秒以内」あたりが要素ということになるようです。なんとなくは分かるのですが、他人にうまく説明できるかというとできないなぁ、という感じ。講演中の補足を引用すると

  • 発生しない条件と発生する条件の差異を抽出する
  • 環境-前提―手順(=トリガ)―振る舞い を意識する

というあたりがポイントのようです。

 

そしてここで例になっている「30秒以内に復帰」に関して、実際の不具合例では17秒以上経過すると問題があるということがわかって改修した箇所、という説明があったので、ちょっと引っかかって質問してみました。

 

『なぜ17秒ではなくて30秒を要素として抽出するのか?』と。

 

私が思ったのは、「17秒が境界として存在するのであればその周囲を狙うのが不具合分析としては素直なのでは?」ということだったのですが、回答はちょっと意外な方向から来ました。

 

「我々は第三者検証会社なので不具合に関してその後の情報を得られることが少なく、なので改修に際して得られた情報はこの取り組みでは使用しない方針にしています」ということでした。

 

・・・。なんだか申し訳ない気持ちになってしまいました。私はたまたま不具合改修内容も確認できるような立場で業務をしているのですが、不具合報告しっぱなしでその後のフィードバックがないことも珍しくない、というのは少々衝撃的でした。そんな業務形態もあるのね・・・。

(実際にはこの例でも改修情報についてコメントがあったくらいなので、全然情報が無いわけでは無いでしょうし、得られた範囲で情報使っているとは思いますが、それにしてもなかなか・・・)

 

と、話をもとに戻して要素をNGTでツリーにする話。

ただ、前述したようにNGTの予備知識が無いので、このあたりが理解に難渋しました。

そのあたりは置いておいて、要素間の関係としては以下の4つがあるそうです。

  • And
  • Then
  • After
  • Behavior

多分このへんは全然わかってなかったので今後もしっかりフォローしないとダメだな・・・(泣)。

 

ついで要素をつなげていきます。このあたりもなんとなくな雰囲気になるのですが

  • 画面状態とある機能が動作している状態
  • 画面状態の遷移
  • 画面状態と各操作
  • 端末種類と各種操作

 

あとはこれをフレームワーク(環境―条件―状態―操作)に当てはめるということで新規なテストケースにしていきます。

要素を新たにつなげたルートをフレームワーク上でたどるといいようです。

 

まとめとしてはこの手法である程度不具合を追加で発見できたこと、また、実施タイミングとしては進捗が75%くらいのところでやるのがいいよ、ということでした。

 

感想としては

 まずはこの方法をやるのであれば、NGTちゃんと勉強しないといけないな。

(実際演者さんの会社ではにしさんをお招きして勉強会したそうです)

というのと、もう少し要素の抽出方法や組み合わせ方を言語化というかきっちりさせたいなぁ、というあたりでしょうか。似たようなシチュエーションに遭遇することがあるので、非常によくわかるのですが、うまいこと機能や状況をシステマティックに組み合わせるというとろまでもう一歩な感じのもどかしさを感じました。多分講演した本人が一番そのあたりは実感されているのではないかという気がします。「コツ」という表現をされていました、できれば使いたくない、と思ってそうだなーと。

 

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で見積もる、なんてことができるようになる
  • テスト環境をテストシステムアーキテクチャ、各段階のテスト内容をテストスイートアーキテクチャで考えると便利。試作段階ごとに考えたり、というようなことが容易に。

まとめ

 

JaSST関西’18に行ってきた話(セッション 3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」編)

 セッション3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」
https://www.slideshare.net/keinakahara3/ss-102572276

 

似たような会社に勤務しているというところもあり、気になっていたセッションです。講演者の中原さんは豆蔵やチェンジビジョンを経て2012年にコニカミノルタ入り。この講演は老舗の製造業系事業会社勤務の人向け、ということで私は対象ど真ん中な感じですね。

コニカミノルタさんはご存知写真がメインで創業事業ですが、今やそれはやっておらずという状況で、これからは業界や分野を越えた新事業が必要だ、というのがおおまかなバックグラウンドになります。ということで、経営のトップ階層からは「何か儲かる新規サービスを開発せよ」というお題目。ありがちです。私の周りでも年中聞こえてきます。新規サービスといっても難しい。

何が難しいか、中原さんは以下の2つを挙げます。

  • 何が売れるのか不明(=プロブレムソリューションフィット)
    開発するソリューションが顧客の課題を解決するのかどうか、という点だそうです。なにかにつけては手持ちのソリューションをねじ込んでいき、あまり満足いただけない、みたいなことをよく見聞きしますね。
  • (売れたとして)儲かるのか不明(=プロダクトマーケットフィット)
    こちらはちょっとピンと来なかったのですが、ソリューションとしてすごくいいんだけど、個別過ぎてとか、対象が限られすぎてビジネスとして成長できない場合があって、そういう場合は売れても儲からない、となるそうです。(成長できない=売れないって気もするのですが、伸長していかない、というのが適切なのかな)

特にこの講演では前者を対象とするようなのですが、難しい以上「迅速に仮説検証しながら育てていく」進め方が良い、と中原さんは言います。スライドには「リンスタ/アジャイルやん」と書かれています。そんなことは自明と言わんばかりの書き方ですね。確かに最近の流行で言えばそうなりそうですが、これが老舗メーカーでは難しいと。ようやく本題に近づいてきました。

で、老舗メーカーでは何が難しいのかというと、「組織構造と文化」が問題とのことです。セクショナリズムとか「これまでやってたから大丈夫だろう」みたいなことですね。これをなんとかしようということで、中原さんがやられたのが

  • チーム構成とマインドセットを変える
  • 開発の進め方を変える
  • 品質保証方法を変える

の3つということでした。

 

組織構造と文化により発生する具体的な問題としては2つあって、以下を挙げられていました。

  • 「役割によってゴールが違う」問題
    企画の人は企画を考えるのがゴールであり、ソフト開発は要求どおりのソフトをQCD守って作るのがゴール、というわけです。なのでコミュニケーションもうまくいかないし、そもそもうまく合意に到達できるわけもない、と。
  • 「情報劣化や誤解」問題
    ボールを投げるんだけどグレーゾーンがあってうまく伝わらない問題。「言わんでもわかるやろ」と「書いてないやん」が飛び交うというわけです。これは心当たりもあり、わかりやすいですね。

で、これをなくすために組織構造と文化を変えるということで、組織構造を変えるというのが壁をなくす、文化を変えるというのが「あとはよろしく」とか「ここまでが僕の仕事」というのをなくす、ということに相当すると。

 

徐々に核心に近づいていく感じです。組織の壁を取るために部門を横断したチームを構築したということを紹介されていました。いわゆるスクラムチームというやつで、企画部門がPO、開発部門がDev/ScrumMasterとなるようなチームを作ったそうです(外部からコーチを1名入れて、それが中原さん自身、ということでした)。正直なところ、それをどうやったのかとかいうあたりを聞いてみたかったのですが、そこはバッサリとカットされている感じでした。

参考としては https://www.slideshare.net/keinakahara3/ss-81883094 が挙げられていました。

ちょっと肩透かしをくらった感はあります。でもまぁ落ち着いて考えると、こんなもんは一念発起してやる以外にうまい手なんてないんですよ、という話なのかもしれません。参考資料のスライドの最終ページにも「勇気<覚悟」って書いてあるし。言っちゃなんですが、私なんかは勝手に問題が解決することだけを期待してぼーっとしている部分がないといえばウソになるでしょうし。やっぱり行動しないといけないんだろうなぁと・・・。

やや脱線しましたが、文化の方の話にもどります。こちらはこれまで要求ありきだったのをみんなで考えるようにしたと。ソフト屋さんは脱御用聞きでチーム全体で要求そのものを開発するんだ、ということでした。そのためには開発者もビジネスを知らなければならないと。なのでビジネスの状況を共有したり、ビジネス上の仮説をカンバン化したり、リリースの狙いをボードにして共有したという事例が紹介されていました。

もう少し具体的な手法の説明としてはやや用語というか手法の名称先行な感じではありますが以下のような順で進んでいきます。

  1. 利害関係者の特定
    インセプションデッキ/ステークホルダーリスト
  2. ターゲットユーザーの共有
    誰が使うのか
    ペルソナを使用
  3. 顧客課題の共有
    カスタマージャーニーマップ(ASIS)
    UXベースで考える。不満は何かの機能に偏在しているのではなく、そこに至るまでの体験にも左右されている。
  4. 提供価値の共有
    カスタマジャーニーマップ(TOBE)
  5. 最小限の提供価値と実現範囲特定
    ユーザーストーリーマッピング

と書き並べてみたものの、(アジャイル関係に明るくない私には)さっぱりわかりません。このあたり手法としては有名なのである程度名称だけで話が通じる前提で講演が進んでいく感じでした。とりあえず用語関係、結構しっかりフォローしないと理解が難しそうです。

なんにせよポイントとしては

  • 誰のどんな課題をどのように解決し、どんな効果を狙っているのか
  • そのために何をどこまで作るか

という2Stepであると説明されていました。特に仮説検証のための最小限以上のものは作っても無駄になる、というのが印象的でした。確かに間違っていたときの被害を最小限にするためには余裕があるからといって作りすぎは良くないですが、なかなか実行するとなると難しいですね。あれこれ積んでしまいがち。

講演内容が「アジャイル型要求開発」なので、あとはこれを繰り返すだけ?と思いきや続きがあります。『サービスとアクターのインタラクションしか表していない』ので、足りないと中原さんは言いますが、これまた勉強不足なのでその表現だとさっぱりわかりません。もう少し具体的には「機能横断的な非機能要求がカバーできてない」。これならイメージできそうです。負荷とか応答速度とかそういうやつですね。この辺次第でアーキテクチャはいくらでも変わるので、その辺を抜きにして要求が十分かというとそうではないということですね。なるほど。

でもまだ足りないと話が続きます。最後に出てくるのは「価値提供に値する品質なのかどうか」。品質、これがまた難しい用語ではありますが・・・。これに対するアプローチとして品質に精通している人に協力してもらうというのが出てきました。ちょっとJaSSTということで取ってつけたのかな?という気もしましたが、そうでもなさそうです。

参考に挙げられていた https://www.slideshare.net/keinakahara3/ss-81883094 でもそうですが、開発をアジャイルにしてもQA以降はプロセスが定義されていてウォーターフォール的に、というのは私の周りではちょいちょい目にします。最終製品としては出荷タイミングがあるんだからそれを基準に社内イベントを、というパターンですね。でもそれはこの講演の趣旨から行けば壁を容認することになるわけでダメですよね。となればQAを巻き込んでしまえというのはある意味自然な流れかなと思いました。(できているのが超スゴいなぁ、どちらかといえばそこまでの道のりを詳しく聞きたいなとも思いました。)

実際やったこととしては品質レベルをチームで決める(なぜならば提供する価値が仮説なので品質もまた仮説、よって品証部門だけに責任を押し付けられない)ということをやったそうです。確かに斬新すぎで評価できないというのはありそうな気がします。特に老舗だと分化が進んでいるのでQAがついてこれない、みたいなことは結構あるのかもしれません。となるとQAの巻き込みもそこまで見透かして(=QAに振り回されたくないための作戦)のことかもしれないですね。受け入れ基準を自然言語で定義して開発がそれをテストケース化し実行、結果は自然言語でレポート、というのも受け入れ基準作成にQAを参画させてしまうためのやり方、という見方ができるかもしれないな、と思いました。

最後に質疑応答などありましたが「なぜなのかを明確に伝える」というのが回し方のポイントいう話をされていて、チーム体制とか文化を顧客中心な感じに組み替えていくと結局そうした組織の中で意思疎通するにはそういう軸で語ることが大事になるのだろうな、とある意味納得しました。

 ・・・

正直もうちょっとノウハウ的なものを労せずにいただけたりしないかなーと思っていたのですが、当然ながら現実は甘くなく、精進が必要だということを再認識した次第です。あと、アジャイル関係の用語とかは勉強しないとそもそも話が通じないなというのを強く思いました。カタカナ語難しい・・・。

JaSST関西’18に行ってきた話(スポンサーセッション編)

基調講演編に続いてはテスト管理セッションとテスト設計セッションになります。
これらのセッションは2トラック×3コマになっていまして、計6コマのうち3コマを選択して聴講となります。

私の選択は以下でした。

  1. セッション 3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」
  2. セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」
  3. セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」

 とその前に基調講演のあとにあったスポンサーセッションの話を少し。

基調講演後のスポンサーセッションは富士通さん、ベリサーブさん、JSTQBさんの3社でした。まず富士通さんですがINSTANTCOPYというスクリーンショット取得用のツールの紹介でした。

なんというか、ツールとしての需要は当然それなりにあるし、(賛否はともかくとして)テスト方面でいかにも使いそうではあるのですが、いかんせん基調講演の超洗練されたTDDのライブコーディングから「スクリーンショットを簡単に取得できてExcelテンプレートにはめこめますー」、という話が落差ありすぎて、「お、おぅ・・」という感じになりました。とはいうものの、スポンサー様のおかげで比較的リーズナブルな金額でありがたい講演が聴けるわけですし、スクショツールもある意味ソフトウェアテストの”リアル”なので(良いかどうかはもちろん別の話)そういうのを目の当たりにできるのもJaSSTのいいところかなぁ、と思います。ただこの順番はコントラストがキツすぎてちょっと残酷な感じでしたね・・・。

続きましてベリサーブさんのTESTRUCTUREなるテスト設計支援ツールの紹介でした。ツールの特徴はいくつかあるのですが、今回のセッションではトレーサビリティの確保が容易、という点を押しておられました。特にテスト設計の際に仕様書記載の要件を網羅するように設計しているのだが、時に抜けが発生してしまいヒヤリとするというエピソードを紹介されていました。このツールを使えばビジュアルに仕様書上にタグ付けして要件などを表示し、さらにそれに紐づけてテスト観点やテストケースをたどって行けるような雰囲気の紹介でした。さらにテストケースを自動生成(All-Pair法などを利用)する機能もあるそうです。観点や因子を指定すると組み合わせテストケースを生成する感じですかね?(さすがに手順などまで記載されたものを自動生成するわけではないですよね)ベリサーブさんのようないろんな会社からテストを受託してきてそれぞれのところの流儀があるようなところではこういうのに蓄積するのがいいのかもしれませんね。ウチはそこまでスケールしてない感じですね(設計者が少ない・・・)特許も取得しているということだそうです。(特許第6148362号、http://www.conceptsengine.com/patent/grant/0006148362 )ちょっと読んでみましたが、仕様と観点を格納していてテスト生成機能があってそれらの関連がわかるように表示する、みたいな感じだったので、この手のツールだと何しても該当しちゃいそうな印象ですが、特許的にはどういう感じなのでしょうか・・・。

最後はJSTQBさんでした。いつものような感じで資格制度の説明と直近の話題としてシラバス(FL Agiletester、AL TechnicalTestAnalyst)の紹介でした。シラバスが世に放たれたとなると近日これらの資格認定試験もはじまるのでしょうか・・・。AL-TTAとったらAL完全有資格者になれるらしいのですが、ノンプログラマな私になんとかなるんやろか・・・。(まぁ職場じゃ ALとTMの区別を人事に説明するのが面倒すぎて人事データベースに登録することに挫折してしまいましたが。)ぼつぼつシラバス読んでいかないといかんですね。

スポンサーセッションだけでちょっとした長さになったのでこのへんにしておきます。
しかしまぁスポンサー様のおかげさまで比較的お安くありがたい話が聞けて感謝感謝ですね。

(一昔前は五千円でお弁当ついた上に日経コンピュータ1年購読がおまけとかものすごいお得イベントだったのですが、今でも1日5千円でたっぷりテスト話が聴けるイベントなんてなかなか無いのです。特に関西方面では)