テスト設計パターンに挑戦「仕様スニペット001」をやってみる

こちらについてどのようなテストケースを書くのか考えてみようと思います。

「仕様スニペット」については思いつくほど実力がないので、自分の身の丈でということで考えてみようと思います。

 

1.仕様通りであることを確認する

正常系(笑)

動作だけにフォーカスしたデシジョンテーブルを作ってみました。


正常系だけやります"という方針で正常系の定義がなされなければこれだけで十分とされる現場があったりします。

 

デシジョンテーブル

GIHOZで自動生成したテストケース

異常系(笑)

異常系の動作も加えてみます。

この場合の異常系とは、エラーハンドルになりそうです。

異常系 エラーハンドルを動作に加えてみたデシジョンテーブル

GIHOZで自動生成したテストケース

※データが0の場合削除をトリガした時の動作について仕様に書いてませんでしたが、うっかり記載してしまいました

よく見たら抜けてるテストケースがあります。

 

間違ってたのでやり直した

上記が間違っていたので直しましたが、できないことと裏返しになっただけでこれって意味あるんだろうか?

直したデシジョンテーブル

自動生成したテストケース

追記
FBをもらいました。

指摘をいただいて気付いたのですが、条件指定部の内容がいけてなさそうです。

 

 

WACATE 2019年冬参加報告 ~テスト業界随一の加速装置、wacateに参加して 自分自身に急ブレーキをかけようと思った話~

本記事の説明

本記事は2019年のWACATEに参加したときの気持ちを書き連ねたものです。

ここに記載することは特に誰かに伝えたいとかでもないし、何かを語りたいわけでもなく、ただひたすら心の中を吐露する26歳くらいのおじさんの記事です。

本来ならばお蔵入りにしておくものでしたが、ある人からリクエストがあり、一部改変しつつもなるべくその時の気持ちそのままに記載しています。

暗い内容なので、見たくない人は今のうちに見ないようにしてください。

全部この人が悪いです。

※プライバシーのため、要望くださった方をマスクしています

WACATEとは

別に説明しない。以下を見てください。いろいろ加速させるところです。

wacate.jp

わざわざ遠出して参加しようと思った背景

私は大阪で第三者検証会社に在籍しており、QA界隈を見て、大阪で孤独だと感じていました。 地方にいるとわかると思いますが、東京みたいな勉強会がありません。現場内や社内でもっと技術交換がしたいと思っていますが、今いる会社にはそういった文化がなく、それをリードできるようなポジションでもありません。
東京に配属された同期が羨ましいな、とかTwitterが楽しそう!とか、ずっと思っていました。
WACATEに行ってみたい!私もあの輪の中に入りたい!
WACATEに参加すると決めてから、WACATEに参加して恥じないように、社内でのアウトプットを増やしたり数少ない大阪のQAイベントにも参加したり、ブログをちょこちょこ書いたりしていました。
「何があっても WACATEに行く」と決めてから、半年くらいずっと楽しみにしていた。
ある意味、WACATEに賭けていました。

急ブレーキをかけると決めた

帰りの新幹線で振り返り、本当によかったのか?と自問自答していました。心地いいと思ってよかったのか?勇気を持って外に出てよかったのか。楽しいと思った自分。

残った薄ら寒さ。
ワークショップなので楽しい!アウトプットをする楽しさ!それってもう知ってることなのでは?
WACATEのポジショニングペーパーセッションで、参加する動機として「おもいでを作りたい」と記述しました。結局、他者に何かを求めようとしている浅ましさに嫌気がさしていた。
一体自分は界隈に何を提供できるのか
  • そもそも第三者検証会社の経験に頼りすぎてはいないか?
  • 本の知識に頼ってはいないか?
  • それは自分で研究したものではないのではないか?
自己嫌悪
なんとなく知っていることを話して、聞いて、楽しいと思っている自分。
そこに主体性はありませんでした。
 
