タイトル未定

品質や趣味について語りたいブログ

WACATEで分科会オーナーをやってきた 〜その2〜

独りアドベントカレンダー10日目です。

ご存知でしたか、年度内ならまだアドベントカレンダーなのです。

 

(色々忙しかったり体調が不安定だったりでこんなことに)

 

前回の記事はこちらから。

 

 

前回の記事が「分科会オーナーやってきた」の表側

今回の記事がそのコンテンツを作るときにどう考えていたかの裏側だと思っていただければ。

 

 

考えていたこと

「きっかけ」をつくる

探索的テストに触れたことない人も少なくなさそうなので、まず「知る」「触れる」機会をつくれればと思っていました。

組織によっては探索的テストにまったく触れることがないこともあると思います。

別にそれが悪いこととは思いませんが、「知る」に至らないことには選択することもできないのでこちらは良くないと思っています。

 

観点の違いを知る

次に、触れたことのある人にはどんなことを感じて学んで欲しいかを考えていました。

単純ですが、観点の違いです。

 

経験ベースのテスト故に、人によって よく見る観点は異なり、偏ります

探索的テストをしている人が10人集まれば、10人がそれぞれ異なる流れで、異なることを気にしながらテストをするでしょう。

 

ましてや年齢経験も異なれば、webや組み込みなど業界も異なる集まりです。

普段はあまり出会えない観点に出会って刺激になれば、というのが経験者に対しての狙いでした。

 

「モブ」テスト

2つ目と少々被りますが、WACATEにはテスト専門ではなく普段は開発専門な方も参加しています。

モブでテストの中で、同じものを見ていても「テストの人」「開発の人」がそれぞれ異なることに着目したり、異なる経験からバグを探し出すでしょう。

これを体験して、互いに歩み寄るための好奇心を少しでも生み出せればと思っていました。

 

どんな狙いでどんなバグを仕込んだのか

壮大なネタバレですが、正直時間もなくテストアイテムとしてそこまで優秀とも思えないのでいいでしょう。

ここに挙げたもの以外にも仕込んであるので、楽しむ分には差し支えないかと思います。 

 

また機会があればちゃんと作ると思います。

 

ボタンを連打すると○○系

コッテコテのバグです。

お気に入り/お気に入り解除、フォロー/フォロー解除用のボタンを連打することで意図していないであろう操作ができます。

まずひとつを見つけ、残りを予測して見つけて欲しいという狙いがありました。

 

開発知識のある人に「伝われ...ッ!!」の想いで「トグル処理になっていないので連打するとお気に入り数を爆上げできます」と一言ざっくり解説を添えました。

「過剰にお気に入り数を増やせる」ということは、リレーションが重複して作られてしまう(トグルでない)つくりになっているので、解除リレーションを削除しているものと予測できます。

 

試してみるとひとつずつお気に入り数を減らせるので、推測が合っていそうなことがわかります。

では、解除ボタンを連打してリレーションが0個になったときボタンが押されたらどうなるでしょう。

 

存在しないリレーションを削除しようとして500エラーを吐きます。

 

また、これらはお気に入りで発生した、つまり1対Nの関係にあるもの、リレーションテーブルを使っているであろう機能で起きている可能性があります。

 

なぜならこの機能を実装した人はトグル処理ではなく「リレーションがなければリレーションの作成、ひとつでもあれば削除」のロジックで実装をする人だからです。

同じような機能は同じように作っている可能性が高いですよね。

(欠陥の偏在?)

  

予期せぬタイミングでフォロワーが増える

元々は単純に実装時に作り込んでしまったバグなのですが、おもしろかったので残しました。

「こんな状態でテストに回すな」レベルの違和感バリバリのもので、TOP画面からマイページに飛ぶだけでフォロー数が勝手に増えています

案の定、好評(?)で大盛り上がりでした。

 

お酒を飲んでいて楽しくなってしまっていたので仕方ないのですが、これはあまり構ってはいけないタイプのバグでした。

 

明らかにおかしいバグがあると楽しくてそこばかり深掘りしたくなるのですが、

