イベント概要
sli.doのURL
このブログの概要
Agile QA Night in FUKUOKA!!のパネルトークセッションで、参加者の方にsli.doを使って質問を募集しました。
せっかくなので、淡々と答えてみようというブログです。
私のコンテキスト
- テストエンジニア歴3年半ぐらい(Web系)
- 今は受託開発と自社サービスのテストをやっている
- 主にシステムテスト、受け入れテストをやっている
sli.doでいただいた質問
1.後の方でコメントした内容は、あまり皆の目とまって無いように見受けられます。 いいねが多い順も大事ですが、たまに少ない方からも選んでみてはどうでしょうか?
そうですね!
面白い質問も多かったので、順番に答えるターンとインパクトある質問を答えるターン、さっと回答できそうな質問に答えるターンなどあると面白そうですね。
2.アジャイルなQAとそうでないQAの成果物で最たる違いは?
よくわかんないですね。
そもそも現状QAの成果物って会社やチームによってバラバラだと思っています。
なので「アジャイルだからこれがある!」っていうのはないような気がします。
3.なぜにブロッコリー?
もともとは髪型じゃなかったですっけ?
たしか。
4.ご自身の活動は品質向上にどのように貢献していますか
ぐさりとくる質問ですね。
言われている「品質」がどの品質なんだろう?という疑問はありますけど。
あと、「貢献」という言葉も気になります(笑)
貢献している感覚はないんですよね。
自分のテスト業務をする通じて開発者が楽になったり、お客さんが使いやすくなったりしているのでは…と思っています。
5.開発モデルの変化に対してテスト業界がどのように変化してきたのかについて
業界が…ですか。
その開発モデルに対してどうテストしたら良いかを考えて、様々な手法が生まれたんじゃないかなぁと思います。
ISTQBシラバスが更新されたり、新しいロールができたり、各会社や現場でどうやったら良くなるのかを考えて。
6.自分の所にはQAが近くにいます。社会や近くにQAがいない場合Majorなどの判断など密にコミュニケーションが取れないかと思うのですが進行に問題はありませんか?自分の所ですと中々考えにくいので知りたいです。
うーんと…QAと遠隔でコミュニケーションすると、ということですかね?
その場合は別に問題はなかったですね(過去の経験)。
チャットメインでコミュニケーションしたり、必要に応じてスカイプやオンライン会議をしていたので。
物理的に遠くても密にやれると思うし、近くても密にできないということもあるし。
「密に」の中身とそのプロジェクトでどうしたいか次第じゃないですかね。
もしかしたら「密に」取る必要がないかもしれない。
7.テストエンジニアがいないチームで、開発エンジニアが開発が終わったあとにテストを行っているというプロジェクトにて、テストエンジニアの皆さんから開発エンジニア達にアドバイスがあればお願いします。
ぜひ、テストの視点やお客さんの視点でテストしようとしたらいいかなぁと思います。
私の好きな資料に↓池田暁さんの「単なる仕様チェックを卒業してテスト技術力を高めていくために〜押さえておきたいキホンのキ〜」というのがあるんですがこのP30 ~ P35をぜひ。
8.テスト準備期間が充分に取れない時はどうしてますか?これだけはやっておくということがあれば教えてください
まずは取れるようにアプローチしたいですよね(笑)。
充分…そもそもどこまでできているかわからないのですが、開発者から仕様を聞くというのだけは最低限やってます。
仕様だけじゃなくて「なんでこのプロジェクト始まったの?お客さんは何があってこのシステムほしいの?」などは必ず。
9.ぶっちゃけアジャイルやめたいですか?
そもそもうちはアジャイルやっているのか?という疑問があるので(笑)
仮にやっているとするなら、アジャイルやめなくていと思います。
ただ、無理やりにアジャイルを意識することはしなくていいと思います。
10.リアルバクに関してどのような考えを持っていますか? 「テストの粒度」と強く絡んでいて、トレードオフの部分が大きいと思いますが、各社の意見を聞きたいです。
リアルバグ = リリース後にみつかったバグ としますね。
テストの粒度…全数テストやるかどうか?みたいな話ですかね?
「自分が想像できなかったバグ」についてはしょうがないとあきらめます。
これについては「どうやったら次からそれを見つけれるか?」を考えます。
「自分が想像できたバグ」については、なんでそれが漏れてしまったかを考えます。
過去には「直前に大きいバグが治って油断した」「精神的に余裕がなくて見逃した」ということがありました。
これらについては、「油断しそうなタイミングで気を引き締める」「余裕がなくならないようにスケジュール調整する、精神状況を日々モニタリングする」といったことをしています。
11.テストしていくなかで有効、便利なツールが知りたいです。
テストのどのフェーズで対象はなんだろう…。
ひとまず↓など参考にするといいのでは?と思いました。
12.どれくらいの規模にプロダクトが成長したらQAチームが必要だと感じますか? 開発者によるテストで回らなくなったら。とかですか? QA担当を入れるタイミングが知りたいです
どんな規模の開発チームに合ってもいいと思います。
13.優先度の中、低って結局処理されないことが多いのですが、どう処理してますか?
バグ票/インシデントレポート の優先度の話ですかね?
時間とお金が絡むので難しいですよね。
うちは最終ジャッジは開発者(プロジェクトオーナー)にゆだねているので、どうしても直したほうがいいものについては、中でも低でも交渉しています。
質問してくださった方どんな基準で優先度をつけているのか気になりました。
14.qaからウォーターフォールからアジャイル開発にしよう!と発信しにくいイメージですが、みなさんは既存の開発の状況をqaから変えていける発信力があるのでしょうか?どうやったらアジャイル開発に変えていけるのでしょうか?
そもそも私QAじゃないので…(笑)
そもそもウォーターフォールやめてアジャイルにしたい理由って何なんですかね?
私の場合たぶん、よっぽど変えたい何かがあればちゃんと話して変えてもらうと思います。
そのときはちゃんと話聞いてくれるメンバーだと思います。
ただ僕は大きく変えるよりは、小さく変えていく方を好んでいるので「ガラッと変える」みたいなことはそもそもあんまりしないですね。
15.モブプロだとなんで忖度が発生しづらいのか理解できなかった
みんなで見てるから、だと思います。
その場で作ってその場で疑問を口にするので。
16.QAの成果物って何ですか?
テストではなく、QAの成果物ですか。
あと誰に対する(何に対する)成果物なのか気になりました。
テストプロセスでいうと、テスト設計コンテストU-30チュートリアル資料P67が参考になると思います。
↓以外だと、テスト実行時のテストケースやバグ票のレポートなどですかね。
17.テストを行う際にテストデータが必要かと思いますが、どうやって準備していますか?テストデータが足りなくバグが出せなかったりとかあるのかなと思って聞きたいです
重要な部分については予めデシジョンテーブル使ったり、テストパターンを考えて準備してます。
状況によっては実装内容聞いたりしてます。
足りなくても最終的にバグが見つからなかったらバグではないので、それはそれでいいのでは…(笑)
ただ足りなくて自分のテストフェーズでバグが見つからず漏れてしまった場合はありますね。
それは質問10と同じ対応しますね。
18. 普段使ってるツール(バグトラッキングとかCI/CDとか、コミュニケーションとか)を教えてください!
以下になります。
19. ソースが読めないとモブプロに入れてもらえない感あるんですが、あるいは疎外感感じると思うんですが、いかがでしょう
気にせず入っていっていいんじゃないですかね?
そこで学ぶこともできるでしょうし。
疎外感は感じるかもしれないですね。
その場合はソースが読めるようになったら疎外感なくなるかと。
なんのために参加しているのか?をわかってもらうとなくなるかもしれません。
20. QAで一番大事にすることは何ですか
品質、なんだと思います。
品質保証っていうぐらいですし。
なんの品質なのかは状況次第。
あと、その品質を大事にするために他に大事にすることがいっぱいあるなぁ…と。
難しいですね。
21. 開発のスコープが事前にわかっていても複雑度が増していくとリグレッションテストの範囲が広くなっていくことは避けられないと思います。そんな中でQA期間がリリースサイクルを不安定にさせないためにどういった施策を実施していますか?
開発チーム側でE2Eの自動テスト書いていってくれてたりします。
自分がやる手動テストではテスト実施の範囲絞ってますね。
影響範囲聞いたりしてます。
22. 会場の空気、もっと盛り上げたくないですか?
盛り上げたかった!
次回以降やるときはがんばります!
23. テスト工数を見積る上でのテストベースは何、そして見積る時期は?
今の所要求のリストと機能、画面のリストですね。
案件開始時とテスト実行が始まる少し前の2回あります。
24. QAを極めるとの最終的に行き着く先はどうなると思いますか
QAいなくなるんじゃないですかね?
またはみんながQAになる。
俺がガ●ダムだ的な。
25. Agile と Waterfall Like の開発プロセスで、テストの成果物やテストの実行時間に具体的にどのような違いがありますか? Agileで進めると十分なテスト実施時間が確保できず品質を担保するのが難しいという課題もあると思うのですが、そのあたりはどのように解決していますか?
・テスト成果物や実行時間の違い
→ 質問2と同じですかね。
・充分なテスト実施時間が確保できず
→ それで品質を担保できていない(=品質がおちている)のであれば、そのリリースサイクル見直した方がいいような気がします。
または、そのリリースでサイクルできることをやったほうがいいような気がします。
ただ、テストしすぎるというのもリリース遅くなってしまうので、リスクベースドに考えてテストするか、開発者側にもテストしてもらうというのも有りかなぁと思います。
感想
質問の回答難しいですね(笑)
なるべく短くを意識したんですが…語りたくなる。
質問した方の背景がわからないのがもどかしいし、どのテストフェーズのことを言ってるんだろう?と気になりました。
質問に答えるのも勉強になりますね。
半年後ぐらいにまた答えると違った回答ができるかもしれません。
質問いただきありがとうございました。