なぜQAとして発信するのか考えてみた話。

はじめに

自分が勉強会の登壇や、外部への発信をやっている理由は端的に言うと「同じ価値観を持つ仲間に知ってもらいたいから」だと思っています。
理由として「同じ価値観・経験を持つ人」が業界の構造としてかなりの少数派であることが挙げられます。今回はそこら辺のことは短めの文章で書こうと思います。
※あくまで個人の見解です。

目指している姿

スクラムチームのエンジニアの理想像は「T字型人材」だと考えていて、開発チームにおけるエンジニアの枠組みの中にQAエンジニアも含まれていると思っています。
なので、スクラムチームがswarmingするときは開発だってするし、仕様検討だってするし、テストだってする。
その中で「一番得意なのがテストだよ」…っていうようなエンジニアをQAエンジニアとして考えています。

参考:Swarmingとは スワーミングがアジャイルチームを助ける

日本のIT業界におけるQAエンジニア人材

といいつつ、こういったエンジニアは少なくとも自分の会社のカジュアル面談の場にはほとんどやってきません。そもそも、QAエンジニア・テストエンジニアの人が少ないです。
PRや採用側の問題…とかもあるかもしれないのですが、日本のIT業界は責任範囲を明確に絞り、その領域に特化した人材で開発を進めてきたことこと…とかも理由として考えられます。面接に来ていただける候補者の多くがテストの設計と実行の経験だけという場合が多く、計画や評価を含めたすべてのテストプロセスを担当した経験がある人の方が少ないように感じます。
※テストプロセスについては下記に載せておくので興味があったら参考リンクをご確認どうぞ。

JSTQB TestAnalystにおける テストプロセス

  • 計画、モニタリング、およびコントロール
  • 分析
  • 設計
  • 実装
  • 実行
  • 終了基準の評価とレポート
  • 終了作業

JSTQB認定テスト技術者資格-シラバス(学習事項)・用語集-

そのため、経験領域と目指している姿にギャップがあるのは分かった上で、難しい採用活動を進めているのは理解しているつもりです。
しかし、(あくまで自分が見える範囲の)海外に目を向けてみると目指すべき姿とマッチした経験をもった人は日本よりはいるように感じています。
ISTQB Agile Testerを取得できる国もあるので、そういった部分も関係があるかもしれないですが、計画からレポーティングした上で、継続的なテストの推進を経験してる人…とかもたまにいる印象です。

なのでどうするか(まとめ)

グローバルな観点で言えば、海外の品質保証のスタンダードを取り込みながら働くべきだと思っています。
そうしないと独自の品質保証の仕組みを推進した結果として、今度は海外でメンバーが取れなくなるリスクが発生するからです。
なので、日本における採用は経験を持つ人が少ないのは認めた上で、同じ価値観の人に来てもらうしかないかなと考えています。

やったことないのであれば覚えればいいし、そういった成長込みで仕事をするメンバーと一緒に働けたらいいなぁと思っています。
なんでもやるような「T字型人材」を目指すような人に向けて今日も発信していこうと思っているので、引き続きよろしくお願いします。

おわり

JaSST'20 Tokyo RejectCon 登壇の裏側レポート

ブログに書いて欲しいというネタが複数あったので、今回の記事は個人ブログの方に書くことにします。
来る2月3日(節分ですね!)に開催されました。「JaSST'20 Tokyo RejectCon」という勉強会で登壇してきたレポートになります。
個人ブログの方がもう少しフランクに書けるのかな…文体が安定しないので、変わらないかもしれない。

概要

connpass connpass.com

ブログ枠の方のレポート qiita.com

masskaneko.hatenablog.com

勉強会全体のレポートについてはブログ枠の方が発表していますので主に自分の事について書こう。

はじめに

今回の発表は @tsueeemura さんからお誘いいただきました。
TwitterのTLで開催することは知っていましたし、今年はTokyoに出してないなーぐらいに思っていましたが、対面でお誘いされたので断るなんてことはできません。
加えて「なんでも大丈夫です!!」と強く言われたので、なるほど…それなら一昨年に出してダメだったやつでも大丈夫だなということで参加を決めたのでした。

勉強会自体はみなさん各々の話したいことを発表されていたので、いい意味でRejectConっぽくない勉強会で楽しい感じでした!
実際に勉強会に行ってみてRejectConっぽい発表が自分くらいしかしてなかった…気がするので無駄な心配でした。

実際の発表

speakerdeck.com

発表で使った資料は上記ですが、結論から言うと一昨年に出した内容を発表するのってすごく大変でした。

大変だった理由

  • 思い出す&過去の失敗をリカバリするのが大変
  • RejectConとはについて悩む(構成について悩む)
  • 普通に忙しくて大変

思い出すの大変&過去の失敗をリカバリするのが大変

