ソフトウェアのテスト について考えたい ということを伝えたい スライド

https://xtech.nikkei.com/atcl/nxt/news/18/08224/

https://xtech.nikkei.com/atcl/nxt/news/18/08224/

https://xtech.nikkei.com/atcl/nxt/news/18/08224/ 同社は作業を行ったベンダー 名を明らかにしていないが、 「作業者の人的ミスによるも の」と説明している。

https://japan.zdnet.com/article/35138018/

https://japan.zdnet.com/article/35138018/

Googleのエンジニアリング担当バイスプレジ デントBenjamin Treynor Sloss氏はブロ グ記事を公開し、同日に発生した障害の根本 的な原因は、特定のリージョンの小規模な サーバーグループに適用するはずだった設定 の変更が、誤っていくつかの隣接するリージョ ンの多数のサーバーにも適用されてしまった ことだったと説明した。 https://japan.zdnet.com/article/35138018/

「全体としては、YouTubeは1時間で視聴 が2.5％減少し、Google Cloud Storageサービスではトラフィック量が 30％減少した」とSloss氏は述べている。 https://japan.zdnet.com/article/35138018/

Michimune Kono @Microsoft RSGT2018

10 「クラウドというのは、大きな、 いろんなサービスの集合体ですから、 たとえば自分のところが動いていても、 ほかのサービスがダウンしているということは 当たり前に起きます。 ネットワークが切れたり、OSがおかしくなったり、 毎日どこかが壊れているんです。」 Regional Scrum Gathering Tokyo 2018 基調講演より

11 「ある時点で何かがちゃんと動いてても、 次の週にはその前提が変わっている。 完璧というのが世の中に存在しないんです。 その中でどうやってシステムを動かし続けるか。 答えないんですけど、 その答えない中で考えるのがそのすごく楽しい。 たぶんご理解いただけると思うんですけど。」 Regional Scrum Gathering Tokyo 2018 基調講演より

12 「そういうなかで、安心して どんどん新しいことを試したり、 テレメトリ新しいのをデプロイしたりするには、 やっぱり、背骨がしっかりしないとだめでして、 そのおっきな一つが、CIがちゃんと回っている、 チェックインのモニタリングがちゃんとが回っている、 というのは絶対必要だなと思います。」 Regional Scrum Gathering Tokyo 2018 基調講演より

20年前のことですが、この会話を昨日のことの ように覚えています。私の同僚の一人である マーシェルは、机の上にある厚さ1インチの紙の 山を指差していました。 "それは、私たちがテストしているソフトウェア パッケージの機能のほんの一部を網羅したテス トケースです。"いくらテストを書いても、いくら ケースを実行しても、スクリプトから外れたとき には、いつも最も深刻なバグが見つかるのです。 https://pragprog.com/titles/ehxta/

この会話から20年間、私はこの パターンが何度も繰り返されてい るのを目の当たりにしてきました。 組織がソフトウェアを野放しにす ると、その驚きはさらに悪化しま す。 https://pragprog.com/titles/ehxta/

悔しいですが、否定できないのは、すべて の条件をカバーするために事前にテスト を計画することができないということです。 データ、構成、相互作用、シーケンス、タイ ミングにはあまりにも多くのバリエーショ ンがあります。すべての可能性をカバーす る包括的なテストのセットを作成しようと すると、テストを書くのにすべての時間を 費やしてしまい、テストを実行するために 残された時間がなくなってしまいます。 https://pragprog.com/titles/ehxta/

新しい技術を調べたり コード書いたりするのは、 だんだん楽しくなってくるけど、 テストは好きになれない。

多くのチームは、チームの 一員としてたった1 人のテ スター、またはさらに悪いこ とに、複数のデリバリーチー ムをサポートするテスターと して、もがいています。 https://leanpub.com/agiletesting-condensed-japanese-edition

新しい機能を考えるの はとても楽しい。 ただし、自分でテストし なくていいなら。

他人に作らせて チェックしなくていいなら もっと楽しい。

誰も歩いたことがないような 道を、あなたの大切なお客様 に歩かせるのですか？

ユーザーが使う前に 自分たちのソフトウェアを 自分たちで探索しよう。

必要なのは、包括的なテストケースの完 璧なセットではありません。その代わりに、 2つの核心的な質問に答えるテスト戦略 が必要です。 1.ソフトウェアは、想定されている条件の もとで意図した通りに動作するか？ 2.他にリスクはないか？ https://pragprog.com/titles/ehxta/

CHECKING (チェック) 最初の質問には、サポートされている構 成や条件の下で実装が意図した通りに動 作するかどうかをチェックするために、事 前に設計したテストで答えることができま す。 https://pragprog.com/titles/ehxta/

EXPLORING (探索) 探索的なテストでは、ネットがカバーして いない領域を偵察します。前回の実験の 結果を次の実験に反映させるために、小 さな実験を次々と設計し、実行していきま す。 潜在的なリスクを発見すると、より深く調 査します。あなたの観察力と分析力を使っ て、その場で調査を適応させることができ ます。 https://pragprog.com/titles/ehxta/

しかし、2つの質問はテストの2つの側面 を表しています：ソフトウェアが期待され たものを満たしているかどうかをチェック することと、リスクを探ることです。チェック も探索も、それだけでは十分ではありませ ん。 https://pragprog.com/titles/ehxta/

