yoshitake_1201’s diary

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

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

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と同じですかね。

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

感想

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

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

勉強会やカンファレンスで写真を撮るときはMicrosoft Pixカメラがオススメ

その他

f:id:yoshitake_1201:20190410154930p:plain

最近カンファレンスや勉強会で「講演中の写真撮影OK」というのが増えてきている気がします（私が知らなかっただけかもしれないですけど） 。
直近参加したJaSST'19 TokyoでもゆるっとITでも写真撮影がOKでしたし。
最近では大学の授業中でも写真を撮ることが許可されてたりもするので、かなり一般的になっているんだなと感じます。
実際撮れると便利ですよね。

だけど音や動作が気になる…

ただ、OKだからといってカシャカシャ音鳴らしながら撮影すると以下のようなことが発生することもあると思います。

  • 講演者の方の話が聞こえにくくなる
  • 気が散る（講演者、参加者どちらも）

↑のような問題はなくしたいなぁと思って、このブログを書いてみました。
このブログを読んで頂いた方で、他にオススメのアプリ、または行動などあればぜひ教えていただけると幸いです。

無音のカメラアプリを入れる

Microsoft Pix カメラ

Microsoft Pix カメラ

  • Microsoft Corporation
  • 写真／ビデオ
  • 無料

オススメは Microsoft Pix カメラです。
このカメラ、無音なだけでなくドキュメントにいい感じに自動補正かけてくれるなど多機能です。
残念ながらAndroid版はまだ出ていないようですが…。。。

※ 他の無音カメラはこちらを参考ください
app-liv.jp

撮る時のカメラも位置も少しだけ気にしてみる

matome.naver.jp

ジャニーズファンの中ではたくさんのルールがあるそうなんですが、「うちわは胸の高さまで」というルールを知ったときは、ただただすごいなぁと思いました。
掲げすぎると後ろの方が見えなくなっちゃうからそれに配慮したルールってことですよね。

勉強会で写真を撮るときも、少しだけで良いのでこれを気にしてもらえると良いなぁと思いました。

※ 余談なんですが、自分は車を運転しているとき、前を走る車がカーナビや後部座席のモニターにTV番組やアニメを流していると気になっちゃうんですよね。
なので講演中もカメラ撮っている方が気になってしまうことはあったりします。
カメラを撮る時の高さについては気にしすぎなのかもしれないですが、こういった視点もあるなぁと思っていただけると嬉しいです。

登壇する側として

最近、ありがたいことにたまに登壇させていただくことがあります。
そしてつい先日自分も写真撮られる側デビューしたんですが、慣れないものでカメラを向けられると少し気になっちゃいますね（笑）
なので、撮影についてのアプローチとして以下を気をつけようと思いました。

  • スライドを事前公開、または発表直後すぐに公開する
  • 発表開始時にスライドの公開をアナウンスする

自分が一聴講者のとき、スライドが公開されるかどうかなど知れるとかなりありがたいですもんね。
特に講演開始前にスライドを公開している方はすごいと思います！
感謝ですね。

おわりに

写真が撮れなかった、資料が見れなかった場合などは講演終了後に講演者の方に相談してみるなどすると、その場で見せていただくなどできるかもしれません。
どうしても必要な場合などは相談してみるのも手と思います。

また、冒頭にも書きましたが、他にオススメのアプリや行動などあればぜひ教えていただけると嬉しいです。

(おまけ)ワークの成果物などを撮るときにオススメ

Microsoft Office Lens|PDF Scan

Microsoft Office Lens|PDF Scan

play.google.com

このアプリは音鳴っちゃうんですけどね（笑） ワークショップなどをやったときの成果物を写真に撮りたい！ってなるときありますよね。
そのときは↑のMicrosoft Office Lensというアプリがおすすめです。
エクスポート方法も様々ですし、歪み補正やテキスト化してくれたりもします。
※ ワークの成果物の写真撮影は、もちろんですが許可を取ってからお願いします(^^)

「ゆるっとIT vol.10 ソフトウェアテストの話を聞こう」で発表させてもらった #yurutto_it

イベント参加レポート

f:id:yoshitake_1201:20190405194005p:plain

f:id:yoshitake_1201:20190405194027p:plain

イベント概要

ゆるっとIT vol.10 ソフトウェアテストの話を聞こう
yurutto-it.connpass.com

