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の働き方は親和性ありそうなので、他の人もそういった人が増えている…のかな？
△：コードが書けるQAになる
GWを使ってTech CAMPのイナズマコースを受講。
Ruby on Railsを使って簡単なMVCのWebアプリを作れるようになった。
何かフレームワークを覚えたいなと思っていたのでまとまった時間を使って取り組めたのはよかった。
その後、カスタマーサポートに異動になったり、リーダー業の比重が高まってコードを書く機会が減ってしまったのはちょっと残念。
来年は業務以外の個人でE2Eのテストコード書いたり、新しいアプリ開発してみるのも楽しいかなとか思っている。
作ったもの
github.com
また、Salesforceの標準機能を使った機能開発とかする機会があったので、仕様検討と設計とかの業務をすることができた。
仕様検討→設計→実装→テスト→ドキュメンテーションの流れを一人でできたのはとてもよかった。
△：英語学習
2019年になって、海外拠点のメンバーとの会議や仕事をする機会が増えた。
１時間まるっと自動テストについて会議したり、１ヶ月間同じチームになって一緒にバックログ作ったり仕様検討したりした…。
相手側もゆっくり話してくれたりしたおかげでなんとかなったけれど、現状のままでは非常に厳しいというのを痛感した。
そして、リスニングはもちろんだけれど自分の話したいことを伝えるには圧倒的にスピーキングの練習が必要だと感じた。
来年はこういった機会がさらに増えそうなのでもっと頑張らないとなぁ…。
2020年の目標を定める
2020年も引き続き「自力をつける」は継続の予定。
QA系は新しいスキルと言うよりも新たな分野に挑戦するような仕事をしたい。
あとはスクラムチームの外に対しても影響力を発揮できるようなエンジニアになりたい。
Salesforce系の資格を取る
2019年はカスタマーサポートを通してSalesforceの知識をいろいろつけることができた。
きりの良いところで形にしておきたい。
認定プロダクトオーナーを取る
スクラムチームのメンバーに対して認定スクラムマスター研修はすごく役に立った一方で、スクラムチームの活動についてステークホルダーにきちんと理解してもらったり、最終的な判断を下すPOの力になることでもっと良いチームになるかもと思ったので2020年は認定プロダクトオーナー研修に行きたい。
コードを書く
自分の働き方としては、仕事でコードが書ければ一番嬉しいことなんだけれど、周りから評価される・求められる働き方が違いそう。
スクラムマスターやったり、QAチームの仕組みを作ったり、困っているチームのスポットのヘルプに入ったり、スポットの特設チームの立ち上げしたりするとこを求められたりする。
場合によってはそのうちプロダクトコードの修正したり自動テスト書いたりも求められそうなので、きちんと準備しておく。
2019年はRubyだったけど、2020年は今のチームが使っている言語・フレームワークについて理解を深めることはしておきたいなぁ。
ブログを書く
2019年はほとんどブログを書かないで一年が終わってしまった。
2019年の後半では自分の思いや考えている施策について発信する機会が増えたので、あらかじめきちんとまとめたり・書いてあったりしたら便利なのでブログとかに残しておきたいなぁと思っている。
英語教育
これはまずいと思ったので英語力のベースアップを頑張る。
正直、自分の英語力はあまりにもひどいので、何をやっても前進しかなさそう。
なのでとりあえず、単語の勉強と英会話の機会を増やして自分の中で文章を構成するトレーニングを行いたい。
映画を楽しむ
ここまでカタめな話だったので、趣味の話。
毎月、映画館で映画を観る人は趣味は映画と名乗っても良いそうなので映画についても感想だったりを書けたら良いなぁ。
終わりに
と言うことをつらつら書いてたら2019年も残り１分だということなのでここら辺で一区切り。 2019年は仕事としてはとても躍進したので、2020年も同じ勢いで進んで行きたい。
おわり
2019年に学んだ「意思決定」の際に大切にしていること
- はじめに
- 素早く決める。決断のハードルを下げる。
- 選択の先を見極める。「不可逆な意思決定」は慎重に検討する。
- 勇気と蛮勇 ～重要な決断で犬死はしないこと～
- 聞こえの良い理想だけではなく、現実を生きるために覚悟を決める
- おわりに
はじめに
12月も下旬に差し掛かろうとしているので、この機会に本年の振り返りを行い、頭の中も整理しようということで備忘録を兼ねて投稿。
QAチームのチームリーダとして役割を担い始めたのが2018年の12月なので、今年は丸1年リーダー業をなんとか実施することができた。
あらためて今年を振り返ってみると、2019年は否応なしに「意思決定」を求められた一年だったと思う。
QAチームのリーダーをやりつつCSチームに異動したり、タスクフォースを1年間継続させるために奔走したり、これまでに実施したことないプロジェクトを成功に導くためには全体の流れを自身で描きつつ問題に対して解決策を実践することが必要で、その時々で重要な意思決定を迫られる場面が何度かあった。
思い返すと、上手く行ったものや、別の手があったかもという筋の良くないものもあったが、何度かそういった意思決定を繰り返し経験をすることで、自分の中で重要なポイントみたいなものが存在することを朧気ながら感じた。
今回は大事だと思ったポイントや考えについて、共感した書籍・ブログ記事等を紹介しながら書き残すことにした。
素早く決める。決断のハードルを下げる。
普段過ごしているチームの開発手法であるスクラムはよく分からない事（不確実性）に対してアプローチする手法だと考えている。
仮設検証を短いサイクルで回しフィードバックを受けることで、目的に対してその都度方針を修正しながら大きな目標に向かっていくフレームワークだと思っている。
そのため大事なことは、方針を素早く決める（仮説検証サイクルを回すこと）だし、決めた後もその都度修正するものだからこそ、選択自体に時間をかけないことは重要だと思っている。
意思決定の速さみたいなのはSmartHRの代表、宮田昇始さんのブログはとても共感できたので非常におススメ。（この記事は短いのですぐ読める。）
また、やってみるとわかるのですが、ミスって変なものを頼むことは少なく、結果に差を感じないんですよね。逆に、熟考しても失敗することはある。よく『 "5秒で考えた手" と "30分かけて考えた手" は、実際のところ86％が同じ手である』と言いますが、「熟考しても結果に大差はない」「結果が悪くても大したことない」ということを日常的に刷り込むのがいいのかなと思います。
選択の先を見極める。「不可逆な意思決定」は慎重に検討する。
では何でもかんでも素早く判断すればいいんだっけと聞かれたら、自分の答えはNoだ。
なぜなら、一度判断したら取り返しのつかないことや撤回することができない選択も中には存在するからだ。
重要なことは先ほど書いた、「素早く決めるもの」と「慎重に決めるもの」を見極めることだと思う。
前の項目で書いた通り、「素早く決めるもの」＝「後で修正できること」だと思えば分かりやすい。
では逆に「慎重に決めるもの」は何だろう。自分の中では下記のブログの「不可逆な意思決定」というのが自分の中でしっくり来たので紹介したい。
不可逆な意思決定とは、一言でいえば、「一度決めて前に進めてしまうと、簡単に元の状態には戻せない意思決定」のことです。スタートアップにとってはまさに資本政策がそうですし、価格を下げる意思決定なども（価格は一度下げてしまうと上げずらいという意味で）不可逆な意思決定に当てはまると思います。
他にも、普段自分が大事にしなければいけない観点も「慎重に決めるもの」に含まれると思う。
例で言うと、QAエンジニアなら「人・モノ・カネに関係するテスト」は繊細に扱うテーマなのでこう言ったものも判断材料を集め、慎重に検討する意思決定の類だと考えられる。
勇気と蛮勇 ～重要な決断で犬死はしないこと～
不可逆な決断や重要な決断をするときに大切なことは、適切なタイミングや目的に即した決断なのか客観的かつ冷静な判断が必要だ。
2019年の自分はあまり出来なかったと思っている部分だと考えている。
結果として、自分に起きる変化・影響は考えられてもチームのメンバーの影響やもっというと周りがどう思うかまでは考えが至らず、多大なる迷惑をかけ失敗したこともあった。
実際、仕事上の決断なので命までは取られないのだけれど、危機的状況の中でも冷静な判断を下すということはすごく難しい。
そういったメンタルや心の在り方について、新渡戸稲造は「武士道」の中で「勇」として言及しており、とても参考になった。（できるとは言ってない。）
下記は書籍の中の水戸光圀の言葉
「戦場に飛び込み、討ち死にするのはいともたやすきことにて、身分の賤しき者にもできる。生きるべきときは生き、死ぬべきときにのみ死ぬことこそ、真の勇気である」
武士道 | 新渡戸稲造著 岬龍一郎訳 | 書籍 | PHP研究所
聞こえの良い理想だけではなく、現実を生きるために覚悟を決める
危機的状況に陥った時や、あるべき姿と現実が乖離している場合、なんらかの手段を講じる必要があるのだけれど結構な割合であるべき姿、理想に向かって一直線に進もうとした結果、上手く行かないケースをよく見てきた。
そうしたケースは理想と現実の乖離があまりにもかけ離れている場合がほとんどで、その時の急場をしのぐ最善の手段になっていないからだ。
大事なことは急がなければならないのはもちろんだが、焦らないことこそが重要だと思えるようになった。
理想と現実の乖離を埋めるため、決定したことを実現するために、耐え忍びながら変化していくことを受け入れる必要がある。
現在の課題を一気に解決してくれる銀の弾丸は無いし、忘れがちな当たり前のことを積み上げていく意識をすり合わせすることの大切さを学んだ。
ちなみに、改革をテーマにしたときに戦略企画室の方に「上杉鷹山」についておススメされたので本を読んでみたところとても共感できたので紹介しておく。
備えのほうは予定通りには進まない。そのうちに困難な事態のほうが先に押し寄せてきてしまう。これに対してどうすればよいか。
有効な手段などあるはずがない。最善の方法がなければ、次善、三善の策を、それもなければ、少なくとも最悪でない方法を取るよりほかにはあるまい。
また、本の中で鷹山の根底にあるものは以下と書かれており、TeamGeekのHRTを思い出した。
米沢藩における鷹山の政治および経済政策は、ただ施策として優れていたばかりではない。その底には、鷹山の無比の誠実さと謙虚さ、そして人々に対する地合いの心がゆるぎなく根を下ろしていた。
HRTとは
- 謙虚(Humility)
- 尊敬(Respect)
- 信頼(Trust)
おわりに
つらつらと思ったことをいろいろ書いた結果、結構な量になってしまったけれど、普段自分の意思決定がどのように考えて、何を大事にしているかみたいなのの一片をアウトプットできたのは個人的にはよかったかなと思う。
重要な決定をした後は、その選択を正しい結果に進むように努力する必要があると思っていて、そのためにチームリーダーは、協力できるための仕組み・環境を整備したり、意思決定のプロセスがメンバーが納得できる説明・透明性を確保することなんだろうなぁと思っている。
もちろん自分もスクラムチームの一メンバーでもあるので、最後に自分が大切にしている「銃士の姿勢」を紹介にして終わりにしようと思う。
大事な決断って結構メンタル削られたり、不安だったりするのでそういう人を見かけたら一緒に共犯になって片棒を担ぐようにしている。
開発チーム（とスクラムチーム！）のメンバーは、三銃士と同じ姿勢を持たなければならない。「ひとりはみんなのために、みんなはひとりのために」である。この銃士の姿勢は、仕事を成し遂げる責任をチームメンバー全員が負うという点を強調する
おわり。
以上の記事はチームスピリットアドベントカレンダーのExtra Post枠（控え）
QAからCSへレンタル移籍をしてきた話
はじめに
プロフィールでは「スニーカー好きのQAエンジニア」と書いていましたが、若干訂正があり…。
実は2019/06/10 ～ 2019/10/31のおよそ5か月の間、社内のカスタマーサクセス（CS）チームへレンタル移籍に行っていました。
なのでここ5か月弱くらいはほとんどカスタマーサクセスサポートがメイン業務でしたので訂正しておきます。
とはいえ振り返ってみると、QAエンジニアとしてはとても良い経験だったのでここに書いておきたいと思います。
(また、１１月からはQAエンジニアとして再始動です。)
レンタル移籍の経緯
件のチームメンバーの退職＆産休が重なり、局所的にメンバーが不足するということで、ヘルプのメンバーの招集がかかり、開発チームから自分とバックエンドエンジニアの二人でヘルプに行くことになった。
他の職種にチャレンジする際の注意事項として、伝えたいことは一言だけです。
望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。
今回はチャレンジに前向きなメンバーでヘルプに行ったため、二人とも非常に実りがある時間を過ごすことができました。
一方でもしそうでない場合は、トラブルになりかねない出来事だと思うので要注意。
ホントに注意。
CS（Customer Success）チームの仕事内容
Salesforce上のアプリケーションなのでユーザーのシステム管理者からComunity Cloud上であげられるサポートケースの調査・回答がメインの業務として行いました。
開発チームでの詳しい領域（勤怠管理）のケースを中心に割り振られて回答していました。
その他アカウント管理や、データ修正もあわせて実施。
この辺りはQAエンジニア前の前に運用プロジェクトのエンジニアとして働いていたこと、サポートチームが手厚い研修をしてくれたため、比較的すんなりと働くことができました。
また、偶然二人で行く形になったのですが、同じ境遇の同期（厳密には違うけど）がいるのはかなり良かった。
分からないながらも助け合うことができたり、互いにレビュー等ができたので、それもまた良い方向に作用したかなと思っています。
よかった事・悪かった事
〇：ドメイン知識がついた
サポートケースに回答する以上、質問を正確に理解して正しい回答をする必要がある。
製品に関する知識、Salesforceに関する知識、勤怠管理にまつわる業務知識、が質問者と同等の理解にないとケースには回答できない。
そのため、検証環境を用意して、実際に問い合わせ内容が再現できるか・案内した手順が実施できるか検証を行う。
この仕事は開発でのバグの再現確認等とかなり近しい仕事に感じられた。
違いとしては、QAの時はある程度で調査を切り上げてfixを担当するメンバーに任せることができたが、原因を突き止める（回答として伝えられる）まで調べる必要があるのが大きい。
結果としては粘り強くやることや、限られた時間の中で戦略的に進める力が養われ、自信の知識を整理やさらに深めるために有意義な時間となった。
〇：ユーザーの声が聴ける
人事や総務が片手間で対応する場合や、システム開発部の担当などシステム管理者といっても様々な属性があることが分かった。 そして、作る側にとって難しい仕様は大抵ユーザー側も理解するのが難しい機能になるということが認識できた。
また、ユーザーにとって、問題が製品部分なのか自身のブラウザやネットワークなのかは関係なく、「機能が使えない」という一つの状態になってしまう。
そして、往々にして状況を切り分けるための情報が足りていないことが多い。
そのため、サポートで切り分けやある程度は相手の気持ちになって状況の推理する必要がある仕事だということが分かった。
（ちなみに変に勘ぐってしまい検討違いの回答をする可能性もあるので、思い切ってきちんと状況を整理する等のコミュニケーション力も必要）
〇：様々な背景のメンバーと話せる＆仲良くなる
前職で人事の営業だったり、歴戦の導入メンバーだったり、普段開発チームにはいないようなメンバーと話す・一緒に仕事をすることができた。
日々の会話の中で新しいインプットが入ってきたりすることで、また別の刺激になった。
サポートケース対応がないときは、仲良くなった営業メンバーが使う資料のデモ画面の準備を手伝ったり、開発メンバーの時とは違った種類の差し込みタスクは新鮮。
×：引継ぎは計画的に
突発的に移動してしまったので、残されたQAメンバーに負荷を与える結果になってしまい、本当に申し訳ないことをしてしまった。
本当に申し訳ない気持ちでいっぱいです。
結果的にお詫びの肉をおごることで難を逃れたが、きちんと仕事の引継ぎはするべきだと思いました。
あれ、でも…自分も肉おごられても良いのでは…。
まとめ
QAエンジニアに必要なスキルとしてはテストの技術といった「テクニカルスキル」のほかに「ドメインスキル」が重要だと思っている。
そういう意味でいうと製品のドメインや顧客の属性など様々な情報をインプットすることができたので非常に有意義な時間を過ごすことができた。
一方で、有意義な時間を送れたからといって全員が同じ経験をすべきかというとそうでないと思っている。
CSチームでのやりがいはお客様の成功（カスタマーサクセス）を通して感じれるかどうかがポイントになりそうだと思った。
自分の場合は、困っているシステム管理者がケースを通して課題を解決していく姿に立ち会うことで開発とは違ったやりがいや仕事の意義を見出すことができた。
一方で、開発チームとしてのやりがいというのは難しい機能・案件をリリースしたりチームに貢献したりすることで感じる部分だと思っている。 なので、互いにやりがい・難しいポイントが違うからこそ、合わない人が同じ経験をしたところでなんの実りにならない時間を過ごすことになってしまうので…要注意。
QAエンジニアの自分としてはとても良い経験だったので、ちょっと伸び悩んでて興味がある人はあえて新しい環境に身を置くことで新しい発見があるかもしれないと書いておく。
ただ、望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。という一言に尽きるかなと思う。
【おまけ】QAエンジニアとしての活動＋その他
CSチームに所属しながら…
勉強会を開いた＆登壇したり…
【増枠】QuALiTy~QAエンジニアによるLT大会~ - connpass
認定スクラムマスター研修受けたり…
認定スクラムマスターになった（LSM）
— No.9@なまい (@riririusei99) August 3, 2019
会社のオフィスの引っ越しをしたり…
JSTQBテストマネージャ試験受けたり…
引越し大名やってたせいで、試験勉強の完成度としてはすごい自信ない…。
— No.9@なまい (@riririusei99) August 24, 2019
JaSST北海道で登壇したり…
してました！
（意外といろいろやってた）
おわり
JSTQBテストアナリストの勉強方法を書いてみる。
はじめに
２月に受験したJSTQB Adavanced Level テストアナリスト試験の結果発表があり、見事に合格することができました。
今回の記事は合格までの道筋・勉強方法を書いていければと思っています。
JTQB Adavanced Level TA(テストアナリスト)試験とは
世界で最も普及しているソフトウェアテストの認定機関であるISTQB資格を日本で受けられるというもの。
現在日本で受けられる資格としては、Foundation試験（FL）・テストマネージャ試験（TM）・テストアナリスト試験（TA）がある。
Advanced Levelの試験については応募資格のレギュレーションがある
- JSTQB認定テスト技術者資格 Foundation Level資格の合格者、JSTQB（日本）以外のFoundation Level資格の合格者
- 業務経験3年以上（業務経歴申請書の提出あり）
Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board
Advanced Level試験／資格試験－JSTQB認定テスト技術者資格／日科技連|ソフトウェア品質|SQiP研究会
STEP0. 前回の受験
実は2018年もTA試験を受験して落ちています。
- 動機：マネージャが受けるからとりあえず受けてみた（自腹だから落ちてもいいよねマインド）
- 勉強：忙しさにかまけて、さらっとシラバスを読んだだけ
- 試験当日： さーっと進めたら30分くらい余ったので先に帰った
この時点で受かる気がなさそうですが、当日の試験はテスト技法をあてこんだり、状況に応じて対応を判断するような実例問題が中心だったので「いつもの仕事の延長だ」とか「いろんなシステムを想定して問題が面白かった」とか「ワンチャン受かるのでは…」と試験を甘く見てましたが見事に落ちました。（マネージャは見事に合格しました）
という恥ずかしい失敗経験をかき消したいというモチベーションを元に今回の資格試験に臨んでます。
STEP1. 申し込み
まずはHPをよく読み、受付している期間に申し込みを行います。（仕事が忙しくなると、試験日は大体いつか覚えてられるが申し込みの締め切り日は忘れそうになるので注意。） 申し込み時にはFL認定証の写しやFLでの認定番号が必要になるので、あらかじめ準備しておく。（職場で申し込もうとすると大抵、手元にない） 初回受験時は業務経歴申請書を提出する必要がある（メールで案内が来る）ので、募集要項からダウンロードして作成します。
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から勉強し直しの必要があるという不安な日もありましたが無事に合格できてよかったです。
取得していない認定資格はテストマネージャもあるので、ゆくゆくは取得できたらなぁと思ってます。ほかにもスクラムで開発しているので、英語を勉強してアジャイルテスターの資格を取りたいなぁとか思っています。
状態遷移図・表の書き方＆考え方
はじめに
状態遷移図の話を書こうと思いながら前回のブログから１ヶ月経ってしまっているので徒然と書くことにする。
状態遷移図とは
本を読んだ内で一番分かりやすかったのはテスト会社がやっていた有償のセミナーでエッセンスを聞いたのが非常に分かりやすかったんだが色々問題が歩きがするので、今回もwikipedia先生に解説していただく。
Wikipediaを読んで分かったが自分が知っている状態遷移図というのはUML図におけるステートマシン図（state machine diagram、状態機械図）というものがルーツにあってそれを簡略化しているということが分かった。
今回はふんわり分かれば良いので簡略した書き事を書く。
書き方のルール
正しいお作法についてはwiki参照(UML)
今回はふんわり分かれば良いので下記のルールで書いた。（差分は赤文字）
- 塗りつぶされた円が START（開始）を意味する。必須ではない。
- 中抜きの円は STOP（停止）を意味する。必須ではない。
- 丸で状態を表す。
- 矢印が操作・振る舞いを表す。
実際に書いてみる
テーマ
腕時計のストップウォッチ機能
※便宜的に上のボタンをA、下のボタンをBとする。
振る舞い（仕様）
- 初期状態は針が0を指している状態
- 初期状態でAボタンを押すと針が動き出し、計測開始する
- 計測開始状態でAボタンを押すと針が止まり、一時停止する
- 一時停止状態でAボタンを押すと針が再度動き出し、計測開始する
- 一時停止状態でBボタンを押すと針が0を指し、初期状態へリセットされる
状態遷移図
振る舞いに書かれた情報を元に、状態遷移図を書くと下記のような図になるはず。
この時計にはAボタンには3つの機能があることがわかる。（計測開始、一時停止、計測再開）
状態遷移表とは
状態遷移図をもとに今度は操作の一覧を表に落とし込むのが状態遷移表である。 もしかしてこれもwikiありそう…と思ったらやっぱりあった。
すご～くざっくり書くと
書き方のルール
- 縦軸に現在の状態
- 横軸に操作
- 交わる場所に操作後の状態を書く
実際に書いてみる
STEP1:図から表に落とし込む
書き方のルールに基づいて図を表に落とし込むと下記の様になる。
| 状態/操作 | Aボタン | Bボタン |
|---|---|---|
| 初期状態 | 計測開始 | |
| 計測開始 | 一時停止 | |
| 一時停止 | 計測開始 | 初期状態 |
交わったセルが状態遷移テストにおける一つのテストケースになる。
表では空白が2つできているため、想定結果がわからない状態（もしくは仕様が決まっていない状態）なのできちんと仕様を確認することが重要。
ここらへんの考慮漏れとかを早い段階で指摘するのがテスト設計での腕の見せどころかもしれない。
STEP2:足りない部分を落とし込む
足りない部分を追記したバージョン
| 状態/操作 | Aボタン | Bボタン |
|---|---|---|
| 初期状態 | 計測開始 | 初期状態※１ |
| 計測開始 | 一時停止 | 計測開始※２ |
| 一時停止 | 計測開始 | 初期状態 |
※1: ボタンは押せるが、状態遷移しない
※2: ボタンがロックされるため、状態遷移しない
この状態で初めてすべての表が埋まりテス実施できるようになった。
今回は物理的な時計の話なのでどの状態でも常に2つのボタンを押すことができたが、そもそも操作ができない場合などは「N/A(not available)」と書いたりする。
まとめ
状態遷移図・表の書き方を書いてみた。
実際の業務では操作が複数の状態を起因にして違ったり、操作の数が多いとかあるので図や表が複雑になりがち。
本当はNスイッチの話もしたかったんだけどまた次の機会かなぁ。
おわり
c0,c1,c2カバレッジってなんだっけな話
はじめに
c0,c1カバレッジと状態遷移図のnスイッチの話が自分の中でごっちゃになってたので調べて自分の中で整理する話です。
※状態遷移図テストとnスイッチの話もしようと思ったが、長くなりそうなので今回はc0,c1カバレッジを
教えてwiki先生！！
Wikipediaがいろいろ書いててとてもわかり易かった。
なるほど、c0とかのカバレッジはホワイトボックスの手法なんだなと分かった。
- 命令網羅 (statement coverage) (C0)
- 分岐網羅 (branch coverage) (C1)
- 条件網羅 (condition coverage) (C2)
自分の中で理解する
というわけでサンプルプログラムを書いてみた。
雑に書いたサンプルプログラム （Javascriptで引数は数値なイメージです。）
【追記】 二個目の分岐の中でx,yを使用していたため、後述するテストケースでは網羅できなくなるため修正しました。
function outputTriangle(x, y, z){
// 最初の分岐
if(x>0 && y>0){
var area = x * y / 2;
console.log("底面積は" + area);
}else{
console.log("おやおやなにかおかしいぞ");
}
// 二個目の分岐
if(z>0){
console.log("体積は高さ" + z + "を掛けて３で割る！");
}
}
命令網羅 (statement coverage) (C0)
「命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい。」とのこと。(by wiki)
テストケースは下記になりそう。
x=2,y=3,z=4（面積、体積の表示）x=0,y=0,z=0（例外）
分岐網羅 (branch coverage) (C1)
「分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい。」とのこと。
なるほどわからんな状態なので改めて整理する
| 最初の分岐 | ２個めの分岐 | テストデータ例 |
|---|---|---|
| true | true | x=2,y=3,z=4 |
| true | false | x=2,y=3,z=0 |
| false | true | x=2,y=0,z=4 |
| false | false | x=2,y=0,z=0 |
こんな感じか。分岐を意識するんだな！
条件網羅 (condition coverage) (C2)
「条件網羅基準を用いてテストを行う場合は、各々の個別条件について、全ての可能な結果を少なくとも1回はとるように実行すればよい。」
ということで表に落としてみる。
| No | x>0 | y>0 | z>0 | テストデータ |
|---|---|---|---|---|
| 1 | true | true | true | x=2,y=3,z=4 |
| 2 | true | true | false | x=2,y=3,z=0 |
| 3 | true | false | true | x=2,y=0,z=4 |
| 4 | true | false | false | x=2,y=0,z=-1 |
| 5 | false | true | true | x=0,y=3,z=4 |
| 6 | false | true | false | x=-1,y=3,z=-4 |
| 7 | false | false | true | x=-2,y=-3,z=4 |
| 8 | false | false | false | x=-3,y=-2,z=-4 |
補足
なお、判定結果に影響を与えない真理値に関しては省略しても良い。と書いてあったのでこちらを考慮するとこんな感じでしょうか。
短絡評価
| No | x>0 | y>0 | z>0 | テストデータ | 結果1 | 結果2 |
|---|---|---|---|---|---|---|
| 1 | true | true | true | x=2,y=3,z=4 |
面積表示 | 高さを表示 |
| 2 | true | true | false | x=2,y=3,z=0 |
面積表示 | 表示されない |
| 3 | true | false | true | x=2,y=0,z=4 |
メッセージ | 高さを表示 |
| 4 | true | false | false | x=2,y=0,z=-1 |
メッセージ | 表示されない |
| 5 | false | true | true | x=0,y=3,z=4 |
メッセージ | 高さを表示 |
| 6 | false | true | false | x=-1,y=3,z=-4 |
メッセージ | 表示されない |
| 7 | false | false | true | x=-2,y=-3,z=4 |
メッセージ | 高さを表示 |
| 8 | false | false | false | x=-3,y=-2,z=-4 |
メッセージ | 表示されない |
x>0が満たされない時点でyの値は判定結果に影響を与えないので省略できる。 なので5,7と6,8は同じテストケースと判断する事ができそうなので省略する。
短絡評価後
| No | x>0 | y>0 | z>0 | テストデータ | 結果1 | 結果2 |
|---|---|---|---|---|---|---|
| 1 | true | true | true | x=2,y=3,z=4 |
面積表示 | 高さを表示 |
| 2 | true | true | false | x=2,y=3,z=0 |
面積表示 | 表示されない |
| 3 | true | false | true | x=2,y=0,z=4 |
メッセージ | 高さを表示 |
| 4 | true | false | false | x=2,y=0,z=-1 |
メッセージ | 表示されない |
| 5 | false | (true) | true | x=0,y=3,z=4 |
メッセージ | 高さを表示 |
| 8 | false | (false) | false | x=-3,y=-2,z=-4 |
メッセージ | 表示されない |
5,6でもいいはずなんだけど個人的にこっちの方がいい気がするので5,8とした。
もっと言うと、3,4と5,8は結果が同じなので更に削ることが可能だよね！（今回はここまで）
こんな感じか。分岐の条件を意識するんだな！
その他のカバレッジ
その他にはこんなのものある様子。
- 判定条件／条件網羅 (decision/condition coverage)
- 複合条件網羅 (multiple condition coverage)
- 経路網羅 (path coverage)
また静的解析でのカバレッジについては若干ニュアンスが違うので注意されたし。
感想
プログラム的には体積の表示は最初のエラーが出た時点で計算ができないから表示させたくなかったのだけれど、意図的に変な書き方になっています。
テストデータに文字列とかを入れると結果がエラー内容が変わって来ちゃったりするのですがいろいろややこしくなるので今回は簡素にこんな形にしました。
理解はしていたつもりだったけど実際に書いて確かめるって大事だと改めて思いました。
Javascriptの単体テストを書く（power-assert）
はじめに
単体テストについてはE2Eを組む前段で用意してたことはあるのだけれど、真面目に書くことがなかったのでpower-assertを使ってテストコードを書くことに挑戦してみる。
参考
みんなのPowerAssert github.com
インストール
$ npm install mocha espower-loader intelli-espower-loader power-assert --save-dev
ディレクトリ構成
.
├── node_modules
├── package.json
├── src
│ └── Calculator.js
└── test
└── test.js
対象&テストコード
Calculator.js
module.exports = class Calculator {
constructor(name){
this.name = name;
}
plus(x, y){
return x + y;
}
minus(x, y){
return x - y;
}
divide(x, y){
return x / y;
}
};
test.js
const Calculator = require('../src/Calculator');
const calculator = new Calculator('riririusei99');
const assert = require('power-assert');
describe('Test plus', function(){
it('shoud return 3 when value is number', function(){
assert(calculator.plus(1,2) === 3);
});
it('【ERROR SAMPLE】shoud return "12"', function(){
assert(calculator.plus("1","2") === 12);
});
});
describe('Test minus', function(){
it('shoud return 3 when value is number', function(){
assert(calculator.minus(5,2) === 3);
});
it('shoud return -2 when value is number', function(){
assert(calculator.minus(3,5) === -2);
});
});
describe('Test devide', function(){
it('shuoud return 1 when value is number', function(){
assert(calculator.divide(5,5) === 1);
});
it('shuoud return error when 0 divide', function(){
assert(calculator.divide(5,0) === Infinity);
});
});
テスト実行
power-assertのREADMEを参考に実行する
$ node_modules/mocha/bin/mocha --require intelli-espower-loader test/test.js
こんな感じで出力される
おわりに
環境の準備は割とさっくりできた。
テストの書き方とかが大事なんだろうなぁというかんじなので、次回はもう少し複雑なコードに対してテストを書いてみるみたいなのをやってみたい。
CTFで作ったお遊びスクリプトとかがちょうど良さそう。
