JaSST’18 Tokyo A2セッション簡易レポート

本日初めてJaSST’18 Tokyo に参加してきた。以下、一番印象に残ったセッションについての簡易レポート。


Web.JaSST~ウェブ系QAがみんなのお悩みに全力で提案を返す会~

  • 2名1組×4でパネルディスカッション
  • お題ごとにチームで回答する
モデレータ:鈴木 里惇さん(LINE)
チームA:柿崎 憲さん(サイバード)、鶴岡 洋子さん(ユニファ)
チームB:山本 久仁朗さん(アカツキ)、米山 允章さん(メルカリ)
チームC:山本 健さん(mixi)、川﨑 久美さん(mixi)
チームD:浅黄 友隆さん(ヒューマンクレスト)、山口 真央さん(ヒューマンクレスト)

【質問1】

テスト観点を洗い出すとき、システムの細かな仕様に気を取られ、いわゆる「木を見て森を見ぬ」状態になりがちです。網羅的にテスト観点を洗い出す際の工夫は何でしょうか?

A
ロジカルシンキング
大きな観点から詳細に落とし込んでいく
テンプレート
漏れがちな観点をリスト化
B
マスターテストプランを用意する
サービス(≠機能)として重要な観点を洗い出しておく
C
業務知識を身に着ける
発注者の顔を見る
D
コミュニケーションロスを減らす
仕様書やテストケースをレビューして認識合わせ

【質問2】

バグ分析のメトリクスはどのようなものを取得しているか?バグ分析はどのようなことをしているか?(そもそもやっているか)

A
障害情報をログとして残して全体に共有
信頼度成長曲線(バグを分析すれば成長曲線が作れる)
→Web系だとやりきれない場合が多い?
B
バグの件数、重要度、機能、人、クラッシュ率、修正までの時間
BTSを使用している(アカツキ)
メルカリはチームに一人QAがいる。
バグ件数などを個人の目標や評価に落とし込んでいる
個人的にはクラッシュ率を一番重視している(米山さん)
C
宵越しのバグは忘れる
分析する前に直せるならさっさと直す
D
時間切れ

【質問3】

給料が安くてつらいです。QAの適正な給与はいくらいくらいでしょうか?
また、給与を上げるためにはどうすればよいでしょうか?
A
報酬を上げるためには事業に貢献する以外にない
QAとして業務にかかわる範囲を広げることで、QAの価値を上げようとしている
B
転職
スキルアップ
C
テストに限らずプロジェクトの困りごとを少しずつでも解決していく
プレスリリース書いたりモンスターのデザインをしたこともある(山本さん)
D
勉強して会社にアピール

【質問4】

QAメンバーの評価をどのようにやっているか?また、チーム/個人の目標設定をどうしているか?
A
会社>部>課>個人へブレイクダウン
炎上していない(問題が起こっていない)ことが一番に評価されるべきで、そのように枠組みを作っている
B
QA向けにスキルセットと評価のフレームワーク作成中
本番バグ件数などを具体的目標に入れている人もいる
コミットメントの達成度(どう評価するか事前に話し合う)
mixiでは三か月ごとにやっている
D
1on1を実施して目標設定
技術と経験でスキルセットを設定→評価

【質問5】

プログラミングができるQAの採用に苦労している。そういったエンジニアはどういった点に魅力を感じて転職するのか?
A
同じように苦労している
テスト自動化の土台すらない会社なので、土台を最初から作れることをアピールポイントにしているが、テストオートメーションの仕組みを知りたくて応募してくる応募者とのミスマッチが起きている
B
開発者をコンバートする
元々のQAは炎上案件に引き抜かれて定着しないので、新卒2年目で適性のありそうなエンジニアをQAにコンバートしてやっと軌道に乗った
C
社内外問わずエンジニアを口説く
品質保証に興味があるエンジニアは多い
逆に、QAエンジニアがコードを書けるようになるルートも考えないといけない
D
QAの権限
問題解決の姿勢が一番大事

【質問6】

品質保証チームの仕事の範囲はどこまでと考えているか?
A
自分で枠組みを決めず、技術の空白を埋めに行く
ユーザーを理解するためにビジネスサイドに寄る
保育園/幼稚園向けのサービスを展開しているので、QAが保育士の研修を受けに行く予定(鶴岡さん)
B
QAの担当スコープはサービス全体
C
困っているところがあればどこまでも
現状は要件まとめや仕様まとめ
D
部署→すべて
チーム→すべて

【質問7】

テスト管理ツールをうまく導入できているのか?結局Excelが最強なのでは?
A
時間切れ
B
Webの自動化ができているならTestLinkで管理
マニュアルテストはエクセルやGoogleDocsが最強
C
Excelがやりやすいのであればそれでいい
トラッキングしたいのであればマージしたソースがわかるものが良い
mixiではGoogleDocsでテスト管理をしている小さいサービスもある
D
管理するのがテストケースならExcelでOK
管理対象が何かで使い分ける
RedMineでテストケースを管理している
Excelからの移行コストを考えないといけない
結局デファクトスタンダードがないので組織の規模に合わせて使い分けるのが良いのでは

【質問8】

探索的テストの場合、テスト開始時にボリュームが見えづらいので、何をもって終了と判断しているか?
A
プロダクトの要件を満たせているか?
探索的テストという言葉は危ういと思っている
自分たちが行っているテストによって顧客になにが提供できるかを考える
B
そのテストは探索テストか?という問いかけ
どこをどういう観点でテストするかを突き詰める
C
何をしたいのか決めておく
何をもって終了かはプロダクトに応じて決めておく
D
観点を決めて実施
時間を区切って実施
機能テストをやっているなら観点を変えたり掘り下げたりする

自社にはプログラムが書けるQAエンジニアが不在なので、質問5にあったような、エンジニアをQAにコンバートするというプランが非常に魅力的に思えた。
しかしそもそもエンジニアの人数も足りていないので、自社で実現できるのはまだまだ先の話か…。とはいえ自分のキャリアパスの一つとして、プログラムが書けるQAエンジニアというのはアリな気がしてきた。もっとQAの勉強をしよう。(もちろんプログラミングも)

“JaSST’18 Tokyo A2セッション簡易レポート” への1件の返信

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です