先程の連打バグとは異なり、こちらは異常なことが明らかで容易に見つけられるものです。

このあたりは感覚な気がしますが、自分であればあまり深掘りはしません。

 

基本的な機能の明らかな異常がパッと見て見つかるのであれば、まず基本的な操作を一通り行います。

実装時及びマージする前によくレビューされていない可能性も考えられますし、こういった場合は回帰テストも不十分な可能性が高いです。

広く浅く探索し、まずはアプリケーションが落としたくない要件、致命的なバグを早く見つける方針です。

 

また、バグから派生して発生しているバグであれば根本の一箇所を直すと連鎖的に解決することがあるので、あまり派生バグを探すとバグ票の数が膨れ上がるする可能性もあり、対応の優先度を誤る二次被害も起こり得ます。

中枢を成すような機能に露骨なバグがあるときは別の機能に取り掛かる方が建設的であることも多いです。(感覚ですが。)

 

スマートフォンで閲覧

bootstrapを使ったのでスマホサイズでも致命的なことにはなりませんが、いい感じに表示が崩れるように確認を非常に雑に済ませました。

Webアプリケーションなので、ユーザーがどう利用するかを考えると気にしなければいけません。

 

 スマホからのアクセスも当然、想定されます。

Webの業界にいればパッと思いつくかもしれませんが、例えば組み込みにしか触れていなければ出てきにくいかもしれません。
(自分も組み込みの観点はおそらくパッと出てこないです。)

 

そして、ここで気にしてほしかったところがUI/UX部分です。

PCを中心に使っているので、スマホからの操作性はむちゃくちゃなはずです。

何をバグとして報告するのか、その基準や感覚も人によってバラついていると思います。

自分は気にしないけどあの人はここを気にする、またその逆など、様々な人の意見にふれることができればと思っていました。

 

UI周りで余談ですが、タイムゾーンをUSにしておいたのですが誰もそこにはツッコミを入れてくれなかったので自分からツッコんでしまいました。

参加者の方々からは「そういうものだと思っていた」との声もありました。

つまりは言いたかったのはそういうことです。おもしろいですよね。

 

おわりに

当日は寝不足アルコールの影響もあって、このあたりまで全体にお伝えできなかったことをここにお詫びします...。

大勢の方にご参加頂いたり、実行委員の方🥦に拙い自分の進行をサポートして頂いたりと、この場で感謝の気持ちもお伝えできればと思います。

 

バグを意図的に仕込む作業はなかなか楽しいものでした( WACATE 前夜 AM4:00でなければ... )。

チームや組織の中でテストの教育等にこのようなものを使ってみてもおもしろいかもしれません。

 

12月も過ぎ去りアドベントカレンダーでありながらアドベントカレンダーではなくなっているので、好き勝手書いていこうと思います。

気が向いたら その3 として、頂いた声のご紹介記事にでもしてしまおうかなと思います。

 

 

用語を定義するということ 〜ユニットテストってなに?自動テストってなに?パフォーマンステストってなに?〜

 

こんばんみ、halspringです。

ソフトウェアテストの小ネタ Advent Calendar 2019 の22日目です。

 

伝達の不具合

この記事のメインです。

「考えていることを伝える」ということは、思っている以上に難しいといった話です。

 

まず、我々は自分の考えを人に伝えるときに、主に言語を用います。

「考え」を「言葉」にコンバートするわけです。

 

既にタイミングで、

  • 選択する言葉の誤り
  • 情報の欠落
  • そもそもの「考え」の誤り

不具合が発生している可能性があります。

 

そして、言葉を伝えるときに、

  • 伝達情報の欠落
  • 伝達順序の誤り
  • 言い間違い

などの可能性がありますね。

 

さらにはそれを受け取る相手がいるわけで、

  • 聞き逃し
  • 聞き間違い
  • 認識の錯誤
  • 知らない用語の補完ミス

などの要因で伝達ミスが起こり得ます。

 

防ぎたい不具合

例として口頭でのやり取りを挙げましたが、

これらは文章でもあり得ますし、絵でもあり得ます。

 

手段によって細かな部分のポイントは異なると思いますが、

