Better Software Testing

ソフトウェアテストをもっと良くしたい

Hacker NewsからQA関連の記事を取得し、Twitterに投稿するbotを作った

news.ycombinator.com

github.com

Hacker NewsにはAPIが実装・公開されていて、上位500件分の記事を取得したり特定の記事の詳細を取得したりすることができる。

僕はときどきHacker Newsを眺めたりしているが、大量にある記事の中からQA関連のものを見つけるのが大変だと感じたので、APIを使ってbotを作ってみた:

github.com

仕組みとしては、

  1. Hacker Newsから500 top and new storiesを取得する
  2. そのうち上位100件の記事の詳細を取得する
  3. 記事のタイトルに特定のキーワード(QA, quality, bug, test)が含まれているかどうかを判定する
  4. キーワードが含まれている場合、その記事のタイトルとURLをTwitterに投稿する

というもの。

これをAWS Lambdaにデプロイし、毎朝9:00に実行する。

で、実際にツイートされたものがこちら:

f:id:katsu-ichiro:20220228080802p:plain

実行例

本当は手順1で取得した500件全てを手順2以降の対象としたかったのだが、実行時間がそれなりに長くなりそうで、そのぶんだけAWSに課金しなければならないのが辛いと感じたので100件にとどめた。

あと、昨年から5個くらいTwitterやslackのbotを作ってきたせいか、botの作り方はだんだん慣れてきた気がする。ちょっと嬉しい。

チームで品質を磨いているという感じがして良い

tech.smarthr.jp

チームで品質を改善する、良い取り組みだと思った。

目的がバグ出しなのか、改善箇所の洗い出しなのか、品質評価なのか、はたまた?という感じで読んでいたが、どうもプロダクトのユーザビリティ評価、というかブレインストーミングに近いらしい。様々な役割の人と一緒に進めたいのであれば、こういう感じがちょうどいいのかもしれない。

  • 触りながら気づいたことはどんなことでもいいのでメモをする
  • 評価タスクの変更などいろいろ操作してみる
  • 差し戻ししたり、いろいろ操作してみる

たぶんこの辺りがSmartHR社でのロールプレイテストのミソで、細かいルールや手順がなく、難しい言葉を使わないから精神的なハードルが低く設定されるのだと思う。

私は日頃、ヘルプページ作成業務で操作手順を文章にする機会を意識の切り替えに利用していますが、仲間を巻き込んで「ごっこ」をしながら視点の切り替えが自然とできてしまうロープレには、「その手があったか!」と衝撃を受けました。

結果として、↑↑こういう感じで進めることができているのかな、と。

一方で、ロールプレイテストはあくまで品質評価の1手法という感じがするので、よく設計されたテスト、リグレッションテスト、自動テストなどとバランスは取っていきたいところ(SmartHR社でもそうしているとは思うが)。ロールプレイテストはテストの網羅性向上やバグ出しを目的とするテストではないため、このテストを以て「よし品質OK」と判断するのはいささか不安ではある、と感じる。

とはいえ、チームで品質を磨く良いプラクティスだと思うし、QA以外の職種の方が品質の意識を強める良い機会にもなると思うので、機会を見つけて活用してみたい。

QA・テストエンジニアの求人からまとめた情報

LAPRASに掲載されているQA・テストエンジニアの求人を集計し、以下の情報をまとめた:

  • 各社で採用しているCI/CDツール
  • 各社で採用している自動テストツール
  • 各社の給与レンジ

結果:

  • CI/CDツールは、CircleCIが最も採用されている。次いでAWS
  • 自動テストツールは、ほとんどの企業で記載なし。記載されている中では、Autifyが最も多かった
  • 給与レンジは、下限・上限ともに予想していたより高かった。下限は400万円台の会社が圧倒的に多いだろうと思っていたが、500, 600万円台とほぼ同数であった。また、上限1,000万円オーバーの会社が半数近くあったのも意外であった

f:id:katsu-ichiro:20220213085035j:plain

CI/CDツール

f:id:katsu-ichiro:20220213085108j:plain

自動テストツール

f:id:katsu-ichiro:20220213085140j:plain

給与レンジ

 

