yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

connpassでは中止操作をする前に、イベントタイトルやイベント情報を編集したほうが良い

この記事は?

q-te.connpass.com

今週の火曜日(2019/8/27)、19:00 ~ 上記の勉強会開催予定でした。
しかし悪天候で電車が止まるかなぁといった心配もあったためイベントを中止しました。
ふりかえってみると中止の判断は正解だったなぁと思っています。

ただ主催イベントを中止するのが初めての経験だったので、ここに気をつけること(特にconnpass操作)について書きます。

connpassで中止操作する「前に」やったほうが良いこと

以下2点です。

  • イベントタイトルに【中止】などの文言を入れる
  • イベント本文にもでかめに【※ このイベントは中止になりました】などの文言をいれる

connpassでの中止操作について

f:id:yoshitake_1201:20190830194219p:plain

イベントの編集画面のヘッダー部分に「イベントを中止する」ボタンがあります。
クリックすると、こんな感じのModalが出てきます。

上記にも書かれているんですが、イベントを中止してしまうと編集操作が一切できなくなります。
■ できなくなる操作
- イベントタイトル
- イベント本文
- 参加枠や会場などなどの編集

↑以外は、普通にイベントが終了したときと同じようにやることができます。
以下の操作はイベント中止後も問題なくできます。

  • イベント関係者へのメッセージの送信
  • 申込者の管理(CSV出力など)
  • イベント統計の閲覧

今回中止を決定した後やったこと

  • connpassのイベントタイトルに【中止】と入れた
  • 参加者に中止連絡を送った(connpassの機能で)
  • Twitterで中止の拡散した
  • 参加者が10名程度だったので、connpassに連携しているアカウントを調べてDMした
  • 個別連絡できない人もいたので会場で待った
    → (結局誰も来なかったので良かった!)

おわりに

せっかく企画したイベント(勉強会)を中止するのは結構勇気がいると思います。
安全第一だと思うので、強行しない姿勢は大事と思います。

JaSST'19 Tohokuに参加してから3ヶ月経とうとしている #jassttohoku

この記事は?

2019/5/31に行われたJaSST'19 Tohokuに参加してきました。 本当は参加レポートを書こうと思ったんですが…タイミングを逃し(笑)
なのでこのブログでは、JaSST'19 Tohoku参加後、取り組んでいることを書きます。

イベント概要

開催日: 2019/05/31(金) jasst.jp www.aster.or.jp

リスク分析をチームで始めた

始めようと思ったきっかけ

www.slideshare.net

基調講演で株式会社Freeeの小山さんから「リスク分析」のお話がありました(講演資料P53 ~ P64)。
講演を聞く前までの自分の活動を振り返ってみると、これまで個人では、プロダクトリスクやプロジェクトリスクを自分の頭の中でなんとなく考えてはいました。
そしてその結果、なんとなくテストやる順番を変えたりもしていました。
チーム(テストチーム2名体制時)では、不安に思ったらその時会話 & 共有をしていました。
それはそれでとりあえず良かったんですが、個人のしかも頭の中でなんとなくやっても、何も残らないなぁと講演を聞いて改めて思いました。
せっかくならなにかやった結果残したほうがいいですし、頭の中から外へアウトプットすることでより整理できると思いますし。

なので、講演を聞いた後テストチーム(現在は3名体制)でリスク分析を時間を取って始めることにしました。

やり方

リスク分析のやり方(フォーマット)は小山さんの公開資料のものを参考に「リスクの分類(種類)」と「いつ起きるのか」を付け加えてみました。 残りの項目は丸パクリです(笑)。
小山さんの講演資料ではFreeeさんで使っているリスク分析のフォーマットを載せてくださっていたので、どうやるのか具体的にイメージしやすくとてもありがたかったです。
以下使っているフォーマットです。
テスト開始前にテストチームで集まって「なにか不安なことない?」と雑談しながら不安(リスク)をシートに書く → なんとなく発生確率と影響度を書いてみる → それぞれのリスクに対するアプローチを決める と言った流れで行っています。

