107.リグレッションテスト その⑤
リグレッションテストのやり方の一例
変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般がリグレッションテスト。
なので「これ!」といったやり方があるわけではないです。
ここで紹介しているのは作者が行った方法を並べています。
続きを読む自動テストは、プログラムやツールを使って、決められた内容にそって行うテストの総称です。
例えば、プログラムと一緒に「テストするプログラム」を書いて、自分たちの書いたプログラムが思った通りに動くかテストするunit testがあります。
他にもAPIというデータ処理をして返してくれる窓口にデータを送って、返ってきたデータが正しいか確認するAPIテストなんかもあります。
あとは、作ったwebやアプリに対して、自動的にボタンクリックなどをするようなツールを使ってテストするE2E(エンドツーエンド / いーつーいー)自動テストもあります。
テスト業界いる人が「自動テスト」と話した場合はE2E自動テストを指すことが多いです。
開発の人が「自動テスト」と話した場合は、プルリクエスト(自分が書いたプログラムをみんなのプログラムとくっつけてください!というリクエストを投げたりします)したときに自動的に実行されるunit testを指したりしています。
マンガで描いた通り、影響がある部分がどこかはとっっっても難しい問題。
JSTQBでは「影響度分析」という言葉で出ています。
影響度分析…変更が影響するすべての成果物を識別すること。変更を達成するために必要なリソースの見積りを含む。
変更が影響するすべての成果物を識別……とサクッと書いてくれてますが、そんなにサクッとはいかないのが現実です(^-^;
メソッド(プログラムだよ)を直したら、そのメソッドを呼び出しているところを探したり。
データベースのテーブル(表みたいなものだよ)をいじったなら、そのテーブルを使ってるところを探しまわったり。
APIをいじったら速度低下してないか計測したり。
バッチのSQL文を変えたらその影響で速度低下して、そのバッチがつきぬけて(時間オーバー)後続処理に影響ないんだっけって探ったり。
環境の変数をいじったら同じ環境にいるシステムでその変数使ってるところ探したり。
ガッツリやろうとすると時間がいくらあっても足りないところでもあります。
次のお話からは、こんなやり方をしてるところもあるよ、といったお話をしていくつもりです。
テストケースに、そのテストケースが何のテストベース(テストを考える元となる資料だよ)のどこから出したもの、と紐づけておくとよかったりします。
その元の資料にある場所に変更があったとき、どのテストケースの部分に影響がおよびそうかわかりやすくなったり、仕様変更時にどのテストケースを修正したらいいかわかりやすくなったりします。
テストの言葉だと「トレーサビリティの確立をする」なんて難しい言葉で言ったりします。
何を根拠としたものかたどれるようにしておく、ってことですね。
(ちなみに作者はweb系/ゲーム系にずーっと身を置いてますが、本を読み知識としては知っているものの、しっかり書かれている現物には出会ったことがなかったり)
変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般のことをリグレッションテストと言います。
特定の手法を指している言葉ではなくて、そういう目的のテスト全般をリグレッションテストというよーといったかんじです。
昔は「回帰テスト」と呼ぶところが多かったけれど、今のJSTQBのシラバスでは「リグレッションテスト」になっています。
他にも会社によって呼び方はそれぞれ。
かたくなに呼び方にこだわらず、会社でちゃんと伝わる言い方をしましょう。
言葉は正しく伝わってこそのものです。
バグ修正などを行うと中に手が加わるわけで、やっぱり中身はちょっとだけ変わります。
その「ちょっと変わる」によって、その機能からの出力がちょっと変わることもあります。
その機能だけ見ると上手く動くようにはなっているのですが、関係する機能が実は「その出力だと受け付けられない><」とか、受け付けられるように他の機能も修正してたけど直し忘れた箇所がある…なんてなってしまっていて、動かなくなってしまうことがあるわけです。
これは直接関わっている機能(プログラムの中で、その直したプログラムを呼び出しているところ)だけではなく、データなど共通して使っているモノ、システムが歯車のように連動して動いているところでも発生したりします。
マンガで描いたように、新機能から入れたデータが既存システムだと問題ある形だったり。
あと、システムの環境の設定をいじったら他のシステムだと動かなくなってしまったとか。
こう考えると「最終的には全確認では!?」とか「どうやって見ていけばいいんだ!」みたいになるかと思いますが、その辺は次回あたりで描こうと思います。
システムの規模が大きくなれば大きくなるほど、発生するリスクは高くなりますので、リグレッションテストは重要になってきます。
データが空、何もない状態を「null」といいます。
テストする人は、登録フォームなどで何も入力しない項目を作って登録をしてみたりするとバグを見つけられたりします。
開発している側は「空で来ることを想定してなかった!」みたいな思い込みがあったりするわけですね。
似たようなところで、割り算が発生しそうな部分に0(ゼロ)を入れてあげるのもいいです。
0で割り算が発生するとエラーになります。
(理由はネットで調べてください。0だと割る数が定まらないよね、とか、1を0.1で割ったら10、0.01で割ったら100、0.001で割ったら1000……割る数を0に限りなく近くしていくと無限大になるよね、とかいろんなことが書いてますw)
デグレの説明は第102回で行っています。
さて、今回のクリスマススペシャルのお話はYWTの話です。
テストの話じゃないじゃん!というツッコミがあるかと思いますが、描きたいことに走らせてもらいました!
***
作者はここ最近、りんちゃんと同じように毎日の仕事のふりかえりをしています。
そこで使っているふりかえり方法が「YWT」です。
マンガで描いた通り、かなりシンプルで使いやすい方法です。
自分一人だけのふりかえりでも使いやすく、日記のような経験のふりかえりにはもってこいです。
ワークショップでも、例えば最後に参加者にYWTシートを渡して、個人に学びのふりかえりをやってもらうのもよい方法です。
(つぎやること ->業務で活かすこと、なんてしてもよいかもですね)
まず何より大切なのは、最初に「やったこと」を思い出すことです。
「そういえばこんなことした!」
と、自分の経験をもう一度引き出してきて反芻することが重要です。
意外と記憶の彼方にいってしまったりするのです(^-^;
りんちゃんのような日記のときや1年の個人のふりかえりをしよう!なんてときは
「あったこと」
も記載するとよいです。
やったことと起こったことの両面をふりかえることができます。
続きを読む