UbuntuでCodeceptJSのスクリプトを実行する

  1. AWS EC2インスタンスを起動する(OSはUbuntuで、あとは適当)
  2. Node.jsをインストールする
  3. CodeceptJSとpuppeteerをインストールする
  4. Chromeをインストールする
  5. CodeceptJSのプロジェクトを新規作成し適当なスクリプトを書く
  6. npx codeceptjs run --stepsコマンドを実行する
  7. はい

qiita.com

codecept.io

ubunlog.com

 

# Node.jsのインストール
sudo apt update
sudo apt install -y nodejs npm
sudo npm install n -g
sudo n stable
sudo apt purge -y nodejs npm
exec $SHELL -l
# CodeceptJS, Puppeteerのインストール
npx create-codeceptjs . --puppeteer
# Chromeのインストール
sudo apt install ./google-chrome-stable_current_amd64.deb

connpassからQA関連イベントを取得してSlackに通知する

概要:

  • connpassのAPIを叩いて、以下の条件に該当するイベントを10件取得する
    • プログラムを実行した月のイベント(例:2022/01)
    • イベントタイトル、キャッチ、概要、住所に「QA」を含むイベント
  • 取得したイベント情報から、以下の情報を取得しSlackに投稿する
    • イベントID
    • イベントタイトル
    • キャッチ
    • 開始日時
    • 終了日時
    • 参加可能人数
    • 参加人数
    • URL

使ったもの:

connpass.com

api.slack.com

実行手順:

  1. Slackで、スラッシュコマンド"/get_qa_events "を実行する
  2. SlackからAPI Gatewayにリクエストが飛ぶ
  3. API Gatewayがリクエストをキャッチし、Lambda関数を実行する
  4. Lambda関数内にて、以下の処理を行う
    1. connpass APIを叩き、QA関連イベントの情報を取得する
    2. 取得した情報をSlackに投稿する

実行結果:

f:id:katsu-ichiro:20220201060334p:plain

実行例

Slackの仕様上、実行時間が3秒を超えるとエラーメッセージが表示される。ただし、一度開始した処理そのものは最後まで実行されるので問題ない。

 

感想:

作り込まなかったというのもあり、そんなに時間かからずに作れた。開催年月や検索ワードを自由に設定できると尚良いのだが、今回は基礎を作ったところで満足。毎回ブラウザ立ち上げてconnpassにアクセスしてキーワード入力して、、という操作をやっていたが、これをコマンド1つで実行できるようになったのですごく便利感がある。

 

ソースコード

github.com

結論のない不安と予感を書き出す

僕は今、主にテスト自動化をメインスキルとして売り出している。

E2EテストとAPIテストをスクリプト化して定期実行してメンテナンスして、、ということを今までやってきて、ありがたいことに高く評価してくれる企業がいくつかあった。

だが、今後3−5年で自分の市場価値は落ちるのではないかと思っている。

というのも、テスト自動化はMagicPodをはじめとしたSaaSの登場でコモディティ化しているし、僕より下の世代(〜20代後半)には高い技術力を持つエンジニアがたくさんいるからだ。

今後数年間の間に、テスト自動化エンジニアの数がグッと増え、そのレベルも上がるのではないかという予感がしてならない。いやこれはむしろ喜ぶべきことなのだと思うが。

となると、相対的に僕の価値は落ちてしまうので、何か別のアイデンティティを確立した方が良い気がしている。あるいは、テスト自動化のスキルを圧倒的に深掘りする必要がある。

これが専ら最近の悩みで、たぶんエンジニアやっていればいつかはこういう悩みに出くわすと思うのだが、僕にとってはそれが今、という感じ。

キャリアは難しい。安定しない。

居酒屋でできそうな、QAエンジニア向けの遊びを考えた

概要:

テスト段階で見つかってそうなバグを想像し、お互いに発表し合う。

 

手順:

  1. 題材となるソフトウェアを決定する(例えば、注文用タッチパネルなど)
  2. 参加者は各々、上記ソフトウェアの「テスト段階で見つかってそうなバグ」を想像する
  3. お互いに発表し合う
  4. 発表された(想像上の)バグのなかで、「最も深刻度が高い」かつ「確かにこのバグはありそう」と思わせたものを発表した参加者の勝ち

 

なかなか盛り上がる遊びだと思うのだが、いかがだろうか。QA以外の人を巻き込んでみると、視点の違いがわかってより楽しめるかもしれない。