らーめん

HRのSaaSを開発する会社でQAエンジニアをやっています。 QAという狭い分野につい…

らーめん

HRのSaaSを開発する会社でQAエンジニアをやっています。 QAという狭い分野について細かいTipsを投稿してみようかと思っています。 投稿はあくまでも私見で所属している組織の見解ではありません。

バグを見つける40のアイデア（リンク集）

らーめん

    • バッチ処理のテスト観点について

      バッチ処理について簡単に定義を紹介するとhttps://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%81%E5%87%A6%E7%90%86 バッチ処理は非同期処理であり、リアルタイムに処理されるのとは異なります。そのためソフトウェアテストにおいても特別な考慮が必要になります。 具体例（実際のところどうなのかは知りませんが）たとえばnoteの書いた記事に対して閲覧数（ビュー）を午前7時、午後14時と1日2回のバッチ実行によ

      らーめん

      • Push通知のテストについて

        はじめに最近でもPush通知の誤送信が話題になり、Push通知の検証方法について興味を持たれる方も多くいらっしゃるようなので、記事を書いてみました。 Push通知の検証環境は現場によって異なると思うので誤送信を防ぐ方法をお伝えすることはできませんが、Push通知についてどのようなことを検証しているかイメージはできるようになると良いなと思っています。 Push通知のテストのチェックポイントPush通知のテストのチェックポイントとしては以下のポイントがあると思います。 1.

        らーめん

        • tracking eventの検証をするときのちょっとしたコツについて

          はじめに組み込み系のサービスのQAをやっている人はあまり馴染みがないかもしれませんが、Web系のアプリを運営していればなにかしらユーザーのアクションをtrackingしているのではないかと思います。そしてそのtrackingが期待通りかQAしたこともあるのではないかと思います。 この記事で扱わないこと　どのようなツールを使うと良いか 　ユーザーの行動を計測する効果的なtracking eventの設計のしかた この記事で扱うこと　QA/テストエンジニアがtracking

          らーめん

        バグを見つける40のアイデア（リンク集）

        らーめん

          イテレーション開発とテスト設計

          Twitterでツイートが長くなったのと、大事なことだと思うのでnoteにまとめようと思いました。 問題の所在イテレーション開発の場合、テスト設計は各イテレーションごとに作るのか、最低限目指したい機能が完成する姿をイメージして俯瞰的なテスト設計を作るのか。私は後者であるべきだと思っています。 理由俯瞰的なテスト設計が無いと、各イテレーションごとの実装が正しい方向に進んでいるかわからないから。 たとえ話1「西」という漢字を書こうとするとして、最初のイテレーションが一画目の

          らーめん

          イテレーション開発とテスト設計

          らーめん

          開発メンバーが100人を超えた大規模サービスのQAについて

          開発メンバーが100人を超えた大規模サービスをQAしていて日々感じていることをポエムにしました。1. 他のチームが何やってるか把握しきれなくなる機能のテーマごとにスクラムチームを組んで各チームにQAエンジニアをアサインしていますが、チームの数が10を超えてくると、各QAエンジニアは他のチームの新機能や機能変更についてキャッチアップできません。サイロ化とかそういう話じゃなくて透明性が有っても情報量が多すぎて記憶しきれません。職種別ミーティング等の横串の組織で情報共有しても把握し

          らーめん

          開発メンバーが100人を超えた大規模サービスのQAについて

          らーめん

          スモークテストのテストケースを書く際の注意点

          はじめに以前にリグレッションテストについて記事を書きましたが、今回はリグレッションテストと似て非なるものであるスモークテストについて書きたいと思います。 ソフトウェアテストにおけるスモークテストとは、開発途中のソフトウェアをテスト（試験）する手法の一つで、起動するかどうかや基本的な機能が動作するかなどをざっと確認することです。もとは電子機器・電気機械の開発工程において電源を入れて発熱しないかを確認するテストに由来すると言われています。なので極論を言えば、エアコンであれば、煙

          らーめん

          スモークテストのテストケースを書く際の注意点

          らーめん

          スマートフォン向けWebサービスのQAとHuman Interface GuidelinesとMaterial.ioについて

          はじめにQAエンジニアがUIが適切かどうかについて考えるときに、何を参考にしますか？スマートフォン向けのWebサービスであれば、私はAppleのHuman Interface Guidelines（以下HIG）とGoogleのMaterial.io（以下Material.io）を参考にするべきだと思います。 よく議論されるところで言えば、確認ダイアログの「はい」と「いいえ」はどちらが右でどちらが左が適切かという問いについて、AppleとGoogleのガイドラインがそれを説明

          らーめん

          スマートフォン向けWebサービスのQAとHuman Interface GuidelinesとMaterial.ioについて

          らーめん

          『Agile testing condensed Japanese Edition』を読んで

          はじめにAgile testing condensed Japanese Editionを読んで個人的に共感したところとあまり共感できなかったところをまとめてみました。 原著を読んでいることを前提に細かい説明は割愛してます。 購入リンク他の方のNote（とても良くまとめられていると思います）https://note.com/hgsgtk/n/nf8d0ffc8a605 共感したところ第3章の「アジャイルにおけるテスト計画」のところで、 テストの主な目的の1つは、ユーザー

          らーめん

          『Agile testing condensed Japanese Edition』を読んで

          らーめん

          『TQMの基本と進め方』を読んで

          はじめに私はソフトウェアテストのテストエンジニアですが、ソフトウェアだけじゃない品質管理の本を読んでみようと思いました。 いろいろと勉強になったので感想を書きます。 TQMとはTQMとはTotal Quality Managementの略です。まず、2ページ目に「TQMとは」という定義が書かれています。そこでは ”TQM”とは、顧客の満足する品質を備えた品物やサービスを適時に適切な価格で提供できるように、全組織を効果的・効率的に運営し、組織目的の達成に貢献する体系的活動

          らーめん

          『TQMの基本と進め方』を読んで

          らーめん

          WebサービスのEmailのQA

          はじめにWebサービスでEmailのQAというとレイアウトの確認をイメージする方も多いのではないでしょうか？そしてHTMLのレイアウト確認に使われるLitmus等のツールが有名ですが、そもそもレイアウト確認だけがWebサービスでお客さまに送信するEmailで確認が必要な項目ではありません。むしろ個人的にはレイアウト確認よりも重要なことがたくさんあると思います。なのでこの記事を書きました。 簡単にまとめると、「送られるべきではない人に送られないか」と「送られた内容が期待通りか

          らーめん

          WebサービスのEmailのQA

          らーめん

          決済のQA観点

          はじめに売買などの支払い機能を有するWebサービスの場合、新しい決済方法（なんとかペイとか）を導入する時や、決済に関するコードをリファクタリングする時や、決済代行会社を変更する時などに、決済周りについて網羅的に検証をする機会が定期的にあると思います。そういうテストエンジニアの方向けに、決済の検証をする際のQA観点をまとめてみました。 はじめにお断りしますが、この記事のテスト観点では十分ではないと思います。ただ、なんらかの気付きがあれば良いと思い書きました。 正常に決済が完

          らーめん

          決済のQA観点

          らーめん

          リファクタリングとQA

          リファクタリングとはリファクタリングとは一般的には「外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること」です。リファクタリングによりシステムを長く使い続けることや、トラブル時の対応を早めることが可能と言われています。 リファクタリング後の挙動が変わっていないことの検証がQAにとって一番難易度が高いあくまでも個人の見解ですし、状況にもよりますが、新機能の実装やバグの修正確認等よりもリファクタリング後に挙動が変わっていないことの検証の方が難易度が高いです。その理

          らーめん

          リファクタリングとQA

          らーめん

          俺が考えた最強の検索テストケース

          はじめに俺が考えた最強の会員登録テストケースの続きです。 Webサービスでは検索についてもどこも似たようなことをやってるのではないかと思います。検索についてはテストケースを作るより、テストデータを作成するのが地味にめんどくさかったりするのではないでしょうか？ 大事なことなので今回も書きますが、「俺が考えた最強の」とあおっている時はだいたい中身が薄いです。これもそうです。あと現職で使っているテストケースでもありません。 テスト観点部分一致と完全一致 iPhoneを時々ip

          らーめん

          俺が考えた最強の検索テストケース

          らーめん

          QAから見たWebサービスのスクラム開発の理想と現実

          はじめにQAエンジニアとしてスクラム開発を経験して感じた疑問点をまとめてみました。 スクラムメンバーの多様性スクラム開発は8名前後のチームが最適とされますが、その中にQAエンジニアは入っていますか？スクラム内に入る場合も入らない場合もどちらもあり得るのではないかと思います。 QAエンジニアに限らず、Webサービスの特にアプリケーション開発においてはスクラムメンバーのスキルは同じではないと思います。同じではないというのはレベルが高いか低いかということではなくて種類が違うとい

          らーめん

          QAから見たWebサービスのスクラム開発の理想と現実

          らーめん

          俺が考えた最強のログインテストケース

          はじめに俺が考えた最強の会員登録テストケースの続きです。 Webサービスではどこも似たようなことをやってるのではないかと思います。特に会員登録あたりは自動テストで運用しているところも多いのでは無いでしょうか？ 今回はEmailでのログインのテストケースを考えてみました。 大事なことなので今回も書きますが、「俺が考えた最強の」とあおっている時はだいたい中身が薄いです。これもそうです。あと現職で使っているテストケースでもありません。 テスト観点ログインは考慮しないといけな

          らーめん

          俺が考えた最強のログインテストケース

          らーめん