考えや意思を伝達する上で大事なことは、「認識を揃えること」だと思います。

 

 

知らないことを想像するのは難しく、

曖昧なものは曖昧なまま補完され、

認識のズレたものは誤解を生みます。

 

 

そして、もう一度先程の混入し得る不具合を見ると、

防ぐことが難しいものと、防ぎやすいものがあると思います。

 

言い間違いや聞き間違いについては、注意していても防ぎきれません。

当人達以外に環境に影響されることもあります。

また、起こってしまっても言い直す聞き直すことが対応できるので、大きな問題にはなりません

 

 

防ぎやすいのに大きな問題になりやすいのが、

「選択する言葉の誤り」「認識の錯誤」「知らない用語の補完ミス」

です。

ここをなるべく防ぎたい。

 

 

不具合の例

たとえば、ユニットテストって大事だよね」と言われて何を思うでしょう。

 

それは、

テストレベルの文脈におけるユニットテストなのか、

ユニットテストフレームワークで作られたテストコードなのか、

TDDの文脈におけるユニットテストなのか、

はたまたそれ以外のユニットテストなのか、絞り込むことができません。

 

「自動テスト」はどうでしょう。

ユニットテストフレームワークで作られたテストなのか、

e2eのシナリオのようなテストなのか( その場合、e2eとはなんなのか )、

APIの返り値を見ているのか、

手動でないテストすべてを指しているのか、わかりません。

 

また、「パフォーマンステスト」と言われても、

想定されるリクエストより多くのリクエストを送って落ちないことを見るのか、

1リクエストあたりのレスポンス速度を見たいのか、

DBへのIOやバッチ処理に異常がないことを確認したいのか、

負荷がかかったときにスケーリングされることを確認したいのか、わかりませんよね。

 

取り組もう

特にソフトウェアテストに関しては、個人/組織/現場で特にこれらの認識がバラついているように思えます。

業界・組織レベルでこれらをうまく揃えることは難しいかもしれません。

ですが、プロジェクト単位であればどうでしょう、数人のチーム内ではどうでしょう。

 

規模の小さいところから、ガラパゴスな使い方になってしまっても良いので、

まずは用語を定義して認識を揃えることで、伝達時の不具合による不幸が減るかもしれません。

 

もちろん、ガラパゴスを推奨しているわけではありませんが、

所謂 公式(or のようなもの)にこだわり過ぎず、わかりやすい言葉を作ってみても良いと思います。

 

説明できない引用されただけの言葉より、説明できる非公式な言葉の方が健全です。

 

 

おわりに

はい、偉そうなことを言いました。

ですが 自分が思っていることで、大事にしていることなので、

自分の考えていることが少しでも何かのお役に立てばと思います。

 

ちなみに言葉の引用を否定しているわけではありません。

公式なものは共通して認識されている可能性が高いので、知っていることはとても大事です。

しかし、みんなが知っている可能性が高い故に疑いにくいです。

 

相手なくして「伝える」ことはできないので、

相手のことも考え、どの言葉なら錯誤が起きにくいか、曖昧な言葉はないかと考えてみると、

より「伝える」ことが楽しくなるかもしれません。

 

 

WACATEで分科会オーナーをやってきた 〜その1〜

 

 

独りアドベントカレンダー、日が空きすぎて何日目かわかりません。

執筆時点で20日ですが9日目です。時間軸が地球と同じと思うなよ。

 

そしてタイトルからわかるように、2本立て以上にする気満々です。

今回は分科会でやったことを、次はその感想や反省などを。

 

頂いたお題

peing.net

wacateで分科会オーナーをやった感想をブログに書いて!

お題のご提供ありがとうございます。

ストイックなので、ちゃんと頂いたお題に答えるべくWACATEに参加し、分科会のオーナーに立候補してきました

(WACATEについてはすみません、ググってください)

 

 

もともと「やってみたいかも」とは思っていたのですが、

なにせ人前は苦手でコミュ障なもので、こういった後押しがなければ実行できなかったと思います。ありがとうございます。

 

『モブ・探索的テスト』

