Label: タイムラインとか、JQLとかダッシュボードに使うために使っている。つかいまくり。プロダクトの領域やフェーズやロールで作ったりしている。あとWBSにも使っている。
Sprint: スクラムではないけど、進捗管理として使っている。詳しくはここでは書かないけど、やっぱり今やるべきことに集中できるのが目にみえるのがよい
アサイン：一人にしかつけられないのがいい。責務を完全に名指しできるのがよい
エピック Link: タイムラインとかでグルーピング表示できるのがよい
Linked Issue: これがないと何も追えなくなるのでまじで神
Link Confluence: これのおかげで仕様はこちらができるのがよい

2023-12-12

私が組織でQAを配置するとしたら

adventar.org

12日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

今の所のわたしがQA組織をつくるとしたら、スクラムinQAと、Enablingチームにオートメーション強いQAエンジニアの体制にしたいです。スクラムinQAとは、スクラムチームの中でQAという領域を得意とするエンジニアがスクラムチームメンバーとして働くことです。 Enablingチームとは、開発する上での困りごとを解決してくれるチームのことで、たとえばCI/CDの構築やSREのメンバー、他にも開発全体の向上になるために働くチームを指しています。そこにQA（ここでは自動テストに当たりそう）エンジニアもチームメンバーとして働くことを指しています。

スクラムinQAがやること

通常のプロダクトを作る。QAエンジニアはスクラムチームの一員として参加し、プロダクトの品質に責務を置く。彼らは品質、テスト、プロセス改善などに強いコミットができる人によっては、スクラムマスターのような動きができる一部Enablingチームに支援してもらって、プロダクトに必要なテストコードが書ける。

Enablingチームに所属するQAエンジニア SETかもしれない。彼らはスクラムチームが運用できるためにCI/CDを運用する状態をつくるスクラムチームが自動テストまで運用できるように支援する場合によっては、スクラムチームが適切な大きさのテストが書けるような設計技術を持っている

これらをQA組織とする必要はやっぱりないかもしれない。スクラムinQAはスクラムチームが開発チームという組織にいればいいし、EnablingチームはEnablingチームという組織にいるのが自然じゃないかなーと思ったので、QA組織論はまだ語ることはできなさそうです。

2023-12-11

うっかりでっかいマトリクスを作ってしまったら

adventar.org

11日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

私の領域や開発体制に限りますが、でっかいマトリクスを作らないといけないようなことはないです。なので、そうなりそうになったときは（自分はないんだけど）「何が確認したいのか」「組み合わせる必要があるのか」

組み合わせる必要があるのか？が多分ほぼないからないのかも・・・

でも整理したいときは、基本的にGIHOZかホワイトボードとかに図を書いたり、デシジョンテーブル書いたりとかしてその分だけ組み合わせがあれば書くかな・・・

そんな大きいものにはならないし、なるような難しいものを考えられないんだと思います。

なので、大きなシステム作っている人はすごいな・・・

2023-12-10

テストって名前があると全部自分がやらないといけないの？ってプレッシャーがくるぅ

adventar.org

10日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

私は15年くらい、テストとか品質関連の仕事をしていて、今はQAエンジニアという職種で働いていますが、それまでは自分で名前をつけていた（会社にそんな職種がなかった）ので、テスターだったりテストエンジニアだったりと名乗っていました。

で、当時、「テスト」と名のつくものは、全部自分の領域なのかなってなんかプレッシャーを勝手にかけていた。セキュリティテストもだし、オートメーションテストもだし、負荷テストもだし、A/Bテストもだし、ユーザーテストもだし、当然機能テストもだし。

今の職場では専門家がいたりするので、この中だと機能テストくらいになってしまうけど（自動化は私のスキル不足で今ほとんどやってない）、テストって名前があると反応しちゃうよね。

これは特に正解があるわけではなくて、自分の組織、自分のプロジェクトの最適解があればいいんだと思っています。誰も考えてなくて抜け落ちなければそれでよし。その抜け落ちてるかどうかをQAエンジニアが気にするのは大事かもしれない。

テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

リナ的テスト設計方法 3 バックエンドが走らない処理の設計で何をするのか

リナ的テスト設計方法 2 : 最初の表示系で何を設計して何をテストするのか

デフォルトの表示系

設計の考え方

実際のテストで何をみているのか

リナ的設計方法

JIRAがないと生きていけない

私が組織でQAを配置するとしたら

うっかりでっかいマトリクスを作ってしまったら

テストって名前があると全部自分がやらないといけないの？ってプレッシャーがくるぅ