ぜにのQAブログ

どこかの企業でQAエンジニアとして働いてる人のブログです

JaSST'24 Tokyo 視聴レポート

3/14（木）、3/15（金）にJaSST'24 Tokyo が行われました。

今年はハイブリット開催で、自分は全てのコンテンツにオンラインで参加しました。

たくさんの講演の中で、特に印象深かった3つの講演について書いていきます。

 

もくじ

 

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の球が右手人差し指にぶち当たり負傷してしまいました...🥲

当分バッティングセンターはおやすみになりました⚾️

 

MBTIにちょっと救われた話

QAやテストとあまり関係ないですが、今年の中で知ってよかったこととしてMBTIについて書いていきたいと思います。

 

専門的な知識について間違ったことを書かないでほしいと思う方もいらっしゃると思いますが、この記事については完全な個人的感想になっておりますのでご容赦ください。

 

もくじ

 

MBTIとは？

MBTIとはユングのタイプ論をもとにした、世界45カ国以上で活用されている
国際規格に基づいた性格検査です。

【公式】MBTIとは より引用

 

一般的には下記の性格診断テストに答えた結果のことを指すことが多いと思います。

www.16personalities.com

 

どういった項目についての結果が出るかというと、下記の4項目についてです。

  • 「外向的（E）」か「内向的（I）」
  • 「感覚型（S）」か「直感型（N）」
  • 「論理型（T）」か「感情型（F）」
  • 「知覚型（P）」か「判断型（J）」

16Personalitiesについては、これらの項目においてそれぞれどれに当てはまるのかを判定されているものと認識しています。

 

自分のMBTIとそれを知ったことによって起きたこと

自分も↑の性格診断に回答した結果、「INFP-T（仲介者）」でした！

 

www.16personalities.com

 

INFPの特徴としてよく見るのは、「自己愛が強い」「理想主義者」「繊細」で、我ながら少し扱いにくい人だなと思います。

ちなみに「INFP」で検索するとサジェストの上位に「クズ」「やばい」が表示されます...ショック

MBTIを知ったことによって起こったこと

端的にいうと、他の特性を持つ人の言動が以前と比べて気にならなくなりました。

逆にこれまでは、他人が発している言葉の内容に加えて表情や声色などから「本当はどう思っているのか」を読もうとして、自分の中だけで結論づけて落ち込むことまでありました。

また、ストレートなものの伝えられ方をすると、攻撃されている...？と捉えることもありました。

 

そうしたことを気にしてしまうのは物心ついた時からの癖だから直せないと思っていたのですが、

MBTIについて調べていく中で、自分と同じ感覚の人もいるし、全く違う考え方の人も同じくらいいること、また、他人のストレートな言い方や行動は決して攻撃的な意味ではないということがわかり、他人の言動などが気にならなくなりました。

自分と違う考え方の人もいることはもちろんわかっていたのですが、ここでは各パーソナリティの特性に目を通したことによって「実感した」「納得した」が近いですね。

 

その他調べたこと

性格って先天性？後天性？

学生時代から今日にかけて、何度か16Personalitiesは受けたことがありました。

一番最初に診断した時は「ISFJ（擁護者）」、その次は「ISFP（冒険者）」、そして最新は「INFP（仲介者）」と結果が変わっていきました。

なんだか少しずつ性格が変化して行っているように見えるのですが、性格って後天的に変わっていくものなのでしょうか？

 

調べたところによると、先天的な性格（気質/キャラクター）が核としてあり、外側に環境など後天的な物事によって変動する人格（パーソナリティ）があるそうです。

参考：

【図解】パーソナリティとキャラクターの違いを心理学的に解説 | パーソナルステップ

 

「16Personalities 」とあるように、上で受けた診断は人格について診断しているので、受けるタイミングによって結果も変動するのだと捉えました。

 

心理機能診断

もう一つ、16Personalitiesとは別にMBTIを詳しく知るための「心理機能診断」というものもあるそうです。

 

参考：

【MBTI】「心理機能診断」の読み方を徹底解説！！ ｜ 夜無のブログ | 夜無のブログ

MBTI理論に登場する「心理機能（認知機能）」を個別に診断するものです。

以下4種類の心理機能の得意不得意を数値化してくれます。

