テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

Issue勉強会をしてきたよ

いつもお世話になっている秋山さんたちと 勉強会をしてきました。

“Issueの書き方と伝え方”勉強会 - connpass

テーマはIssue

Issueってなぁに?

JSTQBでいうとインシデントレポートにあたります。
他にもチケットとかバグ票とか呼ばれると思います。

私のお仕事では、Github Issueを使っていることと、
バグだけでなく、テスト中にあがった質問や改善要望も登録するためIssueと呼んでいます。

どんなことをしたの?

勉強会は、4人の発表者の話と質疑応答をしました。

上のリンクに掲載されています

私はこれ

www.slideshare.net

ゆるい会というコンセプトでしたが、なかなか真面目だったかも?緊張したし、発表後腹筋筋肉痛になりました。

プリンmgmgタイムも美味しかったしまじめ?でした。
楽しかったです。

なかでも、いくつか気になるトピックがありました。

余計なことを書かない

事実だけを書き、それ以上のことを書かないというような話がありました。

私は余計なこと?をまぁまぁ書きます。 双方が納得するための説明がないと、しあわせになれないので。

なので、 ・問題に思うこと ・その理由 ・どうしたらよいか ・対応することによる懸念点 まで書くこともあります。

担当エンジニアの顔が見えるので、彼らの得意・不得意なところも吸収しつつ、技術で解決できないかなーとか思っています よくあるのは、UIや日本語などです。

しあわせになるIssue

割と辛い思いをされている方が多いのだなぁという印象が強かったです。

「仕様です で返される 」とか

とはいえ、私自身似たような経験をしたこともあったのですが、 今はほぼないんですよね。。なんでだろう。

一番大きいのが、各issueに対して納得できる回答が返ってくるからなのかなぁと思います。 仕様だったとして、きちんとクライアントさまに懸念点も含めて合意が取れていることがわかれば、そんなにギスギスすることもないから辛くないのですよね。

うとのエンジニアはお客さまの顔が見える仕事をしているわけですが、私はエンジニアの顔が見える仕事をしています。

誰でもわかるIssueを書くことも大事なのですが、せっかく顔が見えるのであれば、相手に合わせたIssueを書くことでしあわせになってたんだなぁと思いました。