得意なテスト、苦手なテスト
定期的に拝聴しているテストラジオさんの過去回を改めて。
あ、学校の勉強科目の話ではないですよ!ソフトウェアテストの話です。
テスト手法がどうのとか、統計的にどうのとかそんな話は微塵もしない超主観的に振り返る記事ですのでご了承ください。
テストラジオとは
210回(2022/07/06時点)も続いている大変長寿なネットラジオ(ツイキャス・You Tube・Podcast)です。
なそさんとよしたけさんがソフトウェアテストについてその時々の旬なネタ、イベント、経験したことについて語り合っている番組です。
JaSST大好き勢には有名だと思われます。
testradio.fm
なそさん、よしたけさんおふたりとも口調が柔らかく、ゆったりした空気感のラジオで大変素敵なラジオですよ。
日頃職場で詰められたり、ピリピリしている現場で疲弊していても無理なく聞けると思われます。*1
今回見ていた過去回
ソフトウェアテストって網羅的にやるんじゃが…
見出し考えてたら気持ちがおじいちゃんになってしまった…。
ソフトウェアテストに日頃触れている人はわざわざ説明するまでもないので、このセクションはすっ飛ばして読んでください。
ソフトウェアテストってできるだけ網羅的に、見落としがないように工夫するのですが……。
そうは言ってもリソースは限られていますし、ソフトウェアを作った人にも得意不得意はあるものです。
複雑さもソフトウェアのジャンルによって異なりますし、ひとつのソフトウェアの中でも機能によって複雑さやテスト難易度も変わります…。
どれくらいの種類の端末で使われる想定なのかとか、運用のことも考慮せねばなりません。
基本的に全てのパターンをテストするということは不可能です。*2
そのためテスト対象のウィークポイントをつついたり、重要度の高い機能を優先したりするものです。
そして、バグは0にはならないながらも大打撃になってしまうような困ったバグを発見するためにせっせとテストします。
なので得意苦手とか考えることってほぼないですし、やらねばならぬテストを粛々と打鍵するものです。
リソースマネジメント的に重要な情報
冷静に考えてみれば、得意/苦手なテストって限られたリソースの中で戦うには重要な情報ですよね。
みんな薄らぼんやり感じているし、自然と担当分けする時に考慮している気はします。
自然と適材適所になるように割り当ててますね。
ただ、その情報を明示的に重要だって言っている人や本ってあんまり見ないような……。*3
番組内でも触れられていましたが、苦手を放置していてよいとも思っていないのでいつも得意なものを割り当てることはありませんがスピードが求められている際に有効な手立てですよね。
他にもモブテストするときの能力の偏りを考慮する際にも活用できそうだなと思うわけです。
得意なテスト、苦手なテストってあんまり考えたことない
有用そうなトピックかもというのをここまで述べてみたのですが、正直なところ得意/不得意なテストって考えたことないですね。
ちょっと考えてみます。
得意かもしれないテスト
そもそもそれができて何が嬉しいの
テスト方針とかバグ修正方針の検討とかそっち系ですね……テストとして入れていいのかわかりませんが一応入れます。
「それやる目的なんだっけ?」「それができたら誰が嬉しいんだっけ?」っていう台詞をよく言っている気がします。
漫然と作業したくないのと案外齟齬があるっていう経験からだと思いますが……。
同じ内容のテストでも目的によって特に注視する部分を自然と変えているとも考えているので、意識付けという目的もあります。更新タイミング、せっかちな操作系
単純に自身が短気でせっかちなので自然に発見しがちですね。
周りにのんびりさんが多いのでこの辺は自分の仕事とかって思ってるかも……。
こんな感じの操作ですね- ボタンが押せるようになった瞬間に押す
- 操作を終えた瞬間に次の操作をやる
- 〇〇しながら××をやる
- 横着しちゃう系操作
ユーザーが理解しやすいかどうか(説明文系)
担当してきたプロジェクトが同業者が使うものが多くコンシューマ向けではないので胸を張って言いづらいですが….…。
一応、文章系の番人をしていることが多いです。- 項目名・説明文が理解しやすいか、誤解がうまれないか
- 提示必須な文章が漏れてないか(規約とか制限事項とかその辺)
苦手なテスト
ユーザーが使いやすい画面構成(特におしゃれなやつ)
ユーザー観点でのテスト系で一番苦手です。
デザインの勉強不足で苦手っていう意識が大変強いですね。
一応最低限の導線・カラーユニバーサルデザインは薄っすら意識はしていますが…。
特におしゃれで使いやすい画面を求められたら完全にダメです。
その辺は今いる業界の特性も影響しているかも……。
おしゃれさを気に留めもしない場所にいます。誤字脱字
文章の存在や全体把握はそこそこできるんですが、誤字脱字チェックは苦手すぎます。*4
どう頑張っても勝手に脳みそが保管して読んでしまうんですよね……。
頑張って探すけど目が滑る滑る。
相当集中しないと難しいです。
最近は諦めてスペルチェック機能や他の人に任せちゃってる感じがします。言語特性を踏まえたテスト
これも完全に勉強不足ですね。
メインで使っているのが特定の言語のみで他の言語のことを知らないし、その言語についても大した量書いていないので理解していないことが多すぎる…。
とりあえず設計がややこしそうなところを攻めるということでなんとか代替していますが、ニッチなバグを見つけるのが下手です。
こんな業界にいるけど、別にコード書くのがそんなに好きではないっていうのも勉強効率が悪化している要因かと。
周りにそっち系が強すぎる人が溢れるほどいるので自分は「そういう人達が苦手なこと穴埋めしよ」って思って逃げがちです……。
苦手なことを考えていたら落ち込んできました。
苦手は簡単に挙がりますし書ききれない程ありますが、得意は苦しみながらひねり出しました。
他のプロジェクトメンバから見たらまた違う認識がされているかもしれませんが……。
「意識しないでできる」「苦痛が少ない」を中心に得意ということにしてみました。
チームのメンバ全員の得意/苦手を改めて振り返ってみると補完しあえているところ、チームの弱点とか見えてきていいですね。