お仕事はテストエンジニア!?

第6話『テスト項目書が雑じゃない！？』

「――よし！」

気合いを入れてテスト項目書に向き合った。

このチーム――企画者、開発者、テスト、デザインを含めたプロジェクトチーム――では仕様書が『聖典』となっていることは今までのやり取りからわかった。

もちろんそれは間違ってはいないと思う。

仕様書は『思い描いたものを正確に人に伝えるためのツール』なのだ。

仕様書でチームメンバーが共通認識を持ってコミュニケーションをとる。

ただこれは「仕様書がカッチリ書かれている」ことが前提。

さっきのような「書いたと思ったけど、実際には仕様書に反映してませんでした」があると、企画者はその機能が作られていると思い込んでいるが、他のチームメンバーは仕様書に載っていないので知らない――つまり『認識齟齬を起こすためのツール』に早変わりだ。

私がさっき気にした文字数は……。

……もちろん仕様書に載っていないのでテスト項目書にも記載はなかった。

ここがないと開発するときに困ると思うんだけど。

私は適当なニュースサイトから記事をコピーして、コメント欄に張り付けてみた。

するとニュース記事は途中までしか反映せず、コメント欄の下に赤字で

『コメントは140文字までです』

と表示された。

なるほどね。

――開発中に開発者もこのことを気にしたのだ。

『いくらでも入力できたら投稿が増えるとデータベースがパンクしてしまう。データベースの設定もできない。何文字までにしたらいいんだ？』

『文字数制限があるとしたら、それ以上入力されたときに入力できない旨を表示しなければならない。何というメッセージを出せばいいんだ？』

『メッセージを表示するなら目立つようにポップアップで出せばいいのか。それとも目立たないように入力ボックスの下に表示すればいいのか？』

これらを開発者個人で勝手に決めてしまっては、他のチームメンバーとも認識齟齬を起こしてしまう。

この決定は企画の領域になりそうだ。

そこでどこかで企画者に質問したのだろう。

すると企画者はこう言うのだ。

『某SNSは140文字ですっけ？　140文字でいきましょう。バーンとポップアップを表示するのもアレですし、入力ボックスの下に赤字で表示でいいんじゃないでしょうか。メッセージ内容？　"コメントは140文字までです"でいいんじゃないですかね』

これはミーティングの場で決まったのかもしれない。

チャットで聞いてその場で決まったのかもしれない。

少なくとも小毬さんたちがいない場所で決定したはずだ。

そのことは仕様書に記載されることなく今に至る――

――こんなところだろう。

「ふぅ……」

こういう場所が他にいったいどれくらいあるんだ……。

他にも入力は無数にあるし、その他エラー時の表示まで考え始めるとキリがなさそうだ。

そう考えると全てを仕様書に書くのも土台無理な話か。

ふと顔を上げると、向かいのちいかわのぬいぐるみの間から、テスト項目に振り回されてアタフタしている小毬さんが見えた。

……せめて決めたことはみんなが見えるところに残しておいてもらえるとありがたいんだけどさ。

仕様書から意識を戻し、今度はテスト項目書に目を向けた。

こちらももちろん仕様書がもとになっている。

もとになっているというか……。

仕様書を開いてページを目で追う。

メインページの仕様部分には

『コメントが送信できる』

と書いてある。

さて……。

目を戻してテスト項目書の「操作」の欄を確認する。

『メインページでコメントが送信できることを確認する』

との記載。

つまり仕様書の文をコピーしてきて、それに『～ことを確認する』と書き足しただけだ。

期待結果を見る。

『コメントが送信されている』

こっちは完了形にしただけっていうね……。

本来の期待結果は、どういった状態になればその項目が合格といえるか、という部分だろうに。

吉村リーダーがブーブー文句をたれながら仕様書からただコピペしている様子が目に浮かぶ。

――プログラムのテストコードを書くときを想像する。

例えば、2つの数字を送ると足し算がされて、結果を返すプログラムだ。

そのときは、1と2を送ると、期待結果は3である。

これが4だった場合は問題があったと言える――

その例でこのテスト項目書の記載を考えてみると。

操作『1+2が計算できることを確認する』

期待結果『1+2が計算されている』

こういったことを書いている。

