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月頃です。
もっと早い段階でアウトプットしていれば、その時点の自分がどう考えていたかを振り返ることもできました。
今、「駆け出し時期にこれをやれ」と強く主張できないのはここに由来します。
当時の自分が何に苦しみ、何に困って、何をしていたのかがわからないのです。
人は学んでしまい成長してしまうと、そうでなかったころの気持ちがわからなくなります。
よって、だらだらと書きましたが、
最終的に強いて過去の自分に告げるなら、
「自分の行動や思考のログを残す程度の内容でも良いので、アウトプットを残しなさい」です。
悲観的意見の伝え方
1日目の記事です。
すでに投稿時点で日付が過ぎています。まぁ、こまけぇこたぁいいんだよ。
まだネタが不足しているので、twitterやpeingからコメントやDMなどいただけると幸いです。
頂いたお題
twitterにて頂きました。ありがとうございます。
「QAの悲観的思考をポジティブ思考であるべきマネージャーや開発者にどう伝えるのがプロジェクトにとってベストなのか？とかどうでしょうか。」
技術といえば技術なようで、マインドといわれればマインドのような。
ソフトスキルのお題です。
悲観的な考え
JSTQBのFLシラバスでもテスト担当者のマインドセットとして悲観的な考えが挙げられています。
1.5.2 テスト担当者と開発担当者のマインドセット
(中略)
テスト担当者のマインドセットには、好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さ ない注意力、良好で建設的なコミュニケーションと関係を保つモチベーションが必要となる。
(引用元 : http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf)
テストをする上で「こうなってほしくない」「こんなことが起こるかもしれない」と自分達のプロダクトやサービス、プロジェクト進行についてリスクを考えることは大切な要素です。
しかし、「仕様と異なる動作がありました」「エラーが発生しました」であれば伝えやすいですが、「この仕様で問題ないですか」「エラー起きないですか」とは聞きにくいこともあります。
伝え方の工夫
自分の中で工夫をしているといいますが、気をつけていることは次の四点です。
- 決めつけない
- 理由を説明する
- 理由をきく
- 解決策も提案する
決めつけない
リスクを考えること自体は正しいことです。
しかし、「絶対に〇〇」と決めつけてはいけません。
「この仕様、絶対に問題がある」
「ユーザーにとって、このUIは絶対に良くない」
少なくとも一度はこのように感じたこともあると思います。事実、自分はそう思ってしまうことが今でもあります。
しかし、その仕様も誰かが考えて作ったものです。
もちろん、入念に考えた上でも考慮が漏れることはあるかもしれませんが、頭ごなしに否定されては修正時のパフォーマンスにも影響しかねません。
法的にルールが決まっているために見栄えや使い勝手が悪いこともあり得ますし、色々なリスクを考えた上で複雑になってしまっているのかもしれません。
理由を説明する
懸念を伝えるのであれば、理由も添えるようにしてます。
当然といえば当然に思えますが、暗黙的に「わかるだろう」と思ってしまい理由を伝えていないこともあるかと思います。
なぜそう思ったのか。どうしてそれが問題なのか。
それらの情報があることで、そのリスクをどう扱うかの判断がしやすくなります。
ものづくりの人がものづくりになるべく専念できるよう、渡せる情報はしっかり渡します。
また、理由を伝えることで他の誰かがそこから派生して新たなリスクを見つけられるかもしれません。
見えていなかったところでリスクヘッジされていた、ということもありえます。
理由をきく
一方的に伝えるだけでなく、理由をききます。
仕様は〇〇となっているが、どんな理由・意図があってそうなっているのか。
例えば設計上、そのような対応を取る必要があるのかもしれません。
「本当はそう実装したくないけれど、そうせざるを得ない」ということがそこから汲み取れます。
その情報は今後のテストでも活かせますし、リファクタリングなど改善を進める上で問題箇所として挙げられるようになります。
例えば法務部門に相談したら、そう表示しないとダメだと指摘されたのかもしれません。
自分の知らなかった法的に必要な対応があったことを知ることができます。
こちらも以後の観点として使うことができます。
といった具合に、自分の知らなかった知識や観点、設計や環境による影響を知ることができます。
解決策も提案する
「問題じゃないですか」と懸念だけを投げられるとどうなるでしょう。
1件2件ならまだ良いですが、それが何件も続くとなると「またかよ...」と精神的にも苦痛でしょう。
本来の作業を中断して対応を考える必要もありますし、正解のない問題も多々あります。
協力してプロジェクトを進め、良いプロダクト・サービスをつくることが目的であるはずです。
自分の担当、専門じゃないからと無関心ではなく、「自分はこう思っている」と伝えることが大事です。
アイデアを提案しなければ、自分の思ったとおりの修正がされないことのほうが多いでしょう。
そうなると、また「問題があります」と報告することになるかもしれません。
また、自分の思っている解決策が問題をはらんでいる可能性も十分にあります。
最終的に良いプロダクトを目指すのであれば、
相手(チーム)を尊重し、背景の理解に努め、必要な情報や自分の考えを出し惜しみせず率直に伝えることが重要だと思います。
(追記)まとめ
twitterにて「一言でまとめると？」と問いを頂き、自分ではうまくまとめられなかったのですが良いアンサーをいただけたのでこちらにも引用にて掲載します。
自分が最初に一言でまとめた言葉は、「“悲観的な考え”は否定的であってはいけない」です。
悲観的であることと否定的であることは等価ではありませんし、
(よほどの意思表示でなければ) 否定的に伝えることにポジティブな効果はないため、否定的であることを否定しようとしています。
その後まとめて頂いた言葉が次のtweetになります。
「問題を見つけるまでは悲観的な考えを持ってテストすることも大切だけれど、見つかった問題を伝えるときには自分の見落としの可能性もあるし、謙虚になって相手へのリスペクトを忘れずに伝えよう」かな。
— あきやま🍵 (@akiyama924) 2019年12月2日
一言ではなくなっているので、1番主張したいことを抜き出して一言にまとめないといけないけど。
こうして反応をいただけるだけで本当にありがたいです。
(それなりにエゴサもしていますので、反応をしていただけると喜びます。)
「不安だから」はテストをする理由にならない
ご無沙汰です、夏以来ブログ更新を怠っていたhalspringです。
特になにかあったわけではなく、ふと思い立ったのでそのまま綴ります。 変な文章になっていてもご容赦願います。
テストをする理由
テストには目的があり、テストには必ず理由があります( なければ実施する意味がありません )。 では、テストは一体なぜ行われるのか。
JSTQBのFLシラバスでは以下のように書かれています。
すべてのプロジェクトで、テストの目的は以下を含む。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 明確にしたすべての要件を満たしていることを検証する。
- テスト対象が完成し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- 欠陥の作りこみを防ぐ。
- 故障や欠陥を発見する。
- ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
- （以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する。
- 契約上、法律上、または規制上の要件や標準を遵守する、そしてまたはテスト対象がそのような要件や標準に準拠していることを検証する。
これらの目的のために、要件を満たしていない機能がないか/ビジネス上のリスクはないか/ユーザーに不利益はないか/法的に問題はないかなど悲観的な考えを持つことが重要になります。 ( JSTQB FLにもテスト担当者のマインドセットとして悲観的な考えが挙げられています。)
悲観的な考えには、不安がついて回ります。
プロダクトで起きてほしくないこと、潜んでいそうな欠陥(過去の欠陥や類似機能の欠陥など)について考えたりと、あらゆる不安を考えます。
不安だからテストをする？
さて、ではテストを行う理由は「不安だから」で良いのでしょうか。
※ここからは勝手な妄想を含みます。 特に誰かが「不安だからテストします」をしていたのを見たわけではないですが、なんとなく「起こり得るのでは？」と思っているだけです。
不安を考えることは誤りではありませんし、悪いことではないと思います。 しかし、「テストを行う理由」にしてしまうことには違和感があります。
「不安だから」は論理的ではなく、感覚的です。 感覚的なテストは果たして良いテストなのでしょうか。
特にテスト仕様書を準備するようなテストにおいて、理由として十分なのでしょうか。
不安をブラックボックスから取り出す
その不安は何に起因しているのでしょう。
不安が現実になってしまったらどんな影響があるのでしょう。
「不安だから」のままでは定量的な評価ができません。 また、際限なく不安は生まれます。
際限なく生まれてくる不安すべてをテストしていては人も時間も足りません。 工数が足りないどころか、工数を掛けるだけの価値があるのかもわかりません。
不安は不安のままでは良くなく、正体を探る必要があります。
不安を「ビジネスインパクト」「影響するユーザー(ステークホルダー)の規模」「発生する可能性」などで定量的な数字に落とし込みます。
( はい、お気付きかもしれませんがリスク分析です。 )
定量化することでテストの優先順位付けや実施する/しないの意思決定が容易かつ合理的になり、納得感も増すことでしょう。
可能であればさらに、テストで確認する必要があるのかも検討すると良いかもしれません。 別の方法でより簡潔もしくは確実にケアすることができるのであれば、最適な手段を用いるべきです。
テストで確認すると決定しても、どんなテストをどれくらい実施すればケアできるのかまで踏み込み、可能な限り合理的で効率的に設計します。プログラムと同じです。
「いい感じに実装しました」と言われてテスト側が良い顔しないのと同じように、「不安だからテストします」と言われても開発側は十分かどうか判断できませんしモヤモヤするでしょう。少なくとも自分はそうです。
プロジェクトの関係者が納得できる、そして合理的で効率的なテストができるようにするためにも不安の中身を知る必要があります。
「不安だから」で行っていいテスト
不安を理由にするのはどうなのか、と書き綴っていましたが、もちろん例外もあると思います。
例えば探索的テストのような工数を掛けずにテスト担当者の経験に基づいて実施するテストであればこの限りではないと考えています。 過去のプロジェクトから得た経験を活かしたり、視点を切り替えながら欠陥を探す活動は感覚的な一面も持っていますし、言語化の難しい不安も確かに存在するからです。
加えて、探索的テストは再現性を犠牲にしている一面があり、逆に考えるとテスト仕様書を用いるテストは再現性が(粒度はさておき)確保されています。テスト仕様書を作成した人でなくとも、一定のテスト実施ができるようになっています。 テスト仕様書を用いるテストは、実施されるテストが再現性を持つことに意味があるから行われるとも言えます。
だとすれば、再現性のためだけに言語化の難しい不安の正体を探り時間を掛けるくらいなら、手を動かしてテストしてしまった方が早いです。
おわりに
お読み頂きありがとうございました。
もしご意見ご感想等あればコメント、ツイート、DMなどお待ちしております。
——
参考までに、WACATE2013の井芹さんのリスクベースドテストに関するスライドをぶら下げておきます。
WACATE2019夏を通して感じたこと
はじめに
どうも、お疲れ様です。
WACATEのあと休みを取らなかったことでずっとテスト尽くしの12日間を終えて土曜日にたどり着きましたhalspringです。
WACATE2019夏に参加してきました(WACATEについての説明は省略します)。
この記事では自分がWACATEに参加して"感じたこと"を中心に書こうと思います。 ですので、今回のWACATEの内容については他の参加レポートやtogetterをご参照ください。
パッとしらべて出てきた参加レポートはこちら
感じることというのはその人の周囲の環境や経験、体調や気持ちによって大きく異なります。 ですので、記事に価値のある情報はほとんどないかもしれません。
興味のある方のみおもしろ半分で読んでいただければと思います。
目次
説明ができる
WACATEは2018冬が初参加で、今回が2回目です。 夏と冬でワークの時間も雰囲気も異なる影響もあるとは思いますが、冬のときよりも積極的に発言や説明を出来るようになっていた気がします。 ソフトスキルが向上した と言いたいところですが、班のほとんどが初参加者で若干頼られる存在になっていたことと、そのことを感じてある種の責任感があったのだと思います。
また、普段はチーム内でテストについてわざわざ説明を行う機会はあまりありません。組織によってはクライアントに説明をすることがあるかもしれませんが、例えば「テストレベルとは」のようことを話したりする機会は少ないと思います。( テストジョークのようなことを雑談で話したりはしますが )
普段 説明したり話すことの少ないことについても、（正しくない可能性は否定できませんが）自分なりに説明をすることができることに気が付き、1年前 やっと新卒研修を終えたばかりだった自分から成長できていることを感じられました。 ソフトウェアテストは 開発のように目に見えるアウトプットを作りにくく、成長の実感をすることも難しいと思います。 WACATEのワークショップは なにが説明できて何が説明できないのか 何を曖昧なまま使っているのか、その辺りをスッキリさせる良い機会なのかもしれません。
経験の共有
WACATE2019夏のひとつの目玉である（と勝手に思っている）テスト計画、 参加者の何人がこれまでに作ったことがあったのでしょう。 別に作ったことがあるから偉いとか、やったことがないからどうとか、そんなナンセンスなことを言うつもりはありません。
過去にテスト計画がテーマの勉強会でも「テスト計画を作ったことがある人」の質問に対して手が上がったのは半分に満たないくらいでした（手をあげるのが好きではない人もいるとは思いますが）。 テーマにテスト計画を掲げている勉強会でその割合であれば、テストプロセス全体をテーマとし若手を中心（新卒や業界1年目2年目の方も多かったです）としたWACATEでは より少ないだろうと思います。
ひとつ前で述べた責任感の話もあり、運良くテスト計画を経験したことのあるだけの自分は おこがましくはありますが、他の参加者になるべく多く自分の持っている知見を共有しなければと感じました。
全てがそうだとは思いませんが、経験できる/できないには運が大きく関わっていると思います。 しかし、経験を出来ずとも経験者から知識を得ることはできます。 当然、実際の経験から得られるものに比べれば不確かで、偏っていて、不足している情報かもしれません。 それでも自分の経験を出来るだけなぞれるように、聞いた人が咀嚼して飲み込めるように意識して伝える責任があると感じました。
経験を積めないことについては本人が悪いわけではありません。 （意図的に避けて経験を「積まない」場合は別ですが。）
自ら飛び込んでいけばいいと言う意見もあるでしょうが、飛び込んで行くにはそれ相応のリスクも必要です。 ただ本を読むだとかそのレベルなら良いですが、転職するだとか職種を変える必要が出てくると様々なものと別れる必要が出てきます。飛び込んだ先で叶うとも限りません。 自分が経験を積むために何かを捨てる必要があるとき、その決断を迷わず出来る自信は正直ありません。
ですから、運良く経験出来る立場になったら 経験出来ないけれど「せめて知識だけでも」と情報を必要としている人達に向けて共有しなければいけない、 そうしなければ、業界全体は良くならないように思いました。なにもせず良くなるとしても、したほうが格段に速いはずです。
土日にお金払って遠出してまでテストを勉強している我々です。 古臭い文化、目的のないテストが行われるような現場、QAエンジニア・テストエンジニアの価値向上、発展のために出来ることがあります。 今すぐは難しいかもしれませんが、加速していきましょう。大層なことを言ってしまったので自分も頑張ります。
リードするということ
テスト計画の経験から、計画を立てる際に班をリードして進める役に他薦して頂きました。 自分がテスト計画を立てるときに、どう考え、どんな流れで進めているのかを説明し、ひとつひとつの自分の判断に対してなるべく理由も話すようにしました。
「こんな理由から こんな感じに進めようと思うのですが、どうでしょうか？何かご意見ありますか？」と尋ね、合意を得ながら進めていったものの、「そういうものなのか」と丸呑みをさせてしまったのではないかと少し不安になっています。
ワークを進める上でなるべく全員に共通の理解を納得感を持てるように自分の意見を言う前に「ここはどう思いますか？」と先に話を振るなどもしてみました。
結果として班のメンバーから意見が出て、「こうした方が良いのではないか」「ここのリスクは◯◯なので優先度をスコープから外してもよいのではないか」と議論検討することもでき、充実したワークを楽しむことが出来ました。 しかし、全体への問い掛けでなく、もっと個人に振ればよかったのではないかと後悔もしています。 ファシリテートって難しいです。
班の方にはありがたいことに評価して頂けましたが、今後 同じような役割を担うときにもっと上手くできるように意識したいです。
リスク分析
自分はテストアプローチを考える時にまずはリスクを出してくのですが、全体のリアクションを見ていて「あまりリスク分析ってされていないのでは...？」と感じました。
意識せずにリスクを気にしている、ということは当然あると思います。無意識にリスク分析を行ってテストを設計することはもちろん不可能ではありませんが、無意識で行なっていては考慮していないもの（例えば機能）が出てきてしまうのではないかと思いました。
全体の成果物の発表を聴いていて、ほとんどの班が「リスクの大きい部分を中心にテストしました」と発表していました。 時間の都合もあって詳細までは聴くことができませんでしたが、テストする機能/しない機能の決定にロジックがあったのかなかったのか、あるならどう決定したのか、ひとつひとつの機能や複合的にどんなリスクがあるか検討していたのだろうかと気になりました。 （どんなアプローチを取っていたのか気になるので、差し支え無ければtwitterか何かでお教え頂けると嬉しいです！）
他の班としみじみアプローチや見つけた不具合について話し合う時間を取れれば良かったのですが、疲れと 人に話しかけるスキルの低さが露呈してしまいました。無念。
経験？ロジカル？閃き？
今回のワーク中、システムテストで主機能を確認、受け入れテストで全機能をシナリオベースで確認するアプローチを取りました。パフォーマンステストやクロスブラウザテストは今回のテスト計画からは外す方向で進んでいました。
ところが、班の人が使っている端末がwindows 4人とmac 2人であったため「システムテストをwin、受け入れテストをmacで実施すればある程度のクロスブラウザの担保はできるのでは？」と判断して、その方針で進むことになりました。
このようなアプローチのアイデア、これは経験から来るのでしょうか？それともロジカルに導いているのでしょうか？あるいは咄嗟の閃きなのでしょうか？
初めは閃きorロジカルから来るもので、徐々に脳にキャッシュされ経験から出せるものになるのでしょうか？ だとすると、キャッシュが古くなり過ぎないように工夫しないとなぁと感じました。
前回も思いましたが、WACATEでtwitterアカウントを開設する方や、放置していたアカウントを掘り出す方、多いですよね。 今回は時間的制約の強いワーク中心であったため、あまり活発ではなかったのかなぁとは思いますが、勉強会やイベントでは大体 誰かが 議事録的なメモ、実況、疑問、感想をつぶやいています。 WACATEに関して言えば、ハッシュタグのない裏側で有識者達がTLの内容を見てつぶやいたりもしています。
この辺りの情報も拾いながら参加すると より視野が広がったり造詣が深まったりします。 疑問をつぶやくと講演者や有識者が答えてくれたり、誤ってメモしていたり理解していることは指摘してくれたり周りを見て気が付けたりします。
界隈の方には（よほどのことがなければ）とても温かく見守って貰えますし、自分はなかなかの人見知りですが twitterから認知して頂いて話しかけてくださる人が増えたり、登壇させて頂く機会を頂けたりと良いこと尽くしです。 リアルのコミュニケーションが苦手な方はテスト用のアカウントを作るもよし、ROM専でもよしなので、情報源は増やしておくことをオススメします。
QAの需要
感覚値ですが、開発やその他職種からテストエンジニア/QAにジョブチェンジしている人が多かった気がします。 テストの重要性が少しずつ理解されるようになって来ているように思えます。
ただ、QAの求人もよく見かけるようになってやはり「必要になったものの、今まで抱えていなかったからどうすればいいのかわからない」という面が見えます。
QA人材のおおまかな獲得方法は、
- 中途で雇う
- 新卒から育てる
- ジョブチェンジさせる
の3つだと思います。 中途で雇う選択肢は、評価できる/見極めることができる人が社内におらず 採用が難しいのかなと思います。 また、必然的にQAチームの立ち上げからになるので、チーム立ち上げ型転職芸人のような熟練者は別として、応募側にとってもハードルが高くなってしまうのかなぁと感じます。
新卒から育てる選択肢も同じような理由で難しく思います。わかる人がいないということは、育てられる人がいないのです。
そうなると残る選択肢はジョブチェンジです。 元々開発をしていれば、自社のドメインには詳しいですし、テストもまぁできる、開発をより良くするにはどうすればいいのか考えることもできます。 おそらくそういった背景の下、ジョブチェンジでQAになられた方が増えているのかなと思いました。
そしてその流れが進んでいけば 開発の知識やマーケティングの知識など、品質保証プラスアルファの知識を持つ方が増えてくるのだろうなと思います。 もちろんその流れがなくともそうなのですが、QAやテスト以外の技術や知識、観点も身に付けて自身の価値を創造して磨いていく必要を強く感じました。
最終的に目指したいところは自分の価値の最大化ではなく関わる方に与える価値の最大化なので、得たものは現場やコミュニティ、業界に還元できるよう頑張ります。
おわりに
色々と生意気なことを書いてしまっていると思います。大変畏れ多いです。
夏と冬でこんなに違うのかと驚きました。 WACATEはどんな参加者にも何かを与えてくれるので本当にすごいコンテンツですね。 実行委員の方々にはとても感謝しています。 そして次回も楽しみにしております。ありがとうございました。
