かいり
Web業界の事業会社で要件定義から開発実装まで並走しながらテストしているQAの今まで試してきたあれやこれや プロジェクトの行く手を照らしたい
こちらについて今回も考えてみました！ 気づいたのですが私は大体 要件（今回でいう仕様スニペット）と関連資料の読み込み そこから実装イメージ（≒詳細設計）への落とし込み さらにそこからテストケースへ変換 という思考ルーチンに沿って進める癖があるようです。 というわけで仕様の理解から以下コピペです。 いわゆるパスワードログイン。おそらくアカウント名でDBを検索して、引っかかったもののパスワードハッシュと比較する普通のやつでしょう。 成功すればログイン（アカウントロ
こちらについて考えてみました。 まずは仕様の理解から親子関係にあるAとB（部署と従業員） ここでは素直に人事労務システムの部署とそこに所属する従業員と捉えます 親Aの数は0〜48 数字が出てきた時点で境界値分析を使うことが確定します 0部署、1部署、n=48部署 子Bの数は全体で0〜128 数字が出てきた時点で境界値分析を使うことが確定します AあたりのBは0〜16 子Bは子Aを必ず1つ持つ 部署に所属していない従業員はいないし、兼務もない。 子Bはいつ
DBのCRUD（Create-Read-Update-Delete）について広く解説している記事は多々ありますが、私はこのうち開発する上で最も危険性が高く、それゆえに知っておくといいのはDeleteだと考えています。その理由なども含めて今回記事にしてみたいと思います。 少しでも参考になれば幸いです。 DBの「削除」が危険な理由今回主に触れるのは厳密にはDBのレコード（データベースの中の行）の削除ですが、それ以外でも、 カラム（データベースの列）の削除 テーブルの削除
『ソフトウェアテスト293の鉄則』の鉄則1ではテストの役割についてこのように述べられています。こちらについて個人的には結構しっくりくるところではあるのですが、最近ここに付け加えて「警告をするタイミングが大切なのでは？」と思うことがあったので今回はそれを記事にしてみようと思います。 少しでも参考になれば幸いです。 私の体験談基本的に私はQAの業務において色々なことを「早いに越したことはないだろう」と早め早めに動いて開発チームに警告を上げるように心がけているのですが、実際これ
今回はこれまでの振り返りがてら読んできた本を抜粋してまとめてみようと思います。 学生時代新卒で入社した会社が入社前にITパスポートを取得を推奨していたので、一番最初に手に取ったIT系の本がITパスポートの教科書でした。ITの基本が浅く広く分かったので良かったと思っています。逆に言うと、学生時代はIT系の勉強はこれくらいしかしていないです。（大学でJavaの授業を取ったものの挫折して単位を落としました） 新卒期学生時代にJavaの授業を取って挫折してしまった経験があったので
まだ粗々な状態ではあるのですが、ある程度使える形になったのでOSSの宣伝も兼ねて記事にしてみようと思います。 テストケース管理ツール「TestAnchor」を公開しました。特に会社等は関係なく完全に自主制作です。 発端は2023年のクリスマスイブQAエンジニアになってからというもの、E2Eのコードを書く機会こそあれど、いわゆるプロダクトのコードを書く機会はめっきり減ってしまいました。他で補填しなかった私が悪いのですがGithubの草も枯れ野原。 テストケース管理ツールを
この記事はソフトウェアテストの小ネタ Advent Calendar 2023 5日目の記事です。 WebアプリケーションやAPIの一番最初の窓口になるURLですが、今まで開発やテストをしてきた際にそこからバグを見つけたことも多いので、今回はテストするときの勘所についてまとめてみたいと思います。 少しでも参考になれば幸いです。 URLパラメータとはhttps://www.example.com/users/12345?a=hoge&b=9999&c=true このような
正確な言葉は忘れてしまったのですが、開発エンジニアとして働いていた頃、上司にタイトルのようなことを言われてはっとした思い出があります。 当時の私はとにかくコードを書くのに必死で、「仕様さえ満たせばいい」と考えてコーディングを行っていました。しかし仕様書に書いてあることは必ずしも正しいわけではなく、上司に指摘されなければ私は不完全な仕様のままリリースするところでした。（そのとき専任のQAはいませんでした） そんなことがあってからはタイトルの言葉を常に意識するようにしているの
「早期テストで時間とコストを節約」とテストの7原則にもある通り、テスト活動はソフトウェア開発のライフサイクルの早期に始めるのが良いと言われています。 私は現在WEB系事業会社で自社製品のQAを行っており、要件定義段階からQAに入ることが多いのですが、その際に必ず行うようにしている「ユースケース分析」が一定の成果を得られることが多いので、今回記事にまとめることにしました。 少しでも参考になれば幸いです。 ユースケース分析とは要は利用者などをはじめとするシステムの関係者（アク
こんにちは。かいりです。 普段何かと「開発経験があるQAエンジニア」を自称するわりにそれっぽいことをしたことがなかったなと思ったので、今回記事を書いてみることにしました。 少しでも参考になれば幸いです。 コードレビューとは基本的にエンジニアが開発のためにコードを書いた時には、エンジニア内でコードレビューを行います。 このコードレビューは、 プロジェクト内のコーディングルールを守っているかを確認する より良い記述方法がないかを検討し指摘する バグを見つける などを目的
こんばんは。かいりです。 今回は先日あったJaSST nano vol.16にて発表したテストメソッドについてまとめてみようと思います。 どうぞよろしくお願いします。 As-Is To-Beテストメソッド（仮）名前がまだいまいち定まっていません笑 いい名称募集中です。 As-Is To-Beは元々ビジネスで使われる用語で、「理想を定め、現実をそれと比較することで課題を見つけることができる」といったような課題発見のためのフレームワークです。私がテストの時に考えていることを言
はじめまして、かいりと申します。 都内のベンチャー企業にて3年ほどWEBエンジニアをしたあと、QAエンジニアにジョブチェンジをし、1年ほどが経過しました。現在は転職をし、同じく都内の事業会社でQAエンジニアをしています。 さて、今回は自己紹介がてらなぜ私がQAエンジニアになったのかということを書いていきたいと思います。 そもそもエンジニアになった理由QAエンジニアになる以前に、なぜエンジニアになったのかから話していきたいと思います。 私は教育学部の国文系というゴリゴリの文
