テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



107.リグレッションテスト その⑤

f:id:m_training:20210607074149p:plain

107.リグレッションテスト その⑤

リグレッションテストのやり方の一例

変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般がリグレッションテスト。

なので「これ!」といったやり方があるわけではないです。

ここで紹介しているのは作者が行った方法を並べています。

 

バグのリストをチャーターにして探索的テスト

チャーターを使った探索的テストについてはこちら。

testerchan.hatenadiary.com

システムテストの後半に行ったりしていたリグレッションテスト。

修正されたバグの一覧をチャーター(テストの参考にする資料、方向性を決める資料といったところ)として確認していきます。

バグの再現確認だけでなく(これは「確認テスト」といいます)、そのバグ票の内容や修正コメントから、関連個所などを確認します。

 

テストケースに優先度をつけてフィルタリング

テストケースに「紐づけ」(トレーサビリティの確立)をしていて、変更時の影響を追えるなら楽なのですが、そうもなっていないところが多いかなーと思っています。

その辺のお話↓

testerchan.hatenadiary.com

なのでよく「この機能を全体的に確認」とか「システムを全体的に確認」みたいにするのですがフルのテストケースを再実施するのは超大変です。

そこでどう絞り込むかというと「テストケースに優先度をつけておく」です。

そこがひとまず通ることを確認しておく、といった形ですね。

コレをやろうとすると「どれを優先するか?優先すべき項目とは!?」みたいな討論は始まったりしますが、それはみなさんでちゃんと話し合いましょう。

 

ツアーを使った探索的テスト

ツアーについては以下のカズさんのブログ、熊川さんの資料に色々お話が記載されています。

www.kzsuzuki.com

以下の資料の15P

http://jasst.jp/symposium/jasst18tokyo/pdf/C4-1.pdf

 

観光ツアーに例えて探索的テストの方向性を定めています。

結構無理やり感もありますけれどw

 

作者がよく使ったのは「ガイドブックツアー」

ユーザーマニュアルに基づき、主要なポイントのみを外さないように操作を進める。