そもそも事例発表のアブストを提出したのが2018年の秋なので一年以上経過しているわけで、まずは過去のアブスト引っ張り出してくるのに苦労し…加えて過去のものを読み直してみると色々粗があるので、発表に足りる内容まで昇華することが大変でした…。
びっくりしたのが、過去の自分が「健康診断に例える」と銘打ちながら肝心の健康診断は一部分で、アブストの中で話したいことは主にアジャイル開発と品質の捉え方の話をしている訳ですね…。

当時の自分は新規性だったりキャッチーな内容を散りばめたかったのでしょう。
(健康診断の件は結構いろんなところで言われてますけどね…。 ) 過去の自分と対話しながら、当時どういうことをしたかったのかを思い出しながら、今の自分だったらこうする…みたいなのを混ぜながら今回の発表を作りました。

…ちなみに普段の仕事でCIサーバーをいじってる時は逆のケースもあり、過去の自分の残してくれた崇高なドキュメントを見ながら、過去の自分が思い描いていた理想を現在の自分が追いかける…みたいなこともたまにありますw

RejectConとはについて悩む(構成について悩む)

JaSST北海道にでて分かったことはJaSSTは学術的なイベントだと感じたので、普段の勉強会より真面目な印象を持っています。
なので、その真面目モードの発表をそのまま持ってくるのは果たしてRejectConに本当にふさわしい内容なのかと悩みました。

Rejectされた内容に対して勉強会の参加者が得たい情報ってなんだろう」…と。

とか真面目に悩んだ結果、以下の内容を発表に組み込むことにしました。

  • 不採択の理由を含めて振り返り、発信する
  • 具体的な事例よりも伝えたいエッセンスにフォーカスする

1つ目は事例を出したい人が参加するかもしれないので、その人に向けて情報が残ればいいなぁという思いがあったので組み込みました。
2つめについては実際に事例発表の場でないので、本来厚めに語る具体的な施策・事例の部分だったりといった部分を削減することで伝えたいことを残しつつ15分の発表に押し込みました。

結果としてはRejectConっぽい発表だけど、事例発表っぽくない発表になったので大筋で思惑通りです。
あとはAutifyさんにゴマすりもできたので完璧。

普通に忙しくて大変

結構安請け合いしちゃうタイプなので自分のリソース管理は苦手です。
そんな中、社内の勉強会(ほろよいてっく)に向けたLTつくって、今回の登壇資料作って、QAメンバーのAL取得のためのテスト技法勉強会の準備したり…この頃は普段の仕事以外のタスクを引き受けすぎました。
本当に間に合うか怪しい瞬間もありましたが、無事に発表できてよかったです。
とはいえ、結果的にどれもある程度良い結果になったので必要だと思ったことはこれからも引き受けちゃう気がします。

まとめ

最近、自分の忙しさにかまけていたせいか参加も含めて久々の勉強会の参加となりました。
別の会社のQAエンジニアの人とお話したり、自分が企画した勉強会の話をして頂いたりと、普段の仕事とは別の刺激になりました。
こういった活動は大事にしていきたいと遠のいていた自分に反省をしつつ頑張ろうと思いました。

おわり

2019年の振り返りと2020年の目標作成

はじめに

2019年も残りわずかになったので、2019年の振り返りと2020年の目標を書く投稿を準備しておく。
2020年の終わりに見て、どれくらい達成できてるか見ると楽しいかもしれない。

2019年の目標を振り返る

2019年にやりたかったことをつらつら振り返る。
毎年、自分はやりたいことをいくつか用意していて、その中でいくつかできたら嬉しいなーくらいの温度感で実施している。
今年の目標を一言で言うと、「自力をつける」みたいなイメージ。

QAチームリーダーをしているので、ある程度やってみせたり、仕事の振る舞いや自分の背中を追いかけてくれる人がいる。
そういった人たちにとってQAエンジニアとして恥ずかしくない人になりたかったというのが理由の半分。

もう半分はスクラムチームが求めるT型人材という名のフルスタックエンジニアになりたかったというのがある。
未知の問題に対しても苦しみながらもきちんと成果をとって来れる、そういう人になりたいっていう漠然とした目指したい姿を持っていて、過去に自分を引き上げてくれた先輩エンジニアの背中を追いかけているのでした。

◎:JSTQB ALの取得

2月にTest Analyst試験 合格 8月にTest Manager試験 合格 まさか両方取れるとは思わなかったけど、日々の積み重ねが試験勉強の範囲をカバーしてたのかな。
TA試験の勉強方法についてブログを書いていたので、TM試験についてもそのうちブログを書きたい。

◎:認定スクラムマスターの取得

7月30-31日にScrumIncの認定スクラムマスター研修を受講(LSM)。
スクラム開発に携わってかれこれ5年くらいになるので、とりあえずこれまでの棚卸しを兼ねて形にしておきたかった。
まさか自腹で研修費を支払うことになるとは思わなかったけど…。

◎:JaSSTの登壇

