テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



2022クリスマススペシャル「勉強会で学んだことの活かし方」

2022クリスマススペシャル「勉強会で学んだことの活かし方」

この記事は「ソフトウェアテスト Advent Calendar 2022」の24日目の記事です。

 

その昔いた会社でこういった話が出たことがあります。

「テスト系の話はフワッとしたイイカンジの話をしてるけど、結局どうやればいいかわからない。現場でのやり方を教えてくれ」

気持ちはわかりますし、テスターちゃんが生まれた背景もこういったことからだったりします。

ただ、こういったお話をする人は「これさえやればうまくいく!そういう方法がある!」という思考がありそうに感じます。

やり方は一例を示すことはできます。

ですがそれは自分たちのやり方であって、それが他の人でも再現性があるかというと、マンガで描いたように条件が異なるのでうまくいかないことが多いです。

なので、聞いたことをそのまま鵜呑みにするのではなく自分で考えることが大切です。

「イイカンジの話だけど結局どうやるの?やり方教えて」

から

「イイカンジの話を聞いた。自分のとこで使うにはこういったことをすればいいんじゃないか」

への思考のグレードアップです。

今回はそんな話をマンガにしたためたつもりです。

 

具体化すると可能性を狭める

 

今回のマンガでは、勉強会で習ったことを活かすために「エッセンス化」するという方法を示しました。

ただこういう道を示したことで、他にも勉強会で習ったことを活かすための良いやり方、自分に合ったやり方があるかもしれないのにその可能性や発想を潰してしまったかもしれません。

別の例でダイエット法を挙げてみます。

食事で太る大きな原因として血糖値の急上昇(血糖値スパイク)があります。

では血糖値の急上昇を防ぐにはどうしたら良いでしょうか。

そこで「小分けに食べる」という方法があります。

空腹で一気に食べると血糖値が急上昇してしまうのですが、いつも食べている量を小分けに食べていくことで血糖値の上昇のブレを抑えることができるわけです。

血糖値スパイクを抑えるという目的なら他の方法をとってもいいのですが……ほら、もう「小分けに食べる」という方法がベストに思えてきますよね!(笑)

 

具体化することによって、他にも取れる方法があるのにその可能性や発想を潰してしまうなんてこともあったりするわけです。

またマンガでも描いたように条件が違うから適用できない、なんていう思考にもなったりします。

 

抽象化すると発想が広がる

マンガでは「エッセンス」なんて書いたりしましたが、抽象化です。

wikipediaだとこんな風に書いてますね。

抽象化(ちゅうしょうか、英: Abstraction、独: Abstraktion)とは、思考における手法のひとつで、対象から注目すべき要素を重点的に抜き出して他は捨て去る方法である

この辺から2ページ目のりんちゃんのセリフ「抽象的な話はね、本質的な話なんだ」となります(笑)

例えば事例で

「こういう風にUI自動テストを構築して回すようになったら本番障害が減った!」

みたいな事例があったとして、セッティングや具体例などの様々な贅肉を落としていったら

「誰でも簡単にいつでもリグレッションテストが実行できる環境づくりをした」

ことが成功の本質だった、といった感じでしょうか(あくまで例ですからね)

 

ちなみにマンガ冒頭に出た「フワッとしてる!」内容の講演にするならば

「誰でも簡単にいつでもリグレッションテストが実行できる環境づくりが大切だ」

こんな感じですかね(笑)

 

閑話休題

そういった本質を取り出せたらこうも考えられるわけですね。

「なにもわざわざUI自動テストではなくても、ウチはマイクロサービスでインターフェイス部分に問題が多いし、APIテストを開発も叩きやすくすればいいんじゃないか?」

こんな発想だって出てくるかもしれません。UI自動テストの事例発表を聞きにいったのに(笑)

 

形骸化はエッセンスを忘れている

先ほどまでの話とは逆で、何かを具体的にやってるけど何のためにやってるかわからない話です。

皆さんのところにも謎の儀式的なプロセスはあるでしょうか?

例えば、デプロイするときに必ずダブルチェックが必要とか。

なんで我々は毎度毎度こんなに細かくダブルチェックをしているのだろう、けど先輩から代々伝わってきたことだしなぁ……みたいな。

これは「方法」は残ってるのですが「エッセンスが忘れ去られた」状態です。

形骸化ですね。

これも足を止めて考えたりすると

「昔エラーが多発していた。それはほとんどが「うっかりミス」つまりヒューマンエラー起因だった。なのでヒューマンエラーを最小限にするためにデプロイ時にダブルチェックをしている」

こういった内容を取り出せると

「いやいや、ヒューマンエラーを減らしたいならデプロイパイプライン組もうよ。今のメンバーならできる」

なんて新しい方法に転換できるかもしれません。

 

 

さて、この辺の具体と抽象の話は以下の本をオススメしておきます。