ひよこから若鶏になったエンジニアが驚いたことランキング堂々の第一位『テストが楽しい！』

この記事は、LITALICO Engineers Advent Calendar 2022 2つめ 12/1 公開の記事です

概要

この記事は、キャリア極浅のエンジニアが手動のテストを楽しんでいることをつづった随筆です。

この記事でわかること

新卒入社2年以内のエンジニアがテスト工程に関係して体験した以下の事項をお気持ちベースでまとめています。

• テストの楽しさ
• テストが開発工程におよぼすメリット
• テスト工程を進めるにあたって今やっていること

この記事でわからないこと

テストの自動化や設計理論などの技術的専門性の高い範囲には踏み込んでいません。
（これから学びを深めていきたい！）

ことの始まり

わたしが所属しているチームでは現在デスクトップアプリケーションの開発をメインで行っており、

このプロダクトのリリース前はテスト工程期間を数ヶ月単位で確保して集中的に行っております。

テスト工程では毎回検証事項が非常に多くなるのですが、
このことの要因として以下の3つの事情が挙げられます。

• 種々の事情で頻繁なリリースは難しいため、リリース間隔はWebサービスに比べて長い（最低でも数ヶ月は間が空く）
  • = ある程度まとめて改修を入れなければならない
• 新規事業のローンチしたてのプロダクト
  • = ユーザー・関係者からのフィードバックを元に大きな機能追加・仕様変更がある
• ユーザーはこのデスクトップアプリケーションで専用のファイルを作成して業務を行う
  • = アップデートの際は、異なるバージョン間で作成されたファイル同士の整合性をとる処理が必要

初回リリース時は、膨大な作業量が必要なテスト工程の大半を外部のテスト会社に委託していましたが、
2回目のリリースを経て、そして現在は3回目のリリースに向けて、
段々と社内で実行可能な範囲を広げる必要がありました。

それはつまり、エンジニアも実装だけではなくテストに本腰を入れて臨む必要が出てきたということでした。

正直なところ、わたしがエンジニアになる前は

『テストって、
　設計時は抜け漏れなく考えないといけないし、
　実施時は決まったことを堅実に淡々と行う作業だし、
　どっちも自分には向いていないよ… 😢』

と感じていました…。

ですが！

いざテストに主体的に関わってみると、その過程で

『💕テストって実は...自分が めちゃくちゃ楽しめる 工程なのでは？💕』

と感じることがたくさんあったのです。

ここからはわたしのこの体験を紹介したいと思います。

テストに関わって体験したこと

同じテスト設計書を元にテスト実施していても、見つかる不具合が人によって異なる時がよくある

シナリオテスト・リグレッションテストだけでなく、
より厳密に手順が定められている機能テストでもこういうことがありました。

さらに、実施者によっては手順を微妙に外して試してみたりする場合もありました。

当時の起票を見てみると、実施者は『ん？』と不自然さを感じたときに、そこでスルーせずにあれこれいろいろな操作を行って不具合の再現を試みたようでした。

勘の鋭さと緻密な検証は、その方がいつも開発時に発揮している長所そのものだったなぁとしみじみと思い出され、

良い開発をできる人が良いテストも実施できたりすることを実感する機会になりました。

自分がシナリオテスト（リグレッションテスト）を実施したとき、『この操作をすると不具合が発生しそう…』→『うわーやっぱり！』という展開がよくあった

機能テストで見つけられなかった不具合をここで見つけてしまうときもままあります。

要因としては、エンジニアとして実装・コードレビューをしている時間が長かったからか、
なんとなく怪しそうな箇所のイメージがつくというのが大きそうです。

実施者によって不具合を検出できるかどうか変わるというのは、当初テスト設計としては良くないイメージしかなかったのですが、
これは実施者によって検証に向いている箇所が異なるということなので、
逆にとらえると適材適所の配置によって検証の効果を高められる可能性があるとも言えます。