8月30日のJaSST北海道でスクラム開発と品質保証と言うテーマで登壇。
QA×スクラムマスターの働き方について事例発表を行った。
スクラムマスターとQAの働き方は親和性ありそうなので、他の人もそういった人が増えている…のかな?

teamspirit.hatenablog.com

△:コードが書けるQAになる

GWを使ってTech CAMPのイナズマコースを受講。
Ruby on Railsを使って簡単なMVCのWebアプリを作れるようになった。
何かフレームワークを覚えたいなと思っていたのでまとまった時間を使って取り組めたのはよかった。
その後、カスタマーサポートに異動になったり、リーダー業の比重が高まってコードを書く機会が減ってしまったのはちょっと残念。
来年は業務以外の個人でE2Eのテストコード書いたり、新しいアプリ開発してみるのも楽しいかなとか思っている。

作ったもの
github.com

また、Salesforceの標準機能を使った機能開発とかする機会があったので、仕様検討と設計とかの業務をすることができた。
仕様検討→設計→実装→テスト→ドキュメンテーションの流れを一人でできたのはとてもよかった。

△:英語学習

2019年になって、海外拠点のメンバーとの会議や仕事をする機会が増えた。
1時間まるっと自動テストについて会議したり、1ヶ月間同じチームになって一緒にバックログ作ったり仕様検討したりした…。
相手側もゆっくり話してくれたりしたおかげでなんとかなったけれど、現状のままでは非常に厳しいというのを痛感した。
そして、リスニングはもちろんだけれど自分の話したいことを伝えるには圧倒的にスピーキングの練習が必要だと感じた。 来年はこういった機会がさらに増えそうなのでもっと頑張らないとなぁ…。 

2020年の目標を定める

2020年も引き続き「自力をつける」は継続の予定。
QA系は新しいスキルと言うよりも新たな分野に挑戦するような仕事をしたい。
あとはスクラムチームの外に対しても影響力を発揮できるようなエンジニアになりたい。

Salesforce系の資格を取る

2019年はカスタマーサポートを通してSalesforceの知識をいろいろつけることができた。
きりの良いところで形にしておきたい。

認定プロダクトオーナーを取る

スクラムチームのメンバーに対して認定スクラムマスター研修はすごく役に立った一方で、スクラムチームの活動についてステークホルダーにきちんと理解してもらったり、最終的な判断を下すPOの力になることでもっと良いチームになるかもと思ったので2020年は認定プロダクトオーナー研修に行きたい。

コードを書く

自分の働き方としては、仕事でコードが書ければ一番嬉しいことなんだけれど、周りから評価される・求められる働き方が違いそう。
スクラムマスターやったり、QAチームの仕組みを作ったり、困っているチームのスポットのヘルプに入ったり、スポットの特設チームの立ち上げしたりするとこを求められたりする。
場合によってはそのうちプロダクトコードの修正したり自動テスト書いたりも求められそうなので、きちんと準備しておく。
2019年はRubyだったけど、2020年は今のチームが使っている言語・フレームワークについて理解を深めることはしておきたいなぁ。

ブログを書く

2019年はほとんどブログを書かないで一年が終わってしまった。
2019年の後半では自分の思いや考えている施策について発信する機会が増えたので、あらかじめきちんとまとめたり・書いてあったりしたら便利なのでブログとかに残しておきたいなぁと思っている。

英語教育

これはまずいと思ったので英語力のベースアップを頑張る。
正直、自分の英語力はあまりにもひどいので、何をやっても前進しかなさそう。
なのでとりあえず、単語の勉強と英会話の機会を増やして自分の中で文章を構成するトレーニングを行いたい。

映画を楽しむ

ここまでカタめな話だったので、趣味の話。
毎月、映画館で映画を観る人は趣味は映画と名乗っても良いそうなので映画についても感想だったりを書けたら良いなぁ。

終わりに

と言うことをつらつら書いてたら2019年も残り1分だということなのでここら辺で一区切り。 2019年は仕事としてはとても躍進したので、2020年も同じ勢いで進んで行きたい。

おわり

2019年に学んだ「意思決定」の際に大切にしていること

はじめに

12月も下旬に差し掛かろうとしているので、この機会に本年の振り返りを行い、頭の中も整理しようということで備忘録を兼ねて投稿。

 

QAチームのチームリーダとして役割を担い始めたのが2018年の12月なので、今年は丸1年リーダー業をなんとか実施することができた。

あらためて今年を振り返ってみると、2019年は否応なしに「意思決定」を求められた一年だったと思う。
QAチームのリーダーをやりつつCSチームに異動したり、タスクフォースを1年間継続させるために奔走したり、これまでに実施したことないプロジェクトを成功に導くためには全体の流れを自身で描きつつ問題に対して解決策を実践することが必要で、その時々で重要な意思決定を迫られる場面が何度かあった。

思い返すと、上手く行ったものや、別の手があったかもという筋の良くないものもあったが、何度かそういった意思決定を繰り返し経験をすることで、自分の中で重要なポイントみたいなものが存在することを朧気ながら感じた。

