GENZ, Inc.

テスト外注のご案内 登記申請ソフトのテストを、開発とは別の目で

当局ソフトの更新告知から適用までの期間は短く、改修と検証の両立が必要です。実装した側とは別の立場で回帰範囲を引き直し、判定に使える記録を残します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

登記申請ソフトで起きやすい不具合

登記申請ソフトの不具合は、申請が通らないという形で利用事務所の現場に届きます。改修箇所の周辺だけの確認でリリースを重ねると、判定の場で説明できる材料が残らず、同じつまずきを繰り返します。

改修した申請情報の項目が欠けたまま送信される

改修で項目が追加・変更されたあと、入力画面だけで確認を終えると、送信データへの反映漏れが残ります。補正となれば、受任案件の期日に遅れが出ます。

項目欠落による補正

電子署名の付与に失敗して、送信が成立しない

電子署名は証明書やICカードといった手段ごとに処理経路が分かれます。一部の経路だけを確かめると、別の署名手段で送信が成立しない事象が残ります。

署名失敗で送信不可

接続先のソフト更新後に、連携部分が動かなくなる

当局側ソフトの更新は事前に告知され、自社製品は連携部分の回帰確認を要します。対象選定が実装者の見立てだけに頼ると、影響箇所の取りこぼしが出ます。

更新後の連携停止

氏名や地番の文字が、送信の前後で置き換わる

氏名や地番の文字は、入力・データ管理・送信の各段をまたぎます。改修箇所の周辺だけで済ませると、送信されたデータで文字がどう変わるかを追えません。

文字変換の差異

処理状況や電子公文書の取り込みが漏れたまま残る

処理状況と電子公文書の取得は、送信が成立したあとに行われます。確認がそこで止まると、取り込み漏れを事務所からの連絡で初めて知ることになります。

公文書の取込漏れ
02 RISK

不具合を見逃したまま提供した場合に起きること

接続先の更新への対応を急ぎ、確認の薄いままリリースを重ねると、不具合は事務所の画面で見つかります。届く先は受任案件と開発計画と収支です。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

テスト体制を点検するときの確認点

回帰の対象を絞る根拠が実装者の見立てだけのままでは、絞りすぎと広げすぎの間で毎回迷うことになります。点検の入口は、範囲決定の構造・接続先の更新への対応・利用環境の差・記録の残しかた・検証時間の確保です。

実装者の見立てだけで範囲を決め続けると、見落としに気づく機会が構造として用意されないまま、同じ判断の積み重ねが進みます。

実装した担当者が、自分の実装を検証していないか

実装した担当者が影響範囲を見立て、同じ組織で結果まで評価していると、見落としの有無を測る物差しが内側にしか残りません。範囲の決定と結果の評価が同じ手に集まっていないかを確かめます。

確認する資料
  • 範囲決定の記録
  • 役割分担図
  • 評価の承認記録
告知から適用までの期間が短いまま次の更新を迎えると、検証の時間がさらに圧縮され、範囲を狭めた確認でリリースへ進むことになります。

接続先の更新に合わせた回帰の範囲を決めているか

申請用総合ソフトはバージョンアップが告知され、接続する自社製品側は連携部分の回帰が必要になります。告知から検証範囲への読み替えが特定の担当者に委ねられていないかを、直近の記録で確認します。

確認する資料
  • 更新告知の写し
  • 対応範囲の対応表
  • 回帰結果の記録
事務所ごとの利用環境の差を条件に反映できないままでは、連絡を受けた事象を社内で発生させて検証できず、切り分けに時間がかかります。

事務所ごとの利用環境の差を、条件に反映できているか

インストールして使う形態と、ブラウザから申請を行える形態が併存し、事務所ごとに端末の構成や同時利用者数が異なります。どの環境の組み合わせまで条件に含めるかの基準を持っているかを確かめます。

確認する資料
  • 導入環境の一覧
  • 検証条件の一覧
  • 事象報告の写し
結果が文書として残っていないと、リリース判定の場で範囲の妥当性を問われても説明の材料がなく、判定が経験則に依存したまま固定化します。

テスト結果を、あとから説明できる形で残しているか

リリース判定の場で「どこまで見たか」を問われたとき、検証範囲と未実施の残り、既知の不具合と回避策を示せなければ、判定は経験則に依存します。結果が記憶ではなく文書で残っているかを確かめます。

確認する資料
  • 検証範囲の一覧
  • 未実施項目の一覧
  • 判定議事の写し
検証の時間を確保できないままでは、リリース直後の問合せ対応に開発の手が取られ、次の改修の着手が遅れる循環が続きます。

改修が重なる局面で、検証の時間を確保できているか

更新の告知から適用日までの期間が短いと、改修と検証の両方を終える必要があり、検証に割ける日数が先に削られます。改修が重なる局面の工数の見通しと、検証時間を確保する仕組みがあるかを確認します。

確認する資料
  • 改修計画表
  • 工数の見積書
  • 要員の配置表
  • 検証日程の記録
04 TEST DESIGN

登記申請ソフトのテストで提供する内容

