つとむ QAエンジニア

SI会社で開発を少し経験し、第三者検証部門に異動。そこでテスト計画～品質評価を担当しま…

つとむ QAエンジニア

SI会社で開発を少し経験し、第三者検証部門に異動。そこでテスト計画～品質評価を担当しました。2018年からTeamSpiritに転職し、QAエンジニアの面白さに気づきました。現在はTebikiで一人目QAエンジニアとして奮闘中。趣味は読書、サウナ、猫と遊ぶことです。

  • （学習ノート）JSTQB FL アジャイル担当者

    JSTQB FL アジャイル担当者シラバスの内容を書き起こしました。

  • 固定された記事

QAエンジニアとカスタマーサポートの協力関係はとても大事だと思う

概要ソフトウェア開発の品質と顧客満足度は密接に関連しており、その両方を向上させるためにQAエンジニアとカスタマーサクセスエンジニアが連携することは重要だなと最近思います。QAエンジニアが一時的にカスタマーサポートチームに移籍したり、カスタマーサポートを兼務したりしている開発組織のブログを拝見したことがあります。他社でもQAエンジニアとカスタマーサポートが密な関係性をとっていることからも、QAエンジニアとカスタマーサクセスチームとの協力関係は、ユーザーにプロダクトをより良く使っ