・感情（F）「Feeling」
・思考（T）「Thinking」
・五感（S）「Sensation」
・直感（N）「iNtuition」

 

さらに、この「F、T、S、N」の4種類の心理機能は

・内向的な機能（i）
・外向的な機能（e）

の二種類に細かく分けられるので、
「Fi、Fe、Ti、Te、Si、Se、Ni、Ne」の計8種類があるということになります。

 

心理機能診断に則ると、自分のMBTI（16personalitiesで出た結果）の「INFP」は下記の特性になるようです。

①主機能：Fi（自分の心を見つめる力）

②補助機能：Ne（斬新なアイデアを思いつく力）

③第三機能：Si（出来事を記憶し、思い出す力）

④劣勢機能：Te（物事を達成する力）

 

通常は①主機能、②補助機能が働いていて、①→②→③→④の順に成長していくそうです。

④、一刻も早く成長したいなあ。

 

心理機能についてここで一言にまとめることはできないのですが、16personalities とはまた違う見方で面白いなと感じました。

参考にした記事にとっても詳しく解説が載っているのでご興味のある方はぜひご覧になってみてください。

 

まとめ

ここまで調べたことや感想など、つぎはぎ繋いで書いてきましたが、ネットで簡易的に診断できる結果については参考程度にとどめておいた方が良く、本当の自分のMBTIが知りたい場合は専門機関で診断を受けるのが確実だそうです。（それはそう）

自分と他人の特性について理解したいですが、この人はこんな言動しているからこのタイプだ、と推し測ろうとすると偏見につながってしまうので自分を理解するツールとしてとどめたいと思いました。

また、自分にはこの特性があるから〇〇できない/しなくても良い、みたいな免罪符のような考え方はしないように心がけたいと思いつつ、ここまで辛いとギブアップした方がいい、など基準を持っておきたいなと思いました。

 

全然関係ない余談

最近、自分が運動不足すぎることに気づき、マシンピラティスに通い始めました。

めっちゃ筋肉痛になるけど楽しいので続けられそうです🧘

JaSST’23 Review ミニ参加レポート

12/1（金）に開催されたJaaSST'23 Reviewに参加したので、感想などをまとめました。

参加後すぐに書こうと思ったのですがなぜか月末になっていました...

 

もくじ

 

参加経緯

  • 去年の講演内容が勉強になり、実務に活かしたいと感じたため
  • 招待公演の内容にも興味があったため

 

レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー

こちらのJaSST'23 Reviewのレビューページの講演1について資料公開されています。

JaSSTソフトウェアテストシンポジウム-JaSST Review'23-レポート

 

【感想】

レビュープロセスの概要については前回（JaSST'22 Review）で拝見しており、今回はその続きのようでした。

ちなみに去年も参加してレポートも書いたので載せておきます。

JaSST'22 Review 参加レポート: https://dev.icare.jpn.com/dev_cat/qae_zeni1031/

 

今回は、下記の2つの項目について新しく話されていたと思います。

  • テストのシフトレフトのようにレビューもシフトレフトの考え方を活かせるかもしれない
  • レビューアーキテクチャについて

 

レビューのシフトレフトについて

成果物が完成してからレビューすると、質問や成果物の欠陥が多く報告されてしまうことが問題点として挙げられていました。

上のような手戻りが発生する状態を改善するために、より上流からレビューまたは一緒に成果物を作成する（モブ）を実施することによって手戻りなどを防ぐことができるのではないか、という内容だったと認識しています。

 

要件定義や受け入れ条件が作成されているミーティングに、レビューアを入れてもらうだけでも効果が出そうだと感じました。

 

詳しくは「レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー」講演資料_p35

 

レビューアーキテクチャについて

下記の工程でレビューを開発工程において繰り返し実施していくことと認識しました。

①観点の洗い出し

②同類事項集約

③構造化（②で分類した項目の内容をまとめた項目名をつける）

=>振り返り

 

レビュー実施時のとっかかりとその後の進め方について明確になってきていると思うので、実務に取り入れやすいと感じました。

 

詳しくは「レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー」講演資料_p53~

 

この講演ではレビュー体系化の今後についても話されていて、