テストはテスト工程以外にもメリットをもたらす

開発のクオリティも上がる

自分の中でテストに関わる前後を比較したとき、開発工程でも以下の変化が見られました。

• 要件定義、仕様検討フェーズ
  • あらゆるパターンを検討しなければならないという気持ちになるので、 全体の整合性を考える癖がつく
    • 例：（デスクトップアプリなので）前のアプリのバージョンにこの情報は入っていないので、どのように対応するべきか？
    • 例：画面Aで要素IがXXという状態の時、画面Bでも要素IIをXXという状態にする必要があるが、その場合画面Bの表示が崩れてしまいそう…
  • 検証が困難に感じる場合、 仕様をもっとシンプルにできる可能性があると気づくことができる
    • 例：条件AのときはXXという状態に変更する、条件BのときはYYという状態に変更する、条件CのときはZZという状態に変更する、条件AかつBのときはXYという状態にする、…以下略
    • →検証するパターン多すぎるなあ…
    • →これってユーザーもプロダクトの挙動をイメージしづらくて使いにくいのでは
    • →本当に必要な状態をXXとYYとZZに絞って、条件を整理してみよう。
    • →十分要件を満たせるし、挙動がイメージしやすくなった！けんしょうぱたーんも減ったのでテストの設計・実施も楽になるね。
• 設計・実装準備のフェーズ
  • 影響範囲のイメージがわきやすいので、 見積りしやすくなる
  • 実装とセットで、テストにどれくらい手間がかかりそうかも予想するくせがつく
• 実装中
  • 影響がありそうなメソッド・コンポーネントを 探しやすくなる
  • 単体テストで担保しておくべき範囲が 明確になり、書きやすい

パッと自覚的に思いつくだけでもこれくらいありました。

テスト工程で不具合を洗い出すだけでなく、そもそも不具合の少ない開発を行うことができそうです。
テストって本当に素敵な体験ですね✨

今やってみているテスト工程の進め方

テストのメリットと無限の可能性に衝撃を受けたわたしは、次のリリースに向けたテスト工程の推進をする役割に立候補しました。

その結果、実は今この瞬間もヒイヒイ言いながら試行錯誤しているのですが、
現時点ですでに手応えを感じている事項もあるので、以下に紹介してみます。

誰がテストを実施するのかによって書き方を変える

今回のリリースに向けたテストでは、テスト工程自体の専門性が高い人員の確保が難しかったため、以下に留意してテスト設計を行っています。

• テスト工程の知見がほぼなくても実施可能な状態であること
• テスト実施者は大きく分けて以下の2つに大別されるので、それぞれの強みを活かせるようにテストケースの書き方を変える
  • プロダクトの事前知識が少ない人
  • プロダクトのことをよく知っている人

プロダクトの事前知識が少ない人

• 該当者
  • 対象のアプリケーションを触ったことがない人
  • 開発やカスタマーサポート以外の職種のメンバー
• 良いところ
  • アプリケーションへの先入観がない ので、純粋に『期待値（仕様）に対する実際の動作』を判定・記録してもらいやすい
    • ↔先入観があると柔軟に期待値を読み替えてしまうこともできるので、開発グループ内での認識の相違を検出しにくくなる
• 留意点
  • 曖昧な説明だとテスト実施を行うことができない/やっていてつらくなる
• 対策
  • アプリケーションの操作方法を具体的・詳細な手順に落とし込んだ『手順書』を用意する
    • ダウンロード・インストール手順から開始
    • アプリケーションのボタン押下やフォーム入力といった一つ一つの動作を1行ずつ分けて厳密に記載
  • テスト実施だけでなく、連絡方法やツールなどあらゆる情報を資料化してサポートする

プロダクトのことをよく知っている人

• 該当者 = 開発グループに所属しているメンバー
  • PdM
  • デザイナー
  • エンジニア
