こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- テスト戦略やリリース計画をどのように考えているのか?(by ログラス)
- 要件・仕様のキャッチアップは?
- ビジネス*3とのコミュニケーションで気をつけていること
- Q&A
- テスト計画書からテスト項目書作成、テスト実行など、それぞれのスケジュール感はどのように決めるべきか?
- to Bでは要件を握るのが大切ということでシーケンシャルな開発になりそうですが、アジャイルテスティングを維持するために工夫してることはありますか?
- リリースの定義はプロダクトの若さなどに依存すると思いますが、その辺りはどのような事を考慮して、決めてますか?
- 新しく入ったQAの方のキャッチアップもアプリ触りまくるみたいな感じですか?もしくはドキュメントが用意されていて読むとかでしょうか?
- QAの方が作成したドキュメントは開発者もレビューするのか?
- 新卒QAにはまずどんなことを教える?もしくはやってもらうか?
- QA未経験の開発者です。上司からテストフローを確立しろ!(テスト項目書とか作れ?)と言われました。何から始めれば良いでしょうか?
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
近年ではBtoC向けのSaaSサービスの立ち上げや、スタートアップなど規模を問わずQA組織の立ち上げをよく見ます。 古くからエンタープライズ向けのBtoBプロダクトを扱うQAにも様々な技法や、面白さがあります。 今回の Agile Testing Night ではBtoBプロダクトのQAエンジニアが集合し、お互いの現場ではどのようなQA活動をしているか多いに語っていただきます。 以下のようなトークテーマを企画しています。
・テストケースのボリューム
・仕様のキャッチアップ
・リリース計画
・ビジネスサイドとコミュニケーションの仕方
・身近じゃないユースケースの定義の話
会の様子
テスト戦略やリリース計画をどのように考えているのか?(by ログラス)
機能面ももちろんテストはしますが、toBということもあって最近は非機能面のテストを多くしているということでした。
ログラスはExcelで今までやっていた作業を置き換えする部分を売り出しており、大量データを消化できるのが競争優位性になるため、非機能要件を重視しているということでした。
具体的な作業としては、システムダウンする閾値を探したりしているということです。(閾値のホワイトペーパーは書いていない)
また、リリース前に非機能面でも要件を握っておいたり、出荷可能な定義をビジネスサイドとのコミュニケーションを密に取りながら考えているというお話も挙がっていました。
また、非機能要件を握るといっても、最初からみえてこない部分もあって完璧なテスト戦略を事前に立てることは不可能のため、最初に暫定的なACを決めて、それが守れるのかを継続的に確認していくというお話もWingArc1stからありました。*1
区長は、非機能要件を考える際にはプロダクトをひたすら触って壊すようにしているということです。
要件・仕様のキャッチアップは?
ログラスでは、顧客にインタビューした際の動画などが残っているので、それをエンジニアでお昼に一時間で同時視聴したり*2、簿記の勉強会を部活的なものを立ち上げたり、エンジニア全員で一緒に勉強しているということです。
これは、ログラスが「なんでこの機能作らなきゃいけないんだっけ?」を重視しているからこそやっているということでした。
また、展示会に参加して顧客の声を聞きだしたり、テスト容易性の観点で開発者に仕様のフィードバックを行うこともしているそうです。
こうした取り組みができているのは、CSをはじめとしたビジネスサイドの人たちと距離が近いが故にできる取り組みだと考えているということです。
WingArc1stでも、顧客と直接会話できる部署に関しては直接インタビューをしたりしているそうで、それが難しい部署に関してはパートナーと話をしたりしているというお話がありました。
他にも、1000本ノックテストという名前で、ユーザーのユースケースを1000本考えるまではリリースしない、みたいな取り組みも試しにやってみたということです。
区長は、やはりプロダクトをひたすら触るということで、何に使うの?どんな使い道が他にあるの?を愚直に実践しているということでした。
ビジネス*3とのコミュニケーションで気をつけていること
コタツさんは、飲みに行ったりと接点を増やすことでまずは一次情報を拾い、そこでQAという仕事への認知もしてもらうようにしているということです。
WingArc1stでは、「どんどんビジネス展開をしたい!」という想いに対して、現実としてアーキテクチャなどを考えると今はここまで売れますよ、みたいなコミュニケーションをすることが多いということでした。
区長は、バグが出たときにどういうバグがなぜ出たのか?という話をすることが多いということです。
Q&A
パネルディスカッションの途中で、Q&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
テスト計画書からテスト項目書作成、テスト実行など、それぞれのスケジュール感はどのように決めるべきか?
- フェーズを分けて、それぞれのフェーズでこんなものを作るというのをインクリメンタルに作る
- WF開発なので、工程ごとにスケジュール感を決める
- スクラムチームでエンジニアとも相談して決める
- バックログに積まれているストーリーにどのようなテストをするのかの計画を記載する
to Bでは要件を握るのが大切ということでシーケンシャルな開発になりそうですが、アジャイルテスティングを維持するために工夫してることはありますか?
- リファインメントのタイミングなど週2-3回話すタイミングがあるため、そこでいきいきとしたドキュメント(ストーリー)を作るようにしている
リリースの定義はプロダクトの若さなどに依存すると思いますが、その辺りはどのような事を考慮して、決めてますか?
- 顧客の多さや顧客層を考えることで決める
- リリースする基準を決め、ステークホルダー(経営層など)と合意をとっておく
新しく入ったQAの方のキャッチアップもアプリ触りまくるみたいな感じですか?もしくはドキュメントが用意されていて読むとかでしょうか?
- 触ることはたしかにそうだが、ユースケースが今ひとつ想像できないので、バックグラウンドが分かるように競合容易性などを調べたりサービスブループリントでまとめたりしている
- 生き字引の人から定期的に話を聞く
- プロダクトアーキテクチャの理解をして、弱点をひたすらたたくようにする
- 障害を見る
QAの方が作成したドキュメントは開発者もレビューするのか?
- あまりドキュメントを作らず、開発陣がドキュメントを作るのをサポートしているようなイメージ
- テスト設計はモブでやったほうがお互いの知識がシェアできてよいと思う
新卒QAにはまずどんなことを教える?もしくはやってもらうか?
- 現場に入ったらひたすら仕事をしてもらう
- この世界(IT業界)ってこうなっているんだよ、を教える
- QAって世の中ではこう定義されているけど自分たちはこう定義しているんだよ、というところをどんどん教える
QA未経験の開発者です。上司からテストフローを確立しろ!(テスト項目書とか作れ?)と言われました。何から始めれば良いでしょうか?
- 現状確認からしたいので一緒に飲みに行きたい
- テストの街葛飾やスクフェス新潟に参加すると良い
- テストすればなんとかなるというわけではないので、テストフローでそもそも何を解決したいのか?というのを考える必要がある
- まずはテスト計画やテストプロセスを書いて上司と相談すると良いと思う
会全体を通した感想
葛飾が出張している様子を見ることができて楽しかったです。
スタートアップ企業か老舗企業(???)かでバトルが時々起きていたのと、区長がやたらと軍事の話に持っていこうとしている(軍事マウント)のが印象的でした。