探索的テスト (Exploratory Testing)

探索的テストのステップ 1.テスト設計 2.実施 3.学習 4.ステアリング https://pragprog.com/titles/ehxta/

1.テスト設計 …これらの書籍では、境界値分析、決定表、 因果関係グラフなどのテクニックに加えて、状 態図、シーケンス図、フローチャートなどの設 計モデルからテストを導き出す方法が取り上 げられています。 これらのテスト設計のテクニックはすべて、探 求する上で今でも関連性があります。テスト 設計に精通していればいるほど、その場で良 い実験を設計できるようになります。 https://pragprog.com/titles/ehxta/

2. 実施 探索型テストでは、テストを思いついたらすぐ に実行します。これは、探索的テストをスクリ プト化されたテストと区別する重要な属性の 一つです。この実行の即時性が、探索型テス トを他のテストアプローチと区別しています。 テストの実行を開始する前に、事前にすべて のテストを設計することはありません。すぐに 実行を開始します。これは非常に重要です。 https://pragprog.com/titles/ehxta/

3. 学習 探索していくうちに、ソフトウェアがどのように 動作するかを発見することができます。あな たは、そのクセや特殊性について学びます。 バグの巣が潜んでいるかもしれない場所の 微妙な手がかりを探しながら、注意深く観察 します。観察は非常に重要です：観察が上手 であればあるほど、より多くのことを学ぶこと ができます。 https://pragprog.com/titles/ehxta/

4.ステアリング 実験を実行するたびに、ソフトウェアがどのよ うに動作するかについて少しずつ理解を深め ることができます。ソフトウェアがうまく処理で きない条件の種類に気付き、その知識を使っ てさらに頑張ります。これまでに学んだことを もとに好奇心を働かせ、次に発見すべき最も 興味深い情報を提案します。発見するために 最も重要な情報に注目しながらステアリング を握ることは、探検家のコアスキルの一つで す。 https://pragprog.com/titles/ehxta/

タイムボックスセッションでの作業 探索は完全にオープンエンドの努力である可 能性があります。あなたの努力を構造化し、 整理するためのいくつかのメカニズムがなけ れば、ソフトウェアを介して無目的に蛇行して 時間や日を過ごすことができ、… ジョン・バッハとジェームズ・バッハは、セッ ションベースのテスト管理(SBTM)のプラク ティスを思いつきました[3]。タイムボックス化 された一連のセッションとして構造化します。 https://pragprog.com/titles/ehxta/

各セッションでは、何を探究し、どのような情 報を見つけたかを知るために、メモを取ります。 しかし、メモはあなたが使用するためのもの です。ステークホルダーへのレビューの際に 参照しますが、従来のテストケースやテストレ ポートのようなものではありません。あなたの メモは、他の人にはほとんど役に立たないで しょう。テストのアイデア、質問、リスク、サプラ イズ、もっと調査したい領域、バグなどについ てメモを作成することがあります。 https://pragprog.com/titles/ehxta/

欠陥許容度ゼロ (Zero Defect Tolerance)

欠陥許容度ゼロ (Zero Defect Tolerance) 多くのチームが欠陥許容度ゼロ(Zero Defect Tolerance) を実践しています。こ こでのゼロは、既知の欠陥がイテレーション やストーリーの完成から逃れることがないと いう意味です。

欠陥許容度ゼロ (Zero Defect Tolerance) これを実現するためには、発見された欠陥を すぐに修正できるように、チームはテスト活 動から迅速なフィードバックを得なければな りません。

欠陥許容度ゼロ (Zero Defect Tolerance) 発見されたら、プログラマーは1 つ以上の実 行可能なテストを書き、テストに合格するよう にコードを修正し、必要に応じて探索的テス トを行います。 チームは問題が修正されたことを把握したら、 それを忘れることができます。

https://www.youtube.com/watch?v=D7v1D9bDAMk

https://www.youtube.com/watch?v=D7v1D9bDAMk

「“個”を極めるのも強さ。 新しい戦い方を探すのも強さ。 だからこそ今、多彩な攻撃や 守備が生まれている。 “強さ”とは 実に多彩」

実はテストとバグ修正こ そが一番大事な作業だ ということに気づいてく れたなら、たぶん、この 研修は意味があったの だと思います。

第一位: 月の輪 https://www.youtube.com/watch?v=ycfEo598B5c 第二位: 極限スイッチ https://www.youtube.com/watch?v=W6Mvefr1_iM 第三位: コンセプトの戦い https://www.youtube.com/watch?v=D7v1D9bDAMk 第四位: 幻覚ヒーロー https://www.youtube.com/watch?v=cYy-HCV2X7o 第五位: 元・根性なしの戦い https://www.youtube.com/watch?v=s5zKWbkHWUk 第六位: 脱 "孤独の王様" https://www.youtube.com/watch?v=rQp1aAz3foY 第七位: 嫌な男 https://www.youtube.com/watch?v=Z5Z4qM06M2Y 第八位: 歯車 https://www.youtube.com/watch?v=Lxx7nCabKrQ 第九位: VS傘 https://www.youtube.com/watch?v=5zK7G8cmgHs 第十位: 及川徹は天才ではない https://www.youtube.com/watch?v=G-m6hXTHyvw ハイキュー!! ベストエピソード 一覧