• 良いところ
  • アプリケーションの要件や仕様の詳細部分など、 『めざすプロダクトになっているか』という抽象的な観点で検証することができる
    • ↔プロダクトの背景知識が少ないと、明らかに期待値と異なる結果以外は検出しにくい
• 留意点
  • 開発グループ内でも認識が異なるような箇所を洗い出すことができるように、自由度高く検証できる状態にしなければならない
• 対策
  • 条件指定を最低限まで絞ってシナリオテストに近い粒度でまとめた『観点書』を用意する
    • 例：pdf出力の観点書の場合
      • 指定すること
        • データパターン（機能テストより少ない）
        • レイアウト・余白などの確認してほしい観点
      • 指定しないこと
        • 具体的に入力するデータ
        • 入力・出力にいたるまでの具体的な操作手順

共通用語を統一する

開発工程でも必要なこととは思いますが…
同じ要素を異なる呼び方で指したり、異なる要素を似たような言葉で表したりしても、
開発工程では阿吽の呼吸・柔軟なコミュニケーションでなんとかなってるのでそのままにしておりました…。

とはいえこれを放置するのは、『検証』が目的であるテスト工程ではつらさの元になります。

特に今回はプロダクトの事前知識が少ない方でもスムーズにテスト実施いただけるように準備しなくてはならないので、
徹底的に用語を統一して、すべての手順書・観点書に添付するようにしました。

これにより、設計者側も手順書・観点書作成時の書きぶりで悩むポイントを減らすことができました。

業務フローもセットで整備する

テスト工程での作業量が本当に多いので、エンジニアチームだけでは人員が足りず、
開発グループのPdMやデザイナー、事業部の他グループの方にもご協力いただいてなんとか実施しています。

そのため、暗黙知ありきで進めていた テスト工程に関わる業務を整理して、明文化 しました。

• テスト結果の記録
• バグ起票
• バグ修正のフロー・各担当者の手順

ここはまだまだ整理しただけの状態なので、改善の余地が大いにありです…。

尽きない悩み

本当にまだまだやれることがたくさんある状態です。

十分に検証事項を網羅できているのかという不安

膨大な検証事項を設定してクリアしたとしても、残念ながらユーザーが利用したときに不具合が発生してしまうこともあります。

これは、検証事項の設定自体に漏れがあったために生じています。

不具合がユーザーの手元で初めて見つかる確率を限りなく低くするためには、
ユーザーがプロダクトを 実際に利用している場面への解像度 をまだまだ高めていく必要があります。

テストの大枠だけでも早い段階で設計したい

要件・仕様が固まってきた段階でテストの大枠を設計してしまいたいです。

いや、むしろテストの大枠を設計しながら要件定義・仕様検討を進めることができれば、
テスト工程で検討漏れが見つかるという悲劇を減らすことができるのではないでしょうか。

めちゃくちゃやってみたいな。

第三者視点で品質評価してくれる存在は貴重

良いテストをしたいので日々必死で試行錯誤しているのですが、わたしの立場上、どうしても死角になってしまう部分もあります。

プロダクトに心血を注いで熱い気持ちで開発している以上、
『そもそも要件や仕様がユーザーにとって本当に適切なものだったのか』
を客観的に評価する機会は、ユーザーのフィードバックを得られる時期まで訪れません。

実装や他の箇所の仕様に引っ張られて、ずれた期待値を設定してしまうこともあるでしょう。

こうしたときに、もし第三者視点でプロダクトの品質を評価してくれる存在に協力していただくことができれば、心強いこと限りないです。

最後に

いかがでしたか？
テストは楽しいし得るものが大きいし、人生を豊かにしそうですね。
みなさんも、テストを楽しんでいきましょう！

▶▶▶明日はうちのチームの本当に素晴らしい¹頼れる新卒1年目の @taka-fujita さんの記事です😆

1. 今回の記事をテストの記事にするか @taka-fujita さんの良いところを分析した記事にするかギリギリまで悩んだくらいの本当に素晴らしい存在です ↩