アジャイルとテスト計画
ソフトウェアテストアドベントカレンダーの9日目です。
halspringです。宣伝ではないですが、独りアドベントカレンダーを書いていて正直キャパシティオーバー気味ですが頑張りますよ(｀･ω･´)ゞ
前日の記事はこちら。
今回はアジャイルにおけるテスト計画についてざっくり書きたいと思います。
アジャイルに依らない(関係のない)部分もありつつ、アジャイルならではの部分もありつつで読みにくいかもしれませんが、しばしお付き合い願います。
みんなだいすきJSTQB
JSTQBにアジャイルのシラバスがあるのはご存知でしょうか？
それが『Foundation Level Extension シラバス アジャイルテスト担当者』です。
シラバスはFoundation Levelの内容を理解していることを前提としているため、読んでいてアジャイル以外の文脈で詰まることが多ければ一度Foundation Levelのシラバスに目を通してみることをオススメします。
アジャイルとドキュメント
アジャイル開発において、
ドキュメントは軽視され、コードが優先されることがあります。
( もちろん本当は「軽視」していいわけではないですし、それはおそらくアジャイルではないですが。 )
より価値のあるものを優先することや、変更に対して柔軟でスピードを求めると、
テスト計画書を作るのは確かに手間も時間もかかりますし、後々の変更の量も膨大になってしまうかもしれません。
テスト計画書を更新する運用コストを考えると、ドキュメントとして残さない選択は自然かもしれません。
計画することと計画書に書くこと
テスト計画をすることと、テスト計画書に書くことはイコールではないと思っています。
また、決めたことと書くことの粒度も等倍である必要はないと思っています。
「こう書かないとテスト計画書じゃない」といったルールがあるわけではありません。
計画は自分達がよりよい方向に進むためにあるものなので、
自分達にとって必要だと思うものを必要なだけ決めて、必要なだけ残せば良いです。
ですので、はじめからガッツリと「テスト計画書かくぞ！」ではなく、メモ程度から始めるでも構わないと思っています。
ただ、はじめから何をすれば良いのか判断するのは難しいと思うので、ヒントといいますか参考程度に「こういうものがあるよ」を挙げていきます。
プロジェクトの概要/目的
当たり前すぎて意外と話し合わなかったり文書に残さなかったりすることがあります。
プロジェクトが進むに連れて、方向を見失ったりズレていることがありますが、事前に話し合っておけばスタート時のベクトルを揃えることができ、文書にしておけば後からズレに気がつくことができます。
テストレベル/テストタイプ
テストレベルを考えるとき、盲目的にV字モデルを前提としてしまいがちです。
単体テスト、結合テスト、システムテスト、受け入れテスト、これらはよくV字モデルとセットで説明されています。
それらが、自分達の開発プロセスに適している根拠はどこにもありません。
スタンダードな用語や定義、モデルにこだわることなく、自分達にあったものを考えていくべきだと考えています。
（もちろん、独自のものを用いるのであれば、スタンダードなものも知っておくべきだと思いますが。）
同様に、テストタイプも自分達で考えて定義すべきです。
「パフォーマンステスト」「性能テスト」「負荷テスト」「ストレステスト」
これらのテストタイプの意味や目的を無作為に集めた複数のプロジェクトメンバーにそれぞれ述べさせたとき、その答えが一致するのはおそらく天文学的確率です。
言葉の認識にズレが生じることで、テストの目的にもズレが生じ、そのズレは徐々に徐々に多くの影響を及ぼします。バタフライエフェクトのように。
用語を定義してメンバー間では認識が揃うようにしておくことが重要です。
自動テスト/回帰テスト
アジャイルでは回帰テストが非常に重要なファクターであり、またそれらは可能な限り早い段階で自動化されているべきだと思います。
小さいリリースがたくさん行われるため、スコープ外へ影響がないことを確かめる回帰テストを行う割合が自然と高くなります。
何度も実施されるテストは、工数やテストの再現性を考えると手動で行う割合を減らしたいものです。
なので、どのテストを自動化し、どこを手動で担保するのかを考えておきます。
もちろん、いきなり自動化が難しければ、最初は手動で徐々に自動化するで構わないです。アジャイルなので。
また、それらは基本的にどこまで確認すればよいのかの判断が難しいです。（ テスト全てにおいてそう言えますが。 ）
判断が難しいので、
ミッションクリティカルになるところを重点的に見るだとか、
自動テストではAPIの入口と出口をおさえてUI部分は探索的テスト(や目視)で確認だとか、
回帰テストの戦略が重要になります。
コミュニケーションのルール
こちらも案外忘れがちです。
知らないところで仕様が変わっていても困りますし、仕様が変更されたことを知らせる場所を決めておいたり、
緊急で重要な報告を誰に行えばいいのかなど、もしもに備えた情報もあると困りません。
また、新しくアサインされたメンバーが朝会や夕会の場所やルール、その他の定例やチャットで用いるルームやチャンネルなどを把握するのにも役立ちます。
バグの起票基準/ルール
バグ票を起票する際のルールについても大事です。
重要度(優先度)をいつ誰が決めるのか、その基準はなにか、といったプロジェクト進行上のルールもありますが、
他にも、自由にラベルを付けてしまうと表記揺れが生じて分析が大変になったり、上記のテストタイプ然り認識がズレてしまうこともありえます。
必要になってから考えるでも良いので、決まったことはその都度追記することが大事です。
おわりに
ここまでお読み頂きありがとうございました。
見当違いなことを書いていたら申し訳ありませんが、
それでもなにかを考えたり話し合ったり議論する材料にでもなれば幸いです。
引き続き、アドベントカレンダーをお楽しみください。
QAのお仕事って、具体的にどんなことをしているの？
独りアドベントカレンダーの7日目です。
遅れは気にせずとりあえず完走を目指します。
お題
QAのお仕事って、具体的にどんなことをしているの？
お題の提供ありがとうございます！
具体的にとのことなので、自分の組織に寄った話を書きたいと思います。
月曜日に出社してまずい空気を感じたら修正します。
QAのおしごと
我々のQAチームは独立しています。
特定のプロダクトやチームに限らず、幅広く活動をしています。
だからといってチームの人数が多いわけではありません。
少人数で多くのチームやプロジェクトのサポートを中心に活動しています。
障害分析
横断的な活動をしているため、優先度を考えて活動をする必要があります。
そこで大事になるもののひとつが過去の障害情報になります。
原因の分析や対応についてなどを開発側が詳細をドキュメント化してくれており、
QAはQAで、再発しないようにQA側に出来ることを考えます。
全てのチーム、プロジェクトで何が起きているのかを把握することはできないため、
ここでは後手になりますが起きてしまった事象から、何をすべきか/何が出来るかを考えQAチームの施策として取り組みます。
また、探索的テストのチャーターとして使えるような情報があれば、全員が参照できる場所に小さくまとめて書き残します。
リスク分析
障害分析は後手の活動ですが、こちらは先手の活動になります。
各部署の企画や開発のカンバンやチケット、紐付く仕様書/設計書の状況を集めて回り、
- どんなプロジェクトが動いているのか
- どんなリスクを抱えているか
- プロジェクトが見落としているリスクがないか
- 他の施策との衝突が起きていないか
- QAがサポートに入るべきか
などを話し合います。
必要になればQA側がテスト仕様書のレビューを行ったり、探索的テストを行います。
テスト計画
プロジェクト側からの依頼があると、テスト計画を行うことがあります。
QAチームが能動的に動くこともありますし、受動的にサポートの依頼を受けることもあります。
プロジェクトの概要をヒアリングし、テスト計画を策定、その後はモニタリングとコントロールをするなどの支援を行います。
プロジェクトの進行中に問題があれば、テストのアプローチを提案します。
品質に問題があれば しっかりとリスクを伝え、どうすべきかの提案も行います。
自分達のQAチームはプロジェクトに対して決定権を持ちません。
プロジェクトがより良い方向に進むように全力でサポートをします。
チーム内開発
QAチーム内で独自にプロジェクトが動いています。
それは開発を行いやすくするための仕組み作りだったり、
ツールやシステムの開発だったり、
QAチームのスキルアップであったり開発チームの育成であってり啓蒙活動であったりします。
そのときそのときに必要なものをチームで考え、
組織としてどうあるべきか、どんなものが欲しいのか、どうなっていたいのか、
それらを考えてそれぞれがプロジェクトにアサインします。
おわりに
組織の在り方が特殊ではあるので、どの組織でもQAエンジニアがこういった業務をしているとは限りませんので、ご留意ください。
テスト以外にも様々な活動をしていることだけ知っていただければ幸いです。
おすすめのイベント（勉強会など）を教えて下さい
お題
おすすめのイベント（勉強会など）を教えて下さい
お題の提供ありがとうございます！
振り返ってみたところ、
- connpassから参加18件
- JaSST'19 Tokyo( 2日間 )
- Selenium Conf( 2日間 )
- SQiP( 3日間 )
- WACATE 夏( 2日間 )
- Online Test Conf
- 発表/運営側 3件? 4件?
- 技術書典7
イベントっぽいイベントはこれくらい参加していました。漏れているかもしれない...
平均すると月2回以上はなにかに参加している日なのですね。
テスト系のイベントに関してはこちらのブロッコリーさんの記事もご参考ください。
http://nihonbuson.hatenadiary.jp/entry/2018/12/03/235718
halspringのおすすめ
( 順不同 )
WACATE
とりあえずテストのことを学び始めた方は参加すればいいんじゃないのかなくらいのワークショップ形式の勉強会です。
ここでの若手は35歳以下を指していますが、36歳以上で初参加の方もいらっしゃいますし、年長者だからといって何かを強いられることもありませんし、煙たがられることももちろんありません。
1泊2日で外部のイベントに参加したことのない方にはハードルが高いかもしれませんが、中身は初めての人にもおすすめできます。
非常に親切丁寧で、実行委員の方々を中心に参加経験のある方がサポートしてくれる仕組みになっています。
業界が狭いので、既に繋がりのある人達の交流を見て不安に感じることもあるかもしれませんが、コミュニケーションが苦手でなければすぐに輪に入ってコミュニティの輪に入れるでしょう。
自分はコミュニケーションが苦手なので、参加者のtwitterから攻めました。
大丈夫です、馴染めます。
参考 : https://wacate.jp
JaSST
日本で最大級のソフトウェアテストに関するカンファレンスです。
規模こそ異なりますが、首都圏だけでなく地方でも開催されています。
内容も濃く、運営側にも参加側にも有識者が集う貴重なありがたい場です。
地方でJaSSTが開催される度に、twitterでテスト界隈の人をフォローしてると「なぜ申し込まなかったのか」と後悔します。
(東京では) テスト系のイベントに参加すると、どこかの実行委員の方が確実に1人は存在しています。
世間は狭いです。
参考 : http://www.jasst.jp/
Online Test Conf
先日日本向けに実施されたイベントです。
この記事がアドベントカレンダー通りの12/6に書かれていたら時系列的にここに書かれることはないイベントです。
土曜日に開催され、参加者も発表者も好きな場所から参加できます。オンラインですからね。
遅めの昼食を取り、こたつでぬくぬくしながら参加していました。
物理的に集まって開催されるイベントでは、
電車での移動がストレスだったり、
PCの電池残量を気にしなければいけなかったり、
机がなかったりでメモの取りにくいことがあったり、
椅子に座り続けておしりが痛いけど動くに動けなかったり、
喉乾いたけど調達するタイミングもなかったり、
飲み物を買う鋤があってもエレベーターで降りなきゃだったり、
周囲の人が気になってしまったり、
空調の暑い寒いがあったりと、
まぁまぁいろんな懸念や問題があるのですが、それらが一気に解決します。
快適でした。非常にリラックスしながら参加できました。
もっと増やしましょう、こういう形式のイベント。絶対これがいい。
参考 : https://www.onlinetestconf.com/
connpass各種
めちゃくちゃ省略していますが、connpassから参加申し込みができる各種イベントです。
色々とイベントがあって、どれに参加すればよいのかわからない気持ちはわかります。
一旦興味の出たもの全て、参加してみれば良いのではないでしょうか。
そのくらいの気持ちで良いと思います。
しっかりと吟味して選び抜いたイベントにしか参加してはいけないわけではありません。
また、参加のハードルに関して自分のレベルとイベントの内容を考慮する必要もありません。
例えば聴いてもわからないかもと尻込みしていてはギャップはうまりませんし、有識者に質問できるいい機会でもあるわけですから。
たくさん参加してみて、自分にあったものがわかってきたら選んで参加するようにすれば十分だと想います。
結局はそれに尽きます。
QAに関する今一番の関心事
独りアドベントカレンダー5日目です。
早くも限界を感じつつありますががんばります。
お題
QAに関して今一番の関心ごとは何？その理由は？
お題の提供ありがとうございます！
基本的に興味があちこちに移っているので、本当に「今」一番になります。
関心事
QAに関する関心事なのかはわかりませんが、今は言語やアーキテクチャなどの開発技術です。
サービス品質や開発効率、テストについて考えるとき、これらによってかなり中身が変わります。
例えば、使っているプログラミング言語が静的型付か言語か動的型付け言語なのか。
言語仕様として担保される機能があったりしますし、気にしなければいけないこともあります。それだけでもテストすべき観点が変わりますよ。
例えばphpでは0から始まる数字は8進数に解釈される可能性があります。
Cであればgetsを使おうものならバッファオーバーフローを気にしないといけません。
これらは言語だけに限りません。
Railsなどのフレームワークなら(意図的に避けなければ)CSRF対策の実装を担保してくれますし、
docker上で動いていれば環境由来の不具合も未然に防ぎやすくなります。
加えてk8sで管理されていればオートスケーリングもできますしデプロイ事情も変わってきます。
さらには、アプリケーションを支えるものだけでなく、
アプリケーションそのもののアーキテクチャ(設計)によってもテスト内容は変わります。
例としてクリーンアーキテクチャであれば、
レビューで思想に則っていることを担保すれば依存関係についてが明らかになり、影響範囲がわかりやすいです。
フロントエンドがパーツ単位、コンポーネント単位で管理されていれば、改修漏れのリスクを減らせます。
(もちろん、それに伴う別のリスクも生まれます。)
やっている内容にもよりますよね。
機械学習を用いるのなら、データの品質を気にしなければいけませんし、
一言で機械学習といっても教師あり学習なのか教師なし学習なのか強化学習なのか、
目的も画像認識なのか自然言語解析なのかLSTMのような回帰を扱うのかで事情が全然異なります。
つまり？
改めて何が言いたいかと言いますと、
ソフトウェアを取り巻く言語やアーキテクチャやインフラ技術など、開発に関する知識がなければ見えないものが出てきてしまいます。
もちろん、それらを知らずとも別の手段でリスクヘッジすることも可能です。
ただ、より効率的にテストをするために、視界を広げるために、
こうした技術のことを知っていて困ることはありません。
(セキュリティ界隈なんて特に顕著ですよね、多分)
ある知識を深めたいときも、
地面の同じ穴に棒を刺して深くするより、ぐりぐりと周囲までほじった方が深く掘りやすいです。
同じある特定の技術の話でも、別のことを学んでまた戻ってくると違う見え方をすると思います。
何周も何周もぐりぐりとほじって知識を深く深くしていく必要があるのかなと思っています。
もちろん、これは技術に限らず、
世間の流行だったり、法律の知識だったり、業界のルールだったり、人の思想だったり、市場のことだったり、人間関係だったり、趣味だったり、
あらゆるところにいつか役に立つ可能性のある知識は転がっています。
常に意識を高く持って、知識として蓄えようとは思っていませんが、
深い知識も大事ですが、興味を広げてあちこち走り回ることも大事なのかなと思っています。
(すぐ変わる興味への正当化も兼ねて)
仕事に対して感じたギャップ、社内外で感じるギャップ
孤独アドベントカレンダー4日目のhalspringです。
なんと今回は4日のうちに投稿しています。
ほとんどテクい記事を書いていないので「これでいいのかな感」がありますが、今回もそんな感じです。
お題
お仕事に対するギャップとかいかがです？
なる前、なった後で、良くも悪くも｢こんなことあるんか！しらんかった！｣ってあるので、自分の経験と対比しながら読みたいです。
お題の提供ありがとうございます！
仕事に就く前と後のギャップについて、
また弊社のQAエンジニアの役割が他社さんとは少し異なるので、そのあたりで感じるギャップについてもせっかくなので綴ってみます。
読んでくださっている方も自身の過去と比べて見てください。
まだピチピチ新卒2年目なので、「最近の若いもんがどんなことを考えているのか」の参考程度にはなるかもしれません。
第一話「学生halspring、就活す。」
学生halspringは情報系の学部生でした。
友人とゲームしたりTRPGしたり、TRPGで計算が面倒なのでキャラシートの管理と諸々の計算だとか装備品とかスキルが管理できるWebアプリをつくっているような意識高いのか低いのかわからない系でした。
halspringは自分のつくったものを人が使ってくれること、喜んでくれることが大好きでした。
なのでhalspringは、(身近な人を含む)より多くの人に使ってもらえるようなサービスを扱う会社に勤めたいと思いました。
また、halspringは「安定した大企業に勤めてほしい」「有名企業に〜」「年収が〜出世が〜」といった言葉が極端に嫌いで、
「ベンチャー気質で」「無名でも共感できる理念を持ってサービスを作ろうとしていて」「利益よりもユーザーのことを考えるような人がいそうな」企業を求めていました。
halspringはなにかをつくることが好きだったので、エンジニアを目指していました。
しかし、同じくらいバグを見つけることが好きでした。
大学の課題や、同期の研究用のプログラムを見てはぶっ壊れそうな入力を入れたり想定していなそうな操作をするのが好きでした。
（ 大学側が学生の進路把握に使っていたWebアプリに結構深刻なバグを見つけて直してもらったのは割と自慢 ）
そして調べているとQAエンジニア、クオリティ(品質)エンジニアといった募集を見つけました。
ユーザーが安心してソフトウェアを使えるようには開発側がしっかりしないと、と思っていたので非常に興味はありました。
興味はありましたが「それって開発に関する知識を豊富に持っていないと、妥当に評価したり検証できないのでは？」と思っていたため、「新卒からなるものではない」と思い将来的に転向を考えられるようになればいいなと思っていました。
故に、アプリケーションエンジニアの募集からWeb系の企業に就職することになります。
第二話「配属先の宣告」
入社に伴い、配属が告げられます。
halspringの同期には、文系出身でリバースエンジニアリングやアセンブリが好きでバイナリを酒の肴にするセキュリティ大好きな情報量の多い変態がおり、彼は新卒からセキュリティエンジニアとしての配属になっていました。
それを横目に見ながら、変態的なキャリアを歩むのだろうな、すごいなぁと思っていたらhalspringの配属が告げられます。
「QAグループ」
一瞬、何も思考できませんでした。
それもそのはず、今だから書きますがQAエンジニアが存在することを知らずに入社しています。
(もちろん、存在を知らないので希望も特に出していません。)
QAエンジニアをハイスキルな職種と感じていたhalspringはセキュリティの彼のような変態にされてしまうのでは、と興奮して恐怖していたことを覚えています。
今ではしっかりと変態にさせてもらえたので非常に感謝しています。
（変態性を見抜いて配属を決めてくださったスーパー人事やCTO、その他関係者の方には本当に感謝です。）
本題 : ギャップ
思い出話終わりです。
自分のような変態性を隠し持っている人が選考にいらっしゃったら引き出してあげてください。
過去のイメージ 対 自社 編
想像
- アーキテクチャや設計をレビューしたりする
- コード追ってバグ見つけたりデバッグしたりする
- ユーザーのこと考えて「ここ大丈夫なん？」とかする
- デザインとかもわかっていたほうがいい
- 統計とかわかっていたほうがいい
現実
- 設計は「見ろ」とは言われないけど勝手に見たりする
- コードを見ないことはないけど、そこまで見ない
- デバッグはしない ( そもそもテスト担当側のスコープではない )
- ユーザーのことも考えるけど開発者のことを考えることも多い
- ユーザビリティ評価は専門の部署が隣にあった
- メトリクス周りで統計とかも知っていたほうがいいだろうなとは思う
と、思っていたほどギャップはなかったです。
実務においては想像よりスコープは狭い印象です。（といっても奥が深いのですが。）
現在、主な業務として行っているテスト計画やリスク分析を考えるとむしろ思っていたよりクリエイティブです。
仕事をしていての気持ち的なところでは、
ビジネスビジネスした堅苦しさを感じることはあまりなく、自分達が誰かのために良いと思うことを各々行っているような感じでとても楽しいです。
つらいのは通勤だけですね。
他に感じたこととしては、
開発よりもテストの方がおもしろくなってしまったことや、
情報系出身であってもテストのことを学ぶ機会がほとんどなかったことです。
テストがこんなにも重要な役割を持っているのに、なぜこんなにも学ぶ機会がなかったのだろうかと思っています。
技術書にもオンラインの教材にも、軽く「大事だよ」程度に書いてあったり、
「テストコードの書き方はこうだよ」くらいの情報しかなく、そこには少々疑問が残っています。
また、これは最近感じていることですが、
QAに求められているのはテストの技術というより、思考の技術であるように思います。
なにを持ってテストが十分と判断するのか。
より効率的にテストするにはどうすればよいか。
どんなリスクが考えらるのか。
開発者はどんなところで誤り、バグを作り込むのだろうか。
この仕様で問題は起こらないか、世に出して良いプロダクトなのか。
いろいろなことを考えています。
そして、それらはテストについての勉強をしていても急にできるようにならないものだと思います。
勉強したこと、見聞きしたこと、知識や経験の抽象度を上げたり下げたり水平方向にシフトさせたりして、
現在手に入る情報、積み重なった過去の情報から様々なことを考えているような気がしてます。
（これをテストの技術と呼ぶのかもしれませんが...）
社内 対 社外 編
「これがQAエンジニアだ」とヒヨコのときに叩き込まれているので、正直 社外のQA事情とのズレを感じます。
ひとつ大きな違いでいうと、自分がテスト設計をほとんどしていないことです。
弊社では開発者が自分達でテスト設計も実行もしており、自分がするのはそのサポートやテスト計画が主です。
自分で社内用にテストツールを開発することもあるので、それに関してはもちろんテスト設計もしましたが、比率でいうと圧倒的に少ないです。
そのため、自分の考えていることが理想論に近い、アカデミック寄りな内容になってしまって現場に即していないのではないかと考えてしまうことがあります。
それについて良し悪しは一概に言えませんし、
会社ではそれでも頼ってもらえたり信頼してもらえているので、期待に応えられているのなら良いのかなと思ってしまう複雑な気持ちがあります。
また、少々 トゲのある内容にもなってしまって恐縮なのですが、
正直、開発側とテスト側の対立が起こることが理解できないでいます。
（twitterやブログのエントリー、思い出話が主な情報源なので、情報の偏りや誇張したものを認識しているかもしれません。）
「より良いプロダクトを作ろう」と集まっていてゴールは同じはずなのに、なぜ敵対してしまうのでしょうか。
そして、テックな方向の勉強会においても「質問」の形でそれらの「愚痴」が挙がることがあります。
なぜそれほどまでに業界にこの問題が蔓延っているのか、知らなくても良いことなのかもしれません。
ただ、温室育ちでガラスの向こうから業界の不幸を見ているだけなのはモヤモヤします。
そういった業界内のギャップを感じ、またその状態に対しても不満を抱えているので、
おこがましいですが、少しでも引き上げられるのであれば引き上げられるよう活動をしたいと思う動力源にもなっています。
仮にそれが理不尽から来るものであればその理不尽をなくして不幸になる人がいなくなれば良いなと思います。
おわり
後半、気持ちが昂りエモくなっていますし、
アドベントカレンダーに載せていい内容なのかわかりませんが、少しでも若手が感じている想いとして誰かに伝われば幸いです。
そして、改めて変態気質のエンジニア志望がいたら自分のように沼に引き込んであげてください。
テスコンチュートリアルを聴講したのでテストアーキテクチャを過去の経験から考えてみる
アドベントカレンダー3日目です。
1日遅れての進行はもうデフォです。
お題
テスト設計コンテストに参加して考えたこと、わかったこと、わからなかったことを書いて欲しいです
お題の提供ありがとうございます！
残念ながら、テスト設計コンテストに参加してその感想を書ける頃には既に年が明けて暖かくなってしまっています。
(参考 : テスト設計コンテスト)
ですので、先日行われたOPENクラスのチュートリアルで説明された、テストアーキテクチャについて少し書いてみます。
資料は上記リンクからでも下記のconnpassからも閲覧できます。
チュートリアルは地方にも中継されますので、興味のある方は来年になってしまいますが是非聴講してみてください。
本題の前に
「テストアーキテクチャ」 という概念については今回のチュートリアルでまともに聴いた程度ですので、誤った解釈、用語の使い方、偏った説明をする可能性が高いです。
本記事におけるテストアーキテクチャに関してはチュートリアルの資料の定義を自分なりに解釈したものになりますので、本家の資料も是非ご参考にしてください。
テストアイテムについて
テストアーキテクチャを考えるために、テストの対象となるシステムが必要になります。
今回は、自分が過去に業務で担当したプロジェクトを参考にアーキテクチャの図を描いてみます。
※ テスト計画書に自分が書いているような内容を図にするイメージなので、多少本来使用する用途や効果とズレが生じる可能性があります。
前提となるシステムは以下のようなものです。
- Webアプリケーション
- クライアントがデータを入稿する
- 一般ユーザーは入稿されたデータを検索・閲覧できる
- 入稿データは一覧ページと詳細ページが存在する
そして、今回のプロジェクトの要件は以下のようなものになります。
- 既存のものとは異なる新たな検索方法を追加する
- 検索するために入稿されたデータを加工する必要がある
- データの加工はバッチ処理で行われる
- 新規の一覧ページを作成する
- 既存の一覧ページ・詳細ページに新規の一覧ページへの導線を設置する
※ 流石に内容を細かくは載せられないため、簡略化とぼかしを入れています。
検討したテスト
テストレベル毎に、どのようなテストを検討したか書いていきます。
呼び方はこの記事のために独自に定義しましたので、後日直接この記事の話を振られても本人に伝わらない可能性がありますがご理解ください。
ユニットテスト
データ加工
クライアントから入稿されているデータを何段階かに分けて加工するため、それぞれの工程をコンポーネント単位でテストします。
回帰テスト(CI)
既存のデータフローに影響がないかマージする前にCIで確認します。
結合テスト
データフロー
データを加工する各コンポーネントを確認したため、それらを結合させデータを流して想定通りに加工されるかを確認します。
データは入稿時にバリデーションされていますが、異常値についてもハンドリングできるかテストします。
パフォーマンステスト
データの加工をバッチ処理で行うため、それらの処理にどれくらいの時間が掛かるのか、どれくらいのデータ量を捌けるか、どれくらいのマシンを用意する必要があるのか検証します。
システムテスト
機能テスト
新たな検索方法をブラウザから動かせるか、検索結果が正しいかをテストします。
また、表示についてもテストします。
(OS/ブラウザ間の互換性も見ますが、図を書いたときに失念して追加が面倒なので省略します。)
セキュリティテスト
新たなページの作成、POSTするデータの種類が増えるため、それらに脆弱性が含まれていないかテストします。
シナリオテスト
新たな検索手段を用いたシナリオや、既存の機能と絡めたシナリオを用意し、一連の操作を通しで行うテストをします。
探索的テスト
過去の障害や仕様/設計の複雑な箇所などを中心にチャーターを準備してテストを実施します。
受け入れテスト
回帰テスト(e2e)
e2eの自動回帰テストを実行し、プロジェクトのスコープ外で問題が起きていないかを確認します。
テストアーキテクチャ
これらをテストコンテナ(資料 p24あたりを参照)にまとめてみます。
また、今回はそれらをテストレベルで区分けし、実施順の観点でつなげてみます。
(きれいな図を作る精神力がなかったので、手書きですがご勘弁を)
それぞれのテストを開始するために、終了していなければいけないテストがひと目でわかるようになりました。
「まぁそうなるよね」 といった具合の図ではありますが、テキストで羅列しているよりはわかりやすいです。
そして、このプロジェクトは想定していたこのアーキテクチャ通りに進みませんでした。
データ周り、つまり結合テストまでテストが終了した時点で、その先の実装が遅れており、テスト仕様書の作成も間に合っていない状態にありました。
進め方を変えなければ普通に考えてプロジェクトは遅延しますので、アプローチの変更を行いました。
よって、アーキテクチャも組み替えます。
(くどいようですが、実際には図やコンテナを意識せずプロジェクトを進めていますので、合っているかも進めやすいのかもわかっていません。あしからず。)
アプローチを変更し、探索的テストを前倒ししました。
探索的テストのアプローチも変え、
「開発側がテスト仕様書を作成している間に、QA側で問題を可能な限り発見して手戻りを減らす」という方針にしました。
(※ 弊社では基本的に開発チームがテストを設計・実施しています。QAは計画やレビュー、探索的テストやその他諸々のサポートを行っています。)
探索的テストで早期に大きめなバグをあげ、細かい箇所は網羅的なスクリプトベースのテストでおさえます。
各機能でテストを進め、機能テストが終了した機能で可能なシナリオテストも進めます。
といった具合に、図にすることで進め方やアプローチの変更点がわかりやすくなりました。
実際は各テストの中にもっと小さいコンテナを入れたほうが良いのだと思います。
詳細は載せられないことと単純にそこまで記憶していないので、そこまで含めた使い勝手までは検証できませんが、少なくとも説明はしやくなるのだと思います。
そして、考えていることが伝わりやすくなるので、それに対する議論や指摘などもより活発に行えるのだろうなとも思います。
実際、上記の図を見て思うところがある方もいらっしゃるでしょう。
まとめ
テストアーキテクチャについて、
一人の脳内で完結させず、周りに共有し検討できる脳を増やすためのツールのようだなと思います。
また、ここでは大雑把なテストコンテナをテストレベルや実施順でしかわけていませんが、テストのアプローチに応じて柔軟に見せ方を変えることができるとより強力だと思いますので、この記事はあくまで書き方の参考にだけしてください。(こんなのでもいいんだな程度に)
そして改めて、こんな感じ( 書き方とか考え方とか見せ方とか )でよいのかどうか、書いている本人もよくわかっていません。
現時点では、テストするコンポーネントで区分けしたり、テストを実施する人で分けたり、目的でまとめたりするとおもしろそうだなと感じているくらいです。
理解を深めるために、色々な資料を読み、実際に手を動かし、アウトプットを残してみてください。
( できれば自分にそれらで得た知見を共有してくださると嬉しいです。 )
駆け出しQAだった自分にまずやっとけと思うもの
アドベントカレンダー2日目です。
きっとあれですね、ずっとこのまま1日ズレて進行しますね。
頂いたお題
駆け出しのQAだった頃の自分に向けて、まずやっとけ、と思うものは？
お題の提供ありがとうございます。
はい、まだ2年目のバリバリ駆け出し中のQAエンジニアですが、考えてみます。
早いうちに学んでおくべきこと
と、解釈した考えをまず。
英語
こういう記事で挙げられるものの筆頭ですが、やはり大事だなぁと常々思います。
日本語よりも英語の資料の方が母数が多いですし、カンファレンスでも本人の言葉(ニュアンス)で理解できることは大いなる強みだと思います。
ただ、QAエンジニアとして駆け出し始めてしまった直後のタイミングで学ぶべきではないと思います。
「できるだけ早いうちに」であれば英語ほど費用対効果の高いものはないと思います。(と言いつつ、未だに全然なのですが...)
何事でもそうですが、優先順位を考えると必然的にそう判断できると思います。
英語を読まなければ品質について全く学べない状況にある場合は別ですが、日本語でもそれらを学ぶために十分体系的な資料が存在しています。
日本語で存在する資料や情報をある程度得て、十分思考できる状態になったと感じ新たな刺激が欲しくなったら英語の資料を読み出すでも良いと思います。
日本語でピンと来ない内容を英語で読んでもピンと来ません。
母国語で思考できるようになってから学ぶくらいがちょうどいいのかなと思います。(なので勉強しますね...)
批判的思考
いわゆるクリティカルシンキングというやつです。
昨日の記事に書いていた悲観的な思考とは異なります。
本当にざっくりかんたんに説明すると、「ものごとを鵜呑みにしない」ということです。
○○さんがそう言っていた、○○という本にそう書いてあった、○○というブログで読んだ。
それらの情報がすべて正しいとは限りません。
また、その文脈の上で成り立つ正しさであり、どんな場面にも成り立つものではないことが往々としてあります。
もちろん、このブログもそうです。
あくまで一個人が何の根拠も出さずに綴っているだけの記事でしかありません。
述べている内容が妥当なのか、論理的に矛盾していないか、何を前提にしているのかなど、様々なことを考えることができます。
本当にそうなのか、なぜそう言えるのかをしっかりと考える思考が大切です。
テストにおいてもそうです。
「仕様は要件と矛盾して(乖離して)いないか」
「分析は正しいのか」「設計したテストはリスクをヘッジすることができるか」
「このメトリクスは求めている内容を可視化できるか」
あらゆる場面でそれら妥当性を確認すると思います。
なにか新しい知識や情報を得るときにも、テストをするときにも役に立つスキルだと思います。
こちらも英語同様で優先度は考える必要がありますが、早いうちに学んでおくべきだと思います。(なのでちゃんと学びます...)
駆け出し始めた直後に学ぶもの
本題です。
JSTQB FLシラバス
THE 王道です。
王道ですが、しっかりと意識して読むと体系的なテストの知識だけでなく、いろいろなことがわかります。
テストのスタンダードを学ぶことで、自分の組織がそれと比べてどんなことをしているのかがわかるようになります。
自分の担当している業務がテストプロセスのどこに該当するのか、なぜやっているのか。
(一部例外的な組織もあるかもしれませんが、)目的を持たないテストはありません。
例えば、はじめはテストを実行するだけの業務でも、
なぜそのテストを実施しているのかを考えることができます。
そのテストがどんなテストレベルでどんなテストタイプで、どんなアプローチで行われているのか考えることができます。
資格試験の学習内容といった位置づけではなく、
考えるためのツールとして非常に優れていると思っています。
アウトプットの習慣・慣れ
考えられるようになったら、
その考えが正しいのか、他の人がどう考えているのかを知る必要が生まれます。
黙って考えているだけでは思考しても価値になりません。
思考に価値を付与するためには、頭の中から外に出す必要があります。
アウトプットというとアレルギー反応が出てしまう人も少なくないと思います。
別に本を書けと言っているわけでも、論文を書けと言っているわけではありません。
ブログですらなくても良いのです。
「twitterを始めましょう。」
twitter地方に生息しているテストクラスタの方々は基本的に親切モンスターです。
ボソっと思っていることやモヤモヤを吐き出すだけでも相談に乗ったり共に悩んでくれるでしょう。
交流が苦手なら、誰かに話しかけろとも言いません。
思ったこと、学んだことをつぶやくだけで十分です。
思考を言語化すること、それを文字に起こして外に出すことが一番大事です。
言葉にして吐き出すことで思考が整理されますし、それまで考えなかった疑問につながったりします。
学んだことを吐き出すことが学びに繋がります。
このループを作り出すために苦手意識をなくし、習慣にしてしまうのが良いと思います。
自分がtwitterとこのブログに吐き出し始めたのが1年目の10月頃です。
もっと早い段階でアウトプットしていれば、その時点の自分がどう考えていたかを振り返ることもできました。
今、「駆け出し時期にこれをやれ」と強く主張できないのはここに由来します。
当時の自分が何に苦しみ、何に困って、何をしていたのかがわからないのです。
人は学んでしまい成長してしまうと、そうでなかったころの気持ちがわからなくなります。
よって、だらだらと書きましたが、
最終的に強いて過去の自分に告げるなら、
「自分の行動や思考のログを残す程度の内容でも良いので、アウトプットを残しなさい」です。
