こう
- 「チームの
テストの 方針 (どこまで 自動で 試すか ) を、 どう 決めますか」 - 「網羅率 (カバレッジ) を 80% 以上に
する、という 決まりを どう 思いますか」 - 「たまに
落ちる 試しが あって、 みんなが 再実行で 通しています。 どうしますか」
面接官が
- 「全部に試しを書く」ではなく、
壊れた ときの 損で 厚さを 決めているか - マージを
止める 条件や 不安定な 試しの 扱いを、 チームの 決まりとして言えるか - 網羅率のような
数字を、 目標ではなく 手が かりとして扱えるか
短い答え
- 壊れた
ときの 損が 大きい所 (お金、 ログイン、 データを 消す処理など ) から 自動の 試しを 厚くし、 損が 小さい 所は 薄くします。 - 速い
小さな 試しを 多く 置き、 画面を 通して 動かす試しは、 申し込みや 支払いのような 大事な 流れだけに 絞ります。 - マージを
止める 条件と、 たまに 落ちる 不安定な 試しの 扱いを 決め、 網羅率は 目標ではなく、 試していない 所を 見つける 手が かりにします。
この
少し
厚さは
時間は
どこを
速い
- 小さな
試し (単体テスト) 関数や 部品 1 つを 試します。 速く、 落ちた 場所が すぐ 分かるので、 数を 多く置きます - つないだ試し (結合テスト) DB や
外の API と つないだときに 正しく 動くかを 試します。 境目の 所に 絞って置きます - 画面を
通す試し (E2E テスト) 利用者と 同じ道で 動かします。 遅く、 不安定に なりやすいので、 大事な 流れだけにします
不具合を
チームの
- マージを
止める条件自動の 試しが 全部通らないと マージしない。 例外を 作るなら、 だれが 決めるかも決めます - 不安定な試したまに
落ちる 試しを 再実行で 通す癖が つくと、 本当の 失敗も 見逃します。 見つけたら 外して 直す札を 立て、 担当と 期限を決めます - 網羅率
「80% 以上」を 目標に すると、 何も 確かめない 試しで 数字を 上げる 動きが 出ます。 数字は、 大事な所で 試していない 行を 見つける 手が かりに使います
試しに
話す例は、
よく
- 網羅率の
数字を 目標にする 何も 確かめない 試しで 数字だけが 上がります - 画面を
通す試しを 大量に書く 遅く、 不安定に なり、 みんなが 落ちても 気にしなくなります - 不安定な
試しを 再実行で 通し続ける 本当の 失敗まで 見逃すようになります
深掘りの問い
- 「試しを
書く 時間が 無い、と 言われたら」 不具合を 直すときに 1 つ足す決まりから 始め、 損の 大きい所だけ先に 厚く する、と答えます - 「手で
確かめる 試しは 要りますか」 見た 目や 使い心地のように 自動で 判定しにくい所は、 手で 確かめる 項目を 絞って 残す、と答えます - 「試しの
方針は、 だれが 決めますか」た たき台は リーダーが 出し、 チームで 話して 合意し、 守れているかを 定期的に 見直す、と答えます