104. リグレッションテストその②
リグレッションテスト
変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般のことをリグレッションテストと言います。
特定の手法を指している言葉ではなくて、そういう目的のテスト全般をリグレッションテストというよーといったかんじです。
昔は「回帰テスト」と呼ぶところが多かったけれど、今のJSTQBのシラバスでは「リグレッションテスト」になっています。
他にも会社によって呼び方はそれぞれ。
かたくなに呼び方にこだわらず、会社でちゃんと伝わる言い方をしましょう。
言葉は正しく伝わってこそのものです。
バグ修正などを行うと中に手が加わるわけで、やっぱり中身はちょっとだけ変わります。
その「ちょっと変わる」によって、その機能からの出力がちょっと変わることもあります。
その機能だけ見ると上手く動くようにはなっているのですが、関係する機能が実は「その出力だと受け付けられない＞＜」とか、受け付けられるように他の機能も修正してたけど直し忘れた箇所がある…なんてなってしまっていて、動かなくなってしまうことがあるわけです。
これは直接関わっている機能（プログラムの中で、その直したプログラムを呼び出しているところ）だけではなく、データなど共通して使っているモノ、システムが歯車のように連動して動いているところでも発生したりします。
マンガで描いたように、新機能から入れたデータが既存システムだと問題ある形だったり。
あと、システムの環境の設定をいじったら他のシステムだと動かなくなってしまったとか。
こう考えると「最終的には全確認では！？」とか「どうやって見ていけばいいんだ！」みたいになるかと思いますが、その辺は次回あたりで描こうと思います。
システムの規模が大きくなれば大きくなるほど、発生するリスクは高くなりますので、リグレッションテストは重要になってきます。
null (ヌル)
データが空、何もない状態を「null」といいます。
テストする人は、登録フォームなどで何も入力しない項目を作って登録をしてみたりするとバグを見つけられたりします。
開発している側は「空で来ることを想定してなかった！」みたいな思い込みがあったりするわけですね。
似たようなところで、割り算が発生しそうな部分に0(ゼロ)を入れてあげるのもいいです。
0で割り算が発生するとエラーになります。
(理由はネットで調べてください。0だと割る数が定まらないよね、とか、1を0.1で割ったら10、0.01で割ったら100、0.001で割ったら1000……割る数を0に限りなく近くしていくと無限大になるよね、とかいろんなことが書いてますｗ）
デグレ
デグレの説明は第102回で行っています。