今回は大事だと思ったポイントや考えについて、共感した書籍・ブログ記事等を紹介しながら書き残すことにした。

  

 

 

素早く決める。決断のハードルを下げる。

普段過ごしているチームの開発手法であるスクラムはよく分からない事(不確実性)に対してアプローチする手法だと考えている。

仮設検証を短いサイクルで回しフィードバックを受けることで、目的に対してその都度方針を修正しながら大きな目標に向かっていくフレームワークだと思っている。
そのため大事なことは、方針を素早く決める(仮説検証サイクルを回すこと)だし、決めた後もその都度修正するものだからこそ、選択自体に時間をかけないことは重要だと思っている。

意思決定の速さみたいなのはSmartHRの代表、宮田昇始さんのブログはとても共感できたので非常におススメ。(この記事は短いのですぐ読める。)

また、やってみるとわかるのですが、ミスって変なものを頼むことは少なく、結果に差を感じないんですよね。逆に、熟考しても失敗することはある。よく『 "5秒で考えた手" と "30分かけて考えた手" は、実際のところ86%が同じ手である』と言いますが、「熟考しても結果に大差はない」「結果が悪くても大したことない」ということを日常的に刷り込むのがいいのかなと思います。

 

blog.shojimiyata.com

 

 

選択の先を見極める。「不可逆な意思決定」は慎重に検討する。

では何でもかんでも素早く判断すればいいんだっけと聞かれたら、自分の答えはNoだ。
なぜなら、一度判断したら取り返しのつかないことや撤回することができない選択も中には存在するからだ。


重要なことは先ほど書いた、「素早く決めるもの」と「慎重に決めるもの」を見極めることだと思う。

 

前の項目で書いた通り、「素早く決めるもの」=「後で修正できること」だと思えば分かりやすい。

では逆に「慎重に決めるもの」は何だろう。自分の中では下記のブログの「不可逆な意思決定」というのが自分の中でしっくり来たので紹介したい。

不可逆な意思決定とは、一言でいえば、「一度決めて前に進めてしまうと、簡単に元の状態には戻せない意思決定」のことです。スタートアップにとってはまさに資本政策がそうですし、価格を下げる意思決定なども(価格は一度下げてしまうと上げずらいという意味で)不可逆な意思決定に当てはまると思います。

 

medium.com

 

他にも、普段自分が大事にしなければいけない観点も「慎重に決めるもの」に含まれると思う。

例で言うと、QAエンジニアなら「人・モノ・カネに関係するテスト」は繊細に扱うテーマなのでこう言ったものも判断材料を集め、慎重に検討する意思決定の類だと考えられる。

 

 

勇気と蛮勇 ~重要な決断で犬死はしないこと~

不可逆な決断や重要な決断をするときに大切なことは、適切なタイミングや目的に即した決断なのか客観的かつ冷静な判断が必要だ。

2019年の自分はあまり出来なかったと思っている部分だと考えている。
結果として、自分に起きる変化・影響は考えられてもチームのメンバーの影響やもっというと周りがどう思うかまでは考えが至らず、多大なる迷惑をかけ失敗したこともあった。

実際、仕事上の決断なので命までは取られないのだけれど、危機的状況の中でも冷静な判断を下すということはすごく難しい。

そういったメンタルや心の在り方について、新渡戸稲造は「武士道」の中で「勇」として言及しており、とても参考になった。(できるとは言ってない。)

下記は書籍の中の水戸光圀の言葉

「戦場に飛び込み、討ち死にするのはいともたやすきことにて、身分の賤しき者にもできる。生きるべきときは生き、死ぬべきときにのみ死ぬことこそ、真の勇気である」 

武士道 | 新渡戸稲造著 岬龍一郎訳 | 書籍 | PHP研究所

  

 

聞こえの良い理想だけではなく、現実を生きるために覚悟を決める

危機的状況に陥った時や、あるべき姿と現実が乖離している場合、なんらかの手段を講じる必要があるのだけれど結構な割合であるべき姿、理想に向かって一直線に進もうとした結果、上手く行かないケースをよく見てきた。

そうしたケースは理想と現実の乖離があまりにもかけ離れている場合がほとんどで、その時の急場をしのぐ最善の手段になっていないからだ。

大事なことは急がなければならないのはもちろんだが、焦らないことこそが重要だと思えるようになった。
理想と現実の乖離を埋めるため、決定したことを実現するために、耐え忍びながら変化していくことを受け入れる必要がある。
現在の課題を一気に解決してくれる銀の弾丸は無いし、忘れがちな当たり前のことを積み上げていく意識をすり合わせすることの大切さを学んだ。

 

ちなみに、改革をテーマにしたときに戦略企画室の方に「上杉鷹山」についておススメされたので本を読んでみたところとても共感できたので紹介しておく。

備えのほうは予定通りには進まない。そのうちに困難な事態のほうが先に押し寄せてきてしまう。これに対してどうすればよいか。

