TestonoBlog

Softwaretest,QA

【JaSST'19】Tokyo2日間のまとめ

こんにちは!とのの@tonono2587です。
レポートをいくつかあげてありますが、先日3/27(水)、3/28(木)の2日間JaSST'19 Tokyoへ参加させていただきました。

tonono.hatenablog.com

tonono.hatenablog.com

tonono.hatenablog.com

本記事では、上記のようなセッションレポートでなく2日間を通したレポートにしたいと思っています。

そもそもJaSST(じゃすと)とは

JaSSTってなに?と聞かれても、いままで(なんだかすごい集まり)という説明しかできませんでした。
(聞かれることも説明することもほとんどありませんでした。。)
JaSST=ソフトウェアテストシンポジウム とのことですが、開催要項ページの力をお借りしてもう少し詳しくしていきたいと思います。

JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-開催要項

ソフトウェアテストおよびソフトウェア品質に関する技術をさらに発展させていくべく、今回もJaSST Tokyoを開催いたします。
参加していただいた皆様に、ソフトウェアテスト分野の最新動向に触れていただく機会を提供することはもとより、同じ興味を持つ仲間を作るきっかけとなるような内容となることを目指しております。
ソフトウェアテストに関して、国内最大級の催しであるJaSST'19 Tokyoで、テストの重要性や楽しさを体感していただき、次の日からの現場での活力に変えていただければと思います。

こうあるとおり、テストや品質に関する技術を高めようとするイベントである!と言えそうです。
ソフトウェアテスト の分野においては最大規模のイベントなので、
アイドルでいうなら「東京ドーム公演!!」みたいな感じで期待も盛り上がりも高い公演だと認識しています。

具体的な内容

公演は2Days、目玉は最初と最後にある「基調講演」と「招待講演」です。
間にはたくさんの「セッション」が並行していて、自分の好きなセッションを選んで参加します。(フェスみたい!)
わたしは今回

などを選びました。他にはテストマネジメントの話やキャリアの話、自動化の話、論文(事例紹介的な)など
参加したいセッションがたくさんありました。*1
目玉の基調講演は"AI-Driven Testing"(AI駆動テスト、かなぁ)、招待講演は"人工知能は何ができて何ができないのか"
どちらも最新技術のお話でした。

感想

"最新動向に触れる機会" について

  • AIや人工知能についてのお話があり、最新の情報にたしかに触れられた
  • メモはとったものの話についていけないところもあって、得た情報に対してどうにかすることはまだできなそうです。(AI/人工知能に関して)
  • 世界の事情や分野での最新情報を知れたことは大きい
  • 周りを知ることで自分(自分のいる会社/組織/自身)がいまどんなところに居るのかちょっとわかった気がした、考えるきっかけになった
  • 他のセッションでも、クロージングパネルでも、いろんなところで「小さく始める、実績をつくる」みたいなことはたくさん言われていた
  • とりあえずはじめて何か見える形にする、のがいまのわたしが一番はやく持ち帰って実践できる情報なのかもしれないと思った。
  • 時間がかぶっていてマネジメント系のお話聞けなかったので聞きたいーーー!

"テストの重要性や楽しさを体感" について

  • QA入門の内容はいろいろ刺さった
  • ちょうど、「テスト」だけじゃない「品質」について興味が高かったからかも
  • 品質のためのテスト、そのテストをうまくやるためのあれこれ…
  • 目指すもの(いいプロダクトにしたい!とか)に対してどこから攻めるか、道がたくさんあるっぽくてわくわくした

"同じ興味を持つ仲間をつくるきっかけ"について

  • 「ゲームのテスト」セッションでまさに"同じ興味だ!"と思った瞬間がたくさんあった
  • 業界職種違えどソフトウェアテストに関わる人はたくさんいる
  • このポエムがまた仲間をつくるきっかけになりますように〜

さいごに

がっつり2日間ありがとうございました。
刺激的で楽しい2日間でした。
参加できた環境や機会にとっても感謝しております。
なにかしらの方法で成果にしていけたらいいなと思います!!

*1:アンケートにも書いたのですが、動画版で売って欲しいくらい。

【JaSST'19】Tokyo2日目 セッションB5:ゲームのテスト

どもどもー!とのの@tonono2587です。
引き続きJaSST'19 Tokyoのレポしていきます。

参加セッション

2019/03/28(2日目)
三銃士モデルを適応してみた! -Next Generation 次世代の挑戦-

JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要

参加前の期待(気持ち)

  • ゲームのテストってなにしてるかわからん
  • 他の会社の方はどんなテストをしているのか知りたい
  • 自社テストのヒントにしたい

セッションのメモ

□三銃士モデルについて

”ゲームテストをする人がらくできるようにしたい” のがきっかけ

  • 世界観
  • コンテキスト
  • 実装 中心に「ユーザー感情」をおく

  • テスト観点を構造化する
     構造化するとやりやすい

  • テスト設計方法の提案
     組み合わせながら「設計していく」
  • テスト合否判定をユーザー観点を使って行う

テスト関心事
テスト観点
テスト値
テストフレーム
テストケース
→テスト手順

ゲームカテゴリごとに、お客さんが気にすることが違う

  • 観点・リスクから優先度づけして、アジャスト可能にしたい
  • まずは小さく!

Q&A

[Q]「ユーザー感情」の集め方は?
[A]
一般的に他と比べるとどうか?とか(最終的に数値化したいけど、)を組織ごとにまとめながらすすめていくのがよさそう
ペルソナを分けて考え、対象ごとのターゲットに合わせてわけたりなど

