タグ: 自動化

  • 7月12日 今日も自動化

    7月12日 今日も自動化

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

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

    今日学んだこと

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

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

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

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

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

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

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

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

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

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

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

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

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