有効な手段などあるはずがない。最善の方法がなければ、次善、三善の策を、それもなければ、少なくとも最悪でない方法を取るよりほかにはあるまい。

www.mikasashobo.co.jp

 

また、本の中で鷹山の根底にあるものは以下と書かれており、TeamGeekのHRTを思い出した。

米沢藩における鷹山の政治および経済政策は、ただ施策として優れていたばかりではない。その底には、鷹山の無比の誠実さと謙虚さ、そして人々に対する地合いの心がゆるぎなく根を下ろしていた。

 

HRTとは

  • 謙虚(Humility)
  • 尊敬(Respect)
  • 信頼(Trust)

www.oreilly.co.jp

 

 

おわりに

つらつらと思ったことをいろいろ書いた結果、結構な量になってしまったけれど、普段自分の意思決定がどのように考えて、何を大事にしているかみたいなのの一片をアウトプットできたのは個人的にはよかったかなと思う。

 

重要な決定をした後は、その選択を正しい結果に進むように努力する必要があると思っていて、そのためにチームリーダーは、協力できるための仕組み・環境を整備したり、意思決定のプロセスがメンバーが納得できる説明・透明性を確保することなんだろうなぁと思っている。

もちろん自分もスクラムチームの一メンバーでもあるので、最後に自分が大切にしている「銃士の姿勢」を紹介にして終わりにしようと思う。

大事な決断って結構メンタル削られたり、不安だったりするのでそういう人を見かけたら一緒に共犯になって片棒を担ぐようにしている。

開発チーム(とスクラムチーム!)のメンバーは、三銃士と同じ姿勢を持たなければならない。「ひとりはみんなのために、みんなはひとりのために」である。この銃士の姿勢は、仕事を成し遂げる責任をチームメンバー全員が負うという点を強調する 

 

www.amazon.co.jp

 

おわり。

 

 

 

以上の記事はチームスピリットアドベントカレンダーのExtra Post枠(控え)

adventar.org

 

 

QAからCSへレンタル移籍をしてきた話

はじめに

プロフィールでは「スニーカー好きのQAエンジニア」と書いていましたが、若干訂正があり…。
実は2019/06/10 ~ 2019/10/31のおよそ5か月の間、社内のカスタマーサクセス(CS)チームへレンタル移籍に行っていました。
なのでここ5か月弱くらいはほとんどカスタマーサクセスサポートがメイン業務でしたので訂正しておきます。
とはいえ振り返ってみると、QAエンジニアとしてはとても良い経験だったのでここに書いておきたいと思います。
(また、11月からはQAエンジニアとして再始動です。)

レンタル移籍の経緯

件のチームメンバーの退職&産休が重なり、局所的にメンバーが不足するということで、ヘルプのメンバーの招集がかかり、開発チームから自分とバックエンドエンジニアの二人でヘルプに行くことになった。
他の職種にチャレンジする際の注意事項として、伝えたいことは一言だけです。

望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。

今回はチャレンジに前向きなメンバーでヘルプに行ったため、二人とも非常に実りがある時間を過ごすことができました。
一方でもしそうでない場合は、トラブルになりかねない出来事だと思うので要注意。
ホントに注意。

CS(Customer Success)チームの仕事内容

Salesforce上のアプリケーションなのでユーザーのシステム管理者からComunity Cloud上であげられるサポートケースの調査・回答がメインの業務として行いました。
開発チームでの詳しい領域(勤怠管理)のケースを中心に割り振られて回答していました。
その他アカウント管理や、データ修正もあわせて実施。

この辺りはQAエンジニア前の前に運用プロジェクトのエンジニアとして働いていたこと、サポートチームが手厚い研修をしてくれたため、比較的すんなりと働くことができました。
また、偶然二人で行く形になったのですが、同じ境遇の同期(厳密には違うけど)がいるのはかなり良かった。
分からないながらも助け合うことができたり、互いにレビュー等ができたので、それもまた良い方向に作用したかなと思っています。

よかった事・悪かった事

〇:ドメイン知識がついた

サポートケースに回答する以上、質問を正確に理解して正しい回答をする必要がある。
製品に関する知識、Salesforceに関する知識、勤怠管理にまつわる業務知識、が質問者と同等の理解にないとケースには回答できない。
そのため、検証環境を用意して、実際に問い合わせ内容が再現できるか・案内した手順が実施できるか検証を行う。
この仕事は開発でのバグの再現確認等とかなり近しい仕事に感じられた。

違いとしては、QAの時はある程度で調査を切り上げてfixを担当するメンバーに任せることができたが、原因を突き止める(回答として伝えられる)まで調べる必要があるのが大きい。
結果としては粘り強くやることや、限られた時間の中で戦略的に進める力が養われ、自信の知識を整理やさらに深めるために有意義な時間となった。

〇:ユーザーの声が聴ける