[Q]「保守の人」などのユーザー感情を考えるときは、中心を(保守のある意味"ユーザー"へ)置き換えたら出せるのでしょうか?
[A]
ここで指す「ユーザー」はエンドユーザーに近いので、保守性/メンテナンス性など技術的なところは”実装”のカテゴリに寄せるといいのでは?

ゲーム業界の○○テスト?!

品質管理グループ
→テストチームの管理などをしているところ

■ゲームテストの世界って?

取り組み(今回のセッション内容)のはじまりは「ゲームテスト設計の 国際標準化 したい!」ところから

ISO/IEO/IEEE TR 29119-10 Games Testing

これにつける付録とは?

  1. テストタイプ/テストレベル/テストフェーズ の体系化
    テストコンテナの作成??

  2. テスト観点の体系化?
    テストフレームの作成?

□ゴール
テストコンテナやテストフレームをつくって、ゲームテストを体系的にまとめる!

では、ゲームテストの”テストタイプ”ってなんだろう?

■研究会でやったこと

〇〇テストの洗い出し

  • プロモーションコードテスト:iOSアプリ限定、プロモーションコードを発行し、本番環境でテスト
  • コリジョンテスト:壁をすり抜けたりしないか
  • スキル検証
  • CBT(クローズドβテスト) などなど…

  • 「○○テスト」ってたくさんある

  • 他社でつかっている言葉で知らない言葉 があった

  • "おさわり会"

    • リリース前の新バージョンのアプリを(他プロジェクトの社員含め)社員がさわって確認する会。UI/UX
  • "乙女チェック"
    • 女性向けアプリを乙女の気持ちでテストする。ユーザー心理的に重大なバグがないかを探すためには乙女心を準備する!!

いろんな「○○テスト」がありました。

標準化への課題

  • ○○テストとは…の資料が社内に存在しない
  • 同じ会社でも認識が違うかも →自分の会社のテストについて、説明できるようにしよう!!

〇〇テストの分類

担当/担当部署・名称・目的…で分類していく
→テストにまつわる言葉が混在していて、整理が必要になった
(「○○テスト」はカテゴリAにもカテゴリBにも入れたい…)

○○テストの比較

「○○テスト」の名称、だれが、いつ、何を気にして、何を確認しているのか を確認することに

例)
- マスター差分チェック
マスターデータのダブルチェックのこと - 素材を確認するテスト 画像/3Dモデルなどの確認のこと

→次は 〇〇テスト を体系的にまとめてみよう!!

テストコンテナ

直近の取り組み
認識合わせが終わったので、テストコンテナをつくろう!!

コンテナ - 企画 - 開発 - クリエイティブ:素材制作チーム

などなど

  • テスト
  • 効率的な素材確認
    • 素材そのものの確認
    • 言語違い
    • 音割れ

他部署の内容がわからない… →連携していきたい

□テストフレームにいれたもの

  • 機能名
  • 条件、手順
  • 結果、アウトプット

Q&A

[Q]
「乙女チェック」について、うまくいく方法は?
どうやって乙女心をつけるのか?
[A]
表示崩れがただのバグなのに、乙女にとっては重大なバグ!=乙女心が足りない
→IPの勉強する時間をとって対策

[Q]
単語の違い、認識の齟齬は他社間だけではなく
外注の協力会社などとも合わないんじゃないか??
[A]
結局、認識合わせした

三銃士モデルを現場適用してみた!

【背景】

エンジニアレビュー済みのテスト項目なども終わって、フリーデバッグだけ、
というフェーズになって重大なバグが見つかり、リリースが伸びた
ということが(結構)あった

「フリーデバッグ」とは??
→仕様外の操作をしたりするテスト

課題解決

□解決のための動き

  • フリーデバッグの期間を伸ばす
  • フリーデバッグの期間が以前より早まった
  • テスターの増員

→でもこれだけではそこまで効果がなかった

□不具合を分析したところ…

  • 期待結果の記述があいまいだったので、OKで通っちゃっていた(そのためベテランしか発見できなかった不具合)
  • 機能の組み合わせが不十分だった(のでベテランしか)
  • 上流工程で予想しない操作をした(メインパスじゃない、特定のパス)(だったのでベテラン…)

□どうするか?

  • テスト手順書作成(実装):期待値の記述を徹底して対策する?
  • テスト観点組み合わせ(設計):十分に組み合わせて対策する?
  • テスト観点抽出:ベテランが出す?

→ベテランが対応する時間がない…

  • 上記をできるように人を育てる!

→やっぱり時間がない…???

人材育成が先か、教育方法が先か?

(にわとりたまご論争)

→じゃあテスト観点をマインドマップで整理したら??というアドバイスをもらった

□やってみた

「項目の粒度が作成者の力量に左右される」ことに対しては、
ベテラン作成者がマインドマップでまず観点を整理し、それを元に項目作成をおこなった

○よかった点

  • マインドマップを再利用できるようになった
    →機能ごとにメインブランチを切っていて、似た機能や改修などはそれをもとにちょっとなおせばすぐ使える

△注意点

  • マインドマップ」そのものに慣れてないと効果が出ない
    →結局なんなの?意味あるの?みたいに取られてしまう

((((((さわれるまでテストさせてもらえない状況をやめたい)))))))


Q&A

[Q]
ユーザー感情の閾値などを握っていく(組織内で納得して定めていく)コツは?
[A]
似たような事例をみて、こんな感じ、とコミュニケーションとっていく

