WARAI冬の陣2022でテスト計画についての話を聞いた（2022/11/26）
オンラインで自宅からラクラク参加です。コロナが流行してからというもの、色々と不自由ですがこれだけはありがたいなと思います。
タイムテーブルはこちら。
10:00~11:00 Sect.1 テスト計画を学ぶ
11:00~12:00 Sect.2 組織的テストプロセスの理想と現実
12:00~13:00 休憩
13:00~14:00 Sect.3 アジャイル開発におけるテスト計画
14:00~15:00 フリーディスカッション＆情報交換会
資料は公開可能な部分がいずれ公開されるということでした。
今回の参加の動機は自組織でのテスト計画をより良くできないかなという感じのものです。テンプレートは用意するものの、結局それ埋めてハイ終わりみたいな感じの対応をされることが多く、おっさんとしては言いたくないものの魂入れてほしいなぁとか思ったりするのです。でも今どき「魂入れろ」とか言ったところで通じるわけないので、何かないものかと。できればテンプレートレベルアップできないかなみたいな動機ですね。
ちなみに今回の勉強会のきっかけは登壇者いわく、「テスト計画がテンプレートを埋めるだけの『テスト計画を作る』というタスクになっていて本質を見失ってやしないか？思考停止では？？」という思いからだそうです。はい、私の動機見透かされた上に下心打ち砕かれました。いやまぁそんなうまい話ないですよね。（だいたい私が勉強会に参加するといつもこんな感じですけれど）
ということでSection1です。
Section1はとISO29119を参考に構成されているとのことでした。ISO29119は一部しか無償公開されてないので、代わりに が紹介されていました。ちなみにされているらしいです。（要会員登録）
まずASTER標準セミナーテキストによると
テスト計画は「テストの使命を明らかにし、目的を定義する」
ものなんだそうです。うーん使命ですか。そこまでは考えたことなかったなというのが正直な感想です。
ということで当然使命ってなんなんだということになります。登壇者いわくは使命とは「なぜ我々は居るのか」、目的とは「我々のミッションとはなんぞや」ということではないかと。たしかにそもそもQAを置いているのは何のためなのか、どういう事態を避けたいがために人員として自分は配置されてるの？というのを一度考えてみるというのは根っこのところの再確認のためにはいいかもしれないですね。答えが思い当たるのかという心配はありますけど。
そしてその使命や目的に合致するようにテスト活動を構築する、と話は続きます。状況（今後起こりうること）により課せられる制約（テストがどうやりにくくなるか？）の中であってもテストの目的を達成するためのアプローチとして、プロセスやルールを規定しないといけないと。その結果適切な技法なりタスク、日程を導いていくことになるようです。
で、言われてみればそうだけどできてないな、と思ったのが以下。
テスト計画はモニタリングとコントロールのフィードバックに応じて更新する
うん。書きっぱなしになってること、あるあるです。テスト後のふりかえりもあやしいくらいなので進行中のテスト計画を明示的に修正＆更新なんてとてもとても。（状況の悪化に応じて悪あがきすることはありますが、それとは当然違いますからね）
テスト計画をレビューすることを考えても結局過去のテストからの教訓が必要になるわけだし、それが貯まるためには相応のプロセスがないと個人の記憶以上のものは利用できない、となってスケールしていかないですよね。
計画とはこれからの道筋を作ることで、そのためにはいろんな疑問や障害の解決を明示していくことが必要。それができれば安心感と自信をもってプロジェクトやテスト実施に臨むことができるというのが登壇者なりの解釈ということでした。
次いでISO29119の方ですが、こちらではテスト戦略およびテスト計画プロセスというのは以下から構成されているとのこと。
-
コンテキストの理解
-
テスト計画作成の準備
-
リスクの特定と分析
-
リスク低減のアプローチの特定
-
テスト戦略の設計
-
人員配置とスケジュールの決定
-
テスト計画の文書化
-
テスト計画の合意形成
-
テスト計画の通知と利用の開始
おぉ、こんなにあるのか。そして私が悩んでたテンプレートを埋める段階というのは7番目じゃないか。いきなりこんな後半からやったらそりゃうまくいかないわ・・。おまけに9番までやって完成じゃなくて3番から6番は反復的に実行して完成度を上げていくのだそうです。ここでも更新が大事というわけですね。
で、それぞれの要素を説明していくべきなのでしょうけど、そこは私が変に説明するよりも規格なり解説書読んでもらったほうがよさそうです。
てなわけで早々に話はまとめに。
テスト計画は段階的な策定プロセスの中で様々なステークホルダと合意形成しながら進める。
そうなんですよね。テンプレート埋める作業から始めるのではなくて、まずは関係者との対話が必要ということなんですね。うん、確かにそうだ。
テスト計画はテストチームのためだけにあるのではないし、テンプレのテスト計画書を作りきって終わりというものでもない。
ぐぬぬ。ぐうの音も出ません。
そして組織的テストプロセスとの関わりとの考察として以下が続きます
計画の合意事項に置いては過去の結果、データを参照する場面が多い。組織的なテストプロセスによって得られるテストに関するデータを新たな計画に対して用いることでテスト計画が誤った方向にいかないように是正する。
これまた納得でプロセスがないと作りっぱなしになりがちだし、見直そうとおもっても素材がない、となるんだなと。計画が大事なんだけど、エイヤッと気合を入れればなんとかなるというわけではなく、ここでも地道な積み重ねなんですね・・・。
以上がSection1の内容でした。
Section2は非公開の内容が多いので書くのは控えておきます。あと、Section3のアジャイルに関しては自分があまりアジャイル開発経験がないのと、聞いていて感じたのが「アジャイルだから特別に何かやらないといけない」みたいなのは無いんだなと言う印象だったのでこれまた特筆しなくてもいいのかなと。
短期間なのでプロセスを軽量化しないといけない、みたいな話はあるにしても根本的に違うものを持ち出さないとダメ、ということは無いんだよ、というふうに自分には聞こえました。
「検索してたどり着いたけど、ここにも欲しいこと書いてなかったかー」と思った方がいらっしゃったら、多分次のWARAIに参加してdiscordに招待してもらうのがいいかもしれません。資料も貼ってありますし、過去開催回のディスカッション内容も参照できますのでオススメです。
ということでスッキリ解決、とは行かないものの考え続けることが大事という話なのでした・・・。
Pre Jasst'20 Kansai の話
https://jasst20kansai.connpass.com/event/185271/
JaSST Kansai の本番が「テストのための分解、再構築」ということでプレイベントの内容もそれにちなんだものになったそうです。本日のテーマはその分解や再構築の対象になるテスト対象の要求や仕様、これをどのように抽出しているか学びましょう、という講演でした。講演者は豆蔵の大段さん。
ということでいわゆる要求エンジニアリング手法というものの解説がメインとなりました。なぜそうなのかというのは伝えたいこととして冒頭に説明がありました。
ということがポイント、ということでした。
ということで以下本編です。まずは要求の重要性の話。
いくつかのデータを元に説明されていましたが、ソフトウェアのエラーの大半は要求や仕様の不完全さに起因するのだそうです。NISTの2002年の報告ではバグの6割以上が要件分析と設計の段階で発生、US AirForceの1992年報告では修正の必要だったエラーのうち、41%が要件分析、28％論理設計の問題だったんだそうです。いわゆる上流工程大事、ってやつでしょうかね。そしてこの手の話ではお決まりとも言えますが手戻りコストの話と下流ほどそのコストが膨れ上がるという話が続きます。これは研修とかではしょっちゅう聞きますね。手戻りコストは全開発コストの3-5割、そして要求の誤りは手戻りコストの70-85%、仕様関連のバグは全体の50%なんて話があるんだそうです。まぁ現場現場によると思うので参考程度、だとは思いますが。
そして要求に問題があるとどうなるかという例が列挙されていきます
-
開発はしたものの、クレーム発生
-
顧客「なぜこうなっていないのですか？」 開発「その仕様は聞いていません」
-
やりたいことは出てくるが明確な要求は出てこない
-
作業内容や範囲がころころ変わる
-
設計や実装の工程で仕様変更が頻発
・・・・既視感、もとい恐ろしいですね。
-
テスト段階での仕様の問い合わせが多い
-
テスト段階で現物に併せた仕様変更や調整、制限が行われる
-
テスト段階で大幅改修が発生する
・・・これこそ既視感、じゃなかった先を続けましょう。
こういう状況のとき、要求にはどのような問題があるのでしょうか。大段さんの説明が続きます。
-
仕様の抜け漏れ
-
文書化されない仕様
-
曖昧な仕様
-
定義されていない用語の使用
-
矛盾のある仕様
「仕様」を「テスト仕様」に置き換えるとこれはそのままテストの問題でもあり、テストエンジニアは常にこれらの問題に対応しているはず、なので、要求に関する理解を深めることがテストにも役立つ、というわけです。
そんなわけで今回説明いただいたのはシステム開発における「要求エンジニアリング」というもので、要求を獲得し要件化して妥当性を確認する、という作業になります。
早速「要求」と「要件」が出てきました。大段さんお勤めの豆蔵さんでは以下のようになっているそうです
-
要求（顧客要件とも）
-
関係者から出たシステムに対する要望で、そのうち関係者間で取り上げることが合意されたもの
-
-
要件（成果物要件とも）
-
システムが備えるべき特性を技術的に定義したもの
-
ちなみに仕様は
-
仕様
-
要件を必要な詳細度で正確かつ完全に定義したもの
-
だそうです。
違いがわかったところで要求の獲得方法です。大まかな流れとしては
-
生成源を特定
-
抽出（初期抽出→網羅的抽出）
-
折衝
となります。
まず生成源ですが、要求の発生するところはどこか？という話です。例としては以下のようなものが挙げられていました。
-
ゴール
-
いわゆるプロジェクトの上位目標、ビジョンとかですね
-
-
利害関係者
-
ドメイン知識
-
不具合リスト（過去の積み残し）
-
リスク（安全・セキュリティ）
-
このあたりはまぁそうですよねというのが続きます
-
-
運用環境
-
システムの運用稼働に関する制約
-
-
組織環境
-
組織の文化、構造、内部政策
-
利害関係者は実際に人物が存在しているわけですが、それ以外はヒアリングすればよいというわけにはいかないので担当をアサインして要求を獲得しにいくことになるようです。
利害関係者は以下のような方々になるということです。
-
顧客
-
ユーザー
-
システムにより職を失う人も喪失者集団という利害関係者なんだそうです
-
-
マーケティング、アナリスト
-
市場動向やニーズ、ならびにその代弁者
-
-
官庁
-
法規制など
-
-
開発者
-
テスター
-
支援者（テクニカルライタなど）
-
運用/保守担当者
-
生産ライン
-
組み込みではよくあるという話です。
-
こういった生成源にたいして、インタビューしたりアンケートしたり、時には進行役付きのグループMTGとかプロトタイピングして要求を引き出していくそうなのですが、その際のポイントとしては
-
高位の目的、ビジョンやコンセプト、ゴールの理解
-
背景や意図を理解することで認識ズレを防ぐことができる
-
目的や意図から見逃していた要求を拾い上げることができる
-
目的や意図は要求の根拠に相当するものなので、要求そのものとは区別して扱う
-
-
-
用語集をつくる
-
同義語をまとめると効果的（Userに対してユーザーや「一般」も同じに意味になる、とか）
-
こうして初期抽出をしていくのですが、その際には大項目、ID、要望内容、理由などを記録していきます。要望と理由はまとめずに分離して書き、複数の理由がないかチェックするのがポイントだそうです。また、とにかくたくさん出てくるので重要度をつけて採否を決めることも大事で、ここでも理由を記録しておくのが大事です。（あとになってなんで採用しなかったんだっけ？となるのを防ぐため）
ここまでが初期抽出で、ついでそれらに漏れがないのかという網羅的抽出になります。手法としては
-
シナリオを使って網羅的に出す
-
既存システム画面による網羅的抽出
で、対象が違うだけで大まかな流れは同じみたいなので前者で説明していきます。
ユーザーがシステムを利用する局面を具体的に取り上げてその利用のステップに沿って要求を抽出することで漏れをなくそうという流れです。シナリオを定義してユースケースをUMLなどで記述し、それを別途体系に照らして不足がないかを洗い出し、最後に要求間の依存関係を整理する、という手順になっています。
シナリオはアクター、事前条件、システム、事後条件を登場人物とした相互作用として記述されるみたいです。このあたりはもうちょっと具体例があると良かったかなと思います。なんとなくわかった気にはなったのですが、あとで思い返すとよくわからない部分もあるような。
で、これだと初期抽出と変わらないので、網羅するために体系を定義してそれに照らし合わせるということをやります。ここのところがポイントなのかなと思いました。体系はユースケース、ならびにシステム全体に対する非機能要求をもとに構成するようです。
体系というからにはレベル？階層？を揃えないといけないので、以下のような感じにされていました。
-
大項目 ユースケースに対応
-
中項目 イベントに対応
-
小項目 イベント単位の入出力や非機能要求に対応
ふわっとしていた話だったように感じていましたが割と具体的になった気がしました。抽出したユースケースで足りないものがないか並べて付き合わせる感じでしょうか。非機能要求の方は考えが及びにくいのでどうするのかなというところですが、そこで登場するのがこちら。
ISO 25010
・・・・。うーんという気もしますが、そうそううまい話があるわけでもないですよね。といってもあくまで参考に照らし合わせて併用する感じだそうです。まぁ規格至上だとだいたい歪んでしまいますものね。そうは言っても何も参照せずにもらなく抽出するのも難しいわけで、使えるものは使えばいい、ってことなのでしょう。大事なのは範囲を決めてその中をもれなく、ということでした。
あとは要求間の依存関係ですが、こちらは例えば
-
ボタンを押すと商品購入できる
-
商品には対応する購入するボタンが存在する
この場合ボタンが存在しないと購入できないという依存関係が存在するということでした。前者の要求は暗黙に後者を前提にしているので、その存在をあぶり出さないといけない、という感じかな？
そして最後は折衝です。関係者間での合意。重要度や要望元を整理し、種々のバランスのもとに合意を形成します。ここでも採否理由の記録をしておくと役立つとのこと。
合意したら要求を要件化します。要件は完全に定義すれば同じものが得られるようになってないといけないということで、明示的に指定されない項目を含めて明細に指定されないといけないそうです。難しそう・・・。要件を文書化する際の注意事項は以下。
-
体系的に。抜け漏れなく
-
要件リスト全体の体系を明確に
-
明確かつ特定的に
-
仕様と説明は区別
-
要件は検証可能でないといけない
要件を引き出すためには要求との関連付けが大事ということです。要求がないのに要件が出てくるのはおかしいので、要求が漏れている可能性があります。あとは要件を引き出すためには要件自体も体系的に構成することを意識したほうが良い、ということでした。例えば
-
要件の構成項目を事前に決めてそれに沿って抽出する
-
画面レイアウト
-
初期値
-
入力データ
-
事前条件
-
処理
-
出力表示
-
例外
-
エラー
-
性能
-
I/F
という具合に。
ざっくりそんな感じの話だったのですが、最後にテストのとの関わりです。まず結論としては「要求エンジニアリング手法の活用は有用」というのが大段さんの言いたいことで、その理由は
-
体系的に洗い出された要求、要件、仕様はテスト分析しやすい
-
開発との共通理解
-
テスト対象、範囲の明確化
-
テストしたいところを絞り込みやすい
-
というあたりでした。うなずけます。そしてやってることはテストとそれほど違わないとも言っていました。なぜかというと技術要素が同じだから。具体的には
であると。たしかに・・・。
最後にテスト開発への活かし方ですが以下のようなものでした。
-
テスト開発への活かし方
-
要求、要件、仕様のつながりを意識したテスト開発
-
テストエンジニア間の認識ズレを無くす
-
要求、要件、仕様の理解
-
特に背景や理由
-
-
用語の意味
-
-
-
重要なテスト条件の抽出およびレビュー、テストの実施
-
曖昧なテストすべき要求、要件、仕様はないか
-
それらを優先的に、レビュー、テストする
-
-
まだ洗い出されていない要求、要件、仕様はないか
-
開発へのフィードバック
-
-
-
プレイベントなのに書いたのがJasstKansai本番直前になってすみません。
まぁ自分の復習になったので良しとしておこう。
JaSST '19 Kansai の感想
年に一度の恒例行事ということで、今年もJaSST Kansai に行ってまいりました。
今年から場所が伊丹から天神橋筋六丁目に変わりまして、奈良から行くには便利になりました。
内容はせっせとつぶやいたものがまとめられているのでそちらを見ていただくとしてここでは感想など書いてみたいと思います。
まず今年のプログラムですが、昨年は基調講演がTDDだったりと結構技術寄りな印象でしたが今年はテーマが働き方改革ということもあり、かなりマネジメント寄りの内容になった感じを受けました。
基調講演は「プロジェクト運営を乗り切るためのテストマネジメント入門」
実のところまぁ業務でもいろいろ困っているので、即効性のあるステキ手法などあったら持って帰ったろ、みたいな下心がありました。が、早速講演者より以下のお言葉。
このツールさえあればマネジメントはOKというツールがあるという派手な話ではございません
・・・。ですよねー。そんなウマい話があるわけないですよね。そう思っていても毎回淡い期待を抱いてしまう俺、愚か。
とは言え、年間1200プロジェクトの経験に裏打ちされた講演には参考にすべき内容が多々ありました。というか事例のあるある感がえげつない。
リリース直前に不具合見つけて詰められる
あー、ありますね。「なに見つけてくれとんねん、コラァ」みたいなやつ。
市場流出したほうがいいというのでしょうか・・・。お気持ちはわからなくはないけども。
特にリスクのあぶり出しをしっかりしなさい、という実に基本に忠実な話でした。
そのために、「えらい目に遭ったリポジトリつくる」や「先輩にやばかったTOP5を聞くと良い」とか自分でもできそうな内容を言われていたのが手を出しやすく感じでよかったです。
あとは一人では無理なので、というのを繰り返し強調されていたのも印象的でした。
- 一人では無理なので、人に頼む。
- 人に頼むからには簡単にしないとだめ。
- 100点満点狙いの複雑な打ち手はたいてい続かない。
というあたりですね。
「やなことであると認識されてしまうと進まなくなる。やってみようと思わせることが大事」
というのもありました。参考になりました。
ただ、講演が猛烈に早口だったので、そこだけはちょっと悔やまれます。内容の豊富さから行けば当然の帰結だったかもしれないのですが、午後の休憩時間が30分とかいうところがあったので、ちょっと延ばしてもよかったのかなぁ、と後知恵ながら思いました。
昼休み（せっかく便利な立地になったんだけど、結局コンビニで弁当買ってきて会場で食べた）をはさんで、午後は 「新時代で活躍するための、テストエンジニアのキャリアのつくりかた」。講演者はアマゾンジャパンさん所属ってことで、スゴそうと思いつつスタート。
テストエンジニアは開発側ともビジネス側とも接点がある特殊な立ち位置
なるほど、これは心当たりありますね。確かにテストに役立つ知識とかって意外といろんなものがあったり、逆にどんなことでも役立てようと思うと使えそうな気がするよなーと言うのはあるかも。
テストエンジニアに企業が求めるスキルを求人からひもといていくと・・・
- コンピュータサイエンス
- テスト自動化経験
- コーディング/デバッグ経験
- データ分析スキル
- テストケースマネジメントツール使用経験
- そして避けることができない 英語力 などなど・・・
はじめの印象通りスゴいことになってきた・・・。
私はもともとの配属でメンタルやっちゃってテストに回されたくちなので言うまでもなくポンコツなわけですが、普通に考えりゃ開発とちゃんと対話しようと思えばそうなりますよね。とりあえず啓発に励まなにゃならんということは認識できました。
で、話は成長するにはどうすれば？という方面へ向かっていきます。
成長のためにできること
- 仲間を見つけよう
- 師匠（メンター）を見つけよう
- 優秀な人と仕事をすることにこだわろう
- 自分の実力を測ってみよう
だそうです。２．３．あたりはなかなか難しそうですね。
１．とか４．とかあとモチベーションを維持する点においては私の場合は年一回のJaSST Kansai がとっても役立っております。
続いてはJaSST'19 Tokyoの再演、「意図的にバグを混入させたソフトウェアを用いた研修の実践と効果」
基調講演でも「訓練された要員を適時確保することは難しいので教育は重要」という話がありましたが、こちらはその教育の話です。
社内で技術の普及を担当されているということで、研修を実施して受講者からかなりな好評であるにもかかわらず、その後プロジェクト支援に入ると教えたこと全部忘れてるやないかという有様というのが悩みだったんだそうです。
謎のマトリックスで丸が埋まってくテストとかやってるんです
あっ。それ見たことあるような・・・。っていうか謎マトリクス書かせてるかもしれん、俺。
それはさておき、研修の効果が出ないのを考えた結果、
設計書渡す、演習して解答配る、では体験が薄い
体験が薄いので Knowing-Doingギャップを越えられない、つまり知ってるけど実践しない、となっていた。との分析結果。
それを踏まえてバグ入りソフト、仕様書、果ては打ち合わせ議事録まで用意して一式引き渡してテストを体験してもらう、という研修メニューを考案されたとのこと。スゴすぎる。私も研修担当するときがありますが、流石にそこまで丁寧には作り込めてないです。正直やっつけ仕事になってること、ありがちです。
これだけ丁寧に作り込むとコンテンツを渡すだけで自学自習してくれるそうで、研修教材たるものそこまで行けば理想的だよなぁ、と思いました。
短期間で多くの要員を教育する、ということができれば組織の実力は飛躍的に上昇するというわけで大企業ではとっても大事ですよね。短期間で技術を組織に行き渡らせる、というか。自分の中のKnowing-Doingギャップは現時点で何に関して大きいのかなー？と思いました。
最後は「リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく テストエンジニア版」。
正直なところ、ウチの部門はリモートワークどころかフレックスタイムすら導入されてないので、この講演はちょっと参考にならないかなー、と思っていました。
でもそんなことありませんでした。それはリモートワークの定義が以下だったから。
リモートワークという言葉は範囲広い。異なるロケーションの人と働いていればそれはもうリモートワークと言える。他拠点や外注先だってそう。そう考えると2019年現在、ほぼすべての人がなんらかの形でリモートワークしていると言っていいのでは？
うん。確かにそう言われればそうだ。ウチなんて大半アウトソースでかなりの部分がオフサイトなんでもろ該当だこれ。
情報のとり方についてもしかり。なんとなく耳に入ってくる、ということは期待できない。自分から情報を取りに行かないといけない。
うんうん。ちゃんと明示的に言わないとダメですよね。
突き詰めると、リモートワークが難しいのではなくて、コミュニケーションが難しい。
あぁ、そういうことですね。納得。
チャットのややこしいところは全員に見られてしまうところ。「ここわかんないだけど」みたいな話はちょっと無知をさらすみたいでためらう人が居たりする。
デジタル心理安全性が低い状況。 結果、DM依存してしまう。 そうなるとデジタルタバコ部屋的な空間が出現する
うちはチャットというかまだメールがメインですが、これは非常に心当たりあります。対応間違えると周囲から袋叩きで批判される環境じゃチャレンジなんてするわけがないし、失敗しないことだけが優先されるよね。
心理安全性に関してはこちらの資料が参考になると紹介されていました。
まとめは
リモートワークは難しい。テストエンジニアはなおさら。 だけど分野によっては可能性があるし、難しさとメリットを天秤にかけて適切に使えば非常に強力な武器になり得る。
という一見すると煮えきらない感じの結論ですが、結局題名どおり歯を食いしばってやっていくことが大事なんだな、と。
ちなみに道具にお金をかけましょう、ということでテレコン用のデバイスとかでノイズ入ってイライラするのはもったいないよ、という話が紹介されていました。でも演者は結局iPhone付属のイヤホンに回帰しているそう。意外に優秀らしい。
リモートワークはしてないけど、最近テレコンなんかはするので、今度いままでに使用したデバイスの感想でも書いてみようかな。
とまぁダラダラ書いてしまいました。
去年（メモとっといてあとで再編集してブログ化）のほうがまとまっている気もしますが、今年はTwitterでつぶやきまくってみました。意外と一日中テザリングでTwitterしても通信量はそれなりでした。気楽だけど１年後とかに見るならまとまってるほうがいいかなー？両方やるのはしんどいしなぁ・・・。
Redmine.Tokyoを聞いてみた
Redmine.Tokyoの第15回勉強会を聞いてみました。
東京に行かずともYoutubeライブでリモート視聴できるとは便利ですね。
資料は順次Upされるようですし、以下もあるのでごくごく簡単に感想だけ書いてみます。
まずは新バージョン（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とかですが今年はどうなるかな・・・？？
