@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Nagoya.Testing in Tokyo -テストを強いられている人達の話- に参加した

ソフトウェアのテストに関心があるので、Nagoya.Testing in Tokyo -テストを強いられている人達の話- - connpassという勉強会に参加した。

テストというよりもアジャイル開発、とくにスクラムと、チームのマネジメント・コーチングの話で、とても参考になる内容だったものの、自分が求めていたものとは少し違っていた。求めているもののほうが間違っているのかもしれない、という気づきがあった。

特に印象に残った部分

  • バグの根源には何かしら「無理」がある。無理からくるバグをテストで取り除こう、という考え方が間違い。無理をやめよう。
  • いかに普段からテストして、テストを減らすかを常に考える。
  • 残業をしない。
  • ソフトウェア工学の知見を活かす。先人に学ぶ。
  • チームメンバーに、わかるまで800回くらい、同じことを表現を変えて言い続ける。伝え続ける(人間とはそういうもの)
  • いかにして、アイデアを「自分が考えだした!」と思わせるか。インセプション。
  • 基本を大事に。基本ができてないのにいきなり我流スクラムとか、うまくいくわけない。うまくいかない理由が、基本を外してるせいなのか、他に解決すべき真の問題があるのか、切り分けるためにも、まず基本に忠実にやる。失敗しているなら、まず基本と違うところを基本に戻す。
  • できるようになるまで、被害が少ない範囲内で、7回くらい失敗させる。失敗とは、物事が計画通りにできなかったこと(ミスに限らない)。イテレーションの間隔を短くして、何度もPDCAサイクルを回せるようにすれば、より多く、小さな失敗から学べる。
  • 計画と予測が粗いと、そもそも本人が何に失敗しているのか気づけない。何かがうまくいかないから計画からズレるわけで、まず計画からズレているということを認識させる。ズレる原因が何か、を考えるのはそれから。
  • 形式知にすることにこだわらない。積極的に暗黙知にする。形式知にしたところで、活かすための訓練の方法論がない。チーム開発の体験を通じて、暗黙知を共有する。
  • 開発と別に独立したQAのチームを作るのは絶対にナシ。お互いの「結果」が相反するので、結果を出すためにお互いが敵視し合う関係になってしまうから。QAのコーチを雇って、テストはあくまで開発者自身がやるが、どのようにテストすればよいかのコンサルティングを受けられるようにするのはアリ。
  • ユーザーが強いられてる体験があるなら、自分たちも同じことを手でやって体験して、「プロダクトデザイン変えたほうがよくね?」とユーザーのつらみを感じがほうがよい。 GUI とか自動化しづらい部分は無理せず手で触ってテストすべき。

バグ年間一件 kyon_mm

名古屋 株式会社オンザロード テスト無くしたいエンジニア スクラム、SCMハンズオンセミナー

一番多かったのは、二ヶ月に一回もリリースしてない

基盤チーム 4人 フレームワークとライブラリの受託開発、毎月リリース

二年間で2件 メンバーは一年くらいでローテーション

Scrum Test Metris / Regional Scrum Gathering Tokyo 2016 Agile Japan 2016 テスト期間 PDF

バグの根源は無理からきている(何かに無理がある) 無理からくるバグをテストで取り除くという行為が無駄 無理するのをやめよう いかに普段からテストして、テストを減らすか。が重要コンセプト

2014年まで 年間バグ10~20くらい リリース年3,4回、バグったら直してリリース 残業も多かった

品質が10倍あがった => バグが1/10に減った

バグを分析 リリースが難しい要件をチームが作る、という要因 残業を乗り越えられる体力とパワーがあったがゆえに。