[Q]
考えることはできても、それを実現できるスキル、人材はどうしたら?
スーパープレイ、このステージ○秒以内でクリアとか
[A]
技術・技能の話
別の観点での人材育成が要るのでは
ベテランの、技能面でのレベル感をみて、そこを目指すとか

感想

  • 認識合わせ大変そう
  • 認識合わせのお話から、どんなテスト(○○テスト)があるのかほんの少し知れた気がします。
  • 「乙女チェック」という強い言葉笑
  • ↑印象的でした。視点によって対応の優先度、重要度も変わるんだという話だと認識しました。たしかにそうだなぁ…
  • マインドマップすごくよさそう
  • (話すごく逸れるけど)やったことの記録とっておこうと思った

JaSSTレポはもうちょっとだけ続く見込みです。

tonono.hatenablog.com

tonono.hatenablog.com

【JaSST'19】Tokyo1日目 セッションD4:QA入門セッション

2019/04/01
どうもー!とのの@tonono2587です。
前回に引き続きJaSST'19 Tokyoのレポしていきます。
tonono.hatenablog.com

参加セッション

2019/03/27 (1日目)
QA入門セッション 〜トラディショナルなQAと、先進的なQA〜

JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要

参加前の期待(気持ち)

  • 仕事が「テスト」よりも「QA」が強くなってきたかも?
  • QAって?品質って?
  • 「入門」だしわかりやすそう!(フラグか?!)

セッション内容のメモ

前半 秋山さんより

■品質とは

  1. 要求への適合(By Crosby)
    1. 品質向上とはすなわち利益向上
    2. 要求には明示されたもの以外の暗黙的要求も含む
    3. 暗黙的:常識、潜在的なニーズ、期待、など
  2. 誰かにとっての価値(By Weinberg)
    1. 受け取り手を意識する(必ず誰かを想定する)

「価値」
お届けするものに価値があるのかを考えよう

■品質保証とはなんだろう?

「品質保証」という定義もひとによって違う?定義は難しい。
品質保証ができている状態とは?
「A社の車はぶつかっても安全」→"A社"にあてはまるのも人によって違ったりするが、何かをイメージできる状態

□演習しました

[問]
「○○の△△は、☓☓だ」を埋めてください
○○:自社名
△△:商品やサービス名
☓☓:提供している価値(広く信じられていることでも可)

”品質保証”:ブランド(お客様が信じてくれていること)
○○の△△は、☓☓だ
→☓☓が〇〇の△△に対して、品質保証できている”モノ”あるいは”コト”
→☓☓がかけなかった人は1年後にはかけるようにしましょう。(すぐには書けない)
→☓☓がかけた人はそれをもっとよいものにしていきましょう。:品質改善活動 と呼びます。

”品質管理状態”
ある事象が管理されている状態というのは過去の経験を使ってその現象が未来においてどのように変化するかが
少なくともある限度内で予測できることである
JIS Q9000 の品質保証の定義
JIS検索サイトで読める。

■品質保証とは(秋山さんの理解)

テストは基準を決めて実施するもの、テストは品質を映し出す鏡のようなもの
品質保証はそうではない。
お客様との約束を決めて、それに向かって社員ががんばること
なんの確信を与えるか、その確信を保証できているか

■品質保証活動のポイント

  • 顧客視点であること バグの数などで判断したりしない お客様にとっての価値があるかどうか
  • 組織的活動であること

商品品質:プロダクトそのもの
業務品質:仕事の仕方や活動の結果
企業品質:文化

□品質保証部の位置づけ

社長直下なのは(が多いのは?)なぜ?
 − 偉いからではない
 − 全社的に各部の品質意識が一致していなければならないから
 − みんなのベクトルを同じ方へ合わせなければならないから

□品質コストについて

品質の善し悪しはお金に換算しないと経営層は納得してくれない

■前半まとめ

  • 品質保証とは、ひとつの製品でなしえるものではない  - 信用やブランドのようなもの
  • 品質保証とは誰かの頑張りではない  - 全員がトコトン良い品質に向かって改善を続けていること
  • 品質とはバグゼロのことではない  - お客様へ与える価値にフォーカスすること
  • 品質保証とはお金持ちの企業だけ行う活動ではない  - すべての企業で行うこと

Q&A

Q:要求、価値を具体的にどうやって捉えたらいいのか?
A:常に言い続けて文化をつくるのがいいのでは

QAW:Quality attribute Workshop
みないといけないものを”品質特性”としてまとめたもの
自分たちの製品が、どの特性をどこまでもっているかはかる→数値化しないといけない
なにで計るか、どこまでを目標値とするかをQA部門でなくWorkshopで決めるもの
ADD (アーキテクチャドリブンデベロップメント) を行う(要素+構造)

中野さんより

17:41

  1. 新しいテクノロジーへの対応
  2. 価値基準の変化
  3. DevOpsのその先
  4. モチベーションを阻害しない組織へ

1. 新しいテクノロジーへの対応

AIでどう開発するのか?
それをどう評価するのか?
人間が行っていたもの、システムではないモジュールをAIが実行し、システム的なふるまいをすることに対してどう評価するか

すごく複雑な状況でシステムが動くとき、どうテストするか、評価するか

10年の間に没入型の、ユーザー体験が大きく変わる。
新しいユーザーインターフェイスをもとにシステムが提供されるでしょう。

ブロックチェーン:電子台帳管理→ミッションクリティカル性が高いもの
これに限らず他も高くなってきている

