ある晴れた休日。
散歩をしていた時になんとなく思ったのです。
「そうだ。youtube動画を撮ってみよう!」
その日のうちに撮影してyoutubeへポン!
ほんと上記のような思い付きとノリと勢いだったのですが、投稿しましたら好評でしたので3回ほど撮ってみました。
イメージとしては会社に入ったばかりの新人さん用といったところです。
気が向いたら撮っていくつもりです。
そして……マンガも描き進めます~!!
再生リスト
マンガで描いた通り、影響がある部分がどこかはとっっっても難しい問題。
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年の個人のふりかえりをしよう!なんてときは
「あったこと」
も記載するとよいです。
やったことと起こったことの両面をふりかえることができます。
続きを読む
IT業界に入って1か月以内に聞くであろう言葉が「デグレった!」です(ぉぃ
デグレはマンガに描いた通り、何か実装したり、修正した後に今まで動いているところが壊れたり、修正したハズのバグが復活しているときに使われる言葉です。
ほとんどの場合は「デグレ」で使われますが、略さないと「デグレード」かと思います。
名詞の形で言うと「degradation」です。
デグレーションと書いている記事も多いですが、発音を聞くとデグレデーションといった感じ。
日本だとなぜかデグレですが、海外だとリグレッションと言います。
まぁ、なんとなくデグレードの方が悪くなってる感ありますからね!(何
日本国内だと間違いなく「デグレ」の方が齟齬なく伝わります。
この「どこかが壊れた」というデグレ(リグレッション)はとても厄介。
原因がわかると「あぁ、そういえばそこにも影響あったわ!!」となるんですけど、なかなか気づかないのですよね(汗)
それを確認する目的のテストが「リグレッションテスト」です。
何か一つやり方を指すのではなく、デグレを確認する目的のテスト全般をリグレッションテストと呼びます。
じゃあ、どんなことをすることが多いか並べておきますね。
続きを読むデバッグとテスト。
一緒でしょ?という人も多いのですが、実をいうとちょっと違います。
「テスト」はバグを見つける……もとい、システムに存在する欠陥によって起こる故障を発見することを目的としています。
「デバッグ」はバグのもとをつきとめて取り除く……もとい、故障のもととなる欠陥を見つけて、その欠陥の原因をつきとめて、修正するという一連の開発の活動です。
テストとデバッグは聞いていると何となくみんな言葉を使い分けている気がします。
雰囲気で使い分けている感じですが、こういう意味なんだよーと覚えておくと良さそうです。
みんな、バグという言葉を使いますが、テスト系の難しい本を読むときは実はバグという言葉はほとんど出てきません。
代わりに「エラー」「欠陥」「故障」という言葉が出てきます。
この辺も覚えておくと、テスト系の難し目の本も読みやすいかもしれません。
続きを読む
ついについに!!
テスターちゃんは100話を迎えました!!
こんなにも続けてこれたのは、応援してくださっている皆様、楽しみにしてくださっている皆様、共に歩んでくださっている皆様のおかげです。
3コマ目のりんちゃんのセリフは、きゅんちゃんだけでなく、テスターちゃんを見て学んでくださっている皆様にも向けたセリフです。
覚えることはまだまだたくさんあると思いますが、焦らず、マイペースで、楽しみながら進んでいきましょうね!
そのお手伝いができたのでしたら、作者としましては嬉しい限りなのでございます^^
テスターちゃん、次は同人誌7巻、そして書籍2巻に向けて進んでいきます~!
連載が2017年から、ということで3年ほどが経過しております。
その間にキャラの成長…もとい絵が少しずつ変わっていきました。
ここではそれを紹介です。
続きを読む