……私知ってる。これ、小泉構文ってヤツでしょ。

「それだけじゃなくて……」

問題は『コメント送信のテストがこの一項目だけ』ということだ。

この一つで『コメント送信されて反映される』という一番大事な流れは確認できそうだ。

ただメッセージが送信されてから反映されるまでには、裏側では結構色んなことが行われている。

＊＊＊

まずは入力が行われてから送信しようとしたときの文字数チェック。

ここはさっき私が試した通り。

140文字以内なら送信できる。141文字から送信ができない。他に空っぽだったら送信できない、といったところか。

それが問題なければ、多くはPOSTというメソッド――送信するための仕組みでデータがサーバーに送られる。

ここで、どのペットのリストに対して、誰が、いつ、何のコメントを書いたがまとめられて送られるわけだ。

このとき入れるデータを間違えると、別のペットのリストにコメントが表示される、違う人の名前でコメントが表示される、ひとつのリストに何個もコメントがあるのにひとつしか表示されない、そんな問題が起こる。

サーバーに到着したデータはデータベースに入れる前に前処理されることが多い。

例えばデータベースに入れやすい形に整えたり、おかしなデータだったらエラーを返して登録しないようにする。

その他に、メッセージの中にデータベースで実行できる命令文が入っていると実行されてしまう可能性もある。

例えばメッセージに「' or 'a'='a」といった命令が入っていて、それがデータベースで実行されてしまうと意図しないデータ表示がされたりする。これを実行されないように無害化処理したりするわけだ。

ちなみに『SQLインジェクション』と呼ばれる攻撃ねコレ。悪用禁止。

それらを経て、データベースにデータが入れられる。

この時データベースが古いと、絵文字の区別がつかない、4バイトの文字――吉牛の土＋口の字の「よし」など――が入らないといった問題が発生だ。

このサイトで言えば、犬の絵文字を使ったコメントを抜き出したいのに猫の絵文字を使ったコメントが出てきちゃう、よし田さんの名前が表示されずに全国のよし田さんが泣いちゃう、といったところだ。

続いてコメントの画面反映。

まずはWebページが、多くはGETというメソッド――データを依頼する仕組みで「このリストのコメントデータをください」とリクエストを送る。

それに応じて、データベースから該当リストのコメントが全部抽出される。

その時にコメントしたユーザー名やアイコンURLなども他の場所から読み込んで、必要なデータとして整理整頓して返される。

この時はデータベースを実行するコマンドを間違っていたり、効率が悪くて重い処理になったりする問題が発生しがちだ。

そして返ってきたデータをWeb上の適切なところに当てはめて表示を行う。

この時も適用をミスってUI崩れ、つまり画面がおかしくなってしまったりすることがよくある。

ゲームだったら名前表示部分に「8月20日」とかね……。ええ、昔やらかしましたよ。

その他に、Webページに反映する場合はhtmlタグの反映にも気をつけないといけない。

htmlタグというのは、Webページを構成するための命令みたいなものだ。

例えば＜br＞は改行の意味で、これが山ほど書かれたコメントが実行されると、コメント欄が死ぬほど長いというUI崩れが発生する。

その他にも画像などを貼り付ける悪さなんかも考えられる。

なので実行されないように無害化処理を行うのだ。

＊＊＊

『メインページでコメントを送信できることを確認する』

このたった一つのテスト項目。

実はその裏には、汗と涙とうっかりミスポイントがたくさん詰まっているのだ。

なので書かれているテスト項目では確認が足りないように思えてならない。

私が作る乙女ゲーならもっと細かく確認をしているし、人に頼むならもう少し確認してほしい。

「…………」

テスト項目書を下にスクロールしてみる。

――ズラ～リ

『コメントを送信できることを確認する』くらいの粒度の項目が山のように並んでいる。

ってか。

仕様書に載っている全部の文章に「～を確認する」とくっつけた項目を並べてるよね、これ？

このひとつひとつを今私が考えたような粒度に分解していったら、明日のリリースなんて余裕でぶっちぎること間違いなしだ。

試すことを取捨選択しないとタイムアップになる。

……プログラムが見られれば、ユニットテストをしている部分はやらない、といった判断もできそうなものだけど……。

