はじめに QAエンジニアをしているもんです 今回はプロダクトのことを考えすぎるあまり直感的な操作性を考慮しにくくなってしまった話を自戒の念も込めて記事にしてみました 仕様の決め方 仕様を決める時にはざっくりこんな感じで決めていくことが多いんじゃないかなと思います 1. 要件定義 2. MUST要件仕様 3. WANT要件仕様（高） 4. WANT要件仕様（中） 5. WANT要件仕様（低） 6. ... 直感的な操作性との関係性 機能開発時に直感的な操作をなるべく損なわずに便利な機能を盛り込むかはとても重要なことです 直感的な操作が出来ないプロダクトは、問い合わせを誘発したり、たとえ便利であっても利用までのハードルが上がりそもそも使ってもらえなくなったりします ユーザーに喜んでもらうために一生懸命考えて実装した結果がこれでは悲しすぎます 私達はより良い価値提供を目指し日々開発しているプロダ

はじめに こんにちはHRBrainでQAエンジニアをしているmonです。 QAエンジニアをしていると、この仕様なんか使いにくいなと感じることがあります。 この感覚はQAエンジニアとしてとても大事なのですが、テストはしにくいが実運用には適している仕様である場合があり、判断に迷ったりします。 そういった判断に迷った場合や、仕様の見直しを提案する際に心がけていることを記事にしようと思います。 仕様に疑問を持つ たとえば、計算式やダッシュボードが正しく表示されているか確認する場合には、結果から逆算して操作をしたりします。 想定した結果になるようにデータを仕込む作業をく返していくうちに大元のデータを修正出来たら良いなと浮かんだとします。 機能の目的を整理する １． そもそも集計元のデータは何を元に持ってきているのかを考える - 同一人物が操作するのか、複数のユーザーが操作するのか - 手入力なのか、

はじめに はじめまして！株式会社HRBrainでQAエンジニアをしていますmonです。 今回はHRBRainに入社前、QAエンジニアとしての道を歩み始めた際に最も嫌いだったバグ報告をバグ密度を知ることで気が楽になったという話を記事にしようと思います。 バグ報告が嫌いだった理由 IT未経験でQAエンジニアになった当初、テスト実施を通してバグを発見した瞬間は成果が出せた！と嬉しかった私ですが、いざバグ報告になると憂鬱でたまりませんでした。 当時、私の中ではバグ=出てはいけないのも、エンジニアの方のミスという印象を持っていました。 そのためバグ報告=面と向かってミスを指摘させられている様な気持ちになり、コードの書き方も知らないのに指摘なんて、、、と思っていました。 そんな中、QAを完了した際に１つもバグが検出されないということがありました。 てっきり『良かったね』と言われると思っていた私に上司が