JaSST nano vol.24 私達の思考停止

JaSST nano vol.24 warai 関西ソフトウェアテスト勉強会 x JaSST Kansai テス太郎 WARAI 夏の陣2023 ~ pre-JaSST Kansai 2023 振り返り~私達の"思考停止" 発表者: HOLLY (@engineer_holly)

warai 関西ソフトウェアテスト勉強会 WARAIについて WARAI(笑い)は「関西ソフトウェアテスト勉強会」の通称で、 関西在住のメンバーが中心で実施しているソフトウェアテスト/QAの勉強会 第1回開催は2012年。現在は年2回(夏と冬)の定期+不定期のペースで開催している miro

QA/テストプロセスにおける"思考停止"問題 【テーマの趣旨】 本テーマの『思考停止』とは チームやプロセスが成熟する中でいつの間にか深く考えずに行うようになったタスクや、 思い込み・固定観念、柔軟な思考の欠如など。 QA/テスト活動において、上記の"思考停止"に該当する事例を共有し、 自分自身の思考停止に気付こうという振り返りワークセッション。 ※思考停止は自分自身で気付くのが難しい 【流れ】 Step.1 思考停止LT悩み/思いの共有 ・・・JaSST関西実行委員による問題提起 Step.2 ブレスト&ディスカッション Step.3 ディスカッションが落ち着き、問題提起者が腹落ちした段階で次テーマへ miro

テーマ1 シフトレフトは正義? 「コスパよく不具合を減らすならシフトレフト指向が一番」と思ってたが、 最近そうではないのでは...と思い始めている。 [Before] シフトレフトをこう思っていた 少ない工数を無駄遣いはできないし、仕様バグも結構あるし、 要件や仕様のレビュー強化した方がコスパがいいはずだ [After] シフトレフトへの考えの変化 ・リソース・スケジュール事情でシフトレフトできないことも多い ・工数掛かってもシフトレフトがいい場合もありそう ・「シフトレフトやりすぎ問題」もあるかもしれない ・「小さく軽く」のアジャイル開発の良さが失われることもあるのでは? miro

テーマ1 シフトレフトは正義? シフトレフトへの期待 よくカンファレンスに参加すると 「シフトレフトが良いんだー!」と 聞くので、良いものなんだと思っ ちゃいがち 流行りの思想を導入 すると問題が解決 されると思っている シフトレフトがどうかよりも正 義か否かの2択が危険な気がす る シフトレフトの解釈はそれぞれ。シ フトレフトのやり方を決めつける のが「悪」 組織の成熟度によって、導入のタイミ ングを誤ると、印象が悪くなってしま う。ただ入れたらいいでやると思考停 止 そもそもシフトレフトって何? シフトレフトって、 どの程度のことで をいうんだろう? シフトレフトできることと、そう でないことがありそう。ある程度 開発が進んできて初めてわかるこ とや判明する不具合みたいなのが ありそうな。 ソフトウェア開発の技術的な制約 もあると思います。業務が難しい 場合、技術的に難しい場合、など 背景によって最適かどうかはいろ いろありそう プロトタイピングなど ではあまりいらないと いうのはたしかにそう ディスカッションを広げてみる miro

Breakdown:シフトレフトをアプローチとプロセスに分け、アンチパターン、疑問などを書き出してみる アプローチ(主にレビュー) 属人化/個人スキル依存 レビューのスキル によってレフトにシ フトされない 暗黙知が見逃 されがち レビュー視点書いて ると、そこしか見え なくなる レビューの目的・役割 レビューのレベルの相違。 大枠のレベルの共有と方針をレビュー したいのに、細かく項目を確認する形で レビューをされるとか。 並走で行うレビューと、ゲートとして 行うレビューは違う。 レビューのレベル 、ウェイトは柔軟 であるべき シフトレフトの弊害 レビュー通過(するため のドキュメント作成)がボ トルネックになる 目的さえ達成できればいいの に、細かいところまで先に決 めちゃった仕様のせいで実装 に時間がかかってしまう レビュー通ることが 目的になってしまう プロセス:計画(戦略) 計画に組み込む難しさ QAがいないところでプ WBSを書きすぎ問題 ロジェクト計画が決 先のことまで考えすぎ! まってしまう 細かく書きすぎ! 計画は変わる。変わる 計画の更新が 原因を明らかにしない 滞る まま変わりすぎるのも 問題 どこまでシフトレフトするか 品質戦略は経営戦略に QAがビジネスゴ 基づくはずなのに、QA ールを意識してい マネージャーが経営戦 ない 略に参加しない ゴールと評価の難しさ どこまでを見据えれば 何でも定量で評価し 良いのか難しい ようとする miro

テーマ2 テスト自動化は難しい? [背景] テスト自動化について漠然と、「することで保守コストが見合わない」という共通認識 を持っており、具体化できずにいた 一度開発マネジャーに「自動化したい」と提案したが、 「目的がない手段ありきの提案はどうかと思う」と回答されてそれっきり進展なし ※本テーマは悩み相談的なディスカッションになった miro

テーマ2 テスト自動化は難しい? 自動化推進を阻むもの 1. 保守を誰がするか 2. 画面の変更が毎回のようにあり再利用できない (テストデータがすぐ使えなくなる) 3. ハードウェアを操作するテストが多い 意識の違い ・経営層:やるべき ・マネジメント層:躊躇 ・現場:提案 検討不足 2.は自動化すべき でないかもしれな い そもそも「何を自 動化するのか」の 検討不足 自動化といっても色々ある 「大きな自動化」のイメー ジが強いがミニマムから初 めても自動化 プレッシャー 新しい技術に対する不安感 成功しないといけないプレ ッシャー パイロットプ ロジェクトが ないのか ではないか コストメリットの出しにくさ コストメリットの説明の難 しさ ※コストで語るべき ではないと思っている そもそも繰り返し 実施するテストに なってないと、自 動化メリットが出 しにくい 最初の導入コスト がかかるから、不 安を乗り越えづら い 自動化のイメージ 自動化のイメージ= 難しい、が定着して いる? スキルとリソース問題 スキルの問題 でリソース確 保の難易度が 上昇する 自動化のメリットの理解不足 自動化のメリットをあらためて考えたい ・実行者層では、ルーチンワークなテスト に対し、ストレスが緩和される ・メリットは層によって視点が異なる (実行者のストレスの緩和は経営層には響 かない?) 銀の弾丸でないネタを あたかも銀の弾丸である ように説明する必要が あって、限界がある エンジニアが学ぶための時 間を得る=将来への投資 明日の作業を前倒しでする ため、ではない miro

思考停止のワークショップを終えて 経験が長くなるとついつい、途中まで聞いて 「あーこれはね...XXXで...」と言いたくなるが、 それこそが凝り固まった思考停止状態だと気付かされた。 書籍に載っているような一般的な見解を述べたくなるが、 実際の背景には複雑な事情があって、 そこを聞く癖を付けないと ただの「話を聞かないコンサル」になってしまう。 気付きが多く勉強になりました! miro