JaSST'15 Tokyo クロージングパネル「テストエンジニアとデベロッパーとの幸せな関係」
JaSST'15 Tokyo のクロージングパネルを聞いていた時のメモが出てきたので記しておきます。テーマは「テストエンジニアとデベロッパーとの幸せな関係」でした。
このパネルを聞いて「開発とQAは対立するものじゃなく、一緒になっていいものを世の中に出そうぜ」っていうチームなんだよね、って改めて考えました。そのための共通言語としてコードで話ができたらカッコイイよね。
...もっとちゃんとしたまとめがこちらに公開されてたのを今気づいたデス。
- テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（前編） JaSST'15 Tokyo
- テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo
※(さ)は私の感想です。★は私がいいなーと思ったところです。
チェンジビジョン 平鍋さん
- アジャイルのワークショップをテスターがやっていた。@アメリカ
- キャンディの話
- 開発者がテスターに聞きに来た時にキャンディをあげる
- 距離を近くする
- 人と人の距離を近くすることがアジャイルの本質
- 上着のジッパーの話。開発とQAを理解の食い違いを早い段階でなくしていく
- テスト側、開発側、と別れない方がいい
- (さ)アジャイルとテスト、が近づいている？
ACCESS 松木さん
- これまで
- テスティングは品質保証の主要な一部
- バグレポート中心の（devとの）コミュニケーション
- これから
- 開発チームの生産性を向上させる役割
- これまでのQAはなくならない、広がるイメージ
- 効果的なテスト自動化
- (さ)自動化じゃなくてもいいから「技術でテストできる」といいのでは？テストコードだけじゃなく。
- テスト実行環境を簡単に増やせる技術
- 非機能要件には高いスキルが必要
- ペネトレーションテスト
- アタックテスト
- これらにもツールができている
- コードが書かれてからお客さんに届くまでを早くすることにテストエンジニアがかかわる★
- (さ)具体的には？DevQUTのこと？
- DevQUT
- Communicatization（造語）
- 仲良くする、コストが下がる
- 開発と普段から話をする → 自信があるところないところとか優先度
- ユーザーと近くなる→ユーザーコミュニティとか製品についているフィードバックシステムをツールとして使って、開発に届ける
- (さ)ユーザーヒアリングとかにQAが関わるとかかな？
サイバーコネクトツー 八田さん
- ゲーム業界から見ると難しい話
- 品質保証の違う点は「バグがないこと」と「面白いこと」を求められる
- ゲームの仕様を決めるmtgに積極参加
- 仕様を早く把握することをチェック内容を予測できる
過去のバグ経験を元にして、実装チェックリストを開発者と共有
- 開発者に依存することなく過去バグを未然に防げる
Q:テスト技術の進化によってDevとQAの関係が変わってきてるのでは？と思っていたが、技術よりも距離を近くする、ということ？
- A:ゲーム業界も新たなハードが出たりして大きな変化はある。その中で求められるのはいかにDevとコミュニケーションとるか。不具合を出さないようにするか。がメイン。
- 新しい技術を完璧にデバッグするのは難しい
- Devが持っている情報をもらう
- 平鍋さん
- QAが仕様に入って一緒に決める、というのはゲームのほうが進んでる
- ビジネスの構造が違うのかもしれない
- QAの発注の仕方とかどう？
- 八田さん
- 人月で頼む。デバッグ会社に開発後期に頼む
- 社内にQAを置くことで早くから関わる。その後に外注と提携
- プロジェクタにデバッガをアルバイトで雇って、終わったら解散、が最初
- その後に社内にQAを作ろう
- ノウハウをためて開発者から頼られるようになった
- 野中さん
- 技術面でこうやったらもっと距離が縮まるよ、とか
- 松木さん
- 上流におけるQAの取り組みとしては、開発者とコミュニケーション取りながら、はそれがいい
- 下流では、ターンアラウンドタイム(バグが埋め込まれてから、発見されて、報告されるまでの時間)をどれだけ短くできるか。
- (さ)この考えを広めて社内でも具体化したい。実装直後にテストが書かれてるとか
- コード書いてその場のレビューで言われたらすぐ直せる
- 実装後3週間立って言われても遅い
- そのためには
- 機能テストを自動化すると大変。メンテが。
- ユースケーステスト、シナリオテストのような、「ユーザーはこうするよね」だけで自動テスト書く+CI
- QAと開発者が距離を置いちゃうは品質を神格化しているから
- 品質はよくわからないので怖がる。尊敬してる
- それをわかったようなQAを司祭として扱う
- もっと近いものにする
- 品質特性の中から何が大事かを、定量化に早く返せるようなツールを仕組みを作ってる★
- (さ)なにそれ？
- 平鍋さん
- 出荷判定会議が怖かった
- 有無をいわさず最高品質を届ける、という宿命
- Boltonさん
- 開発とQAの距離を縮める、について
- お互いの尊敬はキャンディではなく、お礼の気持で成り立っている★
- 大事なことがあって、技能を持って正確に伝えることができれば、devから聞きに来てくれる
- 品質を定量的に表現することに抵抗がある
- 何故かと言うと、数字を体現するものであって、数字そのものが何かを意味するものではない
- 厳しい会話を回避するための方法では？
- 難しい話し合いでもうまく対応する方法がある
- 自分自身のことを表現することは勇気がいる、勇気があると前に進める
- ターンアラウンドタイムを短くすることに関しては誰もが質問する
- PGをコードを生成することに責任を持つ？それともうまく動くコードをに責任を持つ？
- PGが機能するコードを書くことを責務とするならTRTIMEは長くなる
- フレデリックいわく2006@インド
- 完璧なコードをPGが生成することを期待はされていない
- こういう動きを確認しました、を言えることを期待されている
- テストとチェックの違いを分けて考える
- PGは書いたらすぐにチェックをする。
- PGに対してこうしろあぁしろというのは違う
- 言葉としてQAを使うのは嫌い
- 製品の質を高くすることは、プロジェクト全員の役割だから
- testerとしてはコードもスケジュールも予算もスコープも出荷日も出荷判定もコントロールできない
- このなかで、品質を確約することはできるのか？
- これらの権限をもっているのはデベロッパーやマネージャ
- 本当はこれらが「QA」
- testerとしては彼らに今の状態がどうなのかをわかるようにする★
- そのためには
- ソフトウェアは人々のrelationshipsでできている
- PGとQAを物理的にも近くする
- フロアレイアウトを変えてでもそうする
- コミュニケーションの一部がコード
- プロジェクトは常に時間との開発
- これまでに作ったことのないものにチャレンジしている→不確定
- 時間との戦い、ミスも起こる。自然なこと
- 短い時間で何かを学ぶ必要がある
- だれも実現してないことをやろうとする
- ソフトウェアは人々のrelationshipsでできている
- 開発とQAの距離を縮める、について
- 八田さん
- 平鍋さん
- QAがどのユーザーを巻き込むか、をアジャイルに取り込んでいるのは聞いたことがない
- 伝統的なQAは欠陥がないかをみる。
- ゲームが「面白いか」をQAが見るのは品質の定義が広がっている感じ。(すごい、という意味で)
- Boltonさん
- 使うことが「楽しいかどうか」を質問するのはいいこと
- ユーザーに「感情面」を聞くのは重要★
- 使いやすいかとかだけじゃなく
- 目的を達成できているか、とか
- (さ)そうなるとフロントエンドの動きとか、表現が大事って気がする。「体験」をどこから感じるか。。。
- 実装する人とテストする人はマインドセットが違う
- 作った人とは別の人が外の視点からみること
- 八田さん
- （QAをおいてうまくいった話だが、QAチームがなかったらどうなったか）
- その分PGを増やすことになったと思うが、テストをすることに手は回らないと思う
- 平鍋さん
- Boltonさん
- 45年前にすでにウォーターフォールはうまくいかない、と言われている
- 松木さん
- (テストを別組織にするべきかどうか、その場合何をするか)
- テストをする人は開発者の中
- テストのマインドをもった開発者
- チームが目指したい形と、そのチームを包含する組織(会社)の目指したい形が違うことがある
- 会社が目指す形にあっているかどうかを確認したい場合は開発からQAを別にしたほうがいい
- QAとマネジメントの違いはなにか？
- 組織として表現したいビジョン→マネジメントがもつ
- QAはそれがそうなっているかをチェックする部隊