今後レビューマニフェストなど確定していくとのことなので楽しみです！

 

TEAM TRANSFORMATION TACTICS FOR HOLISTIC TESTING AND QUALITY _チーム一丸となったテストと品質のためのチーム変革戦術

こちらのJaSST'23 Reviewのレビューページの講演2について資料公開されています。

JaSSTソフトウェアテストシンポジウム-JaSST Review'23-レポート

 

 

【感想】

Lisiさんの講演で特に印象に残ったことは、「チームの文化が品質にとって一番重要」とおっしゃっていたところでした。

確かに、レビューやテストのシフトレフトなどをチームで進めるためには、チームの文化が醸成されていた方が良い、前提条件のようなものなのかなと感じました。

 

チーム文化の醸成を実現するために、Lisiさんはよくチームメンバーを観察して気がついたことをメモしているそうで、

チームメンバーに興味を持って観察することによって一人一人の特性を理解してチームワークを良くすると考えているそうです。

自分の偏見や憶測などでチームメンバーを判断せず、傾聴を心がける姿勢は自分も見習わなければいけないと感じました。

 

〇〇パスはハッピーパスだけではないらしい_「ソフトウェアテストをカイゼンする50のアイデア」の感想文①

ブログ更新するぞ

こんにちは、ぜにです。

なんだか最近学習へのモチベーションが高いので、

自身のブログを毎月1本を目標に更新していくことにしました。

3ヶ月坊主にならないようにスモールステップで頑張ります 🎉

 

書いていくこととしては、こんな感じを想定してます。

  • 本のつまみ読み感想文
  • 参加したイベントの感想
  • 資格受験について

 

今回は、「ソフトウェアテストをカイゼンする50のアイデア」の

「Chapter1 テストのアイデアを生み出す_ 感情を利用しよう」について感想を書いていこうと思います。

※電子書籍を購入しているため、引用に記載されているページ数が実際とずれているかもしれません

 

感情を利用しよう

テスターが日常的に指摘するように、新しいソフトウェアのフィーチャーが持つリスクを適切にカバーするために必要なテストの種類に関しては、ハッピーパスは氷山の一角にすぎません。

私たちが提案するヒューリスティックは、10の感情または行動の種類に基づいています。それは、「恐れ」「幸せ」「怒り」「非行」「恥ずかしさ」「寂しさ」「物忘れ」「優柔不断」「貪欲」「ストレス」の10個です。

引用：ソフトウェアテストをカイゼンする50のアイデア (p.29-30)

 

こちらの章では上記の通り、ハッピーパスも含め10種類のテストが紹介されています。

その中でいくつか気になったものをピックアップしました。

 

スカリーパス（恐怖）：

ステークホルダーにとって最もリスクの高い領域

機能や変更について、各ステークホルダーを最も怖がらせるもの

引用：ソフトウェアテストをカイゼンする50のアイデア (p.31)

 

こちらは、テスト分析時に優先的に考え、用心してテストする箇所だと解釈しました。

実務では「リスク」と表現されるもので、テスト設計する際やチームの品質の指標を考える時にも役立つのではないかと考えました。

 

アングリーパス（怒り）：

アングリーパスでは、アプリケーションの反応が悪くなったり、エラーが発生したり、うまく再生できず腹を立てたりするようなテストを探します。

引用：ソフトウェアテストをカイゼンする50のアイデア (p.31)

 

こちらはアプリケーションへの負荷で反応が悪くなったり、またはエラーハンドリングなどが網羅されていないなどユーザー体験が悪くなることについての観点だと解釈しました。

アングリーパスがある程度考慮されていないと、短期的にも長期的にもプロダクトへの評価へつながりそうだなと感じました。

 

エンブレシングパス（恥ずかしさ）：

それらがビジネスの損失のような即時の大惨事ではない場合でも、それらは内部または外部の信頼性に重大な影響を与える可能性

引用：ソフトウェアテストをカイゼンする50のアイデア (p.31-32)

 

こちらはスカリーパスほどの影響力はないものの、もしバグっていたら恥ずかしい、あちゃ〜なパスと解釈しました。

誤字脱字だけでなく、表示崩れ、仕様漏れなども時にはエンブレシングパスに入るのかな？と考えました。

 

読んだ感想