AI側の設計がまずいのか、データが悪いのか
なにをもって受け入れOKとするのか わからない!!!!!!

テクノロジーの進化により製品やサービスは(このあとなんて書きたかったんやろう…)

2. 価値基準の変化

リリース前の製品をテストすることと、顧客満足がどのように繋がっているのか、
ちゃんと考えられているのかどうか?
テストが十分であることをどうやって確かめるのか?

□製品品質から利用時品質へ

priority #3:ソフトウェア品質の基準が要件を満たしていること、製品が要件・仕様通りに動作すること
priority #2:市場やプラットフォームに、ウェブサービスならば検索エンジンに評価・支持されていること、競合に対して不足がないこと
priority #1:利用時品質やUI/UXなどユーザーにとって使いやすいシステムであること、優れたユーザー体験が実現されていること、デザインと利用時の品質要求を結びつけて考え実現できていること

3(製品品質)→2→1(利用時品質)

□利用時品質評価において課題になりそうなこと
- 認識の不足 - 知識の不足 行動や心理などの人間に対する知識が足りていないから評価できない

☆☆☆
製品品質だけでなく、利用時品質にも責任を持つために必要な仕組みを考え、評価軸を定義し、
組織全体で改善できるように取り組むことが重要だと思われる
☆☆☆

3. DevOpsのその先

DevOpsのコンセプトを実現するために、品質保証組織も取り組まなければいけないのではないか

□DevOps 実現に向けて課題になりそうなこと
- 当事者意識の不足 - 技術の不足

デプロイメントパイプラインにはテストの知識があるといいけど、見て見ぬふり感がある
どんどんパイプラインにのせてくけど、(テストに更新がなければ通ってしまうから)テストも都度更新しないといけなくて…
ということはテストの知識寄り
かといって構築を任されても対応できるQAは少ない

f:id:tonono:20190401231135j:plain:w500

☆☆☆
品質保証組織がDevOpsの文化の中でリリースの高速化やテストの最適化など貢献できる可能性がある。
さらにその先には構築した仕組みなどが技術的負債になる可能性も考えられる。
その上でそれらを踏まえた中長期的戦略を企てる必要がある。 ☆☆☆

4. モチベーションを阻害しない組織へ

QCD(品質・コスト・納期)や生産性を高めていくために品質保証と開発組織の関係はどうあるべきか?

案1:問題の発生を防ぐため、業務プロセスを細かく手順化し管理する(マイクロマネジメント型QA)
案2:自分たちのことは自分たちで考えて実施させ、不足や要求に対して必要なサポートをする(サーヴァントマネジメント型QA)

(会場アンケートでは案2:サーバントマネジメント型QAがいいんじゃないか派が多かったっぽいです)(わたしもー)

後半まとめ

  • 新しいテクノロジー
     →テクノロジーの進化は加速度を増していく、品質保証やソフトウェアテストにおいては恩恵も課題も存在する
  • 価値基準の変化
     →プロダクト品質だけでなく顧客満足のために利用時品質にも着目しサービス全体の品質を向上させる必要がある
  • DevOps
     →今後もさらにスマートなサービス・ツールによりDevOpsの文化は発展するが技術的負債になる可能性も導入時に検討が必要
  • モチベーションを阻害しない組織へ
     →品質面における今後の課題(課題になりそうなこと)が山積みの状況において
    ユーザー理解だけでなく開発にも目を向けて協力していく体制をつくることが不可欠
    開発組織のモチベーションを阻害することなく継続的デリバリーやDevOpsを推進し 現場が一体となって価値提供を続ける文化が求められるのではないか

セッションのさいごに

やりたいことは理解できるが、時間もお金もない!どうする??
まずは小さな成果を出す<上のひとの信用を得る<やりたいことを実現していく!

感想

  • 黙っていても売れるほどの"品質保証"を実現するのは大変なのに一瞬で崩れる場合もある…
  • それはたしかにーと思ったのですが、ひたすら努力するしかないのかな??("実績"の側面があるからやっぱりそれしかないのかー)
  • 企業品質の上に業務品質、その上に商品品質がのっている図をみて、「テスト」だけでない品質保証を少しだけイメージできた気がします。(商品品質だけをみるのは視野が狭いかも、という気づき)
  • デプロイメントパイプラインについて全然知らなかったのですが、図を描いてくれたので話が入りやすかったです。
  • 考えるばっかりじゃなくて小さくても成果にしなければ。

JaSSTレポは続きます…

【JaSST’19】Tokyo1日目 セッションA2:Joel Montvelisky氏に聞く世界のテスト事情

2019/03/27

お久しぶりです!とのの@tonono2587です。
JaSST'19 Tokyo の1日目に参加してきました。
セッションA2に参加したので個人的にレポります。

参加セッション

「テストの現状調査レポートからテストの将来を考えてみよう~ Joel Montvelisky氏に聞く世界のテスト事情 ~」

JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要

参加前の期待

  • 「世界のテスト事情」を知る機会がないので聞いてみたい!
  • テストの将来についても気になる
  • 翻訳がある安心感

セッション内容のメモ

予稿集p49〜とメモを見ながら簡単に振り返ります。

第一部:テストの現状調査2018レポートの紹介(日本語翻訳チーム)
第二部:世界のテスト動向、テストの将来(Joel Montvelisky氏)
第三部:パネルディスカッション ~Joelに聞いてみよう~