人事や総務が片手間で対応する場合や、システム開発部の担当などシステム管理者といっても様々な属性があることが分かった。 そして、作る側にとって難しい仕様は大抵ユーザー側も理解するのが難しい機能になるということが認識できた。

また、ユーザーにとって、問題が製品部分なのか自身のブラウザやネットワークなのかは関係なく、「機能が使えない」という一つの状態になってしまう。 そして、往々にして状況を切り分けるための情報が足りていないことが多い。
そのため、サポートで切り分けやある程度は相手の気持ちになって状況の推理する必要がある仕事だということが分かった。
(ちなみに変に勘ぐってしまい検討違いの回答をする可能性もあるので、思い切ってきちんと状況を整理する等のコミュニケーション力も必要)

〇:様々な背景のメンバーと話せる&仲良くなる

前職で人事の営業だったり、歴戦の導入メンバーだったり、普段開発チームにはいないようなメンバーと話す・一緒に仕事をすることができた。
日々の会話の中で新しいインプットが入ってきたりすることで、また別の刺激になった。
サポートケース対応がないときは、仲良くなった営業メンバーが使う資料のデモ画面の準備を手伝ったり、開発メンバーの時とは違った種類の差し込みタスクは新鮮。

×:引継ぎは計画的に

突発的に移動してしまったので、残されたQAメンバーに負荷を与える結果になってしまい、本当に申し訳ないことをしてしまった。
本当に申し訳ない気持ちでいっぱいです。
結果的にお詫びの肉をおごることで難を逃れたが、きちんと仕事の引継ぎはするべきだと思いました。
あれ、でも…自分も肉おごられても良いのでは…。

まとめ

QAエンジニアに必要なスキルとしてはテストの技術といった「テクニカルスキル」のほかに「ドメインスキル」が重要だと思っている。
そういう意味でいうと製品のドメインや顧客の属性など様々な情報をインプットすることができたので非常に有意義な時間を過ごすことができた。

一方で、有意義な時間を送れたからといって全員が同じ経験をすべきかというとそうでないと思っている。
CSチームでのやりがいはお客様の成功(カスタマーサクセス)を通して感じれるかどうかがポイントになりそうだと思った。

自分の場合は、困っているシステム管理者がケースを通して課題を解決していく姿に立ち会うことで開発とは違ったやりがいや仕事の意義を見出すことができた。

一方で、開発チームとしてのやりがいというのは難しい機能・案件をリリースしたりチームに貢献したりすることで感じる部分だと思っている。 なので、互いにやりがい・難しいポイントが違うからこそ、合わない人が同じ経験をしたところでなんの実りにならない時間を過ごすことになってしまうので…要注意。

QAエンジニアの自分としてはとても良い経験だったので、ちょっと伸び悩んでて興味がある人はあえて新しい環境に身を置くことで新しい発見があるかもしれないと書いておく。
ただ、望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。という一言に尽きるかなと思う。

【おまけ】QAエンジニアとしての活動+その他

CSチームに所属しながら…

勉強会を開いた&登壇したり…

【増枠】QuALiTy~QAエンジニアによるLT大会~ - connpass

speakerdeck.com

認定スクラムマスター研修受けたり…

会社のオフィスの引っ越しをしたり…

www.teamspirit.com

JSTQBテストマネージャ試験受けたり…

JaSST北海道で登壇したり…

speakerdeck.com

してました!
(意外といろいろやってた)

おわり

JSTQBテストアナリストの勉強方法を書いてみる。

はじめに

2月に受験したJSTQB Adavanced Level テストアナリスト試験の結果発表があり、見事に合格することができました。
今回の記事は合格までの道筋・勉強方法を書いていければと思っています。

 

JTQB Adavanced Level TA(テストアナリスト)試験とは

世界で最も普及しているソフトウェアテストの認定機関であるISTQB資格を日本で受けられるというもの。
現在日本で受けられる資格としては、Foundation試験(FL)・テストマネージャ試験(TM)・テストアナリスト試験(TA)がある。

Advanced Levelの試験については応募資格のレギュレーションがある

  1. JSTQB認定テスト技術者資格 Foundation Level資格の合格者、JSTQB(日本)以外のFoundation Level資格の合格者
  2. 業務経験3年以上(業務経歴申請書の提出あり)

f:id:riririusei99:20190407120328p:plain
ISTQBが定める技術体系

Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board

JSTQB認定テスト技術者資格

Advanced Level試験/資格試験-JSTQB認定テスト技術者資格/日科技連|ソフトウェア品質|SQiP研究会

STEP0. 前回の受験

実は2018年もTA試験を受験して落ちています。

  • 動機:マネージャが受けるからとりあえず受けてみた(自腹だから落ちてもいいよねマインド)
  • 勉強:忙しさにかまけて、さらっとシラバスを読んだだけ
  • 試験当日: さーっと進めたら30分くらい余ったので先に帰った