「wacateに参加すれば、自分もテストをしている人間になれる!」
そうとは思えなくなった。答えられないと気がつきました。
自分は何をしている人なのか?
どんな価値を生み出したのか?
大阪から行くメリットはあったかもしれない。じゃあ他の人が私と関わるメリットは何だったのか?
 
自分が参加して、場を汚してしまうことに恥ずかしい気持ちになってしまいました。
 
何もアウトプットしていないのに界隈に参加するのはやめよう、そう決めました。
 

じゃあどうすると決めたのか

とても楽しかったし、モチベーションが上がった。でもそれでいいのか?自分の発散場所が媒体を変えるだけにならないか?急ブレーキをかけた。本当に私の番だったのか?*1アウトプットなら簡単にできると思いました。

失敗したらできないことが”大阪にいるから”という言い訳になってしまっている。何をやるべきか。インプットが多くなりすぎている。結局のところ”自分だけが持つ経験知”が持てていない。

  • アウトプットの楽しさに甘えていていいのか?
  • 自分だけに価値のある、独りよがりなアウトプットではないか?
  • 自分が加速するためだけに他者を利用していないか?

結果良ければいいけれど、それは公正ではない。だめだとは思わないし、私自身はそういうのを見ていてとてもおもしろいと思う。ただ、自分がそうだと許せなくなる。そこに成長はない。同じ場所でくるくる回っているだけ。”ただ輪に入ってなんとなく前に進んでいる感”ではなく、本当の前進と越境が必要になる。どこかで、”今の自分をアウトプットすればいいと思っていた”そこに自分にとっての価値はないのかもしれない。私は自分のあるべき姿から十分なほど遅延していた。インプットとアウトプットのサイクルで質を上げることは自分ひとりでもできる。他者を巻き込むエゴ。

 

目の前の課題

  • 自分に問う。
  • 価値のあることをする。
  • 辛くなったら、やめる。

 

あとがき(2023年の自分から2019年の自分をふりかえって)

この文章を書いたときは途中から公開するのを諦めていました。

また、今回公開するにあたっても微妙な表現をちょこっと直しただけなので、怪文書はそのままです。

ここまで読んだ人すごいですね。

 

さて、実際はどうなったかというとコロナが起こりました。

東京の人は残念でしたが、地方の人にとってはまさに僥倖で、オフライン開催されていたイベントが軒並みオンラインとなり、地方と東京の情報格差はなくなったと言って良いでしょう。

 

私自身もJSTQBALとったり、TPIアセスメント*2できるようになったり、そこそこテスト技術だけで言えば充実してきた?感もあり、当時感じてたほどの劣等感とかはないです。

 

薄ら寒さは今も感じながらも、主流からはある程度距離を置いて生きている…つもりではある。

WACATEハイって言葉ありましたが、こういうWACATEハイもあるんだよってことで、この文章を公開いたします。

 

追記

2019年冬のあとに、2021年夏にもWACATEに参加しました。

https://note.com/usk_ymst_p/n/n9bb653c9e223

2回とも参加して名刺交換したり仲良くなった人は界隈からほぼみんな姿を消してしまいましたが、2019年冬のポジペを見ると今Twitterのタイムラインにいる人がいたり、一緒にテスコン出てる人がいたりして、繋がりではないけど変な縁があって面白いな〜と思いました。

*1:2019年冬のテーマは「あなたの番です」でした

*2:江戸時代のテストアセスメント技術です

WARAI夏の陣2023に参加してきました。

WARAI夏の陣2023

QA/テストプロセスにおける"思考停止"問題~Pre-JaSST Kansai

に参加してきました。

warai.connpass.com

LT形式と書いていましたが、嘘でした。ほぼほぼディスカッションとなっており、オンサイト参加の人を中心に大変活発な議論となりました。

 

強制アイスブレイク

まず最初に毎回恒例の強制アイスブレイクがありました。