f:id:yoshitake_1201:20190826095708p:plain

やってみた結果

チームでリスクを確実に共有できる時間がある、共有できる、というのがとても良いですね。
不安を共有する際、他のメンバーが同じことをあげると「やっぱりそこ不安だよね」とリスクに対する認識が強まりますし、違うことをあげると「あ、そこ気になるのか」と視野が広がりますし。
それから、ここであがったリスクに対策をしていたおかげで、実際にリスクが発生したときに、事なきを得たことがありました。
そういうわかりやすい結果が得られるとやっていていい感じがしてきますね。
今後も続けていこうと思います。

テスト技法練習帳やってる

f:id:yoshitake_1201:20190826095852j:plain

当日(以降も)話題になっていましたが、実行委員の方が「テスト技法の練習帳」を作り、参加者に配ってくださいました。
いろいろと裏話も聞いたのですが…半年以上かけてここまで作るとは…ありがたいかぎりです。

そしてせっかくもらった練習帳。
飾っておくにはもったいないので、ぼちぼちとやっています。
やってみると、なかなか難しいですね。
「自分ここまでわかってなかったのか〜」とちょっとショックでした。 問題には回答例も書かれているのですが、そこで自分と違う視点の答えがあるので良いですね。
よく考えさせられます。
問題の他に「ブレイクタイム」というTipsもあるのですが、「仕様書の記載にはテストに必要な情報が足りていない場合があります」(練習帳P27より)といった始まりから、具体的な例をあげて説明をしてくれているのもとても良いです。

テスト技法の勉強会やる

q-te.connpass.com

ワークショップでテスト技法を学び、改めて大事だなぁと思ったので勉強会をやることにしました。
自分の中でまとめてアウトプットしたいなぁとも思っていたので。

1回1テーマ、1 ~ 2ヶ月に1回ぐらいのペースで開催していけたらなぁと思っています。

当日を思い返して

濃い1日でしたね。
しかし基調講演、事例発表、ワークショップ、参加者の方との交流、どれをとっても良いことばかりでした。
講演者の方々、実行委員の方々、当日話してくれた参加者の方々、ありがとうございました。

テスト開始前に「テストの問診票」に答えてもらっている #テストラジオ #108回のネタ

twitcasting.tv

8/11(日)のテストラジオに出演したのですが、そこで自分がやっている「テストの問診票」という取り組みについて話をさせてもらいました。
このブログではそのテストの問診票について少し説明します。

テストの問診票とは?

Googleフォームのタイトルです。
私がプロジェクトに参加するタイミングは、テスト対象がほとんどできあがり、テスト実行を開始するちょっと前、ぐらいがほとんどです。
なので、テスト実行開始前(数日前 ~ 前日まで)には必ず、プロジェクトの背景や、開発したもの(テスト対象)などなど、テストに必要な情報を教えてもらうミーティングを開いてもらっています。
そのミーティングで話してもらう内容を事前にGoogleフォームに書いてもらっているのですが、このGoogleフォームのことを「テストの問診票」と呼んでいます。

なぜ作った?

上記のミーティングは30分 ~ 1時間で行っています。
一応質問リストを用意して、その場で聞いてはいたのですが、話が脱線したり、用意していた質問よりも気になることを聞いたりで、時間が過ぎていき、全部を聞けずということがしばしば(後から聞くんですけど…)。
また、その時初めて聞く話が多いので、思考や疑問が追いつかなかったりも…。
そしてそれを解決するためには、とりあえず事前に質問しておいたらいいのでは?と思い、今年の2月ぐらいからぼちぼちと始めてみました。

なんでGoogle フォーム?