辰巳さんより:テストの現状調査2018レポートの紹介

  • State of Testing という、ソフトウェアテストに関する調査レポートがある
  • そのレポートの日本語翻訳チームがある
  • レポートに書かれている内容
     - 調査の回答者の分布(国とか職種(呼び方?)とか)
     - テストチームの位置づけ
     - テストプロセス(開発モデルや自動化の状況など)
      などなど
  • レポートのなかで、「スキルを磨くための知識の情報源」について、2018年は「やってみる」が1位だった。(前年度までは回答の選択肢になかったもの)

Joelさんより:世界のテスト動向、テストの将来

■テスト動向を知る ことについて

  • 普段大西洋の風向きなどは知る必要はないけれど、旅行に行くとか、
    飛行機・船で行くときなどにはうまくたどり着けるかどうか知るために、
    風向きなども知る必要がある。
  • 「テスト」をビルに例えると、わたしたちは同じビルで働いていて、
    たとえビルの中に居たとしても、風向きや雨が降ったりなど、外の様子は気になると思われる。
    それらと同じで、世界の動きは気になると思います。

  • よく聞かれるのは、「テストは死ぬのか?」とか「自動化で職は失われるか?」ということ

  • そんなことはないと思っていて、実際テスターは増え、テスターとしての職務期間も長くなっている
  • ひとつのプロジェクトあたりテスターが1人~5人とかで、1人・2人というところもよくある。
  • だんだんチームは小さくなっていっている

■どのようなテスト手法が使われているか について

  • スクリプトテスト」の回答割合が2018年に一時的に増加した
  • それはたぶんデベロッパーのためにテストケースをかかないといけないから、スクリプトテスト担当の人が増えている

■これから身につけておきたい新しいスキルについて

  • 技術的なスキル(自動化やホスティングなど)
  • ソフトスキル
     - コミュニケーションスキル
      →もっとも重要なスキルだと答えるテスターが多かった
      →一番難しいのは「人の話を聞くこと」
  • 手法に関する知識
  • お客様とのコミュニケーション
  • データ解析のスキル(今後入ってくるスキルになりそう)
  • おすすめなのは、コミュニティのメンバー同士でどのようなテストをしているかお互いに話して、学ぶこと
  • 調査には「将来どれだけ心配か?」という設問を設けているが、どちらかというと安心して仕事に取り組んでいる人が多い
  • やっぱりテスターが消滅することはなさそう
  • ただし、将来に対して変化していくことは必要

パネルディスカッション: ~Joelに聞いてみよう~

・役割の変化について
・組織の変化について
・技術の変化について

■テスト組織と品質組織の変化

  • 開発モデルにおいては、Agileがメインストリームになっている
  • 小さい単位でコンパクトな開発をする傾向が強い
  • バグの報告先が、独立した品質組織だったところからプロジェクトマネージャーへ変化している
  • 独立したテスト部門だけど、各プロジェクトへテスターが参加し、1~2週間のサイクルでまわしている。

[Q しつもん]
10~15年後には「独立した品質保証部門」は不要になっていくか??
(その部門マネージャの仕事は将来どうなるんだろう?)
[A こたえ]

  • 日本に限らずある問題だけど、地域によって進展度が違う
  • 企業は利益をあげなければいけない
  • 昔は、お客様へ納品し、納品したあとにバグがみつかるとコストがかさむから、という世界
  • いまはスピードをもって利益をあげなければならない これが鍵!
  • すべての環境に専門組織が必要になるわけではない
  • 外注で進めている会社なら、(大きい会社なら、)自社に持ち込むための専任チームはまだ必要

■テスターの役割の変化

[Q] (Webほどスピード感の必要ない、)ミッションクリティカルなシステムにおける10~15年後のテスターのロールの変化をどう考えますか?

[A]

  • それぞれの状況に合わせて、より効率的に、早く、やるにはどうしたらいいかを考える?
  • プロダクトを提供しているわけではなく、サービスを提供している集団である
  • サービスを提供するのは複雑で、ニーズがあるのか、またそれぞれのニーズに合わせてカスタムしていく必要がある
  • これからはよりよいテストの方法を考案していくことになりそう。
  • はやく、よく、安価にテストする方法を考えていかないといけないんじゃないか?
     →「忍者式テスト」をやってみています:探索的テストを毎日少しずつやる

  • 探索的テストは非常に優れたツールだが、大きなツールの一部を担っているにすぎない

  • 他のものとの組み合わせ

■テスト技術の変化

  • 開発スピードが上がっているが、テストがついていけてない
  • 他業種との協業

□希望/期待

  • テストにも高度な技術が必要であることを上位層が理解している
  • 当たり前の技術が当たり前に(探索的テストを知らないとかはなく、知っていることが当たり前になってほしい)
  • 東海地域の活発なコミュニティ活動

[Q] コミュニティ活動を知ってもらう、アンケートに回答してもらえるような 外へ向けたものにするにはどうしよう?

[A]

  • 経営陣はミラクルが大好き!外部のコンサルに説得されてしまう(ただし、みんな大失敗)
  • Agileがひろまったとき、「テスターがいらない」とは誰も言っていない。反対のことを言っていた
  • 「継続的なテスト」が必要。テストドリブン
  • 新しいものの価値を、知らない人に知ってもらうには…という話はにわとりたまご論争と同じになってしまう
  • 伝えたいときは、まず導入して見せるしかない
  • 自分自身がどういった環境に飛び込んでみる!
  • 事例を導入する

コロンブスは「東のルートがある」ことを発見した。それをどの国で説明しても、だれも信じてくれなかった。

最終的にコロンブスは実行(実現/実演?)した。それと同じことをやってもらいたい

