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