こういった不具合があるとユーザーさん怒るまたはがっかりするだろうな、など無意識にテスト観点を出す時に考えていたことが言語化されたような感覚でした。

また、誰にとっての感情なのかが気になりました。

「恐れ」はステークホルダ全員にとってな気がするし、「怒り」はユーザーが、な気がする。

「恥ずかしさ」は作り手がその気持ちになってるな〜など、一視点からの感情ではないということに気づきました。

 

もし10種の感情の観点を実務に取り入れるとしたら、

恐れ、怒り、幸せ、非行、恥ずかしさについては、テスト設計時や回帰テストを考えるときに多く用いる場面がありそうだなと感じました。

また、寂しさ、物忘れ、優柔不断、貪欲については探索的テストに多く用いる場面がありそうだと感じました。

ストレスについては、アプリケーションの性能を継続的に測る時に用いることができる観点だと感じました。

 

実務でも活かせるよう、頭の片隅に置いておこう。

 

全然関係ない余談

最近家の近くにすんごいおいしいパン屋さんがあることに気づいて、最高な気分になりました🍞

 

2年間の振り返り【後編】

ぜにです。

前編に引き続き、2年間を振り返って気になったこと、課題に感じたことを書いていきます！

 

▼前編をご覧になっていない方はこちら！

qaminarai.hatenablog.com

 

もくじ

  1. こんな振り返りしたよ
  2. 気になったこと、課題に感じたこと
  3. まとめ
  4. 余談

 

1. こんな振り返りをしたよ

※前編と同じ内容です

 

【前置き】

入社時点での開発組織はこんな感じでした

  • 開発組織全体の人数は約30名ほど
  • QAチームなど品質管理を専門としたチームはまだない

企業規模拡大の時期だったので、開発組織としても品質を専門としたチームが必要といった方針でQAエンジニアの採用が進み、ご縁あって自分がQAチームの第一号の社員として採用されました。

※自分のこれまでの経歴についてはこちらの記事をご覧ください。

 

【ここから本題です！】

ざざっと時系列で起きたことや良かったこと、気になったことなどをまとめてみました。

※なるべく企業にまつわる固有名詞は伏せています。

入社1年目のタイムライン

入社2年目以降のタイムライン

タイムラインという振り返り方法を実施しており、こちらの記事を参考にさせていただきました！

細かくて見えないところもあると思うので雰囲気を掴んでいただければ。

 

 

2. 気になったこと、課題に感じたこと

気になったこと、課題に感じたことを上のタイムラインから抜粋し、

それによって困ったことや、こうしたら良かったと思ったことをまとめました。

 

テスト自動化を早期に目指しすぎたかもしれない

【困ったこと】
  • 自動化すると効果的なテストが不明確で、テストを作成してもそれが有効であると言えない状態
  • 定期メンテナンスを行うことが難しい状態
 
【なぜ起きたか】
  • 自動化すると効果的なテストが不明確で、テストを作成してもそれが有効であると言えない状態
    • ツール選定を最初に行った
      • 社内全体のテスト（開発側行われているものも含む）を把握していない状態だった
      • QAで行う回帰テストが本当にこの内容で良いか精査していない状態だった
    •  自動化ツールの選定タイミングが早かった
      • メンバーが自分1人しかいなかったのになんでもやろうとしすぎた
      • とりあえずやってみなきゃわからない精神（自動化に関する興味はあったが知識がなかった）
  • 定期メンテナンスを行うことが難しい状態
    • 作成済みの自動テストに変更を加える必要がある場合、担当者が都度修正していたが、QAチームとして定期的に一定の基準を持ってメンテナンスをするというルールはなかった
      • 現在は回帰テスト/自動テストの内容精査のmtgを定期開催しておりメンテナンスへの動きが前進しているが、始めるタイミングが（自分の退社タイミングにとって）遅かった 
      • 機能リリースに対するテストで現状のチーム人数で手いっぱいのため、リソース不足な部分があった

 

【こうすれば良かった】

とりあえず1人しかいないのに色々やろうとしない...！

一旦やってみるの前に、目的や方針くらいは有識者に一度相談しておくべきだった。

やってみなければわからない部分もあるが、ある程度社内のテストの現状と自動テストにするべき項目をまとめておくべきだった。
 