※ 会場提供してくださったさくらインターネットさんがビールなど提供してくださいました。
ありがとうございました！
ビール美味しかったです。

発表資料

speakerdeck.com

発表のきっかけ

ゆるっとIT主催の井関さんから「ソフトウェアテストの話聞きたい！」と声をかけていただきました。
なんの話する〜？と相談して、井関さんにはテストの話をいっぱいしました（笑）
あの時の話…相当散らかってましたね。
井関さんは聞き上手だと思います。
そこからいくつかtopicを頂き、今回の発表内容となりました。
（頂いた全部発表しきれなくて申し訳ない…）

もうちょっと紹介したかった内容

まだまだいっぱいあるんですけどね…。
その中から少しだけ、↓に記事や資料を載っけときます。

testingとcheckingの違い

www.infoq.com dev.classmethod.jp

コードの臭い・不吉な臭い

ja.wikipedia.org

objectclub.jp

テストって実行だけじゃない

f:id:yoshitake_1201:20190405192825p:plain
テスト設計チュートリアル U-30クラス向け 2019年度版 P65より

※ 資料
aster.or.jp

JaSST'19 Tokyoのブログ

以下に私が書いたブログのまとめリンクがあるのでぜひ（笑）

yoshitake-1201.hatenablog.com

個人的な反省点

発表時間をオーバー。。。
まるっとtopic 1つ分足りませんでした。
今後気をつけますm( )m

参加者の方のスコープをある程度絞っていたつもりだったんですが甘かったですね。
rinaさんが良い質問をしてくださいました。 ありがとうございます！
「前提知識」をどう定めるかが難しいです。

また、一般参加してくれてた@saeからは「早口だった」というのをもらったので気をつけます。
たしかに早かった。

あと、質疑応答！
ブレブレになってしまったので、いい回答できるようになりたいです。
JaSSTで登壇されていた方々…やはりすごいです。

感想

今回参加してくださった方々の多くが「開発者」で、メイン業務が「テスト」って方は5人ぐらいだったんですよね。
もともと参加者の想定が「開発者 ≒ プログラム書く方」と聞いていたので、ユニットテストに焦点を当ててみました。
ユニットテストを書くときによく聞く悩みを整理、また悩みに対する考え方などを整理できて個人的には良かったです。

こういった勉強会がきっかけになって開発とテストでもっと交流していけたら良いですね。
勉強会に参加してくださった方がテスト酒場やテスト系の勉強会にも来ていただけたら嬉しいなぁと思いました。
（次の開催日未定なんですけど…（笑）)

では最後になりますが、勉強会来ていただいた方々ありがとうございました！
井関さん、呼んでいただきありがとうございました！

Mac上でIE8、IE9、IE10、IE11、Edgeを使う方法

テスト小ネタ テストに役立つツール

IEとEdgeを使える仮想マシンが公開されている

forest.watch.impress.co.jp developer.microsoft.com

Microsoftが無料でIE8 ~ IE11、Edgeの仮想マシンを公開しています。
利用可能なブラウザ&OSは以下。

方法

  1. 好きなプラットフォームをインストールする
  2. 以下から仮想マシンをダウンロードする(Step.1のプラットフォームを選択する)
  3. Step.1の仮想環境でStep.2のイメージを起動する

※ 90日の有効期限がついているので、起動後（日本語化の設定後）にスナップショットを作成しておいたら便利です。
※ 公式ページにそう書いてくれています（優しいMicrosoft）

These virtual machines expire after 90 days. We recommend setting a snapshot when you first install the virtual machine which you can roll back to later.

以下設定に際して便利な記事です

qiita.com
replication.hatenablog.com
eng-notebook.com
pc-karuma.net
answers.microsoft.com
qiita.com

感想

社内の方に教えてもらいました(^^)
便利ですね。
IEしか再現しないバグのときに実機のWindows PCと一緒に動作させて比較してみたんですが、どちらもちゃんと再現してくれました（当たり前ですね）。
個人的なデメリットは「起動に時間がかかる」「画面が専有される」「メモリ喰う」でしょうか。
なので日常的にはEdgeやIEは実機PCでテストしてます。
手元にWindows10実機がないけど急ぎで確認しないといけないとき…など突発なときは仮想マシン起動してます。

まぁ状況次第で使い分けたらいいかなぁって思いました。

おまけ(IEやEdgeまわりに関係する記事)