この時点で受かる気がなさそうですが、当日の試験はテスト技法をあてこんだり、状況に応じて対応を判断するような実例問題が中心だったので「いつもの仕事の延長だ」とか「いろんなシステムを想定して問題が面白かった」とか「ワンチャン受かるのでは…」と試験を甘く見てましたが見事に落ちました。(マネージャは見事に合格しました)

という恥ずかしい失敗経験をかき消したいというモチベーションを元に今回の資格試験に臨んでます。

STEP1. 申し込み

まずはHPをよく読み、受付している期間に申し込みを行います。(仕事が忙しくなると、試験日は大体いつか覚えてられるが申し込みの締め切り日は忘れそうになるので注意。) 申し込み時にはFL認定証の写しやFLでの認定番号が必要になるので、あらかじめ準備しておく。(職場で申し込もうとすると大抵、手元にない) 初回受験時は業務経歴申請書を提出する必要がある(メールで案内が来る)ので、募集要項からダウンロードして作成します。

www.juse.or.jp

STEP2. テスト当日までの勉強パート

試験問題の結果は回収されてしまうのでどの問題が間違っててどの問題があってるのか分かりませんが、試験を受けてみての自分が正解・不正解してそうな部分が分かっていたので今回は自分の弱点になっていそうな部分(自信をもって正解といえる領域以外)について重点的に勉強することにしました。

カテゴリ分け・方針決定

ざっくりいうと、テストを受けた問題の傾向をカテゴリ分けし、それぞれの理解度を3段階でつけました。(下記参照) 普段の仕事ではストーリーチケットのテスト設計(限られた時間の中で網羅的な・かつステークホルダーの要求する品質を満たせるようなテストを設計)をしています。なので、テスト技法を当て込んでテストケースを作成する問題は得意ですが、業務で取り扱っていない知識体系の引き出しが少ないこと、テストマネージャとテストアナリストとしてスクラム開発では分けて考えていないため一緒に考えてしまって、それぞれが一般的なプロジェクト開発における棲み分け・役割分担といったところが曖昧になっていることという弱点が見えてきました。 試験に向けて、理解度が低いものから優先順位を高く定め、それぞれ学習時間の重みを変えて学習します。

正解してそうな領域(自信をもって正解といえる問題)

  • 普段使っているテスト技法を当て込む問題

たぶんあってると思う領域(多分これが正解!って答えた問題)

  • 普段あまり使わない技法、業務ではツールに任せてしまうテスト技法の問題
  • テストアナリストとしての振る舞いをこたえる問題

おそらく間違っている領域(わからない・回答の一部がわからなかった問題)

  • 知識問題
  • 業務の知識とシラバスの知識とで差異・言い換えながら解釈した問題

シラバスを読み込む

勉強といっても問題集等々が無いので基本はシラバスを読みこむことを行いました(読み込むといっても2周ですが)。シラバスで分からない単語・略称などについてはGoogle検索して、関係する発表やブログなどを読んで、自分の言葉で理解できるまで資料を読み、理解した内容をテキストに書き起こし、あとで読み返せるようにして学習していきます。そのため、シラバスを読み込むと言っても寄り道がほとんどなのでかなり時間がかかります。
とはいえ、時間がかかっても日々の業務改善などに使えそうな知識・考え方が入ってくるので有意義な時間なのでおススメです。

テスト技法の勉強

過去問セミナーTA

テスト技法についてですが、「問題文を読んで実際に使えるレベル」が求められている気がします。 そのため、テスト技法については読み込みに加えて、別に時間を取りました。
対象のシステムに対して複数のテスト技法を組み合わせて考えられる必要があると、当日の試験で自信をもって回答ができると思います。

おススメはJSTQBの過去問セミナーの資料を熟読することです。実際に出た問題を解説していること、資料の少ないクラシフィケーションツリーについて書いてあります。

過去問セミナーTA
http://jstqb.jp/dl/AL_Exam_Seminar_TA.pdf

技法を手になじませる

基本的なテスト技法(境界値分析・ディシジョンテーブルや状態遷移図)については試験で多くの問題が出てくるのですが、今回はシラバスを読んで自分の知識と差異がないか確認する程度にしました。
今回は優先度を下げましたが仮に勉強をするとして、テスト技法は誰か分かっている人に教えてもらう・自分のやり方を見てもらって指導を受けるのが身につく近道だと思っています。
自分の経験では以前に有料の研修に行きましたが、そこでテスト技法の使い方を学んだ経験が日々の仕事でも活きている気がしています。
最近ではテストコミュティのワークショップもたくさんあるので、そういったところに足を運んで手を動かすのもいいかもしれません。

よさげだと思うセミナーを列挙
日本全国対応のソフトウェア品質教育支援 | VALTES

JSTQB認定 ソフトウェアテスト技術者 ― Foundation Levelトレーニングコース | セミナーサイト | 日本科学技術連盟

WACATE : 若手テストエンジニア向け勉強会・ワークショップ

