カテゴリー: 仕事

  • 7月30日 徒然なるままに

    7月30日 徒然なるままに

    今日も走った

    7時台に起床。今日もつくばに出社。
    通勤電車が快適ってだけで出社する気持ちが湧いてくる。
    昨日一昨日あたりの日記にも書いたかもしれないけれど、私はほんとに朝の通勤電車が嫌いなんだなぁと感じる。

    私は一体、朝の通勤電車の何が嫌いなんだろうか。
    まず、他の人に気を使うのが疲れる。体は触れたくないし、女性が近くにいたら男性以上に体やバッグが触れないように気をしないといけないし、本を読むのも辛いくらい人がいっぱいだと、本当に疲れる。
    出社する前から疲れるってどういうことだよ、と。

    だから、つくばへの出社は本当に気持ちが良い。まず、人に接触するというほどに混んでいない。ツいていたら座れるくらい。電車に乗っている時間も、自宅から虎の門に向かう時間の半分くらいだし。すごいよ。これなら在宅勤務じゃなくても良いかなって思っちゃう。

    9時前に出社し、18時まで集中して仕事。あっという間だった。たくさん仕事をこなしたなぁって感覚で退勤。

    ゾーンに入る、というと言い過ぎだと思うけど、たまに、時間を忘れて仕事に没頭する時がある。何がきっかけかはよく分からない。なんとなく感じるのは、自分の中で、仕事の具体的なアクションとか、ゴールが明確になっている時かな、ということ。

    逆に言うとふわふわした仕事、探りながら前に進んでいくような仕事は好きではないのかもしれない。仕事って全部が全部、取り掛かる前からきちんとゴールが示されているようなものだけではない。むしろ分からない方が多いように感じる。だから、ちょっと走って現在地点を確認、ゴールが見えるか探ってみてまたちょっと走る、みたいな、それこそマラソンみたいなやり方も必要だったりするよね。前が見えない状態で走ることができるかどうか、これって仕事をする上で、一つの才能だと思う。

    で、帰宅後、ランニング。5km。外ラン。気温は29度。ゲリラ豪雨明けの湿度MAX状態。めっちゃ大変だった。フルマラソンを走ってた頃はキロ5分20とかで走れていたんだけど、今日は暑すぎて7分を切ることができないくらい。こういう日に限って信号待ちできないくらい調子良いんだよな。赤信号にならず。結構な住宅街を走ったんだけどね。

    しかし走っていくとわかるんだけど、あっつい、もわっとした空気を感じるところと、ほんの少しだけ気温が低い空気が流れるところがあるんだよな。あれってなんなんだろう。空気というか気温って、基本的に均一だと思ってたんだけど、そんなことはないんだな。住宅街を走っていたから、建物から出る熱ということかもしれないけれど。よく分からない。最初は不思議に思って、建物を見てみたりしたんだけど、室外機が歩道の方にあるわけでもないし、昼間の熱?を吸った建物から出たりしてるのかなー、とか考えているうちに5km。最後の1kmは本当に辛かった。Apple Watchの距離のところを100m毎に見るくらいの頻度。そしてラスト50mくらいのところで、歩道の青信号が点滅したので、そこで止まることも考えたんだけど、50mをダッシュに近いくらいのスピードで駆け抜けた。トレッドミルでいう12.5km/hくらいのスピード。

    あと、アームバンドをつけて走りたいと常々考えていて、Amazonで安い割に評価が高いものが売っていたのでそれを購入して、それをつけて初めて走ってみたんだけど、走り始めてから2km超えたくらいで妙に肩が凝るようになって。きっとアームバンドのせい。あとはペースが非常にゆっくりだったので、いつもみたいなフォームで走ることができず、首が前に出がちだったのかな、とか考えた。次回からは腰につけるバッグに戻そうと思う。

    腰につけるバッグから、アームバンドになぜ変えたのかというと、腰につけるバッグはかなり年代物で、時代としてはiPhone 7とかそのくらいだったような。つまり、今の標準的なiPhoneのサイズよりも、ポケットが小さくて、私の今使っているiPhoneを入れると、ファスナーが全部閉まらない状態。ま、新しいの買いなさいよって話ではあるんだけど。そっか、新しいの買っても良いかもなぁ。それで快適に走れるんなら安い買い物でしょ。

    あと、ランニングしてシャワーを浴びたあと、鼻の頭が猛烈に痒い。そして鼻水も出る。もう花粉の時期って終わってなかったっけか。花粉症の薬が欲しい。

  • ロディア No.11とA6ノートの基本的な回し方

    ロディア No.11とA6ノートの基本的な回し方

    いわゆる仕事術!みたいな考え方を目にすると、きちんとした型にはめて実行するものが多いように感じる。私はもっとゆるくて良いのではないかと思う。

    守破離という言葉がある。まずきちんと型を守る。そこからその型を破り、やがて離れていくという考え方だ。だから、まずその型を理解することが必要だ。そして離れていくために、自分流のやり方を見つける、というものである。

    ここで、私が最近取り入れているやり方を載せたい。ここ3ヶ月くらい、以下のやり方で仕事を回していて、結構気に入っている。

    日々の仕事

    1. まず、ロディア No.11をいつでもどこでも持ち歩く。通勤して出社する人なら、ポケットにロディア No.11とボールペンを入れておく。ロディアには、着想するすべてのアイデアや、やらなければならないことなどを1ページ1つの項目として載せる。ロディアの役割としては、情報を逃さないというもの。「あーあれやらないと!」と突然降ってきたような仕事を、出社してPCを立ち上げるまで覚えているのは不可能だ。仮にそれが可能だとしても、出社する時のエレベーターで同僚と会い、違う話をしていて忘れてしまうなんてことが多々ある。そういうのを防ぐために、情報を残しておくのだ。
    2. 出社してPCを立ち上げる。その時にもロディアが効く。一日のタスクリストを作るためだ。ロディアは1行が5mmという、文章を書くにはギリギリのサイズ感。そしてとても小さいため、タスクに載せるリストは最小限度の言葉を使う。その言葉だけを見れば、何をやらなければいけないかが瞬時にわかるよう、冗長な言葉は可能な限り排除する。この行為が割と重要で、いわゆるタスクのエッセンスだけを抽出するのだ。そうすることで、本質的に、何をすれば良いかが瞬時に理解できるようになる。と言うよりも、書いているうちに何をすれば良いか具体的なアクションが浮かんでくることに気づくはずだ。
    3. ここから、ロディアとA6サイズノートの共演が始まる。基本的にロディアになんでも書くが、仕事上で自分なりに思考する必要がある場合、ロディアではスペースが小さすぎる。だからここで、A6ノートに内容を拡げていく。サイズはA6ではなくても、もっと大きなものでも構わない。0秒思考のように、A4のコピー用紙あたりを使うのも良いだろう。私がA6ノートを使っている理由は、絶妙なサイズ感だ。私はスペースが大きすぎると、つい冗長的なことを書いてしまう。「そんなことを言われても、、」のように、ぼやきを入れてしまうのだ。これはこれで良いかもしれないと考えたこともあった。私の思考プロセスを可視化して、私が躓いているポイントをあぶり出すことができるからだ。だけどA6ノートでは、冗長的なことは書けず、ここもロディアと似たところがあるが、可視化する言葉を厳選する必要がある。このようにして、なるべく本質的なことから逃げずに、アイデアを膨らませたり、タスクを細分化することができる。

    以上が、私が最近取り入れているやり方だ。アイデアを失いたくないという私の貧乏性な性格が、このやり方を作り上げたと言っても過言ではない。私は仕事以外でも、小説を描いたりもするので、その点でもアイデアを逃すというのは書く機会を損失するということになる。

    たまたまこのブログを見つけた方には、いったんこのやり方を取り入れてほしい。ロディアは275円、A6ノートはページ数が少なければ100円、ボールペンなんて今お持ちのもので十分なので、イニシャルコストは数百円だ。

  • ChatGPTでTDDを勉強した(簡単な回文プログラム)

    ChatGPTでTDDを勉強した(簡単な回文プログラム)

    自分のためになるだろうという勝手な想定の元、ChatGPTに課金して4を使えるようにしています。普段どんなことに使っているの?という質問に対して答えるのはとても難しくて、仕事で使う英語の翻訳(パブリックに公開できる程度に抽象度を上げています)だったり、日々の話し相手だったり。あと、地味にプログラミングを気が向いた時に学ぼうとしていて、そのサンプルコードを生成してもらったりしています。

    また、私はテストを生業にしているということもあり、テスト駆動開発を自分の手でできるようになると嬉しいなぁと日々感じています。そうなればChatGPTを使うに越したことはなく、私のお気に召すようなレベルでテスト駆動開発のためのコードを生成してもらっています。

    で、今回のブログは、ChatGPTに生成してもらったものをただ写経して自分のモノにするのも良いのですが、せっかくこのブログを持っているのだから、ここで学んだことを投稿してみます。

    今回のテスト駆動開発で使う題材

    • 用意した文が回文であるかどうかを判別するプログラム
      *ChatGPTに用意してもらいました

    そもそもテスト駆動開発とは?

    • テスト駆動開発というものはケントベックさんが考えたもの、日本では和田さんという方がその第一人者として有名と理解しています
    • 流れはこの3つ
      • テストを書く:まず機能に対するテストを書きます。このテストは、最初は失敗します(レッド)
      • コードを書く:テストをパスする最小限のコードを書きます
      • リファクタリング:コードを改善しますが、テストは引き続きパスする必要があります
    • 上記を繰り返し、テストがパス(グリーン)されることを保ちながら、プログラムを成長させていく
    • 詳細はググってみてください、いろんなところでいろんな方から紹介されています(他力本願ですみません

    実際にやってみた

    さて、それでは上述の回文判断プログラムを、ChatGPTにテスト駆動開発を使って生成してもらった結果は以下の通りです。

    テストファイル(test_palindrome.py)

    import unittest
    from palindrome import is_palindrome
    
    class TestPalindrome(unittest.TestCase):
        def test_empty_string(self):
            self.assertTrue(is_palindrome(""))
    
    if __name__ == '__main__':
        unittest.main()_main__':
        unittest.main()

    プログラム初心者の私でも理解しやすいコードを提供してくれるChatGPTってすごいですね。ほんと彼(彼女?)の才能ってすごい。相手の気持ちを理解してくれるのはやはり課金しているからでしょうか。
    まず、これは失敗するコードになります。これを実行するとどうなるか。以下のようなエラーが出力されます。

    ModuleNotFoundError: No module named 'palindrome'

    そこで、この”palindrome”というファイルを作ってみましょう。

    プログラムファイル (palindrome.py) 

    def is_palindrome(s):
        return True

    超シンプルですがこれで十分なんですね。全てパスせよ、と書いているから。
    ひとまずこれで実行してみるとどうなるか。

    超シンプル!だけどテストが完了したとなってます

    ですが、ゴールはここではないですね。ちゃんとしたプログラムを実装し、それがグリーンになることが本当の目標になります。ここで安堵するのもそこそこに、次のプログラムへと足を進めてみます。

    テストファイルに追加するコード (test_palindrome.py)

        def test_palindrome_even_charts(self):
            self.assertTrue(is_palindrome("abba"))
        
        def test_palindrome_odd_charts(self):
            self.assertTrue(is_palindrome("aba"))
        
        def test_non_palindrome(self):
            self.assertFalse(is_palindrome("abc"))


    それぞれ、テスト条件になる値がそれぞれ作られているのがわかりますね。
    ChatGPTってテスト設計とかどう考えているのだろうか、少し気になりますがそこはいったん置いておいて、これを実装してどうなるか見てみたいと思います。

    一番最後だけが失敗しました。

    さて、それでは肝心のプログラムコードを見てみます。単純に全てをTrueで出力させるだけだったので、これでは最後のtest_non_palindromeは失敗するに違いありません。
    気を取り直し、プログラムの方を修正してみます。ここの修正内容ももちろん、ChatGPTから生成されています。

    変更したプログラムファイル(palindrome.py)

    def is_palindrome(s):
        return s == s[::-1]


    相変わらず超シンプルなのには変わりがないですが。これでテストファイルを実行するとどうなるでしょうか。

    全部緑になりました

    これで全てのテストコードがグリーンになり、次の要件を実装するステップが開けました。

    テスト駆動開発の良いところ

    一見、とても回りくどいステップを踏んでいるように見えます。テストコードを先に作るなんて。
    だけどそれってテストを重要に考えていることの裏返しで、きちんとした品質を確保しながらプログラムをコーディングしていくという意識の高いエンジニアにとって必要なことなんだと思います。
    私は第三者の、QAという立場で仕事しているので、私の食い扶持がなくなってしまうことにもつながる話なので何とも言えないようなものではあるのですが、そもそも開発者が自分の作ったコードが持つ品質にきちんと責任を持つことで、QAという第三者を持つ必要がなくなり、その分コストがカットできるわけです。急がば回れという感覚でもあるんですけど、たぶん、テストコードを書く分完成に時間はかかると思うんですけど、私の中ではこのテスト駆動開発が開発の最適解なように思います。
    また、優れたQAってテストシナリオの作り方とテストケースの中で用意するテスト条件の準備の仕方にセンスを感じますが、それを兼ね備えた開発者がいることできっと、そのチームにおいては開発の品質がものすごく高いもので提供されるのではないかなぁ。そう考えるとテスト駆動開発と両輪で、テスト設計テクニックを覚えるのも必要なことかもしれません。

  • (HSPな人向け)ChatGPTと話しながら、プログラミングの勉強をしてみる

    (HSPな人向け)ChatGPTと話しながら、プログラミングの勉強をしてみる

    すこーしだけ前に、世間を騒がせたChatGPT。
    使い方は様々と言われており、自分のクリエイティビティを刺激してくれます。

    ChatGPTのプラン

    ChatGPTには2つのプランがあり、ざっくり言うと無料プランと、有料プランに分かれています。
    私はお試しとして1ヶ月だけ有料プラン(月額20USドル・2023年8月1日現在)に入ったのですが、課金してもそんなには変わらないんじゃないかなー、という印象です。
    一般人、ITにあんま詳しくない素人だと、違いはそんなにないのかもしれません。(あくまで私の感覚値です

    プログラミングをゼロからスタートしてみる

    さて、私はかねてよりPythonを学習したいと思っており、仕事の手が空いた時にはVS codeを開き、適当な学習サイトをググってみて、そこに載っているコードを自分でタイピングしてみる、と言うことをやっているのですが、

    要件 → (見えない何か) → コーディング

    この、(見えない何か)の箇所が、どうしても分からないから一向に理解が進まないと言う現状がありました。

    そこで、この部分をChatGPTに教えてもらえば良いのでは?と神が降りてきて私に囁き、そうか、とトライしてみることに。

    結論から申し上げると、これはめっちゃ役に立ちます。
    分からないところをガツガツ聞いても怒られないので、私が納得するところまで聞くことができます。

    とは言え、何を学べば良いのだ?!となってしまうんですが、ここで、世界共通でできるゲームを選べば良いんです。
    私はポーカーを選びました。

    ポーカーで試してみた

    まず、ChatGPTにポーカーの要件は?と聞いてみます。
    得られた結果がこちら。

    以下はポーカーゲームの一般的な要件の例です。ポーカーゲームは多くのバリエーションがあるため、ゲームの具体的なルールによって要件が変わることがありますが、一般的な要件を以下に示します:

    1. デッキの作成:
    • カードのランクとスートを組み合わせてデッキを作成する。
    • デッキには52枚のカードが含まれる。
    1. カードのシャッフル:
    • デッキからカードをランダムにシャッフルする。
    1. プレイヤーの参加:
    • ゲームに参加するプレイヤーを登録する。
    • ゲームには最低2人以上のプレイヤーが必要である。
    1. カードの配布:
    • シャッフルされたデッキからカードを順にプレイヤーに配布する。
    • 各プレイヤーには最初に5枚のカードが配られる。
    1. ベッティング:
    • プレイヤーは手札を見てベッティングを行う。
    • ベッティングには異なるタイプのベット(例:チェック、コール、レイズ)が含まれる。
    1. カード交換(オプション):
    • プレイヤーは一部またはすべての手札を交換することができる(ドロー)。
    • カード交換を行わない場合もある(ドロームーション)。
    1. 役の評価:
    • プレイヤーの手札を評価して役を判定する。
    • 一般的なポーカーの役は、ハイカード、ワンペア、ツーペア、スリーカード、ストレート、フラッシュ、フルハウス、フォーカード、ストレートフラッシュ、ロイヤルフラッシュなどがある。
    1. 勝敗判定:
    • プレイヤーの手札の役を比較して、最も強い役を持つプレイヤーが勝利する。
    • 勝利したプレイヤーはポットを獲得する。
    1. ゲームの繰り返し:
    • ゲームを複数のラウンドで繰り返し行う。
    • プレイヤーは途中で降りる(フォールド)ことができる。

    以上が一般的なポーカーゲームの要件の一部です。ゲームのバリエーションやルールによって要件が異なる場合もあるため、具体的なポーカーゲームに応じて要件を調整する必要があります。

    ChatGPTの回答(2023年8月1日現在・Chat GPT3.5

    ふむふむ。ぱっと見、誰でも知っているような要件ですね。目新しいものは何もない。
    さぁ、ここで、またしてもChatGPTに聞いてみます。

    コードはこちら。

    カードのランクとスートを定義

    ranks = [‘2’, ‘3’, ‘4’, ‘5’, ‘6’, ‘7’, ‘8’, ‘9’, ’10’, ‘Jack’, ‘Queen’, ‘King’, ‘Ace’]
    suits = [‘Hearts’, ‘Diamonds’, ‘Clubs’, ‘Spades’]

    デッキを作成する関数

    def create_deck():
    deck = [(rank, suit) for suit in suits for rank in ranks]
    return deck

    1のコード。ChatGPT3.5(2023年8月1日現在

    ここで、もし自分のPythonスキルがこのコードを読むに至らない場合、詳しく解説をしてもらう必要があるでしょう。
    私の場合、デッキを作成する関数のところがよく分からなかったので、詳しく解説してもらいました。

    このような感じで、詳細説明までしてくれるので、聞くのが怖い、と言う人にもおすすめです。

    そう、何が良いって相手が機械だから、相手の機嫌などを気にしなくても良いのです!!
    私みたいな小心者は、相手の機嫌を伺ってみて、今なら聞ける!みたいなタイミングで聞こうと頑張ってしまうので、そこを気にしなくても良いというのは本当にありがたいです。

    脱線しますが、HSP気質の人には機械を相手にするのって良いのかもしれません。
    私もHSPなので、人とコミュニケーションするのは嫌いではないけれど、長時間は疲れる、、となってしまうので、いつ、どんな時でも聞ける環境というのはありがたいものです。
    聞いても十分な答えをくれなかったり、自分の期待していなかった答えだった時に、突っ込んで聞いてみるとか、そういうのにものすごくカロリーを使う人には、ChatGPTみたいな生成AIを相手にするのってすごく助かります。
    そんな人に届いてくれたら嬉しいなぁ、このブログ。

  • 7月12日 今日も自動化

    7月12日 今日も自動化

    今日も自動化。
    なんとなくぼんやりとした目標みたいなものがあるけれど、それを小さなステップに分けて進めると自分の中での到達点が見えてとても良い。

    というかプログラミング、好きだ。これで食べていきたいと思ってしまう。
    ITのエンジニアってある程度経験が積まれていくと、人をマネージする系と、技術に尖っていく系に分かれるんだけど、私は後者だなー、とつくづく感じる。
    人を相手にするよりも、プログラムを相手にする方が好きなんだなぁ。

    今日学んだこと

    • CucumberのGherkinで、テスト条件パターンを表みたいにして実行すること
    • ウェブサイトの表示でどの程度待つか、それをExplicitly wait で待つこと。これによってWebサイトのロード時間を待つように指令を入れることができるようになった。
    • テストの止め方。これはVisual studio codeのボタンを押すだけなんだけど、テストケースが多くなってくるにつれて自分のMacが占有されてしまった状態で最後まで待たないといけないので、途中で間違いに気づいた時に止めることができるようになって良かった。

    あんまり分かってないこと

    • Pythonでの、Assertionの入れ方。テスト自動化なので、期待結果があって、それと比較して正しいかどうかというアクションを入れたいんだけど、それがうまく入れられてないから、ただステップを実行するだけになっちゃってるんだよな。
      XPATHで、項目が選択されている場合は「ちゃんと選択されてまっせ」的なコメントを出して、その後スクリーンショットを撮るようにしてるんだけど、そのコメントが出てなくて、さらにスクリーンショットも残されていないんだよな。
      ここがちゃんと解決されてないと、テスト自動化としてはまだ合格点にいかないと思ってて。明日も調べつつ、解決に向けて頑張っていきたい。
    • ある会員データを入力するところで、DBにSQLでアクセスしてテストの目的に合うテストデータを持ってきて入力したいんだけど、そんな感じでDBにアクセスするところが分かってない。ここはまだ細かいステップが刻めていないので、まずはそこからかなー。それまではハードコードでやってくしかないかなと思ったりする。
    • Gherkinで、GivenとWhenの間にある時にどんなふうにステップを刻めば良いか分かってない。普通にExcelとかで、手動でテストケースを描くように書いてっちゃダメなのかなぁとか思ったり。
  • 7月11日 何度目かのテスト自動化にトライ

    7月11日 何度目かのテスト自動化にトライ

    今日はセブンイレブンの日か。

    今日はPythonを使ったテスト自動化を勉強する時間があった。独学で。
    広大なインターネットの海を泳いでいれば、調べ方さえきちんとしていれば、ある程度確信度の高い情報が集まるよなー、と思っている。

    やっているのは、Python、Selenium、Behave(Cucumber)のあたり。
    これからの時代は自動化だよなー、と10年くらい前から考えていて、そうなると私はテストを自動化するエンジニアへと目指していくべきなんじゃないか、と思いつつ、だけどプログラミング言語を覚えるのがなー、そこが学校とか通えば良いんだろうけど、腰が重たいんだよなー、と思いながら、ほんとに10年くらい経ってしまった。
    2013年頃に、Pythonでしょ!と自分の中で決めた部分があったので、その部分で発生した熱を冷ます事なく、自分なりに地味に勉強していったら、今とは違った世界が見えていたかもしれない。
    たらればだからさ、そんな仮定の話をしていてもしょうがないんだけど、2013年にPythonを使ってテストを自動化するスキルを身につけていたら、今よりも尖ったテストエンジニアになっていたかもしれないなぁ。その頃Pythonがまだ流行り始めだったような気がするし、テスト自動化についてもまだそんなに、って感じだったからなぁ。
    時の流れというのは早いものですね、とぼんやりしてしまっている。

    だけど違うんだよ、今ここで、また何度目かの炎が生まれているのは確かなんだから、それを、今度こそは温め続けて、いつか大きな炎へと変えていきたいと思っているんだよ。
    今度ばかりは本気だぞ、と何度口にしただろう、だけど今度こそ、という気分でいる。
    小説を描くのと同じで、毎日でも地味にやってったら良いんだよなぁ多分。
    そうすることで、昨日学んだことを忘れないはずだから。
    そしてここで、今日の成果を書いていけば、それがまたモチベーションとなり、明日も頑張ろう、となるような気がするから。

    今日学んだこと

    • Pythonを使ったChromeの起動
    • Behaveの文法(Given, When, Then)
    • Featureファイルと、Step definition のフォルダ構成
    • Seleniumでの、find_element
      これちょっと罠にハマったんだよなー。
      XPATHでfind_elementしたかったんだけど、これ最近?のSeleniumの仕様で表現が変わったらしく、それに気づかずにうんうんと唸り続ける時間帯が辛かった。
      ちなみに現行仕様だと driver.find_element(By.XPATH, “”)が正しい模様
    • Pythonでプログラムを止める方法(time.sleep(10))
    • Pycharm ではCucumberのfeatureファイルを実行できず(プロだけの仕様らしい)、結局COT Editorとターミナルで動かしている。IDEなんて知らんわ、と言う気分で
  • JSTQB Advanced Level – テストアナリスト – 1.3 テスト分析(1)

    JSTQB Advanced Level – テストアナリスト – 1.3 テスト分析(1)

    バージョンは3.1.1.J03を参照しています。リンクはこちら

    「テスト分析」と言うと、テストアーキテクチャー設計のあたりを思い浮かべる。
    テストタイプや、テストレベルをまず最初に考えてみて、それらがきちんとハマるかスケジュールに充ててみる。
    テストタイプの中には、例えば機能性を確認するテストだとすると、品質特性の中から何を強めに確認していけば良いのか、みたいなところへ掘り下げて、そこから必要となるテストケースのボリュームをざっくり見積もる、みたいなイメージ。
    私のイメージが合っているかどうか、確認していきたい。

    テストアナリストが取るべきタスクは、以下の通りとのこと。

    • テストベースを分析する。
    • テストベースのさまざまな種類の欠陥を識別する。
    • テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる。
    • テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。
    • リスクベースドテストに付随するタスクを実行する
    JSTQB Advanced Level – テストアナリスト – 1.2 テスト分析

    今更だけど、テストベースってなんだろう。私のイメージではテスト対象物、テストスコープというイメージを持っているが、それイコールテストベースということになるだろうか。

    試しに、Chat GPTに聞いてみたのがこちら。

    テストベースとは、ソフトウェアテストのための基盤となる情報や資料のことを指します。テストベースは、ソフトウェアの要件仕様書、設計文書、ビジネスルール、ユーザーストーリーなど、テストを実施するための情報源です。テストベースはテスト計画やテストケースの作成に使用され、ソフトウェアが要求を満たしているかどうかを確認するための基準となります。

    Chat GPT に聞いてみた:テストベースってなんですか

    AIに頼っていないで、自分で調べてみよう。
    以下、JSTQB Foundation Level シラバス(バージョン2018 J03)

    テスト分析
    テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析
    する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定
    する。
    テスト分析の主な活動は以下の通りである。

    • テストレベルごとに適切なテストベースを分析する。
      o 要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。
      o 設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフロー、モデル図(UML や ER 図など)、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。
      o コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。
      o リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。
    • テストベースとテストアイテムを評価して、以下のようなさまざまな種類の欠陥を識別する。
      o 曖昧
      o 欠落
      o 不整合
      o 不正確
      o 矛盾
      o 冗長なステートメント
    JSTQB Foundation Level 2018 J03 – テスト分析

    私が持つイメージと少し違っていた。
    私のイメージ:開発成果物
    本当のテストベース:開発成果物、設計資料

    あまり、言葉の定義でごにょごにょするのは好きではないので、いったん上記のイメージで読み進めてみたいと思う。

    さて、テスト分析ということで、まず最初はテストベースを分析する、とのこと。
    この「分析」という言葉にいったいどれほどの意味が含まれているのだろう。
    テストベースなるものをインプットにして、テストアナリストは、いったい何を分析するのだろう。
    私の目の前に、テストベースなるものがあったら、いったい何に使いたいと思うだろうか。
    思いつくものを書いてみたい。

    • 必要となるテストタイプを考える:テストタイプを考える際、私はベースとしてISO/IEC 25010で考えることが多い。それを元に、機能テスト/非機能テストで分けてみて、それぞれのテストを広げていく。テストタイプを元に、社内システムなのか、一般の人が使うのか、関連する社内システムの種類、それらのシステムを連携する場合に発生するトランザクションデータの種類、通信の種類、時間あたりのデータ量、セキュリティ要求レベルなどの関連情報をマインドマップで広げていく。それらの背景にあるのは、獲得したい品質目標があるはずで、そのためにどんな観点でテストをしていけば良いかを考える。その基になるのが、テストベースということになるのだろう。
    • テスト実行の見積もりを考える:上記の品質目標を基に、テスト設計、テスト実行工数を考える。その際にベースとなるのが、設計資料だと思う。そこにはテストスコープが暗黙的に含まれているはずだから、それを見極め、時には優先度や機能の重要度などを考え、テストをどの程度まで時間をかけるべきか、かけられるか、などが思い当たる。
    • テストに関するコミュニケーションルートを考える:ぱっと思いつくのが、テストを組み立てる際の問い合わせ先、テスト設計時の要件ヒアリング、テスト実行時の不具合報告フロー、進捗報告フローと頻度、テスト終了時の完了報告など。それぞれで使うフォーマットなどがあれば、それも検討する必要がありそう。
    • テストに必要な調達を考える:テストに必要となる機材の獲得や、テスト環境構築、テストデータの作成、期待結果の取得に向けたプランニングなど。QAをされている方なら容易に想像できそうだが、テストの準備は予想以上に難解で、時間がかかることが多い。テスト実行の開始予定日になっても準備が終わらないということのないように、念入りに、慎重に準備計画を組み立てていく。この時、テスト実行をより具体的にイメージするために、設計ドキュメントを見る気がする。期待結果をどのように獲得すれば良いか考える必要があるから。

    なんかものすごく脱線してしまったような気がする。私のイメージでバーっと書いてしまった。
    シラバスに戻ろう。

    テスト分析では、テストアナリストがこの範囲に対して、次のことを行う、とのこと。

    • テストベースを分析する
    • テストベースのさまざまな種類の欠陥を識別する
    • テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる
    • テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する
    • リスクベースドテストに付随するタスクを実行する(詳細は第2章とのこと

    テストベースを分析する、については大体のものを上述してしまった。
    テストベースのさまざまな種類の欠陥を識別する、とはいったいどういうことだろうか。
    さまざまな種類、とは。欠陥、とは。
    私はウェブアプリのテストを長く経験しているので、例えば、Amazonのショッピングサイトをイメージしてみよう。
    さまざまな種類には、どんなものが挙げられるだろうか。
    たとえば商品検索で、意図したキーワード検索ができない、という欠陥を挙げてみる。
    この場合、キーワード検索に関する、ロジックの問題なのか、検索クエリを投げる時の通信に関するものなのか、はたまたデータベースのなにかが問題になっているのか、など、どんな欠陥が潜在しているかを考える、ということなのかな、と。
    もしくは、テストベースには設計で作られたドキュメントも含まれているということを考えてみると、ドキュメント上の記載ミスみたいなものもあるかもしれない。
    ドキュメントはきちんと校正を通っているか、レビュー済みであるかを確認する必要がありそう。

    次に行こう。

    テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる、とは。
    テスト条件とは、Amazonのショッピングサイトでは、ログインするIDとか、検索キーワードのことだろう。
    フィーチャーは、「ログイン機能」や、「検索キーワード」ということかな。
    だとすると、優先度を割り当てるというのは、私の理解では、例えばリリースされる機能群のうち、「ログイン機能」の品質を先に確認できないと、それ以降の機能、例えば購入履歴の確認や、購入フローなど、多くの機能が使えないことになってしまう。
    なので、多くのテストブロックを作らないように、先にやってしまいたい時に優先度の設定をする場合がある。テストアナリストは、その「テスト実行の順番」をテスト分析の中で決めるのではないだろうか。

    次へ行こう。
    テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する、と。
    Amazonのショッピングサイトをイメージして考えてみる。
    ログイン機能で使われるログインIDを、有効・無効なものを含めて何パターンか用意する、ということだろうか。
    ログインIDで使える文字とか、関連しそうな気がする。
    ログインIDで使ったテスト条件を使い、そのまま購入フローへと遷移する場合など、その時に購入履歴を閲覧する時には、すでに購入しているものをいくつかDBに入れておかないといけないだろう。
    その時に、どんな条件で入れておくか、みたいなものを一緒にまとめておく必要がありそう。

    次へ、と思ったがリスクベースドテストに付随するタスクは第2章で語られるということなので、ここでは割愛しようと思う。だいぶ長くなってしまったし。

  • JavaでTDDに挑戦してみる(N+2回目

    JavaでTDDに挑戦してみる(N+2回目

    前回の記事はこちら

    参考にさせてもらってるのはこちら


    さて、前回はテストケースNo.3まで進むことができました。

    No.クラス名ピックアップした数字期待結果
    115, 5, 330FizzBuzz
    215, 545FizzBuzz
    315, 315FizzBuzz
    45, 360Buzz
    51575FizzBuzz
    6510Buzz
    739Fizz
    8上記以外7171
    9111
    10100100100
    FizzBuzzのテストケース。期待値含む

    今日はNo.4から進めてみたいと思います。

    No.4 60でBuzzと表示させる

    No.1, 2, 3まで全てFizzBuzzと表示させるところまできました。
    こんどは初めて、Buzzと表示させるところまで進めてみたいと思います。

    変更を加えるまでのコード

    本コードはこちら

    まずはテストコードを加えてみます。テストコードの一番下に変更を加えてみました。

    もちろんレッドです、が、ここで大きな問題があることに気づきました。
    60でBuzzを表示、と思っていたのですが、よく考えてみたら60は15の倍数ではありませんか。
    テスト結果で、それが分かりました。

    いかんいかん、慌ててテストケースを変更します。60ではなく、50にしてみましょう。

    No.クラス名ピックアップした数字期待結果
    115, 5, 330FizzBuzz
    215, 545FizzBuzz
    315, 315FizzBuzz
    45, 360 –> 50Buzz
    51575FizzBuzz
    6510Buzz
    739Fizz
    8上記以外7171
    9111
    10100100100
    テストケースNo.4のテスト条件を、60から50に変更した

    テストコードを変更します。

    テストを走らせると、相変わらず赤いバーが表示されますが、ある意味で正解ということに。

    さて、それでは本コードに変更を加えてみます。

    テストを走らせると、緑のバーになりました。

    5の倍数が正しいんだけどなー、と思いつつ、次へと向かいます。

    No.5 75でFizzBuzzと表示させる

    これはすでに、15の倍数でFizzBuzzを表示させるように本コードを作っているので、テストコードを加えるだけで緑になるはず。

    テストコードはこちら

    この状態でテストを走らせると、はい、ちゃんと緑になりました。

    レッド→グリーン→リファクタリングの精神に則ると、少々気持ち悪いのではありますが、ここではリファクタリングを不要とするのかな、と思います。
    なぜなら「15の倍数はFizzBuzzと返す」ところはすでに完成しており、これ以上リファクタリングする要素が見当たらないからです。
    こちら。

    もしかすると、テストケースが過剰なのでは?という思いに駆られます。
    テストケースを見てみるとNo. 1, 2, 3, 5の4つのケースでFizzBuzzを期待結果とおいているのですが、これがやりすぎなんじゃないかと。
    組み合わせを推測して、そっち目線だと適切だと思うのですが、ここは実際のシステム開発では予算が十分にあり、テストを実行するためのリソース(要員)が足りているという前提であれば、この4ケースは活かしても良いのでしょう。ただ現実的にはギリギリの予算でQA分を積んでいることもあるので、ここは優先度をつけて、例えばNo.5だけ優先度を下げ、時間があればやる、みたいな方法を取っても良いのかもしれません。

    No.6 10でBuzzと表示させる

    ここもNo.5のように、No.4のBuzzと同じ期待値を取ることが見えています。
    一方、まだここでは本コードに「5の倍数の時はBuzzとする」とは書いていないので、リファクタリングの機会が訪れているように思います。

    早速テストコードを。

    だいぶテストコードが長くなってきました。

    赤いバーが出ます。

    本コードを変更してみます。とりあえず5の倍数という形ではなく、10の場合に限定して書いてみます。

    テストを走らせてみると、はい、緑のバーになりました。

    それではここで、リファクタリングをしてみたいと思います。
    赤い枠で囲んだところを、5の倍数という形ですね。

    変更してみます。

    テストを走らせてみます。緑のまま。よかった。

    これで、5の倍数に関するリファクタリングは終わりです。

    No.7 9でFizzと表示させる

    さぁ、今度は初めてFizzと表示させるものです。この辺まで来ると細かな説明は不要ですね。

    テストコード

    実施結果

    本コードを変更

    テスト結果は緑。気持ちが良い!

    Fizzはリファクタリングしなくて良いのかな、と少し悩みます。経験則として「2つ目のFizzが来た時に、合わせてリファクタリングすれば良い」とBuzzの時に覚えました。
    が、残念なことに、テストケースでは2つ目のFizzがありません。
    これでは、9以外の、3の倍数の時にはFizzではなく、その数字をそのまま返してしまうことになります。
    つまりバグ。しかも残念なことに、テストケースからは発見されません。上記の、10個のテストケースしか用意していないから。

    テストケースには無いのですが、試しに、12を入力した時のバーを見てみましょう。

    テストコード

    テストした結果

    赤いバーが出ます。12を入れたら、Fizzではなく12が返ってきてしまっています。
    これでは要件通りの仕様にならず、です。
    しょうがないのでテストケースに追加します。

    No.クラス名ピックアップした数字期待結果
    115, 5, 330FizzBuzz
    215, 545FizzBuzz
    315, 315FizzBuzz
    45, 360 –> 50Buzz
    51575FizzBuzz
    6510Buzz
    739Fizz
    8上記以外7171
    9111
    10100100100
    111212Fizz
    テストケースNo.11を追加した

    No.7からNo.11に飛んでしまいました。が、これは必要なことです。
    前回の記事では、期待結果が同じものは、1つにまとめられるんじゃない?説がありましたが、こんな落とし穴があるとは。QAを数十年やってる身として、身に染みる思いです。

    さて、気を取り直して、No.11を完成させてみたいと思います。まずは緑にしてみましょう。

    本コード

    テストを走らせた結果

    そしてリファクタリング。Fizzとなっている2箇所(上記参照)を、3の倍数に置き換えてみます。

    実際にはここで、本コードは完成ですね。以下、No.8〜No.10を一気に進めてみたいと思います。

    No.8 71で71を表示させる

    テストコード

    テスト実施前の赤いバーを、と思いましたがこちらはすでに本コード内で処理ができるようになっているため、緑のバーは出てきません。いきなり緑。

    No.9 1で1を表示させる

    ここもNo.8と同様、すでに処理ができるようになっています。ただここは境界値として、一応テストコードを作ってみます。

    テストコード

    緑のバー

    つぎはいよいよ最後です。

    No.10 100で100を表示させる

    テストコード

    緑のバー、と思いきや!テストケースにミスがありました。

    100で100を、ではなく、これは5の倍数になるため、Buzzが表示されるということです。

    またしてもテストケースにミスがありました。。カッコ悪い。。100を境界値としてテストをするのであれば、これは100ではなく、Buzzが返ってくるのが正しいですね。

    修正したテストケースはこちら。

    No.クラス名ピックアップした数字期待結果
    115, 5, 330FizzBuzz
    215, 545FizzBuzz
    315, 315FizzBuzz
    45, 360 –> 50Buzz
    51575FizzBuzz
    6510Buzz
    739Fizz
    8上記以外7171
    9111
    10100100100 –> Buzz
    111212Fizz
    テストケースNo.10の期待結果を変更した

    100でBuzzと返ってくるように変更したテストコードはこちら

    最後の、緑のバー。

    なにはともあれ、これで全部のテストケースをクリアすることができました。

    振り返り

    途中、冗長な説明になってしまいましたが、これで全てのテストを実施することができました。
    こうやって見てみると、最初に考えていたテストケースに間違いがあったり、足りない部分があったりして、要件だけを見てみても、抜けるところがあるんだなー、という印象です。
    Fizzを期待値とするテストケースは、2つ以上必要ということも分かりました。これは意外。
    テストの現場にいる身としては、なるべく少ないケース数をこなすように鍛えられているため、今回のように実際の本コードを見ながらテストしてみると、その、なるべく少なく、というところはきちんと確認をして作り上げるべきなんだなという気持ちにさせられました。

    一方、TDDの入り口をこの一連の活動を通して見ることができたのは、とても有意義でした。
    私にJavaのスキルがもっとあれば、もうちょい複雑なプログラムを書くことができるんだろうなと思いつつ、Cucumberを使ってテストコードを書き、それに合わせて本コードに追加、そしてリファクタリングという流れが見えたのは、大きな一歩です。ケント・ベックさんの本を何度か読んではみましたが、ただ読むだけではなく、実際にやってみることで、それが実感できた印象です。
    ここで終わりにするのではなく、もうちょい複雑なJavaのコードを使いつつ、また改めてTDDをやってみたいとおもいます。

    ご参考まで、コードはこちらです

    本コード

    public class FizzBuzz {
    	public String response(int num) {
    		if(num % 15 == 0) {
    			return "FizzBuzz";
    		}
    		else if (num % 5 == 0) {
    			return "Buzz";
    		}
    		else if (num % 3 == 0) {
    			return "Fizz";
    		}
    		else return String.valueOf(num);
    	}
    }

    テストコード

    import static org.junit.jupiter.api.Assertions.*;
    
    import org.junit.jupiter.api.Test;
    
    public class FizzBuzzTest {
    	@Test
    	public void 引数に30を与えたらFizzBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("FizzBuzz", fizzbuzz.response(30));
    	}
    	
    	@Test
    	public void 引数に45を加えたらFizzBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("FizzBuzz", fizzbuzz.response(45));
    	}
    	
    	@Test
    	public void 引数に15を加えたらFizzBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("FizzBuzz", fizzbuzz.response(15));
    	}
    	
    	@Test
    	public void 引数に50を加えたらBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("Buzz", fizzbuzz.response(50));
    	}
    	
    	@Test
    	public void 引数に75を加えたらFizzBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("FizzBuzz", fizzbuzz.response(75));
    	}
    	
    	@Test
    	public void 引数に10を加えたらBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("Buzz", fizzbuzz.response(10));
    	}
    	
    	@Test
    	public void 引数に9を加えたらFizzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("Fizz", fizzbuzz.response(9));
    	}
    	
    	@Test
    	public void 引数に12を加えたらFizzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("Fizz", fizzbuzz.response(12));
    		
    	}
    	
    	@Test
    	public void 引数に71を加えたら71を返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("71", fizzbuzz.response(71));
    	}
    	
    	@Test
    	public void 引数に1を加えたら1を返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("1", fizzbuzz.response(1));
    	}
    	
    	@Test
    	public void 引数に100を加えたらBuzzを返す() {
    		FizzBuzz fizzbuzz = new FizzBuzz();
    		assertEquals("Buzz", fizzbuzz.response(100));
    	}
    	
    }
  • JavaでTDDに挑戦してみる(N+1回目

    JavaでTDDに挑戦してみる(N+1回目

    前回の記事はこちら

    参考にさせてもらってるのはこちら


    さて、前回までは、テストケースを作るところまで来ました。
    前回の参照

    No.クラス名ピックアップした数字期待結果
    115, 5, 330FizzBuzz
    215, 545FizzBuzz
    315, 315FizzBuzz
    45, 360Buzz
    51575FizzBuzz
    6510Buzz
    739Fizz
    8上記以外7171
    9111
    10100100100
    FizzBuzz問題の同値分割(1と100を追加、そして期待結果も追加

    さてここで、私はちょっと考えました。

    期待結果が同じものは、省いちゃっても良いんじゃないか説

    どっかで過去に学んだ説

    つまりNo. 1、2、3、5は、一つのケースにまとめてしまっても良いのではないか。
    クラス名のところ、組み合わせが、含まれているからです。

    • No.1は15, 5, 3
    • No.2は15, 5
    • No.3は15, 3
    • No.5は15

    これらが、細かな組み合わせによって出力するという設計になっているのであれば、それぞれ別のケースとして成立させる必要があるような気がしますが、今回はそんな設計にしていない(要件から、3の倍数はFizz、5の倍数はBuzz、15の倍数はFizzBuzzとするだけ)ので、端折っても良いのかなと思います。
    ただ、TDDという観点では、途中でリファクタリングを挟むことが一つのステップになっているので、まずは愚直に上記の10ケースを組んでいきたいと思います。

    No.1 30でFizzBuzzと表示させる

    前回の記事を見るとわかりますが、本プログラムの方では、現状ではまだ「入力した数字をそのまま返す」状態にしかなっていません。

    これで、テストコードのほうを、30を入力したらFizzBuzzと表示させる、のところまで持っていってみたいと思います。

    で、実行した結果がこちら。予想通り失敗しました。30を入力したら、30を出力する、ってプログラムなので当然ですね。

    さて、この赤いバーを、緑に変える必要があります。

    まずはシンプルに、30を入力したら、FizzBuzzを返す、としてみます。

    この上なくシンプルなコード。IF文で、30を入れたらFizzBuzzを返すというコードを追加しました。

    結果はこちら。緑になりました。そりゃそうだ。

    これでNo.1は完了です。

    No.2 45でFizzBuzzと表示させる

    これもNo.1と同様に、45と入れたらFizzBuzzと返すようにするだけですね。

    まずテストコードを先に。

    実行、そしてエラー。ですが、一方で「入れた数字はそのまま返す」という要件のテストができていることを横目に感じつつ。

    では本プログラムの方を修正してみます。No.1と同様に、45をIF文で。

    else if がちょっと増えて、めんどくさいプログラムになってきたなー、と感じます。リファクタリングしたい欲がこうやって増えていくんでしょうか。
    バーはめでたくグリーンに。

    そりゃそうだ。
    まぁ、けど、これでNo.2は終了ですね。

    No.3 15でFizzBuzzと表示させる

    これもまた同様ですね。まず失敗コード、で本プログラムを修正という流れかと思うんですが、さすがにめんどくさくなってきました。ので、ここで、本プログラムの方にリファクタリングをしていきたいと思います。やり方としては、

    1. 現状:30でFizzBuzz、45でFizzBuzzとなっている
    2. リファクタリングの内容:15の倍数を取る場合は、FizzBuzzと表示させる

    こうすることで、本プログラム自体がすっきりするはずです。

    試しに15でFizzBuzzと出力するのを書いてみました。else if が2つ続いてて、しかもreturn がFizzBuzzと同様となっていて、効率的ではないように見えますね。

    まず、テストコードのほうは愚直にやっていく、と宣言した手前、こっちは整理せずに追加すべきだろうと考え、15でFizzBuzzを追加しました。

    そして、本プログラムのほう。
    こちらは、「15で割り切れる場合はFizzBuzzと表示させて」というプログラムにしてみました。

    テストを実行させてみます。見事、緑のバーになりました。

    これで、FizzBuzzと表示させるところは完了したように思います。

  • 6月8日 手動テストのシナリオを自動化するのではなく、自動テストのシナリオを自動化すれば効率性、正確性の点でメリットがあるんじゃないか説

    6月8日 手動テストのシナリオを自動化するのではなく、自動テストのシナリオを自動化すれば効率性、正確性の点でメリットがあるんじゃないか説

    仕事で、自動化されたCucumberのシナリオを確認する仕事をしている。
    数百あるシナリオを、地道に1行ずつ見ていると、そのスクリプトを作成するチームのリードから、
    「数百のシナリオをある程度マージしたい。そうすることで効率的になると思うから」
    と言われた。

    ここで私は、ちょっと立ち止まって考えてみた。そのことを今日の日記に書きたいと思う。

    考えたというのは、手動テストを自動化していくよりも、最初から自動化することに主眼を置いたテストシナリオを用意する方が良いのではないか、ということ。

    まだ私の中で、自動化スクリプト(Selenium + Cucumber)の良し悪しを隅々まで理解していないので、なかなか上手いことは言えないのが心苦しいのだけれど、以下のような違いがあると考えた。

    • 手動テスト:表示された画面やデータベースに保存された内容を見て、開発されたものが正しいかどうかを確認する。人の目で確認する。
    • 自動テスト:画面表示テストだったら、画面を構成するものが正しいPATHとかで置かれているか、またデータベースの中にあるものだったら、適切なタイミングでストアされているかを確認する。機械で確認する。

    やろうとしていることは同じように思えるのだけれど、人の目と、機械で確認するという違いは割と大きいように思う。
    人の目だと、見逃す、勘違いする可能性がある。
    一方、機械(コンピュータ)で確認すると、見逃しや勘違いすることはないだろう。ただ、きちんと期待結果を入力しておかないと、どれが正しいのか分からなくなってしまう。ここさえきちんとすれば、自動化の方が(きちんとメンテナンスされていれば)いつでもできるという点、間違いがないという点で、こっちをちゃんとやっておきましょう、というふうに考えることができるのではないか。

    で、そうなると、手動テスト(人の目)をベースとして作ったテストシナリオよりも、自動テスト(機械の目)をベースとして作ったテストシナリオの方が、作りやすいなどあったりするのではないだろうか、と。

    いや、テストシナリオの中にあるテストケースの、テストで確認したいポイントは同じでも良いのかもしれない。順を追って進んでいくテストステップのところで、わざわざ画面に表示されている「ボタンを押す」という行為を機械に押させるようなことはしなくても良いのではないか。
    「ボタンを押した状態」を意図的に作り出せれば、その方がSelenium+Cucumberとしてやりやすいのであれば、メリットが多かったりしないだろうか。

    私に自動化スクリプト作りのスキルがないから、これは仮説でしかなく、ここにスキルが加われば、仮説を検証することができるのになぁ。
    Still Day 1、ここが始まりで、コツコツ勉強していけばいいんだろうけども。やろっかな。