私は迷いの中にいる

毎日眠気しかない謎の深海魚の一言日記

悪習に囚われていても自分を騙していてもそれでも聴くJaSST'21 Kyushu

12月18日にJaSST九州を聴講しました。(オンライン)
JaSST Online Clover以外だと今年初JaSSTかもしれません。(nanoのVol1だけは聴いたかも)
個人メモなので抜け間違いあります。覚えている内容と感想のみ記載。

各セッションの概要と感想

セッション:オープニングセッション

JaSST九州のコンセプト。関東までいかなくてもソフトウェアのシンポジウムに行ける!というような感じで
オフラインで開催していたころは九州の各県をぐるぐるして実施していた。
今回のテーマは「歴史から学ぶ」

セッション「ソフトウェア産業の技術的負債と経年劣化について」

IBMの細川さんのセッション。
ソフトウェアの経年劣化(特に何も対策しない限り複雑さは上昇し続ける)≒技術的負債の話。
それが発生する原因、返済する目的、返済できない理由
技術的負債の返済方法について数学、データ分析を用いたアプローチ。これらを順序だてて話してくださっていました。
複雑化した(というか、コードクローンだらけ)のコードの可視化は面白かったです。
実際あんなにクローン作り出してしまうものなのかな、、と思いますが、あるのでしょうね。
構造化(数学で求められるよ)や、主成分分析を使って類似パターン見つけ出すはおおおと思いました。

このお話で自分が興味をもったのはコードの俯瞰した見方(似通った部分がないか)を具体例で提示してくださったことと
あとは「返済方法はあるのに、色々理由をつけてやらない」という話でした。

私はこれを責められる立場ではなく、むしろ色々理由を付けてやらない側なのだと思います。
(今回伺った内容でいけば「継続的な開発」あたり)
ではなぜこの話を聴くか。
もうそろそろ「理由を付けてやらないで済む」時代に限界がきているからです。
私は比較的レガシーな環境におり、派遣テスターという職業上裁量もほとんどありません。
それでももうずっとこのままでいけるような状況ではなくなってきている。
自分が望む望まない、どこにいるか、裁量が多いか少ないか、自発的に動くか受動的か。
その要素はもう関係なく変化していかざるを得ないだろうな、ということを感じています。
だから、私は今現在悪習に囚われていようがなんだろうが、来たる変化に備えたい。それが話を聞く理由です。
どう備えるのっていうと私はgit使ったことないので来年はほんとgit覚えたいっていうかCI/CD覚えたい。じぇんきんさん・・
テストケースをgitで保存ってほんとおおーと思いました。コードの構成管理と同じレベルで
テストケースの構成管理、仕様の構成管理ができればテスト作成の前の調査ずいぶん時間減るのではという妄想が膨らみます。

おまけ:スポンサーセッション

ヒューマンクレストさんのセッションが熱かった(2000年代黎明から現在に至るまでの話)

セッション「1番役に立った定番のソフトウェアテスト

ソフトウェアテスト技法ドリル」の著者の秋山さんのセッション。
前半が初級者・中級者の時に知っておきたかったこと、及び上級者に知ってほしいこと
後半がおすすめのテストの作り方でした。
聴講時のメモをみたら「参考になるところを拾って参考にならないところを捨てる」と書いてあったのでそうします。
初心者への知ってほしいことで「正しいことだけを蓄積する」(信用できる人を決める、規格は割と信じていい、本とWebは玉石混合)は
このちゃらんぽらんブログを書いている自分は耳が痛かったです。
わざわざ書くまでもないかもしれませんが当ブログはちゃらんぽらんなので軽く読み流してください。
あとは、耳が痛くてもこれはスルーしてはいけないと思ったのは
「「面白い仕事に出会う準備をしている」というように自分をだまさない」です。
これでギクっとするのはまさに自分がリアルタイムで自分を騙しているからかもです。
でもここで「騙している自分」を誰にも知られたくないと考えて閉じこもるなら
その方が自分にとってはよくないことだと思うので、私がたとえどんなに前向きでなくても思ったことはスルーして消さずに書こうと思いました(それが今です)

