# タイトルコール テスティングジャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を探索するコンセプトに、 エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストのコツや品相性の奥深さ、ソーシティビューを考えていることをお話しします。 # 『Taking Testing Seriously』16章で印象に残ったこと こんにちは、サミーです。 今日もワクワクしてますか? 今週はすごく気温が一気に下がりましたよね。 川水と東京にいて寒いって思ったんですけど、日曜日は熊本海底ですね。 空港出たら寒いってなりましたね。 すっかり秋というか、一瞬で秋が過ぎていきそうだなって思っております。 ということで、今日もTaking Testing Seriouslyよりお話をしていきます。 今日は16章ですね。 この16章の部分から第4部が始まっていきます。 文脈と文化ということなんですけれど、 16章は郵便局ホライゾンスキャンダルの教訓というタイトルになっております。 この章はシステムの品質に関わるスキャンダルについて詳細に書かれているんですけど、 とても共感をする内容が多かったなと思います。 詳細にこの会社と、不実も出てくるんですけど、 イギリスの郵便局で使っていたホライゾンという会計システムですね。 この会計システムの品質があまりにも悪くて裁判沙汰になったといいますか、 品質が悪いシステムが社会に与える影響みたいなところかな、が書いてありましたね。 私もだんだん途中読んでいて辛くなってきちゃって、というぐらいひどい状況でしたね。 今回紹介したいのがいくつだろう、3つぐらいすごく共感できたところがあるので紹介していきたいと思います。 まず1つ目がこの16章の最初に書かれている内容なんですけれど、 経営人が自社のビジネスを支えるゾフトウェアの詳細に興味を持つことは滅多にありません。 彼らはただそれが動くことを望んでいます。 動くと仮定したいのです。 これは理解できることであり妥当な場合もあるでしょう。 という書き出しから始まっているんですけど、 まあこれがめっちゃわかると思いましたね。 興味を持つことがありませんというのは結構強い言葉だなと思いますけれども、 分からない、詳しくないという方、経営人が言っているわけなんですよね。 この16章で紹介されている事例というのは、 分からないが故に会計システムを使うことを強要したというような内容が書かれております。 2番目に分かると共感したポイントが、 テスターとしての私たちの仕事は悪い知らせを伝えることです。 もしプロジェクトの状況が妥当な基準で仕事を行うことを不可能にしているのであれば、 私たちはそれを言う義務があります。 これは困難で繊細なプロセスですというような感じで書いてあるんですけれど、 これもめっちゃ分かりますね。 意図的でなかろうが作っている人は、 自分のミスだったりうまくいっていないというのは、 本能的なのかな、隠す性質があるんですよ。 これは良い悪いじゃなくてそういうものだと私は思っています。 なのでプロジェクトの例えば進捗が遅れているとか、 昨日の事例で言えば品質が悪すぎる、プロセスが悪すぎるということであれば、 悪いですというこの悪い知らせを関係者に伝えるということは非常に大事です。 で、それって悪いですよねっていうのはものすごく難しいですよね。 勇気もいるし、伝え方も大事だし、でも言わなきゃいけないしということなので、 ソフトスキルも必要かもしれないですね。 で、どこか別の箇所にも書いてあった気がするんですけれど、 たとえ自分が何もできないとしても言わないといけないみたいな。 それはもう義務というか、言わないといけないというようなことも書いてあって、 そうなんだよね、みたいな。 私の個人的な考え方としては、プロジェクトとしての成功というか、 目指している方向性というのは、 必要十分な品質で機能を出すとか、ユーザーの問題、課題を解決するとかなんですよね。 なのでそのゴールに対して今の品質、やり方、不安の出ている状況がやばいのであれば、 それはやばいと言わなきゃいけないんですよね。 救援だろうが、テスターだろうが、開発者だろうが、経営人だろうが、 実現したい方向性ことっていうのは一緒のはずなんですよね。 なのでその目標、目的に対して今の品質って十分ですか、十分じゃないですよね。 じゃあどうしましょうか、みたいな感じで、 ネクストアクションを考えていくみたいなことは、私は常々大事にしているなというのをこの書を読んでいて思い出しました。 昔の話だと、あとある開発者の方は、ちょっと目を離すとすぐズルをしようというか、 テストを書くのを手を抜いたりとか、ユニットテストを書かないとかっていう風に言うんで、 ちゃんとじーっと見て、ちゃんとやるんですよ、これやってます?やりました?みたいな感じですね。 確認をするみたいなのも昔ありましたね。 あとは逆に自分の失敗した事例だと、分かっての開発者というかリード、チームのリード、プロジェクトのリードをしていた方に 大丈夫ですかって聞いたら、大丈夫ですって言ったんですけど、 私はそれを鵜呑みにしてしまった結果、新規プロダクトのリリースを1ヶ月くらいやったかな。 かつテストが間に合わないというので、営業の人も巻き込んで総動員でテスト実行するみたいなことになった案件が昔ありまして。 本人がどう考えていたか分からないですけど、蓋を開けてみたら絶対大丈夫じゃないじゃんっていうスケジュール感だったんですよね。 なので、その人が言うことを鵜呑みにしちゃいけないんだなっていうのを改めてその時に実感しましたし、 誰が言ったからではなくて、その状況事実をしっかり見て、データとかで判断をして、 っていうのをやっていかないといけないんだなってその時も学びましたね。 そして話戻ってきましょう。最後かな、分かると思ったところは、 テスターが決して形式的な文書を超えて、システムが何をすべきか、何をするのか、 そしてシステムに影響を与えるすべての要素や変数について考えることが重要です。 テスターが効果的にテストしようとするなら、データが考えなければならないシステムは、 使用書によって表されるシステムよりも大きく、より複雑な存在なのですというのも分かるとめっちゃ共感をしたポイントです。 私の言葉で話をすると、深さと広さという表現をするかなと思います。 今回何か機能追加をするというふうになったとき、何をするのか、それをどう実装するのかっていうので、 開発者はどちらかというと深く考える傾向があると思っていますし、それで良いと思っているんですね。 だからこそ、QAとかテスターとかは広いところを見る。 今回ここの画面にこの実装を入れるんだったら、こっちにも入れなくていいのかなとか、 あるいはロジックのところで、今回この辺を修正するんだったら、 この別の画面のここに影響ないですかね、こっちの別の軌道に影響ないですかね、みたいな感じで、 広く考えるシステムを捉えることが大事だなというふうに思っていたりもするので、 ここの部分ですね。 使用書によって表されるシステムよりも大きくより複雑な存在なんですというのは、本当にその通りだなというふうに思いました。 本編以上です。 # #680のコメント返し🥰 コメント開始のコーナーです。今回は680話目、再放送QA事項の道を再び選んだ訳のコメントを開始します。 コメントはコウヘイさんから頂いております。毎日ありがとうございます。 こんにちは。私も経営企画を終えて営業に来たので、ちょっとセレンディビティ、違った環境にいた経験が生きると聞いてありますよね。 ということで、ありがとうございます。 そうなんですよね。私も最初QA、当時QAって名前はほとんど日本で呼ばれていなかったですけど、QAエンジニアにしちゃって、 管理部門で経営企画とか経営情報とか、情報集中だったりとか、内部統制調査だったりとか、 というところを経て、またQAエンジニアに戻ってきたという感じなんですけれど、 その経営企画とか管理部門にいた時のやったこと、経験とか、すごく今も生きてるなって思っております。ありがとうございます。 以上、コメント開始でした。 # 今日のほっこり話 今日の誇り話です。ハロウィンの話でもしましょうかね。 ハロウィンは何かやりますか? 私はですね、昔からハロウィンだけあまり何をするという カルチャーがなくてですね。 イギリスに住んでた時も記憶とか写真とかもハロウィンないんだよね。 というのもありまして、 ハロウィンは全く何もしません。 ハロウィンといえばトリックはトリートですけど、私はいつもですね、 家でトリックばかりをされているという感じですね。 今日はね、さっき ファブリーズかけられたんですよね。ちょっとさすがにイラッとしました。 口に入りそうだったんで、あとスマホにもプシューってなったんで、ちょっとガチでイラッとした瞬間でした。 はい、以上今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございます。 明日の放送はプレミアム放送となります。 いやー10月もあっという間でしたね。 10月最後の土曜日となりますので、10月の振り返りを行っていきます。 今回の放送が役に立った、今日も聞きに来たような人で ハートマーク、いいねいただけますととっても励みになります。 ぜひぜひコメントもお待ちしております。 それではまた明日お会いしましょう。 ハッピーハロウィーン!