JaSST新潟参加レポート
今回は8/9（金）に開催されたJaSST'24 Niigataに現地参加してきたので、参加レポートを書いていきます！
もくじ
基調講演
今回のJaSST新潟テーマは「アクセシビリティ」ということで、山本怜さんが基調講演に登壇されていました。
資料：
このあと13:00からのJaSST '24 Niigata 基調講演の資料を置いておきます #jasstniigata
— ymrl (@ymrl) 2024年8月9日
「いま求められるソフトウェアのアクセシビリティ」https://t.co/ixbfF2Vs7C
学んだこと
現地の様子
開始時間は昼すぎからで、NINNOという会場で行われました。
大きな横に長いスクリーンがあり、スクリーンの前に30人ほど参加者が座る形でした。
また、スポンサーブースが4つあり、各社とも大変盛り上がっていました。（ノベルティもたくさんいただきました🙏）
事例発表やスポンサーセッションなども、アクセシビリティという今回のテーマに沿った内容が多かった印象です。
発表のプログラムが終了すると、会場内で1時間くらい懇親会があり、参加者の方々とお話しする機会がありました。
他社のQAチームの状況やアクセシビリティへの取り組みなどのお話が聞けて有意義でした。
おまけ
帰りに新潟名物のへぎそばをいただきました✨
（写真にalt属性を入れてみました！）
JSTQB ALTM試験を受験しました
先日JSTQB ALTMの受験をしてきたのでそちらについて書きます！
もくじ
受験を決めた理由
QAのスキルを上げるために何か勉強の目標を見つけたかったのと、FLに合格してから3年以上たっていたことに気がついたので受験してみました。
勉強方法
はじめにシラバスのK4レベルをざっと読んでから過去問を解きました。
過去問で間違いを見直したのと、間違いが多い章を中心にシラバスを読んで理解を深め、間違いを全て見直したら再度過去問を解く、を繰り返しました。
また、空き時間や移動時間にシラバスを読んだり、ISTQBの単語クイズなどをやっていました。
受付から試験開始までの流れ
試験会場：新橋航空会館テストセンター（会場は好きなところを選択できます）
持ち物：本人確認書類
- 試験開始の15分前にはついている必要がある
- 本人確認のために身分証明書の提示、写真撮影
- 会場に到着後すぐに荷物は全てロッカーに預ける
- テストセンターについてからちらっと復習しよう、みたいなことはできない
- 受付が完了次第、係の方にメモ用のホワイトノートとペンが支給されて席に案内される
試験
即答できない問題は飛ばして最初にざっと目を通した後、時間を見ながら長文問題などを解いていましたが、見直しを含めると時間ギリギリまで使いました。
問題の分量として、長文問題が4割、知識問題が6割くらいの印象でした。
また、シラバスで使われている言葉のまま出題されるというよりは、ちゃんと理解していないと読み取れないニュアンスになっていた印象でした。
試験終了後
- 受付にホワイトノートとペンを返却
- 受付にて試験終了時間と署名をして終了
予定では6月末に受験する予定だったのですが、都合により延期になり7月末に受けて、結果は受験当日の翌週の木曜日に返ってきました。
そして気になる結果はというと...不合格でした...！
原因を考えた時に、過去問をやりすぎた感がありました。
過去問の中から何かしら同じ問題が出るかもという過度な期待があったのですがそんなことはなく、過去問は問題を解く時間配分や出題形式のシュミレーション程度でよかったなと思いました。
また、過去問に出題されている項目について主に深ぼって学習していたので、単純に全体的な理解が足りていなかったと思います。
反省点を活かし、再度チャレンジしたいです！
また余談ですが、座っていた席がクーラー直当たりだったので凍えながら試験を受けていました❄️
部屋自体も結構冷えてたのと、試験時間も3時間と長いので、夏に新橋テストセンターに受験に行く方は何か羽織るものがあると良いかもしれません。
JaSST'24 Tohoku 参加レポート
今回は、5/31（金）に開催された、JaSST'24 Tohokuに現地参加してきたので、そちらのレポートです！
もくじ
基調講演
井芹久美子さんより、講演「説明できるテストをつくるためにできることを考える」がありました。
公開されているスライド: JaSST'24 Tohoku基調講演/jasst24tohoku_keynote - Speaker Deck
説明できるテストを作るためにできること
- テスト技法を活用
- 段階的に検討
- 欠陥や故障を想定
- モデルを書いて理解
- 求められていることを意識
- 意図や拠り所を言語化
- 適した表現方法を選択
講演を通して、説明できるテストを作るためのポイントとして上記が紹介されていました。
どの項目に関しても学びがあったのですが、特に印象深かったのは「求められることを意識」の部分でした。
テストを分析設計していると、要件や受け入れ条件に気を取られすぎてしまうことがあるので、ステークホルダーの関心はもちろん、他テストの関係性やテストの制約など、多角的な観点から見つめ直し、気にすることを忘れないようにしたいです。
また、講演の内容には直結しないのですが、スライドの見やすさや発表の聞きやすさに感動しました。
講演中に少しワークがあったのですが、ワークの時間や班の中で共有する順番など綿密に決められていて参加者が迷わないようになっていたり、
今話している事柄が今日伝えたいことのうちのどの辺なのかが一目でわかるようにスライドに記載があったりと、とても丁寧な講演でした。
ワークショップ
JaSST東北は毎年ワークを実施するのが特色だそうです。
今回のワークは「同値分割・境界値分析」と「クラシフィケーションツリー技法」でした。
席の周りで4人1組で班になり、各ワークを行いました。
自分が参加していた班はベテランの方はおらず、年が近い方が多かったからか、あーでもないこーでもないみたいな議論でわいわいしていました。
同値分割・境界値分析
今回のJaSST東北のテーマが「あらためて基本のキ」ということで、同値分割・境界値分析のワークがありました。
はじめに同値分割のワークがあり、その次に境界値分析のワークがあったのですが、改めて同値分割のことを考えると、勝手に境界値分析に脳内変換されて別々に考えるのが難しかったです。
クラシフィケーションツリー技法
同値分割・境界値分析に比べてあまり聞き馴染みのないクラシフィケーションツリー技法のワークがありました。
クラシフィケーションツリーとは
クラシフィケーションツリー法は、テストの入力条件をツリー形式の図でグラフィカルに整理して、テストケースを作成する技法です。入力条件を漏れなく整理しテストカバレッジを高めたい場合に有効です。
引用: 「テスト技法」解説 | HQW!
4人で大きな模造紙を囲み、お題に沿ってクラシフィケーションツリーを模造紙に書いていきました。
途中、クラシフィケーションツリーを描くには入力条件をどう分類するのが適切か、班の全員で迷ったところがありましたが、実行委員の方がヒントをくださったり、他の班の成果物を見る時間があり、そこで答え合わせができました。
感想
基調講演でも少しワークがあり、午後の時間はほぼワークの時間だったので、集中力を使ってかなり脳が疲れましたが、限られた時間で班の方とコミュニケーションをとりながら取り組んだのはとても楽しかったです！
当日の懇親会では、スライドの内容やワークの問題はどう答えたかなどのお話で盛り上がり、それぞれ所属されているQAチームでのお悩み事なども聞けたりして大変有意義でした。
余談
人生初東北楽しかったです！
仙台駅着いた時に飲んだずんだシェイクと、当日のランチで食べた牛タン美味しかったです〜！
GW中に読みたい本
4月ももう終盤で、1年の3分の1が過ぎようとしていますね。早すぎる。
そんな今回は、GW中に読まなきゃ〜と思っている本をご紹介します！
優先度が高い順で書いています。
1. JSTQB Advanced Level（テストマネージャ）- シラバス
早速本ではないですが...
私は自分を追い込まないと腰が上がらない人間なので、
6月末にTMを受験するように申し込みました。
GW中に勉強しないとやばいので血眼で読みます。
受験したらそのレポートも書こうと思います！
2. LEADING QUALITY
買ったきり積読になっていたので、この機会に読みます！
3. 伝わる・揺さぶる！文章を書く
amazon：https://www.amazon.co.jp/dp/B0081BBF4K
こちらJaSST'24 Tokyoの講演で紹介されており、気になったのでポチりました。
人に文章で伝えることが苦手なので、何かヒントを得たいなと思っています。
4. やさしく学ぶ 機械学習を理解するための数学のきほん
amazon：https://www.amazon.co.jp/dp/4839963525
会社の所属チームで雑談している時に、機械学習のお話になり、おすすめされていたのでポチりました。
パラ読みしかしてないですが今のところ自分にとってはやさしくないです！
5. “未”顧客理解 なぜ、「買ってくれる人＝顧客」しか見ないのか？
amazon：https://www.amazon.co.jp/dp/B0B4BWVP74
どこでおすすめされていたかは忘れてしまったのですが、気になったのでポチりました。
読むぞ〜
おわり
JaSST'24 Tokyo 視聴レポート
3/14（木）、3/15（金）にJaSST'24 Tokyo が行われました。
今年はハイブリット開催で、自分は全てのコンテンツにオンラインで参加しました。
たくさんの講演の中で、特に印象深かった3つの講演について書いていきます。
もくじ
- 1. B3_QAエンジニアの〇〇UP！キャリア解剖で見える今どきの成長軸とは？
- 2. A6_テストだけでは品質は品質は上がらない？エセ自己組織化した品質組織からの脱却
- 3. E6_「価値あるソフトウェア」の”価値”ってなぁに？
- まとめ
- ざつだん
1. B3_QAエンジニアの〇〇UP！キャリア解剖で見える今どきの成長軸とは？
- セッション概要
- 公開資料
このセッションでは、SigS QAの方々が「プレイヤー」と「マネージャー」の2軸でQAエンジニアの能力UPについて話されていました。
プレイヤーについて
こちらでは、テストって「テストスキル」だけでは成り立たないよね、という旨のお話が印象強かったです。
QAエンジニアに重要な4つのスキルについて
- テストスキル
- ソフトスキル
- ITスキル
- ドメイン知識
QAエンジニアにとって、テストスキルは1/4にすぎない、テストスキルだけ上げようとしても良いQAエンジニアにはなれないので、自分のボトルネックを把握し常に意識しよう、というのがぐさっときました（薄々分かってはいたけど...）
なので早速自分の今のスキルについて、スライドに出てきた図を作成してみました。
テストスキル、ソフトスキルについては、これまでの経験で少しずつ培われているのかなと思います。
現状のボトルネックとしては、ドメイン知識とITスキルかなと感じています。
特にITスキルで、コーディングもですが、機能テスト以外の負荷テストや自動テスト（これはテストスキル？）、セキュリティ、データ解析の分野について知識も経験も浅い状態です。
負荷テスト、データ解析については、業務の中でも今後特に必要となってくる予定なので、学習に力を入れるぞと胸に誓いました...
マネージャーについて
マネージャーについては下記の3つの力UPについて話されていました。
- 理解、分解、再構築する力
- 考え続けて構想する力
- ロール横断思考力
お話の中で、マネージャーには「なんとかする力」が必要、とおっしゃっていたところが印象的でした。
前職でマネジメントについて悩んでいた時に、「どうすればいいのかわからない」じゃなくて、もっと自分から体系的なマネジメントについて学習するべきだったなあと感じました。
また、実際にマネージャーというポジションにいなくても、チームの活動を円滑に行えるように動く時の視点としても身につけておくと良さそうと感じました。
2. A6_テストだけでは品質は品質は上がらない？エセ自己組織化した品質組織からの脱却
- セッション概要
- 公開資料
このセッションでは、指標の計測についてのお話が印象強かったです。
今まで自分は、「FourKeys」についてこの指標を計測し改善するとなんか良くなるらしい、と漠然と認識していました。（お恥ずかしい）
セッションの中で、品質指標についての時代の移り変わりやそれに伴うそれぞれの時代の課題感を踏まえた上で、FourKeysについて「機会損失を最小化するための指標」と話されていて、とても腹落ちし、首がもげるほど頷いてしまいました。
3. E6_「価値あるソフトウェア」の”価値”ってなぁに？
このセッションについて、お三方が熱く価値について語られていたので2時間があっという間でした。
特に、価値の分類についてのお話が印象に残りました。
- デビット・アーカーの価値の3分類
- 自己実現価値
- 情緒的価値（イメージ、印象、愛着）
- 機能的価値（機能、性能）
お話を聞いていて、情緒的価値と機能的価値について、品質特性とも関連を感じました。
それぞれ品質特性が「情緒的価値」につながるのか「機能的価値」につながるのか、はたまた両方を兼ねるのかなどを分類してみたくなりました。
また途中で、安達さんの資料が「価値」について体系的に落とし込まれていて、図解・言語化の神様だ...と、ただただ感動する時間がありました。
まとめ
他にも印象深かったセッションはたくさんあったのですが、今回はここまでにしたいと思います。
去年のJaSST'23 Tokyoでは、普段の業務の課題を解決するためのヒントを得るため、という視点で参加・吸収していました。
今回も、業務上の課題解決へのヒントを得るためというところは変わらないのですが、「テスト」よりも広い視点（アウトカムや価値）についてのお話が多く感じ、それについても少し吸収できたと感じました。
また、今回はハイブリット開催ということで、オフライン勢の方々がとても楽しそうなのをXで眺めてて羨ましくなってしまったので、今後オフラインイベントで気になるものがあれば行ってみたいなと思いました！
ざつだん
このあいだ、今年に入って2回目の打撲をしました🦴 （前回は手の指、今回は足の指）
自分の不注意ぶりにびっくりなのですが、怪我するスパンが短すぎるのでなんかお祓いとか行ったほうが良いのかな、とちょっと迷ってます🔮
個人的にほしいツールの仕様書とデザインを考えてみた
こんにちは。ぜにです。
QAブログと言いながらテストに関する記事とそうでない記事、半々になりそうです。
突然ですが、皆さんは毎日の晩ご飯の献立を考えることやスーパーで何買おう〜となっている時間は好きですか？
自分は好きでも嫌いでもないですができれば短い時間で終わらせたいです。
自炊するようになって初めは楽しかったんですけどね。
そこで今回は、献立を考える＋買い物についてこんなツールがあればな〜〜〜とお風呂で考えていたことを書いていきたいと思います。
ユーザーが解決したいこと
ユーザー（自分）が解決したいこと、手間だと思っていること
- 食べたいメニューが特にない時の献立を考えることが手間
- スーパーで安かった食材を買ってきたけど何に使うか困ることがあるから買うものは予め決めたい
- 一度に数日分の買い物をしたいが、頭の中で数回の献立と食材を紐づけて買い物するのが面倒
- たまに買い忘れがあるが、極力メモに書いたり打ち込んだりしたくない
簡潔にまとめると、「数日分の献立を考える」「献立を踏まえて買うものを抽出する」の2つの作業が手間に感じています。
献立を考えてくれて、それに必要な材料を出力してくれるツールがあればな〜〜〜
デザイン
ということで、デザインを作成するのは初めてですが作ってみました！
デザインについての知識は浅いので色とか余白とかはなんとなくのなんちゃってデザインです。
大まかな仕様
アクセス直後
- シャッフル画面が表示されている
- Day1のみが表示されている
献立シャッフル
- DayX枠内の「何料理？」プルダウンから料理の系統を選択できる
- 「何料理？」プルダウンの内容は下記のみ
- 和食
- 洋食
- 中華料理
- 韓国料理
- 料理の系統が未選択の場合は、枠内の「シャッフル」ボタンが非活性になる
- 料理の系統が選択済みの場合は、枠内の「シャッフル」ボタンが活性になる
- 「シャッフル」ボタンをタップすると、DayXの枠内に下記が出力される
- メイン
- 副菜
- 汁物
- シャッフル結果をそれぞれ「🔁」ボタンをタップで再度シャッフルできる
- シャッフル結果をそれぞれ「✖️」ボタンをタップで項目を削除できる
- 全ての項目を「✖️」ボタンで削除すると、「何料理？」のプルダウン表示に戻る
日数の追加
- 「+」ボタンをタップすると日付が増える
- 7件が上限
- 7件目の枠の下には「+」ボタンは表示されない
買い物リストの出力
- シャッフルの結果が0件の場合は「買い物リストを出力」ボタンは非活性になる
- シャッフルの結果が1件以上ある場合は「買い物リストを出力」ボタンが活性になる
- 「買い物リストを出力」ボタンをタップすると買い物リスト画面に遷移する
買い物リスト画面遷移後
- シャッフル画面で選択した料理に紐づく材料が一覧で表示される
- 材料が重複している場合は1件しか表示されない
- 例：料理Aと料理Bの材料のどちらにも「にんじん」が入っている場合に「にんじん」が2件表示されないこと
- 各行の左側にチェックボックスが表示される
- チェックボックスでチェックをつけたり外したりできる
- 各行の右側に「✖️」ボタンが表示される
- 「✖️」ボタンをタップするとその行が削除される
- 買い物リストの下にメモ欄が表示される
- メモ欄はフリーテキストで最大300文字まで入力できる
- ブラウザバックすると買い物リスト出力前の画面が保持されている
スコープ外
- 食材の量についての情報
- どれくらい必要かは何人分作るかによるため
- 「なにが必要か」にフォーカスしたいため
- 調味料についての情報
- 買わなければいけないタイミングが食材より少ないため
- 家庭の違いによる食材の違い
- 肉じゃがは牛肉派、豚肉派などはいったん無視
データの例
さいごに
妄想を文字にしたりデザイン作ったりするのが楽しかったですし、仕様作成中は「ここがバグりそうだな」などテストを考えるのも楽しかったです。
このまま少しずつ実装まで出来たらいいなと思ってます。
どう実装していくかもまだ見えてないのですが、進捗はたまにブログに書くかもしれません。
年内にはなにかしらの画面ができてたい。
全然関係ない雑談
最近肩こりがひどく痺れまで出てきたので、人生初の鍼治療を受けてきました。
ビビりすぎて最初鍼が刺さっただけで「痛いです！」と言っていたら施術してくれた方に特大の気を遣わせてしまいました。
最終的にはだいぶ鍼が刺さってる状態が平気になって、お灸も気持ちよかったです。
より効果的なテスト分析をしたい_「ソフトウェアテストをカイゼンする50のアイデア」の感想文②
こんにちは。ぜにです。
1月から色々ありすぎてすでに混乱気味ですが、今年もブログ更新継続していきます！
今回は、「ソフトウェアテストをカイゼンする50のアイデア」の
「Chapter2 適切なチェックの設計_ 入力と出力を明確に分離しよう」について感想を書いていこうと思います。
※電子書籍を購入しているため、引用に記載されているページ数が実際とずれている場合はご容赦ください。
受け入れ条件を構造化する
経験の浅いチームは、構造化せず情報を統合して受け入れ基準を台なしにすることがよくあるため、実際に何がチェックされているのかが不明確になります。
ソフトウェアテストをカイゼンする50のアイデア (p.110)
よくチームでテスト分析を行うときに、まず受け入れ条件（やデザイン）を眺め、必要そうなテスト観点を書き出します。
頭の中で「テストしなければいけなそう」な仕様、値を見つけてそれをマインドマップのブランチとしてさらにテスト観点を広げていくことをしています。
この章では、その「テストしなければいけなそう」をもう少し体系的に導き出す方法が記載されているのだと捉えました。
得られる利点
受け入れ条件の構造化を行う利点として、本書には下記のような項目が記載されていました。（一部意訳して抜粋）
- 仕様が理解しやすく、テストの完全性の確認が容易になる（抜け漏れの確認がしやすい）
- 構造化することによって条件と結果が明示的になるため、探索的テストや自動テスト化が進めやすくなる
どうやって受け入れ条件を構造化するか
受け入れ条件を「入力」と「出力」に分け、さらにGiven-When-Then で表す例が本書に記載されていました。
- Given (前提条件)：操作を実行する前の状態
- When (操作): 操作
- Then (結果) : 操作した結果
受け入れ条件を入力と出力で分けるところから考えてみた
厄介なシナリオをひもとく最良の方法の1つは、入力と出力を分離することです。
ソフトウェアテストをカイゼンする50のアイデア (p.112)
今回は上のGiven-When-Thenを用いず、入力と出力だけで分けて考えてみます。
架空の美容室予約アプリの受け入れ基準の一部として、「同じ日時に複数の予約しようとするとエラーが返る」があると仮定し、エラーが返る条件の入力/出力について考えてみました。
まず、「同じ日時」という言葉の中に複数の前提条件（入力）があると考え、「日時の重なり方」というブランチを作成しました。
分析の段階では、観点として「日時の重なり方」までで良さそうですが思いつくパターンを記載しました。
また、予約する施設を選択できると仮定して、施設についてのブランチも追加しました。
簡単な例にすぎませんが、一つの受け入れ基準で複数の観点を導き出すことができました。
これまでは、受け入れ条件に対して解像度が低い状態、またはどう整理したら良いか曖昧な状態でレビューやテスト分析を行いがちでしたが、
まず「入力」「出力」にまず分けて考えてみることで、受け入れ条件の解像度が上がるので、テスト分析が始めやすくなりそうだと感じました。
さいごに
前回、今回と「ソフトウェアテストをカイゼンする50のアイデア」の感想文を書きましたので、次回以降は一旦別の書籍について感想文を書いていこうと思います！
今のところ「Agile Testing Condensed」や「LEADING QUALITY」などを考えてます...
全然関係ない余談
最近バッティングセンターにハマって毎週行ってたのですが、何を間違ったのか120kmの球が右手人差し指にぶち当たり負傷してしまいました...🥲
当分バッティングセンターはおやすみになりました⚾️