GENZはテスト計画の作成から結果の引き継ぎまでを外の立場で担い、担当者の経験に依存する範囲決定を残せる手順へ置き換えます。

STEP 01 現状のテスト資産を確認する既存の手順と観点の抜けを棚卸しします
どう確かめるか

改修の範囲に合わせたテスト計画とテスト設計

当局側の更新告知を自社製品の対応範囲へ落とし、申請情報の作成から送信までの一連の経路を対象に含めた計画を立てます。リリース判定の場で「どこまで見たか」を説明できる材料になります。

  • 01現行のテスト手順と観点表の内容を一覧で確認します
  • 02改修で変わる機能と経路を製品仕様から洗い出します
  • 03不足している観点を切り分け、優先度とともに一覧へ整理します
OUTPUTテスト計画書と設計書
STEP 02 テスト観点を洗い出して優先度を決める改修内容と期日から範囲を設定します
どう確かめるか

改修のたびに使える回帰テストの手順の整備と実行

修正の影響範囲を実装者の見立てだけに頼らず、回帰の対象を手順として残します。次の改修で同じ前提のまま古い手順が回り続ける状態を止められます。

  • 01申請情報の作成から送信までの経路を観点に分解します
  • 02電子署名の付与処理と送受信処理に優先度を付けます
  • 03検証の対象と対象外を分けた根拠を文書に明記します
OUTPUT回帰テストの手順一式
STEP 03 テストを実施して結果を報告する結果と未実施分を報告書にまとめます
どう確かめるか

接続先のシステムとの送受信と連携部分の確認

当局側システムとの送受信部分について、申請情報の送信と処理状況・電子公文書の受け取りを意図的に発生させて検証します。接続先の仕様変更への対応根拠を示せます。

  • 01設計したテストを実施し、検出した不具合を切り分けます
  • 02事象の発生条件を再現手順とともに開発チームへ渡します
  • 03既知の不具合と回避策を、結果の報告書にまとめて添えます
OUTPUT連携部分の確認結果
STEP 04 改修の周期に合わせて継続する次の更新告知にそのまま使える状態を保ちます
どう確かめるか

テスト結果の取りまとめと開発チームへの引き継ぎ

検証範囲と未実施の残り、既知の不具合と回避策を報告書にまとめます。上申や稟議で委託範囲の妥当性を問われたときに、実績として提示できる形で引き継ぎます。

  • 01回帰テストの手順を改修の前提に合わせて更新します
  • 02当局側の更新告知を受けて、対象範囲を再設定します
  • 03次期以降の継続判断に使える実施の実績を積み重ねます
OUTPUT結果報告と引き継ぎ資料
05 RATIONALE

テストを外部へ出した場合に起きる進行の変化

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 回帰対象の絞り込みに外部の根拠が持てる
  • 更新告知から適用までの期間に検証を収められる
  • 利用環境の差を確認条件として整理できる
  • リリース判定に使う説明材料が手元に残る
06 SERVICE

ご相談をお受けできる対象の範囲

GENZがご相談をお受けするのは、貴社が開発・提供している登記申請ソフトと、その周辺にまたがる部分です。当局側のオンライン申請システムは対象に含めず、改修できる範囲を実装した主体とは別の立場で検証します。

SVC 01

自社で開発・提供している登記申請ソフト

申請情報の作成、電子署名の付与、送受信の処理まで、貴社製品の機能全体を対象にします。改修のたびに回帰の範囲を整理し直し、検証します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

事務所の案件管理や請求との受け渡し部分

案件管理・見積・請求など、事務所内の他機能とデータを受け渡す部分も対象です。受け渡しで値が欠ける、形が変わる事象を確認します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

申請データを扱う周辺システム

申請データを保管・参照する周辺のシステムも対象にできます。インストール型とブラウザで使う形態が併存する環境の差も条件に織り込みます。

計画から報告までの流れを示す無文字の図解。
SVC 04

制度や様式の変更を受けて対応する改修部分

接続先の仕様更新や様式の変更を受けた改修部分を対象にします。告知から適用までの短い期間に合わせ、改修と検証を並行して進めます。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

お問合せからテスト開始までの流れ

改修の予定や検証範囲が決まっていなくてもご相談いただけます。対象範囲の整理から始めます。

テスト外注についてのお問合せ

フォームまたはお電話でご連絡ください。改修の予定が未定でもかまいません。

お打ち合わせと対象範囲の確認

接続先ソフトの更新内容と導入先の環境を伺い、検証が必要な範囲を整理します。

お見積の提示とご契約の手続き

対象範囲と期間に応じた見積を提示します。社内稟議に使える資料も添えます。

改修の予定に合わせたテストの開始

ご契約後、改修の予定に合わせてテストを開始し、結果は報告書でお渡しします。

改修ごとの検証、まずは状況の共有から

登記申請ソフトのテスト体制について、現状の共有からご相談ください

現在の改修予定と社内で回せる要員の状況をお聞かせいただければ、対象とすべきテスト範囲の切り分けと優先順位、必要工数の見通しまで、起案の材料として使える形で整理してお返しします。