QAエンジニアとしてスタートしたばかりの方もいればベテランの方もいたりして、幅広い年代の方が参加されていました。

午前中だけとか、そういう参加でもOKとのことですので、そういった方も次回以降参加を検討されてください。

シフトレフトは正義か?

まず最初はシフトレフトは正義か?シフトレフトの使い所があるのではないか?という議論でした。

シフトレフトってなんなの?というところから、アジャイル開発におけるシフトレフトの功罪・レビュー、計画戦略づくりなどの様々なトピックを扱いました。

特にレビューには皆さん問題意識が多く、活発な議論が展開されました。

 

ゴリゴリバーガー

お昼にはゴリゴリパインバーガーを食べました。値段の割にあんまりおいしくなかったです。

レビューについて

レビューについて、質問しているのに修正が帰ってくるなど問題意識がある方を中心にお話しました。

個人的に私がreview workに参加していたこともあり、「レビューはチームビルディングである」であったり「おしゃべりおじさんはレビューの満足度を下げる」などの発言を行いました。

テスト自動化は難しい?

最後はテスト自動化は難しいかどうか?という話題でした。

テスト自動化を導入にするにあたって、どんな問題があり、どんな風に経営層と合意していけばいいか?という話をしていました。

今回の結果

今回の結果はJaSST nano Vol.24 で発表されるらしいです。

よかったら見てあげてください。

jasst-nano.connpass.com

QAエンジニアの面接の質問を適当に考えてみた

寝起きで10分くらいでQAエンジニアの質問を考えてみました。多分テストエンジニア寄りの内容となっていると思います。

なお、私は採用の経験はありません。

むしろ選考受ける側としてこんな質問来たらいいこと言えるよなーって質問かもしれません。


Q.これまでの経験したSDLCの中で工夫した部分やこだわりの部分があれば教えてください。できればその活動がQCDのどの部分に寄与したか教えてください。

意図:その人が守破離のどの部分にいるか知ることができそう。それからどういったところに強みがあるのか知ることができそう。

 


Q.テスト計画を進める際はどのように進めるのか教えてください。進め方を決める際に必要な情報があれば自由にたくさん質問してください。

意図:テスト計画を考える際にどういったことを考えるのかの思考過程を知ることができる。前提条件として何を知りたいかを言語化する能力とかも知れる。特に正解はなく、どれだけ広い視野を持ってるかがわかればいい。

 


Q.本番と同等の環境で行うテストにおいて、テストケースを作る際はどのように進めるのか教えてください。進め方を決める際に必要な情報があれば自由にたくさん質問してください。

意図:いわゆるシステムテストのテスト設計プロセスをどのように考えているかを知ることができる。こちらも特に正解はなく、前提条件を正しく引き出し、自分なりのテスト設計すれば○

 


Q.ソフトウェアの品質を上げるために必要な施作はどんなことだと考えますか?必要な質問は(略)

意図:品質の定義ができて、その上でどんなことが必要か考えることができるかどうか聞いてみている。

 


Q.どういったチームで働きたいですか?

必ずしもお望みのチームに配属されるとは限りませんが、理想のチームにするためにどういった働き方をされますか?

意図:チームワーク力を知る。

QAエンジニア面接対策に適当に答えてみる

note.com

 

上記のサイトが話題になり、下記のような意見があったので、

私もやってみようと思いました。

どうせ現実の私にはつながらないのでブログで答えます。

ーーー

Q.テスト関連のドキュメントで白紙状態から作成した経験があるドキュメント種類を教えて下さい。

A.テスト計画とWBSとテストケース仕様書を作成したことがあります。白紙から作ることは勉強にはなりましたが、能力がある人間が作るのならば、実務上白紙から作る必要性があるかどうかは疑問に思っています。テンプレートがある場合はなるべくそれを元に使っていくことが効率的で抜け漏れが防げると考えます。

 