はい、モブで探索的テストをしました。

自分がディスプレイに画面を映して操作を行い、参加者のみなさんにやってほしいことを挙げてもらいました。

 

目的

考えていたのは次のような感じです。

探索的テストをしたことがない人に楽しさ知ってもらいたい

参加者の多くが20代〜30代前半で、

なかには初めての勉強会としてWACATEに参加している方もいらっしゃいます。

業界によっても会社によっても仕事によっても、経験している業務は様々で 探索的テストを知らない方もいると思い、この楽しさを知ってほしいという思いがありました。

 

多様な観点を感じてもらいたい

WACATEの参加者はWeb系や組み込み系、toBtoC、自社や客先、テストエンジニアやアプリケーションエンジニアなど多様性に富んでいます。

参加者にとって共通するような視点もあれば、知らなかった視点もあったと思います。

せっかく多様性にあふれているので、普段出会えない視点を知って何かを持ち帰ってもらえればいいなぁと思ったりもしていました。

 

(本当はバグ票まで書いてもらおうと思ったのですが、

20人近く参加してくださっていた気がしており、確実にグダるので控えました。) 

 

テストアイテム

では、なにをテストするか。

結構悩んだのですよ、変にWebのサービス選んで関係者がいても気まずいですし。

そして不具合らしきものが見つかるのかも怪しいので、次の結論に至りました。

 

「自分で作ったろ」

 

f:id:halspring:20191220013727p:plain

 

「作りました。」

 

久々に家のPCでrails newしようとしたら環境構築で色々とつまずき、

サーバーもどうしようかと悩んだりして先延ばしにした結果、

前日の夜、仕事から帰ってから着手して当日の朝5時まで開発をする羽目に。

ご利用は計画的に。

 

そしてそれがこちらになります。名付けてwacatterです。

ご利用前に、注意点として、

  • email は実在するものを入れる必要はありません。
  • むしろ個人情報扱いたくないのでそのへんは適当に入れてください。
  • パスワードはちゃんとハッシュ化していますが使いまわしにはご注意ください。
  • 一応、XSSSQLインジェクションなど本当にヤバいやつは防いでいるつもりです。
  • 個人情報の投稿なども控えてください。
  • なにかあっても責任取れません。
  • 負荷を掛けるのも控えてください。無料枠なので普通に落ちて1日使えなくなります。

 

基本的にはtwitterみたいなものなので、なんとなくで使えると思います。

前述の通り 急ぎで深夜に作ったため、生々しいバグをたくさん残してあります

わざと仕込んだものもあれば、作り込んでしまったけど直さず残しているバグもあります。

 

なにがサービスにとって深刻なバグで、
リリース後の修正でも問題のないバグはどういったものでしょう。

 

そんなことを考えながら遊んで見てください。

データが残りっぱなしだときったねぇので、一定時間でデータを全部消すようにしようかなとも思ってます。

面倒だったらそのまま残っていることでしょう。

 

 

せっかく作ったので、参加者のみなさんもブログを読んでいる方も、

探索的テスト以外にもテスト設計の演習だったり、技法の当てはめ方を考えたりするのに使ってみてください。

 

ただし、本当にひでぇバグを残したままなので「こんなの持ってくるなよ、テストできるレベルじゃねぇぞ」という意見はお控えください。傷付きます。

時間がなかったので一部コピペエンジニアリングもしたので、そういった情報もネタにしながらテストするといい感じにバグが出せるかもしれません。

 

オーナーの感想、反省は次回に続きます。

テスト以外でQAが貢献できる活動


独りアドベントカレンダーの8日目です。

誰がなんと言おうと8日目です。投稿日は見ちゃダメ。 

 

お題

アジャイル開発に関わるQAエンジニアが、テスト計画、テスト設計、テスト実行、不具合報告などメジャーなテスト作業以外でプロジェクトに貢献できる「活動」としてはどんなものが考えられますか? 

 

DMにて頂きました、お題の提供ありがとうございます!

前日の記事でQAエンジニアとしてのお仕事について書きましたので、そことは少しズラした観点でどんなことが考えられるのか書いていきます。

 