STEP.3 テスト当日

TA試験は180分60問の長丁場です。しっかり準備して臨んで分かりましたが、時間が足りません。計算だったり・確認に時間がかかる問題だったり、結構大変です。
ペース配分を考えながら受験するのがおすすめです。自分の場合は今回も問題を解いたタイミングで回答の自信度をカテゴリ分けしながら進めて、最後に怪しいところ・間違えてそうなところを見直すようにしました。 朝はしっかり食べないと後半考えられなくなるので、早起きしてきちんと朝食をとるのは大事だと思います。

おわりに

第4回の受験者は前回から220人増えて500人程になったということでテスト系の資格・QAという仕事も一般的になって来たのかなぁという印象です。
今回は考えられる準備をちゃんとして臨んだので落ちたときは、「分からない場所が分かっていない=何も分かってない」なので1から勉強し直しの必要があるという不安な日もありましたが無事に合格できてよかったです。
取得していない認定資格はテストマネージャもあるので、ゆくゆくは取得できたらなぁと思ってます。ほかにもスクラムで開発しているので、英語を勉強してアジャイルテスターの資格を取りたいなぁとか思っています。

状態遷移図・表の書き方&考え方

はじめに

状態遷移図の話を書こうと思いながら前回のブログから1ヶ月経ってしまっているので徒然と書くことにする。

状態遷移図とは

本を読んだ内で一番分かりやすかったのはテスト会社がやっていた有償のセミナーでエッセンスを聞いたのが非常に分かりやすかったんだが色々問題が歩きがするので、今回もwikipedia先生に解説していただく。

状態遷移図 - Wikipedia

Wikipediaを読んで分かったが自分が知っている状態遷移図というのはUML図におけるステートマシン図(state machine diagram、状態機械図)というものがルーツにあってそれを簡略化しているということが分かった。
今回はふんわり分かれば良いので簡略した書き事を書く。

書き方のルール

正しいお作法についてはwiki参照(UML)
今回はふんわり分かれば良いので下記のルールで書いた。(差分は赤文字)

  • 塗りつぶされた円が START(開始)を意味する。必須ではない。
  • 中抜きの円は STOP(停止)を意味する。必須ではない。
  • で状態を表す。
  • 矢印が操作・振る舞いを表す。

実際に書いてみる

テーマ

腕時計のストップウォッチ機能

f:id:riririusei99:20180921005935p:plain
※便宜的に上のボタンをA、下のボタンをBとする。

振る舞い(仕様)

  • 初期状態は針が0を指している状態
  • 初期状態でAボタンを押すと針が動き出し、計測開始する
  • 計測開始状態でAボタンを押すと針が止まり、一時停止する
  • 一時停止状態でAボタンを押すと針が再度動き出し、計測開始する
  • 一時停止状態でBボタンを押すと針が0を指し、初期状態へリセットされる

状態遷移図

振る舞いに書かれた情報を元に、状態遷移図を書くと下記のような図になるはず。
この時計にはAボタンには3つの機能があることがわかる。(計測開始、一時停止、計測再開)

f:id:riririusei99:20180921014221p:plain

状態遷移表とは

状態遷移図をもとに今度は操作の一覧を表に落とし込むのが状態遷移表である。 もしかしてこれもwikiありそう…と思ったらやっぱりあった。

状態遷移表 - Wikipedia

すご~くざっくり書くと

書き方のルール

  • 縦軸に現在の状態
  • 横軸に操作
  • 交わる場所に操作後の状態を書く

実際に書いてみる

STEP1:図から表に落とし込む

書き方のルールに基づいて図を表に落とし込むと下記の様になる。

状態/操作 Aボタン Bボタン
初期状態 計測開始
計測開始 一時停止
一時停止 計測開始 初期状態

交わったセルが状態遷移テストにおける一つのテストケースになる。
表では空白が2つできているため、想定結果がわからない状態(もしくは仕様が決まっていない状態)なのできちんと仕様を確認することが重要。
ここらへんの考慮漏れとかを早い段階で指摘するのがテスト設計での腕の見せどころかもしれない。

STEP2:足りない部分を落とし込む

足りない部分を追記したバージョン

状態/操作 Aボタン Bボタン
初期状態 計測開始 初期状態※1
計測開始 一時停止 計測開始※2
一時停止 計測開始 初期状態

※1: ボタンは押せるが、状態遷移しない
※2: ボタンがロックされるため、状態遷移しない

この状態で初めてすべての表が埋まりテス実施できるようになった。
今回は物理的な時計の話なのでどの状態でも常に2つのボタンを押すことができたが、そもそも操作ができない場合などは「N/A(not available)」と書いたりする。

まとめ

状態遷移図・表の書き方を書いてみた。
実際の業務では操作が複数の状態を起因にして違ったり、操作の数が多いとかあるので図や表が複雑になりがち。
本当はNスイッチの話もしたかったんだけどまた次の機会かなぁ。

おわり