japanese.engadget.com japanese.engadget.com

JaSST'19 Tokyo 参加ブログ(個人的全体まとめ)

JaSST JaSST19Tokyo イベント参加レポート

セッションごとに個別にまとめたブログ一覧

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

yoshitake-1201.hatenablog.com

JaSST'19 Tokyo 2日間の参加ブログ（個人的全体まとめ）です。
ただのポエムです。
以下、参加してよかったこと（順不同）です。

Testing ManiaXを手に入れられた！

WACATEのブースでTesting ManiaXを販売していたんですよ。
自分がテスト業界に入る前に発行されていた同人誌なので、もう手に入らないだろうなぁと思ってたんですが、まさか手に入れることができるとは！
vol.1 ~ vol.9の取扱いがあったので全巻即買いしました。
wacateの方々（特に並木さんかな？）ありがとうございました！

※ Software Testing ManiaXとは？
サークルWACATEが2009年 ~ 2015年の間に刊行していたソフトウェアテストに関する同人誌です。
テストに関わる様々な方が寄稿されていました。
全10巻です。

※ WACATEとは？
テストエンジニアを加速させるためのワークショップです。
次回は6/15(土) ~ 6/17(日)開催とのことです。
wacate.jp

自分の頭の中の整理ができた

自分なりに考えながら日々テストに取り組んでるんですが自信が持てないこともあったんです。
「こうした方が良いんじゃないかな〜」と考えてやってるんですが、「これ大丈夫かな？」と不安になってくるというか（笑）。
だけど「テストプロセス改善」、「QA入門」、「テストマネジメントの鉄則」などのセッションに参加したおかげで、ある程度頭の中を整理できたなぁと思いました。 また自分がやってることに対して「」自信を持つことができました。

「テストマネジメントの鉄則」セッションでの湯本さん、町田さんの発言は特に刺さりました。
「自分のことを言っているのではないか？」と思うほどに…。
そんなわけないんですけど、けっこう業界として「あるある」なことで自分は悩んでいたんだなとわかりました。
共感しすぎてセッションの後半ずっとヘドバンしていたレベルで頭振ってました（笑）。

たくさんの方と交流できた

お世話になってる方々とお話できるのがやはりいいですね。
SNSでよく交流させてもらってますが、リアルだからこそ…っていうのはあります。
セッションの内容についても議論・意見交換することができますし。
また、ありがたいことに今回、情報交換会でたくさんの方に話しかけに来てもらったんですよね。
本当ただただありがとうございますでした。

また今回は同じテストチームの@sae(@sito_110)が一緒に参加してたので、相互に@saeを紹介できたのはかなり嬉しかったです。

チームメンバーと一緒にJaSSTに参加できた！

私はこれまで基本1人でJaSSTに参加してたんで、同じチームのメンバーと一緒にJaSSTに参加するっていうのは初めてだったんですよね。
（実はJaSST'17 KyushuやJaSST'18 Kyushuで経験あるんですが、実行委員だったりなんだりがあるので個人的にそれはノーカウント）
あと、実は今回開発チームのメンバーも1人参加してくれていたので弊社からは3名が参加していました。

1人で参加するのも勉強になるので良かったんですが、チームメンバーが一緒に参加してくれるというのは更に良いですね。
お互いが別々のセッションに参加したときはそのセッションの話を聞ける、同じセッションに参加したときは深く議論できる、という。

JaSSTが終わってから空港へ行く途中や会社に戻ってからのふりかえりなどなどで話が尽きませんでした（一緒に行動していた@saeがそれで喜んでいるかは話が別です。 たぶんうざがられてもいると思います）。

2人以上で参加されていた方々はこれまで、こんないい経験してたんですね。
羨ましくなりました。

感想

参加できてよかった。というのがただただ感想ですね。
語彙力が残念です。

東京は昨年から続いて2回目の参加だったんですがやはり規模がすごいですね。
また、今年はパネルトークが多かった印象で、現場や業界最前線で取り組まれている方のお話を聞くことができたので知見を広く得ることができたと思いました。

基調講演に海外の方を呼んでくださるので世界の話が聴けるというのもかなりいいですね。
昨年に続いて自分の現状との差が大きくて、頑張っていきたいなぁと思いました。

講演者の方々、実行委員の方々、お話してくださった方々、ありがとうございました〜。