答えるときに少し気分を変えてほしいなぁと思ったのがそもそもでした。
基本的にこの問診票は、開発者に答えてもらうのですが、開発中の思考から少し切り替えてもらえたら…と思ったんですよね。
そこから「業務中にGoogleフォームに答える」ってなかなかないよなぁ…と思ってとりあえずGoogle フォームにしてみました。

どんなことを質問している?

普段遣いのものから抜粋 & 質問文を少し変更したフォームの画像になります。
(フォーム自体はこちら

f:id:yoshitake_1201:20190825194709p:plain

質問の内容は大きく分類すると3つですかね。

  • 事務的なもの
  • プロジェクト全体に関わること
  • テストに関わること

それぞれの質問に一応意図があります。
テストラジオでも話していたんですが、「何件ぐらいバグが出そうか教えてください」という質問は、長期的にこの問診票を続けるといろいろ良い働きをしてくれるのでは…と思っています。

使い方

以下の流れで使っています

  1. テスト開始時期が近づく
  2. 開発者に問診票の回答URLを送る
  3. 開発者が回答する
  4. ↑の回答を参考にミーティングを行う

ちなみにですが、この問診票はあくまでも参考程度として使っています。
「このフォームにしっかりかっちり書かなければならない」というものではないです。
そういった意味を和らげたくて「問診票」という名前をつけました。 (すこし柔らかいニュアンスになりますよね)

やってみた感想

いい感じかなぁ〜と。
事前に情報をもらえるので、自分の中で情報を整理できますし。
そして個人的には、「バグ何件ぐらいでそう?」と「やらなくていいテストある?」という質問が良い働きをしているなぁと思います。
基本的に回答者の感覚で答えてもらっているので、数字や書き方などバラバラなのですが、「なんでその件数と思う?」「なんでそれやらなくていいの?」を聞くと、それぞれの考えや思いを知れるので。
そこで聞いた「なんで?」が割とテスト活動に生きている気がします。
まだ思いつきで始めた〜ぐらいの感じなので、今後続けてもうちょっと具体的に良い点、悪い点をブログに書こうと思っています。

問診票については なそさんもテストラジオでフィードバックや考えを話しているので、ぜひ108回目聞いてみてください(笑)

(おまけ)Slackに通知する

Googleフォームはスクリプト(Google App Script:通称GAS)を埋め込むことができます。
なので、フォームに回答して持ったときはSlackに通知するようにしています。
これがなかなかに便利です!

qiita.com

この方の記事がとてもわかりやすいので、ぜひ読んでみてください。
あと、自分もQiita書いてみたのでよければご参考ください。

qiita.com

SaPID Bootcamp2019.5 に参加して3ヶ月が経とうとしている #SaPID

この記事は?

2019/5/25 ~ 5/26に行われたSaPID BootCampの参加レポートです。 参加して3ヶ月ぐらい経とうとしてますが…(笑)
ただ3ヶ月たった今ふりかえってみると、やはり「参加してよかった」と思います。
なので自分のメモのためにも書きました。
ちなみにSaPIDとはなんぞや?的な詳細はこの記事では書いてません。
ポエムな記事です。

イベント概要

www.software-quasol.com

開催日: 2019/05/25(土) ~ 2019/05/26(日)
公式レポート

www.software-quasol.com

SaPIDとは?

問題解決・プロセス改善のための手法(フレームワーク)です。
以下、Software Quasolからの引用です。

”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが(最終的には仲間と共に)解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。

SaPID → SaPID+→ SaPID3.0とアップデートされています。

SaPID Bootcampの内容

  • 1日目
    • SaPIDについてのガイダンス
    • STEP1:問題点洗い出し・引き出し
    • STEP2:事実確認・要素精査
  • 2日目
    • STEP3:問題分析・構造化
    • STEP4:改善ターゲット検討・特定
    • STEP5-1:改善対象の掘り下げ
    • STEP5-2:改善手段検討・決定
    • STEP6:改善目標の検討・決定

SaPIDは9つのステップに分けられているのですが、今回のBootcampでは、Step6の改善目標の検討までを対象としてワークショップが行われました。
(ちなみに、STEP7以降は以下の感じです。

  • STEP7: 改善計画立案
  • STEP8: 改善トライアルと評価・フィードバック
  • STEP9:全体適用→評価・ふりかえり&フィードバック

ちなみにSaPIDをやると以下のような問題構造図ができあがります。
見にくいですが、付箋が因果関係で結ばれています。
f:id:yoshitake_1201:20190819014300j:plain

なぜ参加しようと思ったのか?

私が「SaPID」というワードを知ったのは今から2年前の2017年6月でした。
たまたま…安達さんを紹介していただき、そこからSaPIDを知り、本を読んでみたのがきっかけです。
本の前半には「あるある」な現場の悩みが書かれていて、それを読んだときに納得感があったのを覚えています。
ただ当時は具体的な取り組み方はいまいちピンときてなかったのですが、本に書かれていた「最初は小さく速く改善のプロセスを回す」というのが自分に刺さり、それからSaPIDに少しずつのめり込んでいきました。
ただ、SaPIDの提唱されているフローを最初からやる機会や自分でやることがなかなかできなかったので、今回Bootcampに参加してみました。

  • SaPIDを手順通りにやってみたい
  • 今の自分の現場での悩みや問題を見える化したい

というのが大きな目的でした。

Bootcamp参加してみて

参加してよかった!というのがただただ正直な感想です。
Bootcampでは「自分が今現場で悩んでいること」を取り扱い、Bootcamp中に「自分が行う改善手段」を決めるので、現場に帰ってそのまま実践することができるのが良いですね。

またその「自分が悩んでいること」を考えている中、講師の安達さん、小楠さんからBootcamp中にいろいろと指摘をいただけるというのがさらに良いです。
なかなか自分の現場の悩みについて、指摘を頂く機会はないですから。
自分の出したカードや作った構造にぐさりとくる質問を投げかけてくれます。
とても頭を使いました。。。

もちろん、「SaPIDを手順通りにやってみたい」「今の自分の現場での悩みや問題を見える化したい」についても達成することができました。

Bootcampから現場に帰ってきて

戻ってきてすぐに(Bootcampの翌週に)社内のテストチームでとりあえずSaPIDやってみました!
今のチームメンバーは「私がこういうのやりたい!」というと、すっと協力してくれるので本当にありがたい限りです。

■ 社内に戻ってやってみてわかったこと
・自分はプレイヤー兼ファシリテーターは苦手
・取り扱う問題のスコープの大きさは本当に大事
・チームメンバー素敵
・SaPID面白い

これについては詳細な記事を別に書こうと思います。
Bootcampから戻ってきた翌週にSaPID試してみたんですが、自分が進行する側に回ると中々難しくてですね。。。
思い悩んでいたところSaPIDプレファシリテーターである @caori_tさんに会う機会があり、相談してみたところ、6月頭に九州員来られる用事があったので、そのついで来社していただきちょこっとファリテートしてもらうという、貴重な体験をしました!
その後の結果も踏まえて9月 ~ 10月ぐらいに詳細な記事をかけたらと思います。

3ヶ月(ぐらい)経った今思うこと

本当は参加後1週間以内にブログ書く予定だったんですけどね(笑)
まぁせっかくなので参加後3ヶ月経ってみての感想や経過を書こうと思います。

・参加したという結果だけが残っていないか?
Noです。
参加したこと、SaPIDのStep.6までを体験できたことで、日々の考え方や業務のアプローチが変わっていると実感しています。

何かしらかを聞いたり理解する時、頭の中で構造的に状況を把握できるようになってきた気がします。
また、人からある取り組みを聞いたときに「なぜやるの?」「それやったらどうなるの?」を自然に考え聞けるようになったと思います。

・SaPIDを実践できているか?
残念ながらNoです。 戻ってきてチームでやってみたんですが、取り扱ったスコープが大きすぎてですね。。。 そこで途中で終わってます。   ただ、その当時はチームができたてだったという事情もあり、「とりあえずチームでSaPIDしてみる」というミニマムな目標は達成できました。
今月8月にチーム再編が行われ、テストチームが正式に発足したので、そこでもう一度スコープを絞ってSaPIDをしてみようと思っています。
(これまではテストチームとして独立はしてなかったんですよね) ちなみに、チームでやってみたらこんな感じで…めっちゃでかくなってしまいました(笑)
スコープはしぼらないとですね。
f:id:yoshitake_1201:20190819014312j:plain

Bootcampに参加できたから、自分の中に「現状を構造化する」という感覚がかなり染み付いてきました。
整理しやすいのでかなり好きなアプローチです。
また、SaPIDには構造化だけでなく、構造化しやすくするためのアプローチ(テクニック)も盛り込まれているので、 日々の業務の中で「困っていること」がわかりやすく、また困っていることへの前後関係に気づきやすくなったと思っています。

正直あのタイミングで参加できて本当に良かったです。

一緒に参加して、意見や相談にのってくれた参加者の皆様、講師の安達さん、小楠さん、ありがとうございました!
日々色々取り組んで生かしていけたらと思います。

JSTQB AL関係の資料まとめ(2019/05/15更新) #JSTQB

ブログの概要

www.juse.or.jp

なんと、2019年8月24日のJSTQB AL試験が福岡県でも受験できることになりました!
本当ありがとうございます!

ということで、「いやぁ、福岡だとAL受けれないですから…」とこれまで使っていた言い訳が使えなくなったわけです(笑)
完全に不意打ちだったんですが、せっかく福岡で受けれるなら!というわけで今回の試験AL(8/24はテストマネージャ)を受けてみようと思いました。

その勉強を始めるために、とりあえずネットにある資料や教えていただいた資料ををまとめてみたのが本ブログです。 もしかすると更新していくかもしれません。

テストマネージャ関係

JSTQBシラバス

jstqb.jp

JSTQBサンプル問題

jstqb.jp

ASTERのYouTubeで公開されている動画

www.youtube.com

www.youtube.com

www.youtube.com

過去のJaSSTで発表された資料

ISTQB サンプル問題

www.istqb.org

ASTQB サンプル問題

astqb.org

ISTQBとASTQBのサンプル問題の和訳(非公式)

github.com


テストアナリスト関係

JSTQBシラバス

jstqb.jp

JSTQBサンプル問題

jstqb.jp

ASTERのYouTubeで公開されている動画

www.youtube.com

www.youtube.com

www.youtube.com

過去のJaSSTで発表された資料

ISTQB サンプル問題

www.istqb.org

ASTQB サンプル問題

astqb.org

ISTQBとASTQBのサンプル問題の和訳(非公式)

github.com

JSTQB Advanced Level 非公式問題集

booth.pm

その他メモ

過去のJaSSTで発表された資料

勉強会

jstqb-al-exam.connpass.com

参考ブログ/記事/資料

e5rijun.hatenablog.com

www.slideshare.net

www.kzsuzuki.com ※ ALの勉強をされた際のブログが上がっている

SlideShare検索用

www.slideshare.net

Qiita検索用

qiita.com

note検索用

note.mu

「Agile QA Night in FUKUOKA!!」で発表しました! #fuku_mori

イベント概要

f:id:yoshitake_1201:20190428224033p:plain

connpass.com

発表資料

speakerdeck.com

sli.doの質問に対する回答

yoshitake-1201.hatenablog.com

発表のきっかけ

山本 久仁朗さんから「福岡をもっと盛り上げていきたい」とお声がけいただいたのがきっかけでした。
そこから他運営メンバーと合流 → 今回の勉強会を開催という流れになり、福岡在住メンバーから発表…ということで発表させていただくことになりました。
かなり嬉しかったです(^^)

自分の発表について

なんでAgileとは?な話をしたのか?

以下がその理由です。

  • 自分がAgileをそもそもわかっていない
  • 福岡でAgileかつQAという勉強会は珍しい(と思う)
  • connpass初登録の方が多かった(勉強会始めてかも…と思った)
  • Agile」という言葉は個人によって認識が違うことが多い(と思う)

メインは自分の中で整理したかった…です。
ただ、今回(おそらく)勉強会初参加の方も多いんじゃないかなぁ → Agileとかもそもそも定義が違いそうだなぁ。
と思ったので、一度Agileとは…というのを話したかった感じでした。
結果ふわっとした感じになったので…あれでしたけど(笑)
自分としてはこの発表のためにAgileに関わるものを調べることができてよかったです。
ただうまく伝えられなかったので…今後精進したいと思います。
Agileって考えすぎると難しいなぁと思いました。

集中するのは良いことなのか?

この勉強会終了後、3日後にテスト酒場in福岡をやったんですが、この部分少しディスカッションしました。
「集中するのは良いことのなのか?」
これは「個人の集中を切らしてでもチームメンバーのわからないを解決する」という項目と比較し私(私のチーム)は「個人の集中を切らしてでも質問しやすくする」ということの優先度を高めた、と思っていただけたら良いかなぁと思いました。
↑でも少し誤解されそうですが…ここでは一旦これとします(集中についても更に議論が生まれそうですね)。

自分は「質問しにくいということが発生している」ということをチームの共通認識とし、それに対してどういう優先度で取り組むのか?が大事だと思っています。
なので「集中することが悪だ!」と言いたいわけではありません。
この問題に対しては様々なアプローチもあるでしょうし、チームメンバーや状況が変われば他の選択をすることがあるかもしれません(ただ、今の所吉武がいるテストチームでは↑をやっていきたいと思っていますが)。
できれば、関わっているメンバーで認識を合わせて、「誰か1人がすごく頑張る」という選択ではなく、みんなで解決していければと思ってます。

集中するのは…の余談

この取り組みについて、以前「自分が質問される側になったとき集中が切れてつらい」と言ったところ、
「集中しないとできないタスクなんてないかもしれない」
と助言をいただいたことがあります。

自分はこの指摘から「集中しなくてもタスクをこなせるようになりたい」と思うようになりました。
この指摘が良いのか悪いのか、指摘してくださった方の意図するものなのかどうか…誤解している可能性もあります。
ただ、誤解しててもそれはそれでいいかなぁと。
割と最近は集中/集中しないを切り替えているので、個人的にはこの方向でいいかなぁと思っています。
集中が切れるのを嫌がるのって、「集中した状態になることが難しい」という要素もあるのかなぁと。
なら「集中のON/OFFをすぐ切り替えれるようになる」「集中を維持した状態で、穏やかに対応できるようになる」といったことになるとみんな幸せになれそうな気もしますよね。

パネルディスカッションについて

なんと人生初めてのパネルでした。
率直な感想ですが難しいですね。
パネルトークでバシッと答えれる、他の方とディスカッションできる、というのはやはりすごいことなんだなぁと思いました。
つい自分語りしたくなったり、一部にしか伝わらない言葉で話したりしちゃいたくなるので。

基本的に他の方のお話を聞いていただけでした。
今後どこかでパネルをやらせていただけるなら、この辺り意識してできるようになりたいですね。
短くバシッと答えていたリナさんかっこよかったです。

感想

発表、そしてパネルディスカッションにまで参加と、ありがたいかぎりでした。
自分の発表はLTを3本つづけてやりました、という感じになっていたなぁと。
まぁ今回発表したかったことを組み立てるとそうなるよなぁ…と少し思っていたとはいえ、今後はもうちょっと芯を通した発表できるよう精進します。
(そしてスライド本文文字ばっかですみません)

こういった勉強会、声をかけていただくだけでなく、自分でも企画していきたいですね。
お話できる方が増えると自分も楽しいですし。

さて、最後になりますが、個人ブログで書くのもなんなんですが、参加してくださった方、話を聞いてくださった方、運営メンバーの皆様、ありがとうございました。
また会場準備や軽食など出していただいたLINE Fukuokaの皆様ありがとうございました。

「Agile QA Night in FUKUOKA!!」sli.doの質問に回答する #fuku_mori

イベント概要

connpass.com

sli.doのURL

app.sli.do

このブログの概要

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をぜひ。

jasst.jp

8.テスト準備期間が充分に取れない時はどうしてますか?これだけはやっておくということがあれば教えてください

まずは取れるようにアプローチしたいですよね(笑)。
充分…そもそもどこまでできているかわからないのですが、開発者から仕様を聞くというのだけは最低限やってます。
仕様だけじゃなくて「なんでこのプロジェクト始まったの?お客さんは何があってこのシステムほしいの?」などは必ず。

9.ぶっちゃけアジャイルやめたいですか?

そもそもうちはアジャイルやっているのか?という疑問があるので(笑)
仮にやっているとするなら、アジャイルやめなくていと思います。
ただ、無理やりにアジャイルを意識することはしなくていいと思います。

10.リアルバクに関してどのような考えを持っていますか? 「テストの粒度」と強く絡んでいて、トレードオフの部分が大きいと思いますが、各社の意見を聞きたいです。

リアルバグ = リリース後にみつかったバグ としますね。
テストの粒度…全数テストやるかどうか?みたいな話ですかね?
「自分が想像できなかったバグ」についてはしょうがないとあきらめます。
これについては「どうやったら次からそれを見つけれるか?」を考えます。
「自分が想像できたバグ」については、なんでそれが漏れてしまったかを考えます。
過去には「直前に大きいバグが治って油断した」「精神的に余裕がなくて見逃した」ということがありました。
これらについては、「油断しそうなタイミングで気を引き締める」「余裕がなくならないようにスケジュール調整する、精神状況を日々モニタリングする」といったことをしています。

11.テストしていくなかで有効、便利なツールが知りたいです。

テストのどのフェーズで対象はなんだろう…。
ひとまず↓など参考にするといいのでは?と思いました。

qiita.com

12.どれくらいの規模にプロダクトが成長したらQAチームが必要だと感じますか? 開発者によるテストで回らなくなったら。とかですか? QA担当を入れるタイミングが知りたいです

どんな規模の開発チームに合ってもいいと思います。

13.優先度の中、低って結局処理されないことが多いのですが、どう処理してますか?

バグ票/インシデントレポート の優先度の話ですかね?
時間とお金が絡むので難しいですよね。
うちは最終ジャッジは開発者(プロジェクトオーナー)にゆだねているので、どうしても直したほうがいいものについては、中でも低でも交渉しています。
質問してくださった方どんな基準で優先度をつけているのか気になりました。

14.qaからウォーターフォールからアジャイル開発にしよう!と発信しにくいイメージですが、みなさんは既存の開発の状況をqaから変えていける発信力があるのでしょうか?どうやったらアジャイル開発に変えていけるのでしょうか?

そもそも私QAじゃないので…(笑)
そもそもウォーターフォールやめてアジャイルにしたい理由って何なんですかね?
私の場合たぶん、よっぽど変えたい何かがあればちゃんと話して変えてもらうと思います。
そのときはちゃんと話聞いてくれるメンバーだと思います。
ただ僕は大きく変えるよりは、小さく変えていく方を好んでいるので「ガラッと変える」みたいなことはそもそもあんまりしないですね。

15.モブプロだとなんで忖度が発生しづらいのか理解できなかった

みんなで見てるから、だと思います。
その場で作ってその場で疑問を口にするので。

16.QAの成果物って何ですか?

テストではなく、QAの成果物ですか。
あと誰に対する(何に対する)成果物なのか気になりました。
テストプロセスでいうと、テスト設計コンテストU-30チュートリアル資料P67が参考になると思います。
↓以外だと、テスト実行時のテストケースやバグ票のレポートなどですかね。

aster.or.jp

17.テストを行う際にテストデータが必要かと思いますが、どうやって準備していますか?テストデータが足りなくバグが出せなかったりとかあるのかなと思って聞きたいです

重要な部分については予めデシジョンテーブル使ったり、テストパターンを考えて準備してます。
状況によっては実装内容聞いたりしてます。
足りなくても最終的にバグが見つからなかったらバグではないので、それはそれでいいのでは…(笑)
ただ足りなくて自分のテストフェーズでバグが見つからず漏れてしまった場合はありますね。
それは質問10と同じ対応しますね。

18. 普段使ってるツール(バグトラッキングとかCI/CDとか、コミュニケーションとか)を教えてください!

以下になります。

  • バグトラッキング
  • CI/CD
    • 弊社ではCircleCI使ってます。あと一部でJenkins。
  • コミュニケーションとか…チャットツールですかね?
    • slack

19. ソースが読めないとモブプロに入れてもらえない感あるんですが、あるいは疎外感感じると思うんですが、いかがでしょう

気にせず入っていっていいんじゃないですかね?
そこで学ぶこともできるでしょうし。
疎外感は感じるかもしれないですね。
その場合はソースが読めるようになったら疎外感なくなるかと。
なんのために参加しているのか?をわかってもらうとなくなるかもしれません。

20. QAで一番大事にすることは何ですか

品質、なんだと思います。
品質保証っていうぐらいですし。
なんの品質なのかは状況次第。
あと、その品質を大事にするために他に大事にすることがいっぱいあるなぁ…と。
難しいですね。

21. 開発のスコープが事前にわかっていても複雑度が増していくとリグレッションテストの範囲が広くなっていくことは避けられないと思います。そんな中でQA期間がリリースサイクルを不安定にさせないためにどういった施策を実施していますか?

開発チーム側でE2Eの自動テスト書いていってくれてたりします。
自分がやる手動テストではテスト実施の範囲絞ってますね。
影響範囲聞いたりしてます。

22. 会場の空気、もっと盛り上げたくないですか?

盛り上げたかった!
次回以降やるときはがんばります!

23. テスト工数を見積る上でのテストベースは何、そして見積る時期は?

今の所要求のリストと機能、画面のリストですね。
案件開始時とテスト実行が始まる少し前の2回あります。

24. QAを極めるとの最終的に行き着く先はどうなると思いますか

QAいなくなるんじゃないですかね?
またはみんながQAになる。
俺がガ●ダムだ的な。

25. Agile と Waterfall Like の開発プロセスで、テストの成果物やテストの実行時間に具体的にどのような違いがありますか? Agileで進めると十分なテスト実施時間が確保できず品質を担保するのが難しいという課題もあると思うのですが、そのあたりはどのように解決していますか?

・テスト成果物や実行時間の違い
→ 質問2と同じですかね。

・充分なテスト実施時間が確保できず
→ それで品質を担保できていない(=品質がおちている)のであれば、そのリリースサイクル見直した方がいいような気がします。
または、そのリリースでサイクルできることをやったほうがいいような気がします。
ただ、テストしすぎるというのもリリース遅くなってしまうので、リスクベースドに考えてテストするか、開発者側にもテストしてもらうというのも有りかなぁと思います。

感想

質問の回答難しいですね(笑)
なるべく短くを意識したんですが…語りたくなる。
質問した方の背景がわからないのがもどかしいし、どのテストフェーズのことを言ってるんだろう?と気になりました。
質問に答えるのも勉強になりますね。
半年後ぐらいにまた答えると違った回答ができるかもしれません。

質問いただきありがとうございました。