テスト以外の関わり

参拝

冗談のようなものから...

はい、お参りに行ったりします。

 

考えるだけ考えて、尽くすだけ尽くして、

「あとは祈るだけだ...!!」ってときありますよね?

 

なのでちゃんと全力で祈ります。

 

アジャイル関係ないので、ちゃんとした内容書きますね。

 

ツールの導入支援

テストツールに限る必要はないですが、自分達の得意分野で合ったほうが良いと思います。

より開発しやすくなるのなら、より効率良くなるのならツールの導入支援もQAエンジニアの活動に入ると思います。

 

ただし、むやみにツールを入れればいいわけではなく、チーム内の課題を解決するために適しているものがあれば程度にしたほうが良いと思います。

 

あまりちゃんとしたツールでなくとも、例えばbotでも良いです。

自分はよくチーム内で面倒事や忘れがちなものがあればすぐbot化してslackで通知させたりしています。

スクラムマスターではないですが、チームが気にしなくてもよいことはチームが気にすることのないようにしてあげた方が良いですよね。

 

ペアテスト

(メジャーなテスト活動ではないのでおそらくセーフ)

 

開発者とペアになって探索的テストをするなどいかがでしょう。

ペアでなく、モブでも構いません。

 

テスト側がどう考えているのかを開発側が知ることもできますし、開発者の目線をテスト側が知ることもできます。

仕様を確認するときも知っている人が隣にいるのですぐ聞けます。

 

雑談

プロジェクトに直接関係のない話もできますね。

「最近調子どうですか?」「ちゃんと寝れてます?」など体調の話が特に自分は好きです

プロジェクトに対して不安なことを聞くときに、個人的(プライベートでも)に悩んでいることを差し支えない範囲で質問しています。

 

体調が悪いときはパフォーマンスが下がりますよね。

もちろん、急にお休みしてしまう可能性もあります。

 

機械と一緒に仕事をしているわけではないので、そのあたりも考えてケアしてあげるくらいの気持ちでいたほうが良いでしょう。

言い方はアレですが、立派なプロジェクトリスクです。

(もちろんそんな冷たく「仕事だから」みたいなものではなく、本心から心配なのできいていますよ。念の為。つらい思いをして欲しくないのです。)

 

いること

 

これは我々の組織の関わり方だからかもしれませんが、

いるだけでも違うらしいです。

 

定例に混ざってプロジェクトを見てくれている、

テスト仕様書のレビューに入ってくれている、

探索的テストでQA側も見てくれている、

それだけで「心強く、安心してプロジェクトを進められた」と言ってくださります。

ありがたい...

 

チームが精神的に安心できるように、より快適になるためにできることは、

できる限り叶えてあげることも(やり過ぎではあるかもしれませんが)大事だと思っています。

 

自分は、良いプロダクトが不幸な現場から生まれるとは思いません

良いプロダクトは、良いチーム、良い環境からこそ生まれるものだと思います。

 

ですので、自分は品質を良くするためにこれらの活動をとても大切に思っています。

アジャイルとテスト計画

ソフトウェアテストアドベントカレンダーの9日目です。

