2024/3/14(木)と2024/3/15(金)にあったJaSST'24 Tokyoに現地で参加して、その中のセッションの1つ、 「ソフトウェアテストをカイゼンするいくつかのアイデア」を聴講して、講演中に思い浮かんだことやその後考えたことがあったので、せっかくなのでそれぞれ書くことにしました。
※ 講演の様子を細かく書いたレポート的なものではないです
※ 自分について
・Web系システムの受託開発会社のテストチームのリーダー
・システムを動かしてテストする
・たまーにE2Eの自動テストを作ったりもする
・システムのジャンルや規模は様々
・HP/ECサイト/転職サイト/大学の研究室用のなどなど
・継続して追加開発しているシステムもある
講演資料
「時間経過を待つのではなく、イベントを待とう」
講演では「Loadingアイコンが出るまで待ってます、ならwaitやsleepじゃなくてそう書いたほうが良いよ」という話があり、自分もその通りだなぁと思った。 だけどそう思う一方で、自分はこのコードを書くことがまだある。 自動テストに関連するイベント(システムテスト自動化カンファレンス/ソフトウェアテスト自動化カンファレンス)や 自動テストに携わる多くの方のブログでもこれは言われているし、おそらく自動テストの「キホンのキ」的なものなんだろうなぁと思う。
でも自分がいざ自動テストを書く場面になると、自分の「とりあえずすぐ書けるレベルのコード」がwaitだったりsleepだったりなので、 一旦そう書いて「他のコードが自分の想像通り動いているかな？」って試して問題がなかったら、その後にwaitやsleepの部分をそう書かなくて良いように作り直している。
「とりあえずすぐ書ける」っていうのは「コードが動かなかったときに、疑う優先度が低い部分」という感じかなぁ。 自分の場合は、講演中に鉄平さんが言われていた「ある要素が表示されるまで待つなら、そういう風に書けば良い」というケースがほとんどなので、本当とてもごもっとも。 この辺りまだまだ力が足りない部分だなぁ。
「テストを作業項目に沿ってグループ化したり構成したりすることを避けよう」
講演中も質問もあったけど、説明が難しそうなアイデアだったなぁと感じた。
自分は、このアイデアの説明や質問を聴きながら「操作が同じだからといって、目的の違う複数のテストを、1つの操作でまとめてやるのは避けよう」ってことかなぁと思った。 「1つの操作であれもこれもそれも確認してはだめだよ」みたいな感じ。 テストという仕事をやり始めた初期の頃(6 ~ 7年前ぐらい)は、「効率よくテスト実行を終わらせるにはどうしたら？」っていうのをよく考えていた。 極端に言うと「このケース、手間が多い(同じ操作を何回もやらないといけない)から非効率だ」みたいなｗ
いつからかは忘れたけど、今はこういった考えはしなくなった *1。
この「1つの操作であれもこれも」みたいなやり方は「テストして不具合を見つけたり問題ないって確認することが目的」ではなく「テストを終わらせることが目的」になっているんだと思う。
テストやテストケースを終わらせることは、普段のお仕事では求めてないので、このやり方はやってない。
あと、このやり方はテストがうまい人ほどやってて負担が大きくなるんだろうなぁって思う。 例えば、「1つの操作で4つの別々の事柄を確認しないといけない」のと「『1つの操作で1つの事柄を確認する』が4つある」だと、「一度に気にしないといけない最低限のこと」は後者のほうが少ないので、後者のほうが良い。 自分の身近にいるテストがうまい人は「気にしないといけないこと」はもちろんテストするけど、テストを始めると、テストケースには存在しないことをどんどんテストしていってくれる。 テストを始める前に気になってたこともテストしてるだろうけど、テスト中にシステムを動かしてみてから「さらに気になること」ができる。 そして「さらに気になること」をやると、「さらにさらに気になること」ができる、という感じなんだろうと思う。 こうしてテスト中に気になることが増えていくので、「一度に気にしないといけない最低限のこと」が多いと、気にすることの数が爆発してしまうので、しんどくなるんだろうなぁと思う。
ということもあって、自分はなるべく「テストの目的」ごとにテストケースを考えるようにしてるんだけど、 「あ、これとこれ一緒に確認したほうが良いかも」って思って、複数の目的がくっついたテストケースを作ることがたまにある *2 *3。
だいぶ元のアイデアから逸れてしまった。
本に書いてある内容とはたぶん違う気がするので、ブログを書き終わったら改めてアイデアを読んでみる*4。
「テストコードは書くためではなく読むために最適化しよう」
講演中、「例えば、自動テストで検索のテストを書いてるんだったら『〇〇をクリックする』じゃなくて『検索する』って書こうよ」的な話があったんだけど、自動テストだけじゃなくて手動テストでもそういう場面あるなぁと思った。 あと、手動テストの話だけど、自分は『〇〇をクリックする』って書くときも『検索する』って書くときも両方あるなぁと。
「〇〇をクリックする」って書くときは、検索のテストの中で詳細なステップを書きたいときとかで、例えば以下の感じかなぁ。
・検索のテスト 1. 〇〇ページを開く 2. □□にXXと入力する 3. ◯◯をクリックする
講演で出てた検索を例にしたけど、検索のときはここまで細かくは書かないかもしれない。 検索を実行する方法が複数あったら(たとえば、検索ボタンだけでなくEnterでも検索できるとかなら)書くとは思うけど、いずれにせよ状況次第な気がする。
具体的に書きたいときは、どちらかというとテスト手順が難しいときかなぁ。 「外部連携しているシステムを使わないといけないから、操作手順をいつもより細かく具体的に書いておこう」というときとかはかなり具体的に書いてることが多い。 テストと言うよりはマニュアルに近いかもしれない。 未来の自分たちに向けて、例えばこの先追加開発などがあってもう一度この操作をするときとかに思い出せるように、と思って具体的に書くことがある。
あと、講演では自動テストの話が主だったけど、自動テストの場合はより読みやすさが大事なのかなぁとも思った。 このテストは、「検索機能」をテストしたいのか、それとも「〇〇をクリックする」というテストをしたいのか。 この場合「〇〇をクリックする」は検索を実現する1つの手段のように見えるから、「検索する」って書いてあるほうがテストしたいことがわかって良いなぁと思った。
「自動テストは頻繁に実行し、割れ窓はすぐ塞ごう」
これも自動テストだけでなく手動テストもそうだなぁと思う。 自動テストと手動テストだと起きる事柄が変わってくる気はするけど。 でもどちらにせよ、窓を塞ぎやすいような状態にしておくのがコツかも、と思った。 修正する習慣をつけることで、と資料に書いてあるけど、面倒くさがりな自分からすると、こういうのは習慣にするまでが結構大変。 だから「修正しやすいようにするにはどうしたら？」とか「修正したくなるようになるにはどうすれば？」っていうのをよく考えている *5。
手動テストの話になるけど、テスト中にテストケースを書き換えれるようにしたりとか、テストケースをマスターからコピーして使うというタイプのテストケースには、マスターへのリンクを張っておくとか。 地味だけどそういうちょっとしたことをやっておくと、すぐに修正しやすくなる。 あとこういうときは、チームメンバーがすぐ修正してくれるというのがとてもありがたい。 「自分じゃなくてチームメンバーがやってくれる」というわけではなくて「チームメンバーがやってるし自分もやらないとな」という動機が生まれるのでやりたくなる *6。
おわり
講演で紹介されたアイデアは11個あったんだけど、さすがに11個書くと大変なのでその中から特にいろいろ思ったものを書いた。 講演とても良かったなぁ。 本の解説もありつつ、鉄平さん自身の話もいっぱいあって「訳者オススメの本書籍の使い方」っぽく感じた。 Xにも書いたけど、読書会をしているように感じる講演だったなぁ(他の方の質問に、「えっ、それって〜」と声を出しそうになった)。
あと「ソフトウェアテストをカイゼンする50のアイデア」は、正解じゃなくてアイデアが書いてあるのが良いんだろうなぁと思う。 アイデアだから「自分のところだとこっちのほうが良いかも？」といった感じで、紹介されているアイデアに更にカイゼンを加えることができるし。 もしも「ソフトウェアテストをカイゼンする50の正解」とかだったら微妙だったかもしれない(その場合は、正解じゃないよね〜とかどうやったら良いかなぁとかいう議論が起きそうだからそれはそれで良いのかも)。
現地で参加できたのも良かったなぁ。 同じセッションに参加した人とちょっと会話できたりもするし。こういうのは現地のほうがやりやすいので良い。 楽しい時間だった。 書籍、読めてないアイデアがまだまだあるので、読んでいこうと思う。