Agileの考え方と同じで、失敗するならやってみてはやく失敗しろ という考え方

さいごにメッセージ

大きく変わっていく、と認識することが大切
日本は伝統的で、何かをするには非常に時間がかかっていたけど、いまの日本はそうではなさそう

目を見開いて分析をおこない,どういう変化が起きているのか、自分はどういう変化をおこさないといけないのか考えよう

変化を生もう!!

参加した感想

  • レポートがあることを初めて知った…!
  • 今日お話にあった内容以外も気になるのでちゃんと読んでみたいです。
  • やってみる!が大事
  • 翻訳めちゃくちゃわかりやすかったです
あとがき

すごくメモです…ねむいのもあるので後で読み返してこっそりなおしたりするかもしれません。
明日も参加できるのでがんばります!!
他のセッションについても"メモ"になってしまうかもですが上げたいです。

DeNA QA night 招待講演のメモ

こんにちは、とのの(@tonono2587)です。
2018/11/27に参加した勉強会メモをいまさら(ほんとうにいまさらですが)振り返ってまとめておこうと思いました。

今回のテーマ:DeNA QA night に参加しました

参加したイベントはこちらです。
dena-qa-night.connpass.com

セッション概要にある、

品質の対象の変化とその手段であるテストにどんな変化が生じ,どこへ向かっているのかについて