Q.一連のテスト工程の対応でやりがいや魅力を感じている部分があれば伺えますでしょうか。

A.テスト実行が楽しい。

テスト実行では最低限テストケースとのふるまいの差異を見ることになりますが、私の場合は実際に動いたソフトウェアがユーザーのニーズや様々な規約、マニュアルなどを見比べて、それぞれどう整合しているかを確認していく工程が好きです。

欠陥を見つけた場合は、その内容を解き明かし、言語化していく過程が楽しいと思っています。

 

Q.テストと品質保証の違いをどのように捉えているか伺えますか。

A.  私は動的テストを品質保証の1手段と考えています。

組織には経営戦略があり、それを支える品質保障戦略があり、それらを実現する方法論やメトリクス、プロセスがあり、その中の重要な要素として動的テストがあるという世界観を持っています。

 

Q.品質保証、品質管理、どちらが得意でしょうか?

A.違いを教えて下さい。違う場合はあなたの会社で区別する意味を教えて下さい。

 

Q.(JSTQB未取得の場合)JSTQBの学習はしていますか?どのような学習方法で勉強されていますか?

A. JSTQB TAE試験に向けて勉強しています。サンプルクエスチョンを翻訳して勉強しています。

 

Q.進捗管理/品質管理をしていく上で、管理に使っている数字、指標値を教えてください。

A.  予実工数、欠陥数/テストケース数など…アサインされた組織による。

 

Q.これまでのご実績で、品質向上に繋がった部分があればご紹介お願いできますでしょうか。

A. 過去の案件でゴニョゴニョ。

定性的なものだとふりかえりとかが割と得意でプロセスの改善に役立っている。

 

Q.テスト工程は、どうしても開発工程の皺寄せがきてしまう時が多いと思いますが、これまでにテスト工程が遅延した経験はありますか。
また、どのようにリカバリーをしたか、お話し頂ける範囲で伺えますでしょうか。

A. 遅延した経験はあります。欠陥がある機能に偏ることが多いため、大きなプロジェクトの場合はアサインを早めに移行することで解決できることが多いです。

小さなプロジェクトの場合は、リスク分析の上、スコープを狭めるかリリースを遅らせるかの二択をビジネス側に迫ることになると思われます。なお、前者の経験はありません。

 

Q.独立した第三者的な立場で総合テスト工程を担当しているとして、結合テストレベルのバグが多発した場合にどのような対応をされますか。

A. 

結合テストでバグが多発した結果、スケジュールの遅延が起こるのか、総合テスト工程の開始基準に影響があるかどうかを心配して、結合テストのマネージャーに聞きにいきます。

その先のマネジメントをどうするかは総合テスト環境の特性やチームメンバーの特性によります。

 

Q.品質向上のために重要になってくると考える要素を教えてください。

A.  単体テストだと考えます。

小さなうちにテストをおこなって、最も早いタイミングでフィードバックを行い、内部品質を高め、技術的負債をなるべくなくすことでビジネスへのフィードバックループも早めることができると考えています。

 

Q.QAエンジニアとして大切にしているマインドや考え方があれば教えてください。

A. 建設的なコミュニケーションと批判的な思考

 

Q.今後のキャリアプランに関してイメージしている部分があれば教えてください。

A.がっぽり稼いで遊びまくる

 

A2(追記)

今もこれからもプロセス改善の担い手であることには変わらないが、

なんだかんだでテストに寄ったエンジニアでありたいと思う。

もっと経営側・ビジネス側とのトレーサビリティがとれるテスト技法・開発方法論を考えてJaSSTとかでブイブイ言わせたい。

初めて勉強会を主催しました 〜han-WARAIを通じて〜

han-WARAIというイベントで、初めて勉強会を主催しました。

han-warai.connpass.com

han-WARAIとは関西ソフトウェアテスト勉強会WARAIのパロディであり、左記の勉強会のアンチテーゼとして以前からやろうと思っていたイベントでした。