つとむ QAエンジニア

    • バージョンアップテストの事例が少ない？

      はじめにプロダクト開発において、言語、フレームワーク、データベース、外部API、サポートしているOS、ブラウザなどが適宜バージョンアップされるたび、それらに追随しながら開発している現場があるかと思います。 現在、所属している開発チームでは、フレームワーク、データベース、外部APIのバージョンアップが発生するたびに、積極的に最新バージョンに適用しています。 QAエンジニアとして、そのようなバージョンアップの時に、どういう思考プロセスでリグレッションテストケースを導き出してい

      つとむ QAエンジニア

      • ユーザー利用時のギャップを埋める手段➡リリース告知、ヘルプ記事

        現在、QAエンジニアからCREに徐々に活動の幅を広げようと試行錯誤しながら、業務しています。今年書いた記事の通り、QAエンジニアとカスタマーサポートとの協力関係は大事だと考えています。 今回の記事では、以下の部分について、深堀りしていきます。 リリースされた機能をユーザーに正しく使ってもらうためには、リリースの告知やヘルプ記事（操作マニュアルなど）の充実が欠かせないと考えています。開発チームが想定した使い方をアナウンスしていないと、ユーザーは好き勝手に、ユーザー自身が当た

        つとむ QAエンジニア

        • トランクベース開発とGit flowを比較

          トランクベース開発 ・特徴 　・ メインブランチが常に動作する・リリースできる状態を保ったまま、　　1日に数回、小さい単位でコミットし、メインブランチにプッシュする ・導入するためには・・・ 　・Featureブランチを作らない 　・実装が完了していない機能は「表示を隠す」、「処理が動かないようにする」などユーザーが利用できないように配慮する 　・不具合が発生したら、直ちに修正する ・導入のメリット 　・ コードレビューがしやすい 　　・ 頻繁にリリースするため、修正の差分

          つとむ QAエンジニア
        • 固定された記事

        QAエンジニアとカスタマーサポートの協力関係はとても大事だと思う

        つとむ QAエンジニア

        マガジン

        • （学習ノート）JSTQB FL アジャイル担当者
          8本

        記事

          QAエンジニアのキャリアは無限大

          はじめにQA（品質保証）エンジニアは、ソフトウェア開発において品質を確保するために欠かせない存在です。何に対する品質保証に関わりたいかによってプロダクト開発の枠を超えた職種にチャレンジできると思います。 本記事では、QAエンジニアを起点とする多様なキャリアパスを紹介するとともに、自身が何に影響力を発揮したいかという点でのキャリアパスを説明したいと思います。 ただし、これはQAエンジニアだけに限った話ではなく、エンジニアを起点にした見方も可能です。 QAエンジニアからチャレン

          つとむ QAエンジニア

          QAエンジニアのキャリアは無限大

          つとむ QAエンジニア

          JaSST'24 Kansai に行ってきた

          タイトルにある通り、JaSST'24 Kansaiに行ってきました。そこでの学びを徒然なるままに書き留めます。 参加した理由私も一人目QAエンジニアであり、登壇者の@yoshikiitoさん、@mii________sanさん、@tarappoさんがやられていることは、私自身が現在やっていること、やりたいことと似ていて、直接会話したいと思い、参加しました。 また、QAエンジニアの知り合いを増やすことを2024年の個人的な目標にしていて、社外のQAエンジニアの方と繋がりを持つ

          つとむ QAエンジニア

          JaSST'24 Kansai に行ってきた

          つとむ QAエンジニア

          プロダクトの制約事項を伝えること

          不具合があったとしても、小さく、早くリリースすることは賛成です。 しかし、その不具合は認知されている不具合でしょうか？ 開発チームが、その不具合を認知しているか カスタマーサポートなどビジネスチームが、その不具合を認知しているか 制約事項としてユーザーに知らせているか どこまで認知しているべきかは、難しい問題です。私は、ユーザーのプロダクトを使っていて、遭遇する全ての不具合をユーザーに知らせるべきだと考えています。（すごい極論ですが。。。）少なくとも、カスタマーサポー

          つとむ QAエンジニア

          プロダクトの制約事項を伝えること

          つとむ QAエンジニア

          LEADING QUALITY社内読書会のポイントをまとめました

          はじめにプロダクト品質・プロセス品質について開発チームのメンバーと議論して、具体化したい思いを抱きながら、どうすれば一緒に議論できるか考えていたところ、LEADING QUALITYという書籍に出会いました。 「まえがき」、「訳者まえがき」、「序章」を読み終えたころ、一人目QAエンジニアのバイブルになる！これを皆で読むことで、QAエンジニアと同じ視線で会話できるのでは！と考え、読書会を企画し始めました。 本記事では、LEADING QUALITYの読書会のポイントをまとめまし

          つとむ QAエンジニア

          LEADING QUALITY社内読書会のポイントをまとめました

          つとむ QAエンジニア

          [旅行記録]箱根本箱

          はじめに2023年12月に箱根本箱に宿泊しました。食事、居心地、おもてなし、お風呂の全てが秀逸で、感動しました。旅行が好きで、色々な旅館、ホテルに泊まりましたが、2024年2月現在「箱根本箱」を超える旅館、ホテルはありません。少しですが、箱根本箱の魅力を伝えていきます。 箱根本箱について 簡単に箱根本箱を紹介します。 最寄り駅は、箱根登山鉄道「中強羅」駅です。中強羅駅から歩いて5分程度の所にあります。宿泊した際は、最寄りの「中強羅」駅ではなく、「強羅」駅から歩きました。急

          つとむ QAエンジニア

          [旅行記録]箱根本箱

          つとむ QAエンジニア

          ソフトウェアテストの本質は情報収集！

          はじめに同僚のエンジニアから「テストは合格か不合格かの二択じゃないか」という話をうけて、ソフトウェアテストは合格か不合格かの二択ではないことを知ってほしいと思い、自分なりのソフトウェアテストの考えを整理しました。 ソフトウェアテストとは・・・ソフトウェアテストとは「テスト対象の情報を収集する手段」だと考えています。これは、ソフトウェアの機能、仕様、および要件に関する理解を深めることを指します。ドキュメントレビューや自動テスト、手動テストもテスト対象の情報を収集することが起点

          つとむ QAエンジニア

          ソフトウェアテストの本質は情報収集！

          つとむ QAエンジニア

          2023年を雑に振り返る

          2024年になったので、新年度の目標を立てる前に2023年を振り返ります。 2023年に立てた目標の振り返り 目標① 毎月noteでブログを書き起こす 結果 ： ▲ 書いたnoteの本数は11本でした。 毎月は書けませんでした。 春から秋にかけて、JSTQBのシラバスをnoteに書き起こしました。 目標② イベントに登壇する 結果 ： ✖ 登壇しませんでした。。。来年も目標に上げます！ 目標③ 「箱根本箱」に宿泊する 結果 ： 〇 12月下旬に箱根本箱

          つとむ QAエンジニア

          2023年を雑に振り返る

          つとむ QAエンジニア

          DesignDocで大事なこと（個人的に）

          はじめに先日、Encraftという株式会社ナレッジワークが主催しているイベントにオンラインで参加し、TestDesignDocというドキュメントについて紹介がありました。現職では、TestDesignDocのようなドキュメントは作成していませんが、スクラムチーム全員でDesignDocをブラッシュアップしています。 現職のDesignDocを見返すことで、得た気づき（DesignDocに書いてあってよかった記述）を紹介します。 DesignDocについて以下のような見出し

          つとむ QAエンジニア

          DesignDocで大事なこと（個人的に）

          つとむ QAエンジニア

          小さくリリースする

          とある一覧画面の1stリリース。 登録されているデータがUnicode順で、リスト形式で表示される。 並び替えできない、編集できない、検索できない。 それでもユーザーに公開した。ユーザーはうれしかった。 登録されているデータがリスト形式で俯瞰して見れる。 小さくリリースすることでの価値を感じたリリースでした。 QAエンジニアとしては、並び替えできないと使ってくれないのではと思ったが、そんなことは全くなかった。

          つとむ QAエンジニア

          小さくリリースする

          つとむ QAエンジニア

          （学習ノート）JSTQB アジャイルソフトウェア担当者 3.3 アジャイルプロジェクトの技法

          はじめにアジャイルテスト担当者のシラバスを読んで、重要なところを引用し、感想をつけた学習ノートをまとめました。この記事は「3.3 アジャイルプロジェクトの技法」が対象です。 アジャイルプロジェクトで特におさえておきたいポイント技法や用語について解説しています。 テストベーステストベースとなるものは以下の通りである。 以前のプロジェクトでの経験 システムの既存の機能 フィーチャおよび品質特性 コード、アーキテクチャおよび設計 ユーザプロファイル 既存および以前の

          つとむ QAエンジニア

          （学習ノート）JSTQB アジャイルソフトウェア担当者 3.3 アジャイルプロジェクトの技法

          つとむ QAエンジニア

          （学習ノート）JSTQB アジャイルソフトウェア担当者 3.4 アジャイルプロジェクトにおけるツール

          はじめにアジャイルテスト担当者のシラバスを読んで、重要なところを引用し、感想をつけた学習ノートをまとめました。この記事は「3.4 アジャイルプロジェクトにおけるツール」が対象です。 タスクマネジメントツールコミュニケーションツールアジャイルチームは、3種類のコミュニケーションツールを使い分けて、情報共有を行う。 Wiki メリット ナレッジ共有 Wikiで共有するナレッジ／情報 プロダクトのフィーチャ図 フィーチャについての討論 プロトタイプの図表 開発およ

          つとむ QAエンジニア

          （学習ノート）JSTQB アジャイルソフトウェア担当者 3.4 アジャイルプロジェクトにおけるツール

          つとむ QAエンジニア

          （学習ノート）JSTQB アジャイルソフトウェア担当者 3.2 品質リスクの評価とテスト工数の見積り

          はじめにアジャイルテスト担当者のシラバスを読んで、重要なところを引用し、感想をつけた学習ノートをまとめました。この記事は「3.2 品質リスクの評価とテスト工数の見積り」が対象です。 アジャイルにおける品質リスクの評価リスクとは 有害なまたは望ましくない結果や事象が起きる可能性 品質リスク プロダクトの品質の大きな影響を及ぼすような潜在的な問題 例） レポートでの不正な計算 （正確性に関連する機能リスク） ユーザ入力に対する応答が遅い （効率性に関連する非機能リス

          つとむ QAエンジニア

          （学習ノート）JSTQB アジャイルソフトウェア担当者 3.2 品質リスクの評価とテスト工数の見積り

          つとむ QAエンジニア