Subscribed unsubscribe Subscribe Subscribe

@kyanny's blog

Write down what I learnt. Opinions are my own.

マージナル・オペレーション(6)

Book

表紙は期待できそうな感じだったのに戦闘シーンが一切なくて退屈だった。おまけ漫画はよかった。

マージナル・オペレーション(6) (アフタヌーンコミックス)

マージナル・オペレーション(6) (アフタヌーンコミックス)

X-ミッション

Movie

アクションシーンは迫力があった。ストーリーは正統派B級という感じだった。

X-ミッション ブルーレイ&DVDセット(初回仕様/2枚組/デジタルコピー付) [Blu-ray]

X-ミッション ブルーレイ&DVDセット(初回仕様/2枚組/デジタルコピー付) [Blu-ray]

知識ゼロから学ぶソフトウェアテスト 【改訂版】

Book

ソフトウェアテストについて体系的に学んだことがないので、とりあえず何冊か本を読んで、概念や用語、手法などを知ろうと思い、最も易しそうで Amazon のレビューも良かったこの本から読んだ。文章が堅くなく、文量も少ないようで、一日で読めてしまった。内容は確かに易しくわかりやすい。そこに価値を認めるからには、詳細で網羅的・包括的とはいえない点は仕方ないというべきだろう。文体から受ける印象だけでいえば、筆者のキャラクターは好みではない。

テストをする上での考え方について、なるほどそう考えるのかと初めて知ったこともいくつかあり、読んでよかった。いくつか「それはどうかなぁ」と思うところもあった。どのみちこの本だけ読んで済ますわけにはいかなそうだし、そのつもりでもない。自動化テストについては懐疑的な立場で書かれていたが、自分の目下のゴールはそこなので、先人の見解を踏まえて「勘所はどこか?」を考えていきたい。

  • スモークテストは自分が思っていたよりも「軽く浅い」テストのことを指すようなので、所要時間も短くて済むだろうから Commit ごと・Pull Request ごとに CI で走らせてもビルドジョブを専有しすぎることはなさそう
  • 回帰テスト(リグレッションテスト)については自分のこれまでの理解で概ね間違っていなかったが、より正しい理解に近づいた・理解が深まったと思う
  • 「回帰テストは自動化に向かない」と書いてあったが、じゃあどうやって回帰テストするのさ?という点が疑問(人力で増え続ける回帰テストをやり続けるわけにはいかないだろう)だがちょっと解釈を変えて、「テスト担当者の作業として自動化はしない。回帰テストは開発者が単体テストとして自動化すべきである」と考えたらしっくりきた(というかすでに大概のケースでそうやっている)
  • 厄介なのは「相互に独立した複数のシステムをまたぐ連携機能のバグに対する回帰テスト」をどうするか?というところで、現状そういうものが(エッジケースだとしても)単一システムに対する自動化テストではカバーできないので人力テスト項目に追加せざるを得ず、テストの負担が増しているのだが、これは「もしその機能が再び壊れたとき、ソフトウェアが提供するサービスに致命的なダメージがあるのであれば、『出荷はおろかテストできる品質に達していない』とみなせるので、スモークテストに追加し開発者が新しいコードを書くたびに常時実行されるようにすべき(その自動化テストのメンテナンスコストはたとえ高くつこうが払わなければならない)」と考えてみたら割と納得感があるような気がする。

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

以下、ハイライト。

  • まず境界値テストをやってください。そこで境界値に関わるバグをすべてつぶしてください。そしてもし入力エリアが二つ以上あるようなダイアログとかあるようならディシジョンテーブルテストを行ってください。そして状態が遷移するようなソフトウェアの場合は状態遷移をやってください
  • もしそれでもバグが見つかる場合は二つの理由があります。 あなたの境界値テスト等のブラックボックステストのアプローチが間違っている(ちゃんと本書を理解していない
  • 筆者の経験上、初期に書かれたそれほど練られていないテストケースを繰り返すことにはあまり意味がありません
  • テストを実行しながら、どこかほかの部分に問題がないかを考え、そこをテストす
  • ソフトウェアで弱いところを見つけたら、そこに重点を置き、その部分を十分にテストす
  • テストケースを設計する際、パフォーマンスの要求定義に書かれた通りのテストケースを書いてはいけません。テストはバグを見つける作業だからです。ですから、要求定義通を逸脱するような(バグを発見するような)テストケースを設計しなければなりません
  • テスト責任者は明確な予算策定とコストに対する意識を持つべきです。なぜなら品質とコストは相関関係にあるからです
  • 48時間以内に重要度「高」のバグが発見されていないこ
  • もしそのバグが非常にみっともないものであっても、システム全体をクラッシュさせたり、明らかにセキュリティ上の問題がある場合を除いて修正は思い留まるべきでしょう。コードを修正する場合は、その時点で出荷を延期し、すべてのテストサイクルをもう一回繰り返すことをお勧めします
  • 最後の最後になってなんらかのコード修正を入れることは、それまで行ったテスト作業の努力を無にする危険があるのです
  • メトリックスというのは、単に数字だけを取り上げて判断するのではなく、その数字の性質をよく知ったうえで利用するべきなのです
  • バグメトリックスのもう一つの例は「バグの修正にどのくらい時間がかかるか」というものです
  • テストの自動化を成功させるには、自動化コードの保守コストを低く保つことが必要です。なぜなら、まずい自動化プログラムはメインテナンスコストがかさみ、自動化のコストメリットがなくなってしまうからです
  • 回帰テストは一見自動化に向くように思えますが、それは大きな間違いです
  • そんなバグが以前あったからといって、印刷をしながらほかのすべての機能も組み合わせたりしてテストすることは間違っています

700

これがはてなブログで700件目の記事らしい。そんだけ。

blog.kyanny.me

500件に到達したのが301日前だった。約10ヶ月で200件、月平均20件書いてるペース。600件目は記録し忘れたようだ。約5ヶ月前だったとすると、まぁ当時はそんなことに気づく余裕すら無かったので無理もない。このペースだと来年の秋には1000件に到達する計算。

無駄にイチローの安打記録と比べてみる。年間240件書くとして、いま36歳なので42歳までにあと6年ある。240*6=1440件、+700=2140。イチローはおそらく今シーズンでメジャー3000本安打に到達するので860件足りない。3.6年のビハインド。はてなダイアリー時代の905日をイチローの日本プロ野球時代の安打記録相当とみなすと1278-905=373。1.55年のビハインド。合計して5.15年のビハインド。イチローは50歳まで現役を続けるらしいので、同じペースを維持する差が広まりも縮まりもしないと仮定した場合、55歳までブログを書いていれば追いつける。このブログに書く内容は仕事で調べたことのメモと読んだり聞いたりしたことのメモと何かしら考えたことのメモなので、働いている間は書くネタは尽きないはずである。55歳まで働くことは十分ありえるので、なんとかなりそうである。

最近読んだもの

Reading

samurai20000.hatenablog.com

ハンドルネームの由来が気になるタイプなので、とても興味深く読んだ。あと、なんか自分のはてなIDと由来が似てるなと思った。

自分のはてなIDは id:a666666 だが、これは社会人二年目くらいの頃にはてなが注目されだしていて、「巷で人気の玄人好みなウェブログサービスなんて絶対真面目に使うものか」と厨二病むき出しでわざとテキトーなIDにしてやろうと aaaaaa で登録しようとしたところバリデーションエラーだったか取得済みだったかでとれなかったので a の後ろに 6 を六個並べたのである。由来もクソもないのである。「えーろくろく...」などと声に出して読んでられないので「刺身」のほうが普及してかえってよかったのである。