キャリアについて考えていたこともあり、興味がある内容だったためお話を聴きに行きました!
|´・_・`)。oO(以下、必死にとったメモベースなのでお話そのままではないことご了承ください。)

招待講演「テストの広さと深さ,どっちが大事?」松尾谷 徹さん(デバック工学研究所)

概要

  • 市場の変化、技術の変化がある
  • それにともないQA Peopleは分岐
    →QA難民
    →Contoributer(コントリビューター):○こうなりたい
    どうしたらContoributerとして繁栄できるのか?

  • 誰に対する品質?

  • どんな品質特性?
    相手側が「社会」になってきて、
    社会に対する品質を考えなければならなくなってきた
    現在のサービスはそのくらい大きく影響している

  • それをどうやって測る?

  • どうやったらどんな変化をする?
  • 大きな流れを読む

Analysis:虫の目、細かい
Synthesis:鳥の目、ひろく←これからはこちらが広がっていく

  • どんな心意気で何を学ぶのか
    古いものは残念ながら捨てないといけない

市場の変化からみる

■これまでの流れ

□IT大昔(バブル期まで)

  • ハードウェアを売ろうとしたけど、ソフトが難しいのでなかなか売れない
  • そこで多くの企業は組織/企業活動の合理化をすすめた
  • ハードウェアの検査部門の人たちが中心となって、ソフトウェアの品質をみていた
  • たとえば I○Mとかは、品質管理部は「品質が悪いから」ではなく、社内を監視するために存在していた意味が強い
  • このころ本格的なアプリケーションのテストはあまりなかった

IT大昔の市場構造は、汎用機メーカーが主なプレーヤーだった

□ITちょっと昔(サブプライムまで)

  • カーナビやケータイなどの組み込み系ビジネスが増えてきた
  • そこからだんだんWeb系へ:ホームページみたいな小さなものから、Amazonみたいな大きなものへ
  • 汎用機ビジネスが終わり、水平分散してく
  • Web系の新ビジネス
    急激な成長、裾野の拡大

  • このころの品質管理は、
    負け犬の遠吠え
    品質工学で成功したところはひとつもない
    「正しい」ってなんだろう?
    それをどう評価するか???
    大事なことなどはあとからいろいろ言われているが、うまくいってなかった

□現代

  • 提供側と消費側(お客さん)
  • 消費側が「このサービスを使う人」くらいの狭さから、スマホをつかうひと、のように広く大きく、「社会」になっていっている
  • プロダクトとしてのソフトウェアは終末状態
    単独のソフトウェアをつくってもビジネスにはならない
  • OSSの拡大
    企業の開発戦略が背後にあり、開発していく
    マネタイズの戦略変化
    →知識をどのようにしてお金に変換していくか?になっている
    単独のソフトウェアでは、要求に応えられない
    オープンソースをつかおうとおもったら、自分もオープンソースにならないといけない
  • サービス型ビジネスの繁栄が桁違い
    GAFAによる世界制覇

  • ソフトウェアマネタイズが変化したので、
    品質のパトロンはだれ??
    G○○gleってなに業なの???
    どんどん自転車操業しないともたない時代

技術の変化からみる

■「良否の判断」をなんらかの形で判断しないといけない

  • いままでは、正解は仕様書だった
  • もうサービスには仕様はない。考えていかないといけない
  • 過去、テストの実態は仕様記述だった!
    禁則
    ただし、大多数は「無則」。ここがどんどん増えてきた
    いまはそれが「無害」であることも考えないといけない

■良否の判断における多様な課題

  • 社会や文化に対する品質
    なにが有則、禁則、無則 か?
  • OSSに対する品質
    バグがあっても、使う側の禁則で回避する
  • システムの稼働品質

QA難民にならないためには??

Contoribution がキーワード

  • 評価自身もオープンにして、どのくらいContributeしているか
  • みんなで公平に働こう、という時代ではなくなってきた
  • 日本人は持続的に何かをすることに長けている
    なんでこんなに貢献できたか?
  • 映画の配給とかと一緒で、多くは「べき分布」になっている
    売上はものすごいけど、殆どが上位5つ、とか

お話のまとめ

  • headに対するContributionとしてのQA活動をしてく
    head⇔tail
  • 一夜にしてサービスを崩壊させるリスク対策
  • 過去の価値観は捨てる
    捨てる代表は規範やプロセス定義
  • たくさんの対象がべき分布
  • メンタリティとしての推進力はFlow!
    ポジティブ心理学
    ワーク・エンゲイジメント
  • (ISOとか、品質特性について)いままでにある枠組みでは、いまある規範、定義では測れない
    なので捨てる
    現実のものからはかったほうがいい
  • 全体をみる鳥の目が要る
  • 当たるものをサポートする問題、ハズレを抑える問題に
  • プロダクトの品質は、「品質」の概念が変わってきた
  • 情報やサービスの品質は、
    お客さんへの品質保証
    安定供給:インフラとしてのクオリティ
    社会や文化に対する品質

感想

個人的には、「品質の対象が変化している」ことがわかりやすかったです。
その変化を前提として、「合わないものは捨てる」という話はスッキリ入ってきました。
今回のお話とは逸れるかもしれませんが、
業界全体を広く見られる世界地図みたいなものがほしいな〜と思ったり、
一方で「この雑誌読んどけば大丈夫!」みたいな情報が一箇所に集まったものってないのかな、と思ったりしました。(Software Test Pressはもうないしな〜)
JaSSTがそういう役割なんでしょうか。(ネットだと検索ありきだし散らばってるのでイメージとちがう)
「QA難民」にはなりたくないです!(>_<)取り残されないためにも鳥の目が要ることを実感したうえで、
虫の目と上手く切り替えできていくひとになっていきたいなと思いました。

このテスト本が好き!2018

こんにちは、とのの(@tonono2587)です。
こちらはソフトウェアテストの小ネタ Advent Calendar 2018 14日目の記事です。

ソフトウェアテストの小ネタ Advent Calendar 2018 - Qiita

前日はオムそばさんのこちらの記事でした。

teamomusoba.hatenablog.com

今日は、いままでわたしが出会ったなかでもお気に入りのソフトウェアテストを 紹介したいと思います。

今回のテーマ:とののお気に入りのテスト本

  1. お気に入りテスト本との出会い
  2. お気に入り本!!
  3. まとめ

※ランキングとかじゃなく、ただただ好きな本です。
早速いってみましょー(^o^)ノ

お気に入りテスト本との出会い

はじめに、わたしのテスト本読書歴を振り返ってみます。
どんな本を読んだか整理したかったので、ブクログでを本棚つくってみました。

booklog.jp

ここで本を並び替えながら振り返ると、以下のような感じで読んできたことを思い出しました。

時期 探し方
テストをはじめて数ヶ月 とりあえず会社にあったもの
テストをはじめて1年くらい 図書館の検索で「ソフトウェアテスト」に引っかける
アウトプット覚えてきたころ -(同じ本をじっくり)
設計モヤモヤ期 モヤモヤに関係する単語でも検索
知り合いのおすすめ
最近 モヤモヤ期と似た感じで、おすすめや気になる単語で検索

あまりたくさん読んでいるわけではないですが、いろいろ試すうちに少しずつ自分なりの本の選び方ができてきている感じがします。

お気に入り本!

そんななかで、お気に入りなのはこちらの本です!


ソフトウェアテストの教科書』

おすすめポイント

  1. わかりやすい
  2. 練習問題がついている
  3. 手に入りやすい

1. わかりやすい

この本の帯にもありますが、「世界一わかりやすい」くらいやさしい文で書かれていると思います。
個人的には、翻訳じゃないところが大きいのではないかな、と思いました。
ソフトウェアテストに関する本は翻訳のものも多くて、はじめは頭に入りづらかった思い出があります。。
この本は純日本語(?)で書かれているので安心して読めました。

2. 練習問題がついている

なんと、テスト技法の最後に練習問題がついています!
初心者の頃って経験があまりないので、技法の説明を読んでも実感しづらく、つかうイメージが持てない気がします。
読むからには自分のものにする感覚がほしい!業務につかいたい!でもつかいかたわからん!!
この本だと技法ごとに練習問題がついているのですぐ試せるし、「つかった」気持ちになれるところが好きです!笑

3. 手に入りやすい

テスト本はいい本がたくさんあるので、古くてもう本屋さんに置いていなかったり、
置いていても高かったり。。という本もあります。
これはお値段もそんなに高くなく、本屋さんにも置いてあることが多いし、近くの図書館にもあったので
他の本に比べて手元に来るまでがスムーズだったなーと思っています。
あとあと、分厚すぎず大きすぎないところもいいなと思います。
分厚すぎて圧に負ける、初心者あるある…(あるよね?)

まとめ

読んできたなかでのお気に入りの本の話でした。
お気に入りポイントを3つあげましたが、社内で技法の勉強会をしたときに何回も読んだので、思い入れがあったのかもしれません。
ブクログ積読も管理できたので、あのときさっぱりだった本とかにも再チャレンジしたいなと思いました!!
教科書、まだ読んでいないかたはぜひ!




明日は@yoshitakeさんの記事です! 15日目へつづく… qiita.com

『間違いだらけの設計レビュー』からの学び

お久しぶりです、とのの(@tonono2587)です。
本を読みましたので学びをおいておきたいと思います。

今回の記事はソフトウェアテスト Advent Calendar 2018 2日目の記事です!

ソフトウェアテスト Advent Calendar 2018 - Qiita

記念すべき初日の記事はぱいんさんの

テストエンジニアに求める3つの姿勢 (2018/12) - 飴ブロ(仮

でした。ではさっそくいってみましょう!

きっかけ

以前レビューに関してもやもやしたことがありました。

もやもやについて

  • とののがつくったテストケースのレビュー
  • テスト対象は機能追加されたアプリ
  • ドキュメント1:機能の要件チケット
  • ドキュメント2:画面仕様書(いつもの他プロジェクトより粒度粗め)
  • 開発からテストまで1週間強

わたしの思いは、

  • 「要件が実現されているか」のテストになるよう、そこにいちばん気をつけてケースにした(つもり)
  • 細かい挙動確認は実装を見ながらやるしかないかなー
  • テストケースは納品しないし、自分しかテストしないし、整理と記録のためにつくろう
  • とはいえ自分にしかわからないのはまずいな
  • いつものテストケースフォーマットに沿って整えよう

こうしてレビューしてもらったところ、思っていた以上にえらい数の指摘が返ってきてしまいました。
サクッと終える軽い気持ちだったので、たくさんの指摘にしょんぼりしてしまいました。(´・ω・`)

  • たくさんコメントついちゃった。。
  • 内容は理解できるけど、なんか納得できないなぁ…
  • これ全部なおさないといけないのかな
  • 細かいとこなおすよりテストはじめたい。。

