かいり

QAをしている人。

かいり

QAをしている人。

  • 開発と並走するQAの話〜要件定義から実装まで〜

    Web業界の事業会社で要件定義から開発実装まで並走しながらテストしているQAの今まで試してきたあれやこれや プロジェクトの行く手を照らしたい

コピペは楽だがバグの元

まずはじめに、この記事においては開発者に対して時々言われるような「コピー＆ペースト（以下コピペ）はするべきではない」といった趣旨のことは書きません。ただ、事実としてミス、ひいてはバグに繋がることがある行動ではあると思っているので、そのこととテストする際に気にする点がお伝えできたらいいなと思います。 少しでも参考になれば幸いです。 コピペによるバグが生まれる流れたとえば、画像のようなシンプルなホームページをイメージしてみます。ここについては特に何も言うことはありません。 で

かいり

    • 開発と並走したいQAが開発の各工程でやっていること

      今回は、普段の振り返りがてら開発の各工程でやっていることをまとめたいと思います。基本的にはシフトレフトを意識しながらテストを進めています。 ウォーターフォールもアジャイルも経験していますが基本的にどちらでもやることは変わりません。 少しでも参考になれば幸いです。 前提前提として私はテスト担当者の主な役割は「情報を見つけだすこと」だと考えています。ここには以下のような情報を含みます。 現在地の情報 ＝プロジェクト（の成果物）が現在どのような状況か 目的地の情報 ＝プ

      かいり

      • テスト設計パターンを考える会 考えてみたメモ 仕様スニペット002

        こちらについて今回も考えてみました！ 気づいたのですが私は大体 要件（今回でいう仕様スニペット）と関連資料の読み込み そこから実装イメージ（≒詳細設計）への落とし込み さらにそこからテストケースへ変換 という思考ルーチンに沿って進める癖があるようです。 というわけで仕様の理解から以下コピペです。 いわゆるパスワードログイン。おそらくアカウント名でDBを検索して、引っかかったもののパスワードハッシュと比較する普通のやつでしょう。 成功すればログイン（アカウントロ

        かいり

        • テスト設計パターン（仮）を考える会 考えてみたメモ 仕様スニペット001

          こちらについて考えてみました。 まずは仕様の理解から親子関係にあるAとB（部署と従業員） ここでは素直に人事労務システムの部署とそこに所属する従業員と捉えます 親Aの数は0〜48 数字が出てきた時点で境界値分析を使うことが確定します 0部署、1部署、n=48部署 子Bの数は全体で0〜128 数字が出てきた時点で境界値分析を使うことが確定します AあたりのBは0〜16 子Bは子Aを必ず1つ持つ 部署に所属していない従業員はいないし、兼務もない。 子Bはいつ

          かいり

        マガジン

        • 開発と並走するQAの話〜要件定義から実装まで〜
          4本

        記事

          QAが知っていて損はないDBの「削除」について

          DBのCRUD（Create-Read-Update-Delete）について広く解説している記事は多々ありますが、私はこのうち開発する上で最も危険性が高く、それゆえに知っておくといいのはDeleteだと考えています。その理由なども含めて今回記事にしてみたいと思います。 少しでも参考になれば幸いです。 DBの「削除」が危険な理由今回主に触れるのは厳密にはDBのレコード（データベースの中の行）の削除ですが、それ以外でも、 カラム（データベースの列）の削除 テーブルの削除

          かいり

          QAが知っていて損はないDBの「削除」について

          かいり

          開発チームに警告をするときはタイミングも大切だと思った話

          『ソフトウェアテスト293の鉄則』の鉄則1ではテストの役割についてこのように述べられています。こちらについて個人的には結構しっくりくるところではあるのですが、最近ここに付け加えて「警告をするタイミングが大切なのでは？」と思うことがあったので今回はそれを記事にしてみようと思います。 少しでも参考になれば幸いです。 私の体験談基本的に私はQAの業務において色々なことを「早いに越したことはないだろう」と早め早めに動いて開発チームに警告を上げるように心がけているのですが、実際これ

          かいり

          開発チームに警告をするときはタイミングも大切だと思った話

          かいり

          これまでに読んだ本で振り返るエンジニア遍歴

          今回はこれまでの振り返りがてら読んできた本を抜粋してまとめてみようと思います。 学生時代新卒で入社した会社が入社前にITパスポートを取得を推奨していたので、一番最初に手に取ったIT系の本がITパスポートの教科書でした。ITの基本が浅く広く分かったので良かったと思っています。逆に言うと、学生時代はIT系の勉強はこれくらいしかしていないです。（大学でJavaの授業を取ったものの挫折して単位を落としました） 新卒期学生時代にJavaの授業を取って挫折してしまった経験があったので

          かいり

          これまでに読んだ本で振り返るエンジニア遍歴

          かいり

          3週間でテストケース管理ツールを作れるかチャレンジした話

          まだ粗々な状態ではあるのですが、ある程度使える形になったのでOSSの宣伝も兼ねて記事にしてみようと思います。 テストケース管理ツール「TestAnchor」を公開しました。特に会社等は関係なく完全に自主制作です。 発端は2023年のクリスマスイブQAエンジニアになってからというもの、E2Eのコードを書く機会こそあれど、いわゆるプロダクトのコードを書く機会はめっきり減ってしまいました。他で補填しなかった私が悪いのですがGithubの草も枯れ野原。 テストケース管理ツールを

          かいり

          3週間でテストケース管理ツールを作れるかチャレンジした話

          かいり

          URLパラメータをテストするときの勘所

          この記事はソフトウェアテストの小ネタ Advent Calendar 2023 5日目の記事です。 WebアプリケーションやAPIの一番最初の窓口になるURLですが、今まで開発やテストをしてきた際にそこからバグを見つけたことも多いので、今回はテストするときの勘所についてまとめてみたいと思います。 少しでも参考になれば幸いです。 URLパラメータとはhttps://www.example.com/users/12345?a=hoge&b=9999&c=true このような

          かいり

          URLパラメータをテストするときの勘所

          かいり

          その仕様は本当に正しいですか？

          正確な言葉は忘れてしまったのですが、開発エンジニアとして働いていた頃、上司にタイトルのようなことを言われてはっとした思い出があります。 当時の私はとにかくコードを書くのに必死で、「仕様さえ満たせばいい」と考えてコーディングを行っていました。しかし仕様書に書いてあることは必ずしも正しいわけではなく、上司に指摘されなければ私は不完全な仕様のままリリースするところでした。（そのとき専任のQAはいませんでした） そんなことがあってからはタイトルの言葉を常に意識するようにしているの

          かいり

          その仕様は本当に正しいですか？

          かいり

          上流工程でQAするなら、ユースケース分析をしよう

          「早期テストで時間とコストを節約」とテストの7原則にもある通り、テスト活動はソフトウェア開発のライフサイクルの早期に始めるのが良いと言われています。 私は現在WEB系事業会社で自社製品のQAを行っており、要件定義段階からQAに入ることが多いのですが、その際に必ず行うようにしている「ユースケース分析」が一定の成果を得られることが多いので、今回記事にまとめることにしました。 少しでも参考になれば幸いです。 ユースケース分析とは要は利用者などをはじめとするシステムの関係者（アク

          かいり

          上流工程でQAするなら、ユースケース分析をしよう

          かいり

          QA的コードレビューのススメ

          こんにちは。かいりです。 普段何かと「開発経験があるQAエンジニア」を自称するわりにそれっぽいことをしたことがなかったなと思ったので、今回記事を書いてみることにしました。 少しでも参考になれば幸いです。 コードレビューとは基本的にエンジニアが開発のためにコードを書いた時には、エンジニア内でコードレビューを行います。 このコードレビューは、 プロジェクト内のコーディングルールを守っているかを確認する より良い記述方法がないかを検討し指摘する バグを見つける などを目的

          かいり

          QA的コードレビューのススメ

          かいり

          理想と現実で考えるシステムテスト

          こんばんは。かいりです。 今回は先日あったJaSST nano vol.16にて発表したテストメソッドについてまとめてみようと思います。 どうぞよろしくお願いします。 As-Is To-Beテストメソッド（仮）名前がまだいまいち定まっていません笑　いい名称募集中です。 As-Is To-Beは元々ビジネスで使われる用語で、「理想を定め、現実をそれと比較することで課題を見つけることができる」といったような課題発見のためのフレームワークです。私がテストの時に考えていることを言

          かいり

          理想と現実で考えるシステムテスト

          かいり

          私がQAエンジニアになった理由

          はじめまして、かいりと申します。 都内のベンチャー企業にて3年ほどWEBエンジニアをしたあと、QAエンジニアにジョブチェンジをし、1年ほどが経過しました。現在は転職をし、同じく都内の事業会社でQAエンジニアをしています。 さて、今回は自己紹介がてらなぜ私がQAエンジニアになったのかということを書いていきたいと思います。 そもそもエンジニアになった理由QAエンジニアになる以前に、なぜエンジニアになったのかから話していきたいと思います。 私は教育学部の国文系というゴリゴリの文

          かいり

          私がQAエンジニアになった理由

          かいり