halspringです。宣伝ではないですが、独りアドベントカレンダーを書いていて正直キャパシティオーバー気味ですが頑張りますよ(`・ω・´)ゞ

 

前日の記事はこちら。

tester.ma2ri.net

 

今回はアジャイルにおけるテスト計画についてざっくり書きたいと思います。

 アジャイルに依らない(関係のない)部分もありつつ、アジャイルならではの部分もありつつで読みにくいかもしれませんが、しばしお付き合い願います。

 

みんなだいすきJSTQB

JSTQBアジャイルシラバスがあるのはご存知でしょうか?

それが『Foundation Level Extension シラバス アジャイルテスト担当者』です。

シラバスこちらから閲覧できます。

 

シラバスはFoundation Levelの内容を理解していることを前提としているため、読んでいてアジャイル以外の文脈で詰まることが多ければ一度Foundation Levelのシラバスに目を通してみることをオススメします。

 

アジャイルとドキュメント

アジャイル開発において、

ドキュメントは軽視され、コードが優先されることがあります。
( もちろん本当は「軽視」していいわけではないですし、それはおそらくアジャイルではないですが。 )

 

より価値のあるものを優先することや、変更に対して柔軟スピードを求めると、

テスト計画書を作るのは確かに手間も時間もかかりますし、後々の変更の量も膨大になってしまうかもしれません。

 

テスト計画書を更新する運用コストを考えると、ドキュメントとして残さない選択は自然かもしれません。

 

計画することと計画書に書くこと

 テスト計画をすることと、テスト計画書に書くことイコールではないと思っています。

 また、決めたこと書くことの粒度等倍である必要はないと思っています。

 

「こう書かないとテスト計画書じゃない」といったルールがあるわけではありません


計画は自分達がよりよい方向に進むためにあるものなので、

自分達にとって必要だと思うものを必要なだけ決めて、必要なだけ残せば良いです。

 

ですので、はじめからガッツリと「テスト計画書かくぞ!」ではなく、メモ程度から始めるでも構わないと思っています。

 

 

 ただ、はじめから何をすれば良いのか判断するのは難しいと思うので、ヒントといいますか参考程度に「こういうものがあるよ」を挙げていきます。

 

プロジェクトの概要/目的

当たり前すぎて意外と話し合わなかったり文書に残さなかったりすることがあります。

プロジェクトが進むに連れて、方向を見失ったりズレていることがありますが、事前に話し合っておけばスタート時のベクトルを揃えることができ、文書にしておけば後からズレに気がつくことができます。

 

テストレベル/テストタイプ

テストレベルを考えるとき、盲目的にV字モデルを前提としてしまいがちです。

単体テスト結合テストシステムテスト、受け入れテスト、これらはよくウォーターフォールモデルとセットで説明されています。

それらが、自分達の開発プロセスに適している根拠はどこにもありません

 

スタンダードな用語や定義、モデルにこだわることなく、自分達にあったものを考えていくべきだと考えています。
(もちろん、独自のものを用いるのであれば、スタンダードなものも知っておくべきだと思いますが。)

 

 

同様に、テストタイプも自分達で考えて定義すべきです。

「パフォーマンステスト」「性能テスト」「負荷テスト」「ストレステスト」

これらのテストタイプの意味や目的を無作為に集めた複数のプロジェクトメンバーにそれぞれ述べさせたとき、その答えが一致するのはおそらく天文学的確率です。

 

言葉の認識にズレが生じることで、テストの目的にもズレが生じ、そのズレは徐々に徐々に多くの影響を及ぼしますバタフライエフェクトのように。

 

用語を定義してメンバー間では認識が揃うようにしておくことが重要です。

 

自動テスト/回帰テスト

アジャイルでは回帰テストが非常に重要なファクターであり、またそれらは可能な限り早い段階で自動化されているべきだと思います。

 

小さいリリースがたくさん行われるため、スコープ外へ影響がないことを確かめる回帰テストを行う割合が自然と高くなります

何度も実施されるテストは、工数やテストの再現性を考えると手動で行う割合を減らしたいものです。

なので、どのテストを自動化し、どこを手動で担保するのかを考えておきます。


もちろん、いきなり自動化が難しければ、最初は手動で徐々に自動化するで構わないです。アジャイルなので

 

 

また、それらは基本的にどこまで確認すればよいのかの判断が難しいです。( テスト全てにおいてそう言えますが。 )

 

判断が難しいので、

ミッションクリティカルになるところを重点的に見るだとか、

自動テストではAPIの入口と出口をおさえてUI部分は探索的テスト(や目視)で確認だとか、

回帰テストの戦略が重要になります。

 

コミュニケーションのルール

こちらも案外忘れがちです。

知らないところで仕様が変わっていても困りますし、仕様が変更されたことを知らせる場所を決めておいたり、

緊急で重要な報告を誰に行えばいいのかなど、もしもに備えた情報もあると困りません。

また、新しくアサインされたメンバーが朝会や夕会の場所やルール、その他の定例やチャットで用いるルームやチャンネルなどを把握するのにも役立ちます。

 

バグの起票基準/ルール

バグ票を起票する際のルールについても大事です。

重要度(優先度)をいつ誰が決めるのか、その基準はなにか、といったプロジェクト進行上のルールもありますが、

他にも、自由にラベルを付けてしまうと表記揺れが生じて分析が大変になったり、上記のテストタイプ然り認識がズレてしまうこともありえます。

 

必要になってから考えるでも良いので、決まったことはその都度追記することが大事です。

 

おわりに

ここまでお読み頂きありがとうございました。

見当違いなことを書いていたら申し訳ありませんが、
それでもなにかを考えたり話し合ったり議論する材料にでもなれば幸いです。

 

引き続き、アドベントカレンダーをお楽しみください。 

 

QAのお仕事って、具体的にどんなことをしているの?

独りアドベントカレンダーの7日目です。

遅れは気にせずとりあえず完走を目指します。

 

お題

QAのお仕事って、具体的にどんなことをしているの?

お題の提供ありがとうございます!

具体的にとのことなので、自分の組織に寄った話を書きたいと思います。

月曜日に出社してまずい空気を感じたら修正します。

 

QAのおしごと

我々のQAチームは独立しています。

特定のプロダクトやチームに限らず、幅広く活動をしています。

 

だからといってチームの人数が多いわけではありません

少人数で多くのチームやプロジェクトのサポートを中心に活動しています。

 

障害分析

横断的な活動をしているため、優先度を考えて活動をする必要があります。

そこで大事になるもののひとつが過去の障害情報になります。

 

原因の分析や対応についてなどを開発側が詳細をドキュメント化してくれており、

QAはQAで、再発しないようにQA側に出来ることを考えます。

 

全てのチーム、プロジェクトで何が起きているのかを把握することはできないため、

ここでは後手になりますが起きてしまった事象から、何をすべきか/何が出来るかを考えQAチームの施策として取り組みます。

また、探索的テストのチャーターとして使えるような情報があれば、全員が参照できる場所に小さくまとめて書き残します。

 

リスク分析

障害分析は後手の活動ですが、こちらは先手の活動になります。

各部署の企画や開発のカンバンやチケット、紐付く仕様書/設計書の状況を集めて回り

  • どんなプロジェクトが動いているのか
  • どんなリスクを抱えているか
  • プロジェクトが見落としているリスクがないか
  • 他の施策との衝突が起きていないか
  • QAがサポートに入るべきか

などを話し合います。

必要になればQA側がテスト仕様書のレビューを行ったり、探索的テストを行います。

 

テスト計画

プロジェクト側からの依頼があると、テスト計画を行うことがあります。

QAチームが能動的に動くこともありますし、受動的にサポートの依頼を受けることもあります。

 

プロジェクトの概要をヒアリングし、テスト計画を策定、その後はモニタリングコントロールをするなどの支援を行います。

プロジェクトの進行中に問題があれば、テストのアプローチを提案します。

品質に問題があれば しっかりとリスクを伝え、どうすべきかの提案も行います。

 

自分達のQAチームはプロジェクトに対して決定権を持ちません

プロジェクトがより良い方向に進むように全力でサポートをします。

 

チーム内開発

QAチーム内で独自にプロジェクトが動いています。

それは開発を行いやすくするための仕組み作りだったり、

ツールやシステムの開発だったり、

QAチームのスキルアップであったり開発チームの育成であってり啓蒙活動であったりします。

 

そのときそのときに必要なものをチームで考え、

組織としてどうあるべきか、どんなものが欲しいのか、どうなっていたいのか、

それらを考えてそれぞれがプロジェクトにアサインします。

 

 

おわりに

組織の在り方が特殊ではあるので、どの組織でもQAエンジニアがこういった業務をしているとは限りませんので、ご留意ください。

テスト以外にも様々な活動をしていることだけ知っていただければ幸いです。

 

 

おすすめのイベント(勉強会など)を教えて下さい

書いているのは8日ですが6日目です。 

 

お題

おすすめのイベント(勉強会など)を教えて下さい

 

お題の提供ありがとうございます!

 

振り返ってみたところ、

  • connpassから参加18件
  • JaSST'19 Tokyo( 2日間 )
  • Selenium Conf( 2日間 )
  • SQiP( 3日間 )
  • WACATE 夏( 2日間 )
  • Online Test Conf
  • 発表/運営側 3件? 4件?
  • 技術書典7

イベントっぽいイベントはこれくらい参加していました。漏れているかもしれない...

平均すると月2回以上はなにかに参加している日なのですね。

 

テスト系のイベントに関してはこちらのブロッコリーさんの記事もご参考ください。

http://nihonbuson.hatenadiary.jp/entry/2018/12/03/235718

 

halspringのおすすめ

( 順不同 )

WACATE

とりあえずテストのことを学び始めた方は参加すればいいんじゃないのかなくらいのワークショップ形式の勉強会です。

ここでの若手は35歳以下を指していますが、36歳以上で初参加の方もいらっしゃいますし、年長者だからといって何かを強いられることもありませんし、煙たがられることももちろんありません。

1泊2日で外部のイベントに参加したことのない方にはハードルが高いかもしれませんが、中身は初めての人にもおすすめできます。

非常に親切丁寧で、実行委員の方々を中心に参加経験のある方がサポートしてくれる仕組みになっています。

 

業界が狭いので、既に繋がりのある人達の交流を見て不安に感じることもあるかもしれませんが、コミュニケーションが苦手でなければすぐに輪に入ってコミュニティの輪に入れるでしょう

自分はコミュニケーションが苦手なので、参加者のtwitterから攻めました。

大丈夫です、馴染めます

 

参考 : https://wacate.jp

 

JaSST

日本で最大級のソフトウェアテストに関するカンファレンスです。

規模こそ異なりますが、首都圏だけでなく地方でも開催されています

 

内容も濃く、運営側にも参加側にも有識者が集う貴重なありがたい場です。

地方でJaSSTが開催される度に、twitterでテスト界隈の人をフォローしてると「なぜ申し込まなかったのか」と後悔します

 

(東京では) テスト系のイベントに参加すると、どこかの実行委員の方が確実に1人は存在しています

世間は狭いです。

 

参考 : http://www.jasst.jp/

 

Online Test Conf

先日日本向けに実施されたイベントです。

この記事がアドベントカレンダー通りの12/6に書かれていたら時系列的にここに書かれることはないイベントです。

 

土曜日に開催され、参加者も発表者も好きな場所から参加できます。オンラインですからね。

遅めの昼食を取り、こたつでぬくぬくしながら参加していました。

 

物理的に集まって開催されるイベントでは、

電車での移動がストレスだったり、

PCの電池残量を気にしなければいけなかったり、

机がなかったりでメモの取りにくいことがあったり、

椅子に座り続けておしりが痛いけど動くに動けなかったり、

喉乾いたけど調達するタイミングもなかったり、

飲み物を買う鋤があってもエレベーターで降りなきゃだったり、

周囲の人が気になってしまったり、

空調の暑い寒いがあったりと、

まぁまぁいろんな懸念や問題があるのですが、それらが一気に解決します。

 

快適でした。非常にリラックスしながら参加できました。

もっと増やしましょう、こういう形式のイベント。絶対これがいい。

 

参考 : https://www.onlinetestconf.com/

 

connpass各種

めちゃくちゃ省略していますが、connpassから参加申し込みができる各種イベントです。

色々とイベントがあって、どれに参加すればよいのかわからない気持ちはわかります。

 

一旦興味の出たもの全て、参加してみれば良いのではないでしょうか。

 

そのくらいの気持ちで良いと思います。

しっかりと吟味して選び抜いたイベントにしか参加してはいけないわけではありません。

また、参加のハードルに関して自分のレベルとイベントの内容を考慮する必要もありません

例えば聴いてもわからないかもと尻込みしていてはギャップはうまりませんし、有識者に質問できるいい機会でもあるわけですから。

 

たくさん参加してみて、自分にあったものがわかってきたら選んで参加するようにすれば十分だと想います。

結局はそれに尽きます。