もやもや。。。

本との出会い

このもやもやがかなりあって、それについて(話題は「プロセス改善」でした)オンライン飲み会で話を聞いてもらいました。
そのなかで、「レビューアの机の上にこの本置いてみたら?」とアドバイスをもらいました。
タイトルと「机上にそっと置く」から察するところはありましたが、実行するにもまだ読んだことがなかったのでとりあえず読んでみることにしました。

読んだタイトル『間違いだらけの設計レビュー』


本の内容

簡単にいうと、
間違ったレビューをしていませんか?しかも間違ったやり方をそのままにしていませんか?
どうしたらレビューを改善できるのでしょうか、という内容だと理解しています。

1章では現場で起こりがちな「間違い」の例を、
2章ではその対策として効果的なレビューの手順を 準備から問題検出 まで、
3章ではその続きの 問題指摘から修正 まで
4章でレビュー自体の改善、見直し方法

が書いてありました。

読んでみて

もう1章からめちゃくちゃ刺さりました。
ここであげられている間違いレビューの例が、わたしのもやもやと似ている気がしたのです。
例えば、典型的な間違いレビュー「思いつき」「数字合わせ」「つるし上げ」について。

【思いつき】
レビューアーごとに観点がバラバラ。誤字脱字のような軽微な問題が多くなる
重要な問題の指摘が少なくなる

【数字合わせ】
問題の指摘件数ばかりに注意がいく、指摘件数でのみ管理する
重要な問題の検出が疎かになる

【つるし上げ】
指摘するうちに作成者への人格攻撃へエスカレートする
つらい

ここで言われていたのはどれも、レビューの目的を見失っているということでした。

もやもやへの光(振り返り)

レビューアの名誉のためにも断っておきたいのですが、
内容にわかりみが深いというだけで、実際に(このようなつらい思いを)経験したわけではありません。
この本を読んで響いたのは、レビューの目的を見失ってはいけないな、ということです。
もやもやを振り返ってみると、

  • たくさんコメントついちゃった。。
      →大きなヌケモレがないか、「ざっくり」みてほしいとのの vs 「きちんとしたドキュメントであるべき」レビューア
  • 内容は理解できるけど、なんか納得できないなぁ…
      →レビュー目的の認識がお互いに合っていない。とののからきちんと共有できていなかった。
  • これ全部なおさないといけないのかな
      →認識がズレたまま無理やりレビューの流れだけ進んでいっている。。
  • 細かいとこなおすよりテストはじめたい。。
      →時間が短いからサクッと終わらせたいことも共有してない。大事なことはなんだっけ??

他プロジェクトで「レビュー→なおす 」のある程度決まった流れがあったからこそ、なにも考えずその流れに乗せてしまっていました。

どうしたらよかったんだろう?(反省)

まずは、目的の共有をすべきだったと思います。

  • 背景や状況(期間短い、サクッとやりたい)
  • いつもと違う(形式はゆるくていい)
  • ここを見てほしい!(ヌケモレがないかチェックしてほしい)

目的の認識合わせをしたうえでそれでもズレてしまうなら、こういう意図だったんですが、という説明もできたなぁと思います。
(今回はズレていることもわからずもやもやという形で残ってしまいました。)

まとめ

これを読んで、わたしなりの学びは以下のようになりました。

  • レビューの目的を見失うと、つらいレビューになる
  • 悲しいけど目的喪失はよく起こる
  • 見失っていないか常に気をつけよう!!

この本には他にも 目的を見失ってしまった失敗例や、
失敗を起こさないための効果的な手順 がのっていたりします。
「問題検出」と「問題指摘」は別、とか
ネガティブなマインドを持たないことは「心がけ」ではなく、レビューアに必要な「スキル」です。とかとか
納得できる内容盛りだくさんでした。

  • レビューでつらい思いをしたことがある方
  • レビューがうまくいっていない自覚があるレビューアさん
  • レビューにネガティブな感情を連想してしまう方

ぜひ読んでみてはいかがでしょうか。


さいごに

本は机へ置かずに済みました、ありがとうございました。
アドベントカレンダー3日目へつづく…
ぷったーさんお願いします〜(^o^)ノ http://yoshikiito.net/blog/

qiita.com