# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、共演ジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # テストケースや仕様の確認で使う英単語、フレーズ こんにちは、Qエンジニアのサミーです。 今日もワクワクしていますか? 今回はテストケースだったり、 仕様の確認で使える英単語をお話ししようかなと思っております。 職場で英語を使っていますか? 私は今は使っていないんですけど、 全職では社内で開発エンジニアの方たちと英語を使っていました。 そんな業務の中でよく使った単語だったり、 言い回しみたいなところを1,2,3,4,5,6,7個を紹介したいと思います。 1個目がフィーチャーとファンクションです。 どちらも機能という日本語になってしまうんですけど、 例えばこの機能について教えてくださいみたいな感じで、 Can I ask about this new feature?とか、 そんな感じに聞けばいいかなと思います。 文法が間違っているとかはあるかもしれませんが、 あまり私はそういうところを気にしていなくて、 聞きたいことが聞ける、言いたいことが伝わっていることが 大事かなと思っている派ですので、 文法を間違っていても多めに見てください。 ファンクションとフィーチャーの違いが何かというところなんですけど、 チャットGPTとかブログの情報によると、 ファンクションというのがどちらかというと、 開発視点、技術視点というところで、 動きとか動作を表現する、表すときはファンクションを使うらしいです。 確かに機能テストというのもファンクショナルテストというので、 システムの動作という意味での機能を指しているときは、 ファンクションというのはしっくりきています。 一方でフィーチャーなんですけど、 こちらはどちらかというとユーザー視点で、 価値とか性質としての機能を表すときが、 フィーチャーというふうに使われるらしいです。 なので、この情報から私が感じたことというか、 私の解釈としては、PRDとかこういうものを提供する、 こういう機能を提供するんだよというときはフィーチャーを使う。 あとはフィーチャーフラグとかも言ったりしますよね。 ファンクションの方は、もっと動作にフォーカスしているときの機能というものを指す場合は、 ファンクションを使うのかなというふうに今解釈しております。 ここまでが単語一つ目、フィーチャーとファンクション、機能というところの説明でした。 二つ目はスペシフィケーションですね。これは仕様ですね。 例えばこの仕様についての理解が合っているか確認させてくださいみたいな感じで、 Let me confirm about this specificationなんて言えるかななんて思います。 単語三つ目はCorrectです。正しいということなんですけど、 例えばこの挙動は正しいですかっていうのを英語で言うと、 Is this behavior correctなんて言えるかなと思います。 よく正しいっていう単語だとCorrectとあとRightっていうのがあると思うんですけど、 私の理解としてはCorrectっていうのが客観的に正しいかどうか、 Rightっていうのが主観的なイメージを持っています。 なので、仕様が正しいとか、仕様として正しいとか挙動が正しいという意味だと、 Correctを使うのが正しいんじゃないかなというふうに理解しています。 四つ目の英単語はRequirementsですね。これは要求、要件、 ちょっとこれ結構私もまだ理解が定まってないんですけど、 例えばPRDっていうのもRequirementsですよね。 だとするとPRD、Product Requirements Documentなので、 Requirementsは要求が正しそうですね。 このRequirementsっていう言葉、Requirementsっていうのもよく現場でというか、 使うテスト業務や経営業務をやっていると出てくる単語かなと思います。 五つ目がExpected Resultです。これは期待結果ですね。 テストケースにもよく出てくる単語といいますか、 カラムのところ、名称というところで出てきたりもしますし、 あと不具合報告でも期待結果と実際の結果というふうに両方書くと思うんですけど、 そんなときにExpected Resultはこうこうで、 Actual Resultがこうこうですというふうにリストというか書き出したりします。 Actual Resultというのは実際の結果ですね。 なので期待結果がこうで、実際の結果がこうですという表現になります。 ちょっと横筋というか道筋が外れるんですけど、 テストケースのフォーマットのカラム名にどういう英語を使うかというのもよく迷いますよね。 例えば日本語だと画面とか、あとテスト条件、手順、期待結果というのをよく使うと思うんですけど、 私は最近はガーキン記法の義文演算でパパッと済ませてしまうこともよくあります。 日本語のテスト条件というのがテストコンディション、いわゆるテストコンディションじゃなくて、 義文にあたるこういう条件だったらみたいなものとしてテスト条件と書かれてしまっていることもあったりするので、 それをそのままテストコンディションとやるとちょっと違う、 本来表現したかったものとは違うものになってしまうんだろうなぁなんて思ったりします。 あと手順、オペレーションって書いたりもするけど、画面だったらスクリーンって書いたりしますけど、 結局もやっとするというか、人によって単語が表記売れしちゃうなぁみたいなのもあって、 義文演算でシンプルで良いのではなんて思ったりします。 脇道それましたが、Expected Resultの話でした。 次6個目、単語6個目はHow to reproduceです。これは再現方法ですね。 主に不害報告だったり不害関連のコミュニケーションで使う単語になります。 もしかしたら、reproductionで再現みたいな感じで一言で言ってもいいのかもしれないんですけど、 How to reproduceっていうのはとても分かりやすい言葉なんじゃないかなという風に個人的には考えています。 あとはStep to reproduceとかでもいいかもしれないですね。 最後7個目の単語がThat makes senseです。 これはソフトウェアテストとは関係ないんですけど、知ってて損はしない単語だと思います。 単語じゃないか、言葉ですね、文章。 日本語でThat makes senseを表現すると、ああ、なるほどっていう感じですかね。 仕様のことを聞いたりとか、日々のコミュニケーションの中で絶対なるほどとか確かにとか言いますよね。 なので絶対役に立つフレーズになります。That makes senseです。 ということで今回はテストケースや仕様の確認で使える単語だったりフレーズをお話ししました。 よかったら使ってみてください。 # 再来週はJaSST Tokyoですね ほっこり話の代わりにですね、ちょっとゆるっとお話ししようと思ってます。 さあ、来週はJUST TOKYOですね。いよいよ参加されますか? 私は参加しますので、もしあれよかったら現地でお会いしましょう。 情報交換会とか。 でですね、基調講演の方の情報を見てたんですけど、 ジェームズ・ウィテカーさんですね。 この方、あれなんですよ。去年の12月に和訳の日本語の探索的テストと考え方、 ソフトウェア開発のテスト設計とテクニックを書かれた方です。 知ってました? 今更ながらですね、結構テンション上がっております。 当日、基調講演と質疑応答デッキのお楽しみにしております。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はテストフェーズの話をしようかなと思っています。 単体テスト、結合テスト、システムテスト、受けテストとは、みたいな感じですかね。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 是非、画面右下ハートマークでいいねを押していただけると、とっても励みになります。 また放送を聞いて、学んだこととか考えたこととかあれば、 是非、アウトプットの場としてコメント欄を活用していただけると、 他の方の学びになるので、是非積極的に投稿お願いします。 それではまたお会いしましょう。ごきげんよう。