社内の勉強会はさんざんやってきましたが、社外勉強会を主催するのは初めての経験となりました。

「勉強会やりたい」とは2019年冬のWacate以来言っており、4年越しぐらいで成就したことになりました。

 

han-WARAIではどんなことをやったのか

JSTQB AL TAE試験の対策として、サンプル問題を翻訳した内容をみんなで解いていく形を取りました。サンプル問題の翻訳はもともと実施しており、勉強会の準備や手間についてはほとんどなかったため、そのような形態を取りました。

実際どうだったのか

17人くらいの応募がありましたが、実際に参加されたのは6名くらいでした。

少なくて拍子抜けした部分もありましたが、相互にやりとりすることを考えると、6名くらいがちょうどよかったのかな、と感じました。

今後のhan-WARAIをどうしていくのか

まだ考えられていませんが、TAEの試験問題を解くのは結構勉強のハードルとしても高く、難しい内容なのかなと感じています。

そうなると私が提供できるのは、テストプロセス改善とかですが、TPI NEXTをアセッサとして実際にやってみるとかそんなことになるのか。。

han-WARAIではふりかえりをやります。

han-WARAIでは恒例行事としたいことがひとつありまして、それは「ふりかえり」です。

勉強会は大抵時間いっぱいまで行って、やりっぱなしで行うことがほとんどですが、han-WARAIでは勉強会の時間中に参加者・主催者で相互にふりかえりを行って、han-WARAIの改善や学びを深めることに役立てたいと考えています。

おそらくふりかえりまでやる勉強会はふりかえりカンファレンス以外にないはずなので、新しい試みだと考えています。

 

そういうわけで次回もお楽しみにしてください。

今度はちゃんと参加してくださいね。

「レビューワーク08~レビュー会議における「発言のしやすさ」について考えてみよう!」に参加してきました

先日までnoteで記事を書いていた私ですが、

ごまずん|note

未確定の文字列がある状態でEnterを押すと改行してしまうという最悪の仕様になってしまったため、はてなブログに戻って来ました。

改めて自己紹介します。

私はやまずんといいます。

大阪の第三者検証もう限界末端テスターでございます。

イベント参加レポートを記載します。

3/27(月)19:00-21:00に開催された「レビューワーク08~レビュー会議における「発言のしやすさ」について考えてみよう!」の内容を共有します。

softwarereview-studygroup.connpass.com

なお、他人が書いたnoteですが、前回までのレポートは下記になります。

note.com

 

おことわり

  • 今回のレポートは非公式的なものであり、自分なりに整理したものです。
  • 「こんなこと言っているんだな~」と思ってみていただければと<(_ _)>

まとめ

  • 全員参加のレビューはレビュー活動の質を上げる
  • 相槌やポジティブ発言でホワイトレビューになり、参加率(発言率)が上がる
  • それらのメトリクス収集法をEosと呼ぶ
  • レビューはチームビルディング活動のひとつでもある(メイクセンス!)

テーマ:レビュー会議における「発言のしやすさ」について考えてみよう!

イベント概要

ソフトウェアレビュー勉強会その8 テーマ:レビュー会議における「発言のしやすさ」について考えてみよう!

今年度のSQiP レビュー研究会での研究成果をいち早くご紹介します。 ソフトウェアのレビュー会議では、上長同僚や有識者がレビューアとなって問題指摘が行われるのが一般的ですが、参加者全員で協力して欠陥検出を行うことでレビュー効果はさらに高まります。この場において参加者間の信頼関係の構築、つまり誰もが「発言しやすい場」にすることが課題となります。では、このレビュー会議における「発言しやすさ」とはなんでしょうか? この発言しやすさを定量化してみよう!という先進的な取り組みを、今年度の研究会の1チームが論文にしてくれました。これをまずはご紹介します。 この論文をベースにお集まり頂いたみなさんで、