チームの分析 解散して情報がたまらない(ローテーションの悪の面 開発とテストがチーム内で微妙に分かれている 責任範囲を狭くしたがる

理想像を描く 残業しない ソフトウェア工学の知見を活かす

チームを変える情熱、理論を構築 みんなで変えていく、という気持ちをあげていく メンバーと何度も話す。伝える。聞く。違う表現で。

どう進めるのか、戦略

Product Owner がビジョンをはっきり持つ 世界最高になるために 必要なコストは際限なく払う(赤字でも 大量の失敗を許容する チームに自由と規律を与えて制限を外す

人は自由を与えても思ったほど好きにやれない 本人にオーナーシップを与えて責任に気づかせる

細かいことを入れると一人に年間400-800回くらい言ってる 子供が何か覚えるまでに言う必要回数が800回くらい、チームも子供も同じ(人間はそういうもの、言わなきゃ変わらない

いかに相手に「自分が考えだした!」と思わせるか(インセプション!

オーナーシップ、デリバリーの最後まで責任と自覚を持つ

それやらせてバグ出してリリースできなかったらどうするの? => 実際にリリースするのと社内でやるのと別にすればいい。スクラムのスプリントミーティングのデモとか。

基盤チーム、1週間スプリントから今は1日スプリント、20スプリントくらいやってリリース

基本をちゃんとやる、スクラムちゃんとやったことないのにスクラムっぽいことやってうまくいくわけない 失敗しているなら、まず基本と違うところを基本に戻す。それから改めてどこが悪いか考える。

学習効果を最大化する いろんなやり方で失敗、挑戦、体験する 一つの失敗体験で同じように人が学べるわけではない(体験から学習するやり方は人によって違う) 一つのバグについて7回くらい失敗すると、もう失敗しなくなる。お客さんに影響ないやつは何度でも失敗させる。 チームで失敗も褒めるも尊敬も自由に話せる雰囲気を作るのが大事 KPT で個人的な問題をずらずら書く。個人をけなす意味ではなく、事実を、それがフツー 毎日できるだけ、サンクスカードと懺悔カードを付箋に書いて、次の日に会ったとき渡す

わかめ@TypeScript味 ‏@vvakame 2m2 minutes agoView translation 避けたいバグがあるなら半年とか前からそのバグを踏むようにユーザーストーリーを組んで気づきを得させてやったりするらしい。先見性の塊かよ…。だいたい7回踏ませると綺麗になる。 #NagoyaTesting

積極的に暗黙知にする(SECIモデル) 形式知にする必要あるか?形式知化することは難しい 形式知にしたところで、活かすための訓練の方法論がない

優先順位、設計・テスト判断基準、レビュー方針、これらを形式知化して活用し続けるのは難しい => 暗黙知を体験通じて共有できるようにするほうがよい

スプリント毎にロールをくじ引きで決める(今日のプロダクトオーナー、が新人、で仕様聞かれる、みたいなレベル) スプリント期間が短ければ失敗の影響が小さくて済むし、全くできなければチームがヘルプするので、まわる

やればわかる部分はやればいい、それでもわからなければ形式知にすることを初めて考える

効果 Scrum を完全にマスター バグ減った チームの関係がよくなった 定時で帰るのが普通になった

そもそもバグを作らないプロジェクト、プロダクトにする。その覚悟を全員に持ってもらうようにするのがマネジメントの本領発揮


質問への回答: 実績ベースだと、独立したQAチームを作るのは無し。結果を出すためにクソな感じになるので、開発者がちゃんとテストするようにしたほうがよい。けどQAのコーチングは必要かもしれないので、外部のエキスパートを呼ぶのもアリと思う。QAという肩書の人が、テストについてなんでも聞いて教えてくれる人(ただしテストそのものは聞いた開発者自身がやる)、という社内のQAコーチという位置づけなら、ありかもね。

「スクラム現場ガイド」という本を読め。

敵対的な態度の開発者がいた場合は? => 大失敗してもらうのがいい。明らかなテストだけやる。「この人がテストすると便利」としておき、他はテストせず、相手に気づかせる。

開発とQAの関係 => 分かれてないので、開発者がユニットテストもシステムテストも全部書くし全部やるスタイルにした

ユーザーのことを考えない人にとっては、形式知化したテスト手順書をやるくらいしかできない。手順書を書いた時点でもうテストが終わっている(?書かれたことしかテストしないので、テストの価値が低いし、発見的じゃないからバグも見つからない、的なことか?)

難しいテストはどうする?UI,非同期、多システム連携 etc. もみあげの人 => UI は諦めた。システムテストは、ステージングとかで定期リリースして触ってもらう?フィードバックを短期でもらう 眼鏡の人 => 多システム連携は、SIerだとフットワーク軽くないので、インタフェース境界をバチッと決めて、政治力駆使してこっちはそれ通りに作る、自衛する方向。 グラサンの人 => ユーザーが強いられてる体験があるなら、自分たちも同じことを手でやって体験して、「プロダクトデザイン変えたほうがよくね?」とユーザーのつらみを感じがほうがよい。 GUI とか自動化しづらい部分は無理せず手で触ってテストすべき。

個人プロジェクト「コンパイル時にユニットテスト終わってないとか時代遅れ」というライブラリ作ってて論文書いてる

基盤チームとプロダクトチームがあって、品質をどっちが担保すべきか。プロダクト側でやってほしいが出来る人がいない。基盤のほうが能力は高いが二人しかいない。 眼鏡の人 => 両方やってる身として、基本、基盤側に寄せたほうがよい。プロダクト・プロジェクト側は玉石混交なので、質が一定で担保できない。そもそも線引せず、プロダクト・プロジェクト側で出来る人が直接基盤側にコミットできるようにするのがよい。品質保証は完全に基盤側に寄せないとダメ。(さっきの開発者がテストすべき、という話とちょっと矛盾しないか? => 品質って、テスト済んでる前提で、パフォーマンスとか、一歩先の話なのかも) アーキテクトというロールがある。社内どのプロジェクトにも好きに口出して良い。

大量の失敗を許容するためのマネジメントは、何をすればいいのか? 短いスプリントとかわかるけど、具体的にどう失敗させればいいんだっけ? => 見積もりを明らかにするためにチームで細かく見積もりを何度もする。どうせ失敗するのでリスクバッファを積みたいが、どれくらいバッファ積めばいいかわからない。どうすればいいか。全員のタスクを、最小30分の単位まで細分化する。 人によって所要時間のブレ幅がめっちゃ大きくて20倍とか生産性に差がある。それを認識できてないので見積もりが甘くなる。それを認識させるためのプロジェクトを組んで、成長させる。実験する。経過を細かく見る。いつ 1.02 倍から 1.5 倍とかになるのか。プランニングしてるから事前にだいたいわかるけど、二週間とかのスパンで定点観測していく。それができるような予算組みでやる。

そもそも失敗って何のこと? => 計画したことがうまくいかないこと(ミスとかだけを指すわけではない) 失敗学。差分を知る。課題に対する期待と現実の間に差があるのが失敗。でも失敗はネガティブではない。計画通りいかなかった、という学習機会。当てずっぽうの計画では意味がない(学習にならない) 計画と予測が粗いと、そもそも本人が何に失敗しているのか気づけない。何かがうまくいかないから計画からズレるわけで、まず計画からズレているということを認識させる。ズレる原因が何か、を考えるのはそれから。そのために計画 => ズレ => 修正、のサイクルを短期間で多く回させる。学習機会を大量に消化させる。

失敗した後のやること、お決まりの定番はあるか?

表面的ではなく、なぜバグったか?で分類している。「いまバグってもいいだろ」と思っているフシがあった、とかだと、昔見過ごしてたけど今検知できてるバグがある、君は昔と同じことをしている、という話をまずして、お金の話をする。基盤が作ってるライブラリとかはユーザーがたくさんいる。OSSではなく、お金払って、仕事で仕方なく使っている人たち。バグがあると、ユーザーの仕事が遅れて、どんどん膨らんで、全体でどのくらい損失が出るか(三次受けのプログラマがバグ踏んで、とか)君が手抜きした30分のテストでバグが出たせいで、2200万円分の時間が無駄になる。その30分の手抜きで君はそれを奪った。という一例。

「人と組織はなぜ変われないのか」免疫マップ、を書け。

QCストーリー 「トヨタの型」 マイク・ローザーのウェブサイトで PDF のテンプレがある メンターと一緒に課題に対してメトリクスをつける習慣をつける。小さいことでいい。毎日やる。