QA-Quality Assurance（品質保証）の仕事とは？品質保証エンジニアとは？オートメーションエンジニアとは違うの？
アジェンダ
またまたIT講師のお話です。 こういう記事を書く時は、ほとんどが生徒さん向けに、生徒さん用の記事だと考えて書いているので、脈絡がないのはご愛嬌。
プログラムを書くことがプログラマーの仕事ではない
教えていて、非常に感じるのがこれです。 恥ずかしながら、講師陣にもQAとしての経験がない方もいらっしゃいます。 そういう方にテストシナリオを書いて欲しいとお願いしても、恐らく開発者目線のレビューを踏襲したテストシナリオが出てくることでしょう。 開発畑が長いとエンジニアの目はどんどんユーザーサイドから離れていってしまいます。これは私も例外ではありません。
だからこそ、いったんエンジニアリングを離れて全体を俯瞰するか、運用チームと同じ席で自分が作ったシステムを業務として利用してみることが究極の要件定義だと私は考えています。1
プログラマーの仕事を考える
QAではなく、プログラマーです。 プログラマーの業務とは、システム開発だと言われています。 まずこれに対して思うところがあるかどうか、が一番最初の分岐点でしょうか。
エンジニアがコードを書いている時間をプログラミングと呼ぶのか、設計フェーズも含めてプログラミングと呼ぶのかは人によって異なります。 実際に設計書を書いて実装フェーズに入るプロジェクトは近年見ません。 もしかしたら基本設計もも詳細設計も形骸化してしまっているように思います。2
設計はプログラミングか？
実装時も設計時もアルゴリズムを考えます。ある程度なれると頭の中でサクッと実装する3なんて事をやってのけるようになります。 本当は良くないんですが、ちまちま書類を書くのは運用に即していないため無視される傾向にあります。 無視というよりは軽視？なんか違うな、ぶっちゃけ省略なんですが、あまり練り上げるような事はないです。 ましてや、アジャイル開発だと一つ一つのタスクを練ってしっかりやっていく、なんて事はやらないです。
設計は必要か？
そのシステムを誰が運用するのか、という点を考えます。 運用をするのは技術を知らない人で、保守をするのは業務を知らない人である場合、トラブルが起こると犯人探しが始まります。 開発チーム＝保守チームの場合、運用チームのリーダーからガン詰めされるので、自分の身を守るために設計書は絶対必要です。
逆に、運用者がシステム管理者レベルの人たちで固められているならそこまでやらなくても良いかも知れません。 が、新人が入ってきた場合に彼らでもメンテ出来るのか？という観点を持っておく必要があります。
新人でも読み溶けるものを作る
ここからようやく本題ですが、ここで言いたいのはTDD4の話ではないです。 運用サイドはシステムを破壊することを考えてテストシナリオを作っているか？ということです。
たとえば、メールアドレスとパスワードをシステムに登録するログインシステムを考えてみましょう。 IDとパスワードを入れて、正しい組み合わせなら登録する、というシンプルなものです。
さて、たったこれだけの機能ですが、あなたはいくつテストケースを作ることが出来るでしょうか？ 実務では多ければよいというわけではありませんが、一般的に多いほうが網羅性が増します。
- 【正常系】正しいIDと対応するパスワードを入力してログインボタンを押すとログイン後の画面に遷移すること
- IDとPWを入力しないでログインボタンを押すとログインに失敗すること
- 正しいIDを入力し、PWを入力しないでログインボタンを押すとログインに失敗すること
- 正しいIDと誤ったPWを入力してログインボタンを押すとログインに失敗すること
- 正しいIDと別のIDにログインできるPWを入力してログインボタンを押すとログインに失敗すること
- 存在しないIDを入力し、PWを入力しないでログインボタンを押すとログインに失敗すること
網羅的に実施するならこれぐらいは必要です。 言葉を濁しましたが、確認項目も不十分です。
「ログイン後の画面に遷移すること」とは具体的に何かをテストシートに含めなければなりません。 ログイン前の画面になく、ログイン後の画面に存在する項目を２つほど確認項目に入れると良いでしょう。 ただし、ログイン処理は正常に完了していても、後の画面で問題が発生している事も考えられますので、いずれにせよスクリーンキャプチャを撮っておく事は重要です。 できればサーバーインテグレーションに影響しない項目を上げておくと問題の切り分けができます。
実務で要求される要件
ログイン程度ならいいですが、決済処理はさらにえげつないです。 決済処理中にネットワークを落とした時に決済処理がされる／中断するという観点が必要です。 ハードウェアの不具合をソフトウェアで吸収するような設計を求められる事もあります。5
セキュリティ案件で品質評価・自動化の案件に携わっていた頃は、検出・動作ブロック・悪性の振る舞いがされていないことを確認するために異常系が正常な処理であることを証明する6ということも。 予測できる異常系は可能な限り網羅しますが、そうでないものはユーザーから上がってきて大きなインシデントになった事もあります。
もしかしたら、対応していく中でクラッキングの技術を習得する事になったかも知れません。
ちょっと宣伝
注釈
-
【いつ設計をしているのか】実装を進めながらヒアリングしている事が大半です。実装と設計を同時に行い、実装に設計を合わせるのです。なので、出来上がったものに対して設計書を書くような事も。 ↩
-
【脳内プログラミング】脳内コーディングとも。やべープロジェクトでよくやるアレ。設計書も脳内にあるため、完全に属人化してしまっている。コードが読める人か、本人でもないと設計を書き起こすことができない。 ↩
-
【TDD】Test-Driven-Development。テスト駆動開発。最初に期待するテストを書いて、開発をテストが通るように実装すること。IDEとかを使っていると知らず識らずのうちにビルドエラーを直したりしているのでレビュー時にバグコードが発生する可能性が激減する。 ↩
-
【ハードウェアエラーをソフトウェアで吸収する】たとえば、センシング中に幾つかデータが欠損している場合、再リクエストを飛ばすとかハードウェア側でその瞬間のデータをどこかに保持するとか、ソフトウェアと異なる観点を求められます。 ↩
-
【異常系が正常な処理】期待する動作を行った、なら設計次第でなんとかなりますが、意図しない動作をしていない事を保証するのは悪魔の証明です。 ↩
-
【究極と至高】美味しんぼ ↩