マニュアルに書いてるのに動かない!みたいな本番障害を起こした経験もございまして(^-^;

マニュアルに書いてあるところで問題が起きるのは絶対に避けたい、ということと一通りの主要な機能をめぐることができたので重宝しました。

今のウェブ系サービスだとあんまりマニュアルがないかもしれないですが……。

 

あとはガーベージコレクターズツアー(ゴミ収集車ツアー)

細部にはこだわらず、画面ごと、ダイアログごとに、明らかにおかしいことがないかをチェックする

セッションベースドの形で、画面ごとに見ていく探索的テストも重宝しました。

リグレッション、というより普通に新しいバグがいろいろ見つかっていたりしました(^-^;

 

テスターちゃんねる第5回「仕様通り動くかのチェックだけだとNG!?」後編をアップしました!

「仕様通り動くかのチェックだけでよくない?」「自動テストだけでよくない?」に対する作者なりの返答もしてます。

106. リグレッションテスト その④

f:id:m_training:20210524065624p:plain

106. リグレッションテスト その④

自動テスト

自動テストは、プログラムやツールを使って、決められた内容にそって行うテストの総称です。

例えば、プログラムと一緒に「テストするプログラム」を書いて、自分たちの書いたプログラムが思った通りに動くかテストするunit testがあります。

他にもAPIというデータ処理をして返してくれる窓口にデータを送って、返ってきたデータが正しいか確認するAPIテストなんかもあります。

あとは、作ったwebやアプリに対して、自動的にボタンクリックなどをするようなツールを使ってテストするE2E(エンドツーエンド / いーつーいー)自動テストもあります。

 

テスト業界いる人が「自動テスト」と話した場合はE2E自動テストを指すことが多いです。

開発の人が「自動テスト」と話した場合は、プルリクエスト(自分が書いたプログラムをみんなのプログラムとくっつけてください!というリクエストを投げたりします)したときに自動的に実行されるunit testを指したりしています。

 

リグレッションテストで自動テストが向いている場所

続きを読む

youtube投稿をしてみました

ある晴れた休日。

散歩をしていた時になんとなく思ったのです。

「そうだ。youtube動画を撮ってみよう!」

その日のうちに撮影してyoutubeへポン!

 

ほんと上記のような思い付きとノリと勢いだったのですが、投稿しましたら好評でしたので3回ほど撮ってみました。

イメージとしては会社に入ったばかりの新人さん用といったところです。

気が向いたら撮っていくつもりです。

そして……マンガも描き進めます~!!

 

youtu.be

 

youtu.be

 

youtu.be

 

再生リスト

テスターちゃんねる - YouTube

 

105. リグレッションテスト その③

f:id:m_training:20210418173227p:plain

105. リグレッションテスト その③

 影響があるところ

マンガで描いた通り、影響がある部分がどこかはとっっっても難しい問題。

JSTQBでは「影響度分析」という言葉で出ています。

影響度分析…変更が影響するすべての成果物を識別すること。変更を達成するために必要なリソースの見積りを含む。

変更が影響するすべての成果物を識別……とサクッと書いてくれてますが、そんなにサクッとはいかないのが現実です(^-^;

メソッド(プログラムだよ)を直したら、そのメソッドを呼び出しているところを探したり。

データベースのテーブル(表みたいなものだよ)をいじったなら、そのテーブルを使ってるところを探しまわったり。

APIをいじったら速度低下してないか計測したり。

バッチのSQL文を変えたらその影響で速度低下して、そのバッチがつきぬけて(時間オーバー)後続処理に影響ないんだっけって探ったり。

環境の変数をいじったら同じ環境にいるシステムでその変数使ってるところ探したり。

ガッツリやろうとすると時間がいくらあっても足りないところでもあります。

 

次のお話からは、こんなやり方をしてるところもあるよ、といったお話をしていくつもりです。

 

紐づけ

テストケースに、そのテストケースが何のテストベース(テストを考える元となる資料だよ)のどこから出したもの、と紐づけておくとよかったりします。

その元の資料にある場所に変更があったとき、どのテストケースの部分に影響がおよびそうかわかりやすくなったり、仕様変更時にどのテストケースを修正したらいいかわかりやすくなったりします。

テストの言葉だと「トレーサビリティの確立をする」なんて難しい言葉で言ったりします。

何を根拠としたものかたどれるようにしておく、ってことですね。

 

(ちなみに作者はweb系/ゲーム系にずーっと身を置いてますが、本を読み知識としては知っているものの、しっかり書かれている現物には出会ったことがなかったり)

 

104. リグレッションテスト その②

f:id:m_training:20210405063230p:plain

104. リグレッションテストその②

リグレッションテスト

変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般のことをリグレッションテストと言います。

特定の手法を指している言葉ではなくて、そういう目的のテスト全般をリグレッションテストというよーといったかんじです。

昔は「回帰テスト」と呼ぶところが多かったけれど、今のJSTQBシラバスでは「リグレッションテスト」になっています。

他にも会社によって呼び方はそれぞれ。

かたくなに呼び方にこだわらず、会社でちゃんと伝わる言い方をしましょう。

言葉は正しく伝わってこそのものです。

 

バグ修正などを行うと中に手が加わるわけで、やっぱり中身はちょっとだけ変わります。

その「ちょっと変わる」によって、その機能からの出力がちょっと変わることもあります。

その機能だけ見ると上手く動くようにはなっているのですが、関係する機能が実は「その出力だと受け付けられない><」とか、受け付けられるように他の機能も修正してたけど直し忘れた箇所がある…なんてなってしまっていて、動かなくなってしまうことがあるわけです。

これは直接関わっている機能(プログラムの中で、その直したプログラムを呼び出しているところ)だけではなく、データなど共通して使っているモノ、システムが歯車のように連動して動いているところでも発生したりします。

マンガで描いたように、新機能から入れたデータが既存システムだと問題ある形だったり。

あと、システムの環境の設定をいじったら他のシステムだと動かなくなってしまったとか。

こう考えると「最終的には全確認では!?」とか「どうやって見ていけばいいんだ!」みたいになるかと思いますが、その辺は次回あたりで描こうと思います。

 

システムの規模が大きくなれば大きくなるほど、発生するリスクは高くなりますので、リグレッションテストは重要になってきます。

 

null (ヌル)

データが空、何もない状態を「null」といいます。

テストする人は、登録フォームなどで何も入力しない項目を作って登録をしてみたりするとバグを見つけられたりします。

開発している側は「空で来ることを想定してなかった!」みたいな思い込みがあったりするわけですね。

 

似たようなところで、割り算が発生しそうな部分に0(ゼロ)を入れてあげるのもいいです。

0で割り算が発生するとエラーになります。

(理由はネットで調べてください。0だと割る数が定まらないよね、とか、1を0.1で割ったら10、0.01で割ったら100、0.001で割ったら1000……割る数を0に限りなく近くしていくと無限大になるよね、とかいろんなことが書いてますw)

 

デグレ

デグレの説明は第102回で行っています。

testerchan.hatenadiary.com

 

 

 

103. リグレッションテスト その①

f:id:m_training:20210131172127p:plain

103. リグレッションテスト その①

次回から説明を行っていくので、今回は控えめに。

リグレッションテストは、システムの一部を修正したときに、その影響で今までちゃんと動いていたところが壊れてないよね?を確認するテストの総称です。

一部の何か特別な方法、というわけではないのです。

次回から、リグレッションテストのやり方や、範囲はどうするかなどの話を書いていこうと思っています~!

 

 

クリスマススペシャル『YWTでふりかえり』

f:id:m_training:20201223204328p:plain

f:id:m_training:20201223204352p:plain

f:id:m_training:20201223204410p:plain

クリスマススペシャル『YWTでふりかえり』

  • クリスマススペシャル『YWTでふりかえり』
    • YWTのやり方
      • やったこと
      • わかったこと
      • つぎやること
    • 作者もやってるYWT
    • AdventCalendar2020の答え

 

さて、今回のクリスマススペシャルのお話はYWTの話です。

テストの話じゃないじゃん!というツッコミがあるかと思いますが、描きたいことに走らせてもらいました!

 

***


作者はここ最近、りんちゃんと同じように毎日の仕事のふりかえりをしています。
そこで使っているふりかえり方法が「YWT」です。

マンガで描いた通り、かなりシンプルで使いやすい方法です。
自分一人だけのふりかえりでも使いやすく、日記のような経験のふりかえりにはもってこいです。
ワークショップでも、例えば最後に参加者にYWTシートを渡して、個人に学びのふりかえりをやってもらうのもよい方法です。
(つぎやること ->業務で活かすこと、なんてしてもよいかもですね)

 

YWTのやり方

やったこと

まず何より大切なのは、最初に「やったこと」を思い出すことです。
「そういえばこんなことした!」
と、自分の経験をもう一度引き出してきて反芻することが重要です。
意外と記憶の彼方にいってしまったりするのです(^-^;

りんちゃんのような日記のときや1年の個人のふりかえりをしよう!なんてときは

「あったこと」

も記載するとよいです。

やったことと起こったことの両面をふりかえることができます。

続きを読む

読者への挑戦状 #テストアドカレ

ソフトウェアテストAdventCalendar2020の21日目への道は暗号解読により開かれん……。

(特にソフトウェアテストは関係ないです!)

1週間くらいしたら、普通に公開します~!

 

***

 

 

以下が暗号文じす。

 

 

gyr@a].\qeq/rraywtxj]m,eitj\1-1-

 

 

 

f:id:m_training:20201220202130p:plain