ご無沙汰しております。WACATE実行委員のきんぢです。WACATEブログで記事を書くのは、本サイトをリニューアルしてからはじめの数回以来、実に半年ぶりでございます。
来たる6月、WACATE 2019 夏が開催されます。プログラムでも予告しているとおり、今回のWACATEは2日間（実際の作業時間としては7時間もないですが）という限られた時間で、テスト計画からテスト設計、さらにはテスト実行まで参加者のみなさんに実施していただきます。
テスト実行をするためには当然「テスト対象」が必要となります。私はソフトウェアテストは、ひとつの点において、ソフトウェア設計や実装にくらべて学習が難しい領域であると考えています。それは、実践をするための前提条件を整えるが困難である、という点です。実際にテストをするためには、題材となるテスト対象が必要になります。そしてテスト設計までなら仕様や設計があればなんとかなりますが、テスト実行までやろうとすると実装された動作可能なソフトウェアまで必要となります。これらを学習のために自力で準備するのは決して容易なことではありません。実はこの点こそが、私がWACATE実行委員をしている理由でもあります。まさにWACATEはこういった学習環境を参加者に提供できる場ですからね。
さて、今回のWACATEは実際に参加者のみなさんにテスト実行をしていただくためのWebアプリケーションを用意しました。何をかくそう、私がイチから要件定義をしたのちに実装、そして、テストまで行いました。もちろんテストで見つかったバグもありましたが、一旦それらの修正も全て完了させ、その後にみなさんに実際に見つけてもらうために、改めてバグを仕込んでおります。どんなソフトウェアをつくり、そしてどんなバグが仕込まれているかは、もちろん当日まで内緒です！（ソフトウェア自体は後日OSSとして公開することも検討しています）が、ここでは少しだけバグの仕込みについて。
今回仕込んだバグは大きく以下の2つに分類できます。
- 本ソフトウェアを実装中に実際に自分で作り込んでしまったバグ
- WACATE実行委員でブレストして出し合った「Webバグあるある」から着想したバグ
1つめはさらに以下の2パターンに分類できました。
- しっかり仕様を決めたにも関わらず、ケアレスでロジックを誤ったもの
- ふわっとした仕様で実装しはじめて、結果想定外のパターンがあったもの
前者はいわゆる「実装誤り」、後者はいわゆる「設計漏れ」や「仕様バグ」などと呼ばれるやつですね。ちまたにあるバグ分類軸のバグ「原因」としてもよく見るラインナップです。
一方、2つめを仕込むときに得られた気づきとしては、ひと昔前はあるあるだったバグが、モダンなWebアプリだと質の良いフレームワークやライブラリを使うことで未然に防ぐことができる、という点ですね。あまりネタバレはできませんが、例としては「量の多いリスト型のデータをページ分割して表示する際のページングロジックのバグ」がブレストで出ましたが、今回私はRuby on RailsでWebアプリケーションを開発していて、ページングにはRails界隈ではテッパンのライブラリ「kaminari」を使っていたため、逆にバグらせるほうが難しく、結果当該バグを仕込むことは諦めました。（とか言っておきながら、当日バグったらすみません。。。それは私の実装力不足です。。。）バグを分析する際は、扱う技術領域の世代というのもひとつの観点になりえるのかもしれないな、というちょっとした気づきでした。
というわけで、バグの分析や分類というジャンルに少し興味が湧いた、バグ仕込み作業でした。WACATE当日まであと約半月、参加者のみなさんに意義のある時間を過ごしていただけるよう、テスト対象のブラッシュアップに努めます。
当日、みなさんにお会いできるのを心待ちにしております！
という内容を実行委員ポジペにも書こうかと思ったのですが、コピペするのもなんだかアレですので、私のポジペには本記事へのQRコードだけ貼り付けておこうかと思います。
ポジペ is freedom！