――いやいやいやいや。

私は頭を振った。

今は私の理想論を振りかざすタイミングではない。

なにより何かやらかしたらご飯を食べるお金が入ってこなくなってしまう。私はお腹も空いているのだ。

＊＊＊

「さて……」

メモ帳に簡単に気になることを書き出した。

もし発生したとしたらダメージが大きい問題にフォーカス、といったところか。

そうなると……。

『SQLインジェクション』

これだ。

最近はフレームワークレベル――使っているツールで抑えられていることも多いので通る確率は低い。

だがもし出来てしまったときのダメージは特大だ。

もし発生するとしたら完全に悪意あるユーザーに目をつけられた時のみだ。

そうなると保存されているユーザー情報を抜かれるか、データベースを壊しに来るだろう。

というわけで、攻撃になりそうなクエリ――命令文を打ち込んでみる。

期待する結果は『書いたままの文章で表示されること』だ

もし本当に実行されてしまったら困るし、データベースが壊れるようなものはやめておこう。

壊したら私のご飯を食べるお金が以下略。

――ドキドキ。

実行されませんように、という気持ちは強い。

なんだけど……。

だけどなんだろう、このワクワクするような気持ちは。

実行できるのでは……できたら……。

妙な昂り、高揚感を感じている自分も顔をのぞかせていた。

……いやいやいやいや。

私にシステムをいじめて悦ぶようなサディスティック属性はないはずだ。

たぶん。

緊張しながら実行。

すると、打ち込んだクエリがそのまま文章として画面に反映された。

これはつまり、ちゃんと無害化されて実行されなかったということだ。

念のため変な場所に情報が出たりしていないかをサイトを周って確認する。

「――ふぅ」

……よかった、大丈夫そうだ。

そしてもう一つ、さっきと同じような理由のもの。

私は――

<table border="1"><tr><td>1段目</td></tr><tr><td>2段目</td></tr></table>

ちょっと長めのhtmlタグを書いた。

これも『書いたままの文章で表示されること』を期待している。

そうであれば無害化ができているということだ。

ポチっとな。

すると。

コメント欄に『2段に分かれた表』が現れた。

それを目にした瞬間

「あ」

――トクン。

胸が、跳ねた。

「ん？」

その声に反応して、向かいの小毬さんが「どうしたの？」と言いたげに首をかしげた。

「な、なんでもないです」

……今は。

って！

htmlタグが実行されちゃったじゃん！

腕組をして黙考モードに入る。

――タグの反映。

これだけならそこまで大きな問題じゃない。

せいぜい変な画像を貼られるイタズラをされるくらいだ。

まぁ、それも画像によってはダメージは大きいけど。

問題は

『JavaScriptが実行できる可能性が出てきた』

これだ――

JavaScriptはWebページを操作するためのプログラミング言語だ。

Webページの画面制御やデータ取得はJavaScriptで実行していることが多い。

このJavaScriptは＜script＞というタグの中にプログラム――JavaScriptではスクリプトという――を書くことでで実行可能なのだ。

タグが反映されるということはつまり、『ユーザーがWebページに任意のスクリプトを埋め込んで実行させることができる』可能性があるということだ。

これもSQLインジェクションと同じで、悪意あるユーザーに目をつけられた時に問題になる。

例えば自動的にページを移動するスクリプトを書いて、本物と区別がつきにくい詐欺サイトにユーザーを送ったりできる。

他にも個人データを抜いて人に送るようなことだってありうる。

これは『XSS（クロスサイトスクリプティング）』という攻撃手法だ。

「…………」

タグ実行は許容してスクリプト実行だけは塞いでる可能性……。

……。

たぶんそんな面倒なことはしないな。

<script>alert("こんにちは");</script>

簡単なスクリプトを書いた。

もし実行されたら「こんにちは」というポップアップが画面に表示されるスクリプトだ。

で、これを……。

送信。

次の瞬間。

「わぁっ！？」

向かいの小毬さんが飛び上がった。

どうした、とみんなの不思議そうな顔が小毬さんに向けられた。

「スマホに……スマホに……」

目をまん丸にした小毬さんがスマホの画面をバッと前に向けた。

「スマホに「こんにちは」って挨拶されました！？」