ソフトウェアテスト293の鉄則にある「自動化は"銀の弾丸"にはならない」を身をもって体感しました。
※ソフトウェアテスト293の鉄則_鉄則105 より引用
 
 
 
QAEチームの立ち位置や開発工程のどこから関わるかが曖昧だった

【困ったこと】

  • QAチームも開発側も両者にどう関われば良いか探り探りで、開発者やチームメンバーを困惑させてしまった
  • QAチームのミッションを決めたが、チーム/開発部内でも浸透していない気がした
 
【なぜ起きたか】
  • QAチームも開発側も両者にどう関われば良いか探り探りで、メンバーを困惑させてしまうこともあった
    • QAチームで限られたリソースの中でどういった条件でどのようにプロジェクトに関わるか定義づけられていなかった
      • 各プロジェクトのリリーススケジュールを優先していた
        • リリーススケジュールを見てQAのリソースを見積もり、それをもとにQAがプロジェクトにどう関わるかを決めていた
    • 各プロジェクトのPjMとの接触タイミングが少なく、連携がとれていなかった
      • QAチームから主導していく形ではなく、あくまでプロジェクトから必要とされたときに受動的に動いていた
  • QAチームのミッションを決めたが、チーム/開発部内でも浸透していない気がした
    • こまめな周知がされていなかった
 
【こうすれば良かった】
QAチームで品質の定義、プロジェクトの関わり方を決め、毎月毎週でも周知したり時にはアップデートしていくと良かった。
開発者からはQAチームは未知の存在だったと思うので、QAチームから積極的に歩み寄る、参加した方が良いと感じたmtgには呼ばれていなくてもいくべきだった。

 

プログラミングスクールを途中で退会した

これについては、意志が弱かったに尽きる。
業務時間内に勉強しても良い、と言われていてもQAの業務が優先と感じて意図的に勉強時間を潰してしまっていた。
QAの業務を言い訳にしているが、就業時間外にいくらでもできただろうと言われるとそうだなと思う...。
この有給消化期間中に目的や目標を再設定したい。

 

勉強会/イベントなどから吸収する情報で、概念の理解は割とすぐにできるが具体への落とし込みに弱い
【困ったこと】
  • 見聞きした内容を業務に取り入れようと思った時にスムーズに実践できない
 
【なぜ起きたか】
 
自分の業務で実践する具体的な像が見えていない
  • 話の聞き方に課題がある
    • 話を聞いた時に、即座に「〇〇の場合」「もし〇〇だったら」などバリエーションが思い浮かばない
      • 話の中に複数パターンがある項目を見つけようとしてない
    • 話の中で引っかかるところがあっても一旦全部聞こうとすると引っかかったところを忘れる
    • 概念を理解するのが得意というか、見聞きした情報をもとになんとか辻褄を合わせようとする癖がある
      • 辻褄を合わせるので、ん？と思ったことを自動的にスルーするようになり、解消した方が良い疑問を解消しない

 

【こうすれば良かった】

  • 話や情報の中から、せめて自分の環境に置き換えるとどうなるか考えて引っかかったところを書き留めてみる。
  • 見聞きした情報をそのままメモして満足するのではなく、情報に対してどう思ったか、その情報に複数パターンや例外は存在しないか振り返ってみる
  • イベントなどで事前にテーマがわかる場合は、そのテーマにおける自分の状況を振り返っておき、聞きたいことを明確にしておく

 

3. まとめ

良かったことをまとめた前編と比べてどんよりとした記事になってしまいました... 🙏

根暗なのがもろ出てしまってるし、終始抽象的な話しかしていないのですが、自分の気持ちの整理として書いている記事なのでご容赦ください！

 

4. 余談

家だと集中できないのでシェアラウンジとかで記事を書いたのですが、良かったところ載せておきます🍹

 

▼ 飲み物とお菓子が充実してて席間隔ゆったりしてて最高でした！周りの本棚の本も読み放題 📚

store.tsite.jp

 

▼おしゃれ空間なので自分もおしゃれになった気分になれますが、パスワードの打ち込みに苦戦してしまいおしゃれな人たちにダサい姿を見せてしまいました！

www.te-fu.jp