みなさん、こんにちは！ QAエンジニアのゆーすけです。
11/2にJaSST九州が開催されました。（新潟と同じ書き出し方…）
自分の今期のJaSST参加としては6月東北、9月新潟の2箇所は現地参加としていましたが、今回は九州の中でも福岡開催ということで何やら行けそうな気がしたので、こちらも現地参加をしてきました。
テストの基本に立ち返る
毎年九州内で開催地域を変えてきて、数年ぶりに初期開催拠点の福岡にもどってきたことから
「いまだからテストの基本に立ち返る」
ということをテーマに抱えたシンポジウムでした。
またJaSST実行委員の中に学生の方が参画された、ということもあり、基調講演のターゲットも、
- 学生向け
- 開発をやっているけどテストは初心者
という方が対象とした講演とした、とのことでした。
今回のブログでは主に基調講演の内容を拝聴しながら考えた内容をまとめていきたいと思います。
「わからない？をわかる！に変えよう！- QAエンジニアが実践している基本的な考え方と方法」
ということで、上記が基調講演のタイトルとなります。とりあえずどうしても書きたいことだけを先に書くと、
- 用語はISTQB グロッサリーを活用するのがよい（無料だし！）
- QAの用語統一はプロダクトや会社によって大きく異なる。
- 例えば単体テストという言葉をとっても全然違う
- 単体テスト＝Unit Testのことを考える人もいれば、画面上のかたまりや単機能のことを単体テストという会社もある
でたっ！！！ 自分的QAあるあるの１個目にあげてる内容ですね（2個目以降は未設定）
これを聞いて、「あー、やっぱこれは広く一般的？なQAあるあるなんだな」と強く思いました。
その証拠に、この話が出たときの会場の笑い＋苦笑い＋強くうなずくなど、参加者の反応が本シンポジウムで最も強くあらわれた部分なのではないのかな、と。
この話は自社内の個人の認識相違であれば笑い話ですむかもしれませんが、受発注関係で出た場合は大きなトラブルになるリスクを孕んでいます。
（とある日の光景） ※昔話を事実を元に誇張しています
営業
「クライアント様から見積と人員提案の依頼が来ましたー！”単体テスト”からやってほしいそうです」
自分
「単体テストから？？そうすると開発知見がないと難しいと思うんだけど、それって本当に『単体テスト』の話？？」
営業
「はい、”単体テスト”って言ってました！」
自分
「（ほんまかいな…）」
もちろんこの話のオチは『単体テスト』の話ではなく、単機能テスト＝結合テストだった、ということになります。
この話もまだ笑い話ですみますが、もし単機能テストだと思っていたら単体テストだった、という逆の場合では必要なスキルレベルが変わってくるので、会社間であれば大きなトラブルになる可能性が高いです。
今回の講演の話では「共通用語を定義できる」というインプットでしたが、「共通用語がある」ということが分かってくると、いろんな用語を聞いたときに「それって本当に正しい意味で使われているのか、どういう意図で使われているのか」といろんな部分にひっかかりができ、その「ひっかかる」ということがテストエンジニアとしての血肉になっていくのではないかな、と自分は考えています。
アウトプットする、ということ
講演案内に「紙とペンを使うよ」ということが記載されていたので、「はて？ワークショップ形式で行うのかな？」と思っていた部分があったのですが、実際は、エクササイズとして考えていることの文字でのアウトプットの時間が要所要所で設けられていました。
本シンポジウム中でも複数回に渡って
「レポートを書くところまでがJaSSTの参加です」
という言葉が出ていましたが、これはインプットとアウトプットの関係性的にもとても重要なことだと思っています。
「講義を受ける」といったような知識のインプット工程と、「得た知識を他で活用する」「人に話してみる」「レポートとして作成してみる」というアウトプット工程は、
インプット3割、アウトプット7割
が理想的だと言われています（比率に関しては所説あると思います）
このブログ化も、言ってみればアウトプットの一つとして活用している部分になりますが、実際インプットしたものをアウトプットすることは、人によっては中々ハードルが高い場合もあります。
そういった人はインプットとアウトプットを同時かつ、理想的な比率で行えるワークショップに参加してみる、というのもよい機会だと思いますが、ワークショップに参加すること自体がハードルが高い、ということも往々にしてあります。
今回エクササイズとして、できるテストエンジニアとはどういうことができる人か書き出してみよう、といったような実際にペンを走らせる工程が複数ありました。
こういった講演の流れとしてアウトプットの機会があり、なおかつアウトプットしたものを他に公開しない、という心理的安全が保たれたかたちでの講演は中々に効果的かつ効率的だな、と思いながら参加をしていました。
中には持参したPCで書いた人もいたかもしれませんが、やはりペンを使って紙に書く、とテキストで打ち込む、は効果は違う、と思っているので、個人的にはアウトプットは紙とペンで行うのをおススメしたいところです。
余談ですが、20年くらいまえは不具合レポートを手書き＋FAX＆Excel送付で行っていたころもありますが、いかに最小限の労力でレポートを書くか、ということを求めるために、かなりの早さでレポート作成精度が一定値以上までいった、と思っています。
※文章の一か所直すために全書き直し、とかあったので
テクニカルスキル以外も学ぶ
役に立つテストとして、デシジョンテーブル、境界値という話にも触れられていましたが、境界値の例として
- 未成年・学生無料のイベントがある
- 未成年の定義としては、開催年度内で17歳であること
- 年齢判定としては、生年月日の4月1日と4月2日を境界値として考える
という内容をあげられていました。
ご存じの方も多いと思いますが、学年というのは4/2～翌年4/1生まれで考えられています。
SEの方がそのルールを知らない場合、その判定で不具合が検出される、という話をしていましたが、テストする側もそのルールを知らなかった場合は普通に市場不具合として出るかたちになります（それもかなり恥ずかしいやつ）。
できるテストエンジニアとはどういうことができる人か書き出してみよう、のサンプルとして
「どのドメインでもテストできる」
という項目があげられていました。
言ってみると前項の事例も教育ドメインと言われれば教育ドメインですが、年齢、学年判定は教育系以外でも多く使われる内容です。
つまり極論的にいうと、
「全ての物事の理は、出し分け、分岐の指標になりうる」
だと思いますので、インプットの感度を強く日々過ごされるのがよりよいテストエンジニアへの道に繋がるのではないのかな、と思っています。
まとめ
今回は予めテックブログに書こう、と思って講演に臨みましたが、最初からアウトプットしよう、という気持ちで物事にあたると、
- これをどうアウトプットしようか
- 自分に必要な情報は何なのか
などというインプットしながら同時に脳内でアウトプットする、という状況になると思います。
また今こうして書いていること自体が自分の振り返りや新しい視点の創造になっているので、みなさんもいかにアウトプットをするか、ということに重きをおきながら学習に努めてみてはいかがでしょう。
「レポートを書くところまでがJaSSTの参加です」
書いたので、自分の中でのJaSST九州はこれで終わりになります！
お疲れ様でした！！