実際に現場で話しやすいと感じる場面はどのような状況か?
もしくは話しにくいなぁと感じる場面はどのような状況か?(こっちのアプローチの方が話しやすいかもですね)
について色々な意見を出していただき、

それらを定量的に図る方法はないか?
を考えてみたり、

話しやすい雰囲気を作るにはどういったことをすればよいか?
ということを考えてみたりしたいと思います。 (ちょっと内容変わるかもしれませんが)

どんな内容だったか

  • 前半
    • みんなで思い思いの「話しづらい状況」を出してみよう
    • みんなで思い思いの「話しやすい状況」を出してみよう
    • レビューの雰囲気をよくするために、自分が、他人がしていて雰囲気が良くなったことはないか、みんなで出してみよう
  • 後半
    • Eosの解説
    • レビュー会議でこんな行動を取ると、このパラメータが改善するんじゃないか?と思う行動とパラメータのセットを考えてみよう
    • パラメータのアイディアや、現在出ているパラメータの改善案などを考えてみよう

前半の所感

話しづらい状況として、「ネガティブな発言がある」だとか、「話の内容を理解しようとしない」などがありました。

話しやすい状況としては、「気心知れた仲」だとか、「前向き」などがありました。

 

私の所感としては、同じレビューの場でも、ある人は話しやすい状況で、ある人は話しづらい状況といった、アンバランスな場がレビューの雰囲気を悪くしているのではないか?と考えました。

 

雰囲気を良くするためにみなさんが実施していることとしては、

「ネガティブ発言をポジティブに言い換える」や、「発言者の言うことを一生懸命聞き取り、わからないことがあれば質問して「こういうことですね」と理解する」などがありました。

この点は私はたくさん出ました。

  • 「"〇〇"というところが良かった」とかオウム返し&褒める
  • 自分が議事録担当だった場合、人を攻めるような風潮になってくると、いったん話の整理をしてそれとなく逸らす
  • 何かを批判するときは、〇〇という事実が悪かったという言い方にする人が悪いわけではなく、伸びしろって感をそれとなく伝える
  • 誰かが発言してそれが的外れ的な雰囲気になったら、その人の意図をそれとなく説明してみる

私ってめっちゃ気つかってんだなあと思いました。

後半の所感

Eosについて紹介いただきました。

参考はこちら

https://www.juse.or.jp/sqip/workshop/report/attachs/2022/2_Team-Astraia_論文.pdf

相槌や感嘆詞などをパラメータとして、レビューの雰囲気がどのようなものになっているかをメトリックで定量化しようとする試みでした。

自身・他社の行動としては「ニコニコする」「得意な領域に対する具体的な観点を提示して話を振る」などがありました。

この点も気使いの私はたくさん出ました。

  • 「なるほどね!」って言うと参加者の満足度が上がる
  • 会話が止まったタイミングで短い発言(感想)/質問を行うと会話の参加者数が上がる
  • ウォークスルーでレビューイが相手の目を見て話すと、相槌が増える

最後にパラメータのアイデアや改善案というところではたくさんの意見が活発に交わされ、時間をオーバーするくらい盛り上がっていました。

議論の深さを調べるパラメータの議論や、雰囲気を温度や湿度で表すとどうだ?など、ユニークな意見が数多くでました。

総括

今回の議論のなかで最も印象的というか、メイクセンスしたのが、「レビューを点でなく線で捉えたら、チームビルディングの一種である」というところでした。

確かに、テスターで言えば、テスト計画やテスト分析成果物のレビューというのは、かなり深い自己開示で、それに参加するチームメンバーはどれくらい受容的反応を示すか、というところで、チームビルディングの大事なファクターとなるのではないかとメイクセンスしました。

さいごに

適当に書いたので変なところがあるかもしれません。

その際は遠慮なく指摘してください。(レビュー)