ギクっとしたついでに色々書きます。
中級者への知ってほしいところで
「自分が褒められたとき以外で人が褒められたときに自虐してしまうのはやめたほうがいい、精神的なストレスがたまるから」
ここもギクっとしました。まさに↑に自虐が散りばめられていますね。
ただしここで言っている「止めた方がいいこと」は「精神的なストレスがたまる」ことであるなら、前に進めるなら手段は選ばなくていいのかな、などとも思います。
あと「積極的にコミュニケーションをとる」も、私はよく閉じこもっているのでグサっときました。
グサっときたので閉じこもらず公開しようと思い、このブログを今書いています。
ちなみに秋山さんのおっしゃる初級者とは「JaSST nanoで発表すること」でしたが私は初級者ですらありません。

後半のテストの作り方のお話は「テスト技法よりテスト対象の理解をがんばろう」と言っているように見えました。
IVECレベル3を勉強していたときのフィーチャーツリーが出てきて勝手に感動していました。
テスト対象の理解におけるキモはテスト対象の仕様?振る舞い?の構造化にある気がします。
分解の仕方がイケてるとわりとイケてるテストになるのかなと。
(あとはテストしようとしたときのテストするための構造化)

資料公開されていました。
第153回: JaSST'21 Kyushu|Kouichi Akiyama|note

セッション「ライトニングトークス」

特に印象に残ったものについて。

まおちゃさんの「テストコードのないレガシーアプリケーションとの向き合い方」
これはめちゃ参考になりました。↓
Jasst21 kyushu
コードが密結合で・・・という状況が結構あるあるな気がするのです。
変える範囲を切り出して確認範囲を小さく切り出すという発想はレガシーアプリケーションに身を置くものなら頭の隅と言わず真ん中らへんに置いておきたいです。

あとはつれづれと。
キックオフというプロセスに着目しているのは珍しいなと思いました。
キックオフ、人数増えすぎると興味持つレベル合わせ大変ですよね。(ぼんやりピザ2枚ルールを思い出す)

VStepの失敗話。。
発想の出しやすい手段(付箋とか)と、プロダクト理解、なるほどなーと思いました。
失敗事例を見た感じだと、ガイドワードとか使えばよかったのですかね?
観点出しに暗黙的に必要とされている内容が書かれてておおーと思いました。↓
VSTePのテスト観点出しで失敗した事例についての紹介/Failure case of test viewpoint derivation - Speaker Deck

今の私に理解できるレベルを超えていましたがマルチプラットフォームはどこにいてもぶち当たるので
頭の片隅に残しておきます。↓
Apple Silicon Mac + Rosetta 2 + Dockerで arm64(aarch64)/x86_64 とmacOS/Linuxの組み合わせで自動テストする方法(Elixirだけじゃなく汎用の方法も紹介するよ) - Qiita

全体的な感想

知識としてとどめず考え方や行動に活かせる自信は全くないです。
ですが、技術的負債解決に向けての具体的なコード分析方法などをみるとワクワクしましたし
秋山さんのそれぞれのレベルですれば良かったこと、おすすめの話もぐっとくるものがあり
活かせる自信が無い自分でも聴いて良かったとしか言えません。
多分、この話を聞いて、全部を実践しようとするんじゃなく、一つ一つ自分で出来ることにテーラリングして
進んでいければいいのかなと思います。具体的には
・「何か一つを極める」を1歩踏み出してみる。(おすすめの話で出ていたものでも、すくぼっくでもなんでも)
・とりあえず自分の中で閉じない(この文を公開する)
・まじgit
お話をご講演くださったみなさま、実行委員のみなさまありがとうございます。

ひどい文ですが、いつかのJaSST Clover OnlineのOSTのときにどなたかがおっしゃってくれた
「断片的な情報や感想でも書いてあると助かる」という言葉を胸にこのまま公開します。