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

発電量監視システムでよくある不具合

発電量監視システムの不具合は、正常な条件の画面表示の確認だけでは表面化しません。通信断・欠測・時刻ずれ・締め時刻の境界値が検証から外れると、集計値の誤りが売電精算やリリース判断の材料に残ります。

通信断の欠測がそのまま集計され、日次の発電量が実態より小さく出る

通信断で生じた欠測がそのまま集計処理に入り、日次の発電量が実態より小さく計上されます。欠損扱いと補完の仕様を検証しなければ見逃されます。

欠測と集計差異

締め時刻をまたぐ計測値が翌月に計上され精算額と合わない

締め時刻をまたいだ計測値が翌月分に計上され、月次の集計値が売電の精算額と一致しません。集計期間の区切りと丸めの扱いが金銭影響に直結します。

締めまたぎの計上

出力制御の期間を異常と判定し、制御中の発電量低下で通知が連続発報する

出力制御による発電量の低下を異常と判定し、通知が連続発報します。誤報が続くと運用担当が通知を信用しなくなり、本当の異常が表面化しません。

誤報の連続発報

計測機器の時刻ずれにより、同じ時間帯の値が二重に登録される

計測機器の時刻ずれにより、同じ時間帯の値が二重に登録され、集計値が実態より大きく出ます。機器間の時刻同期の仕様を検証対象に含める必要があります。

時刻ずれの二重登録

CSVの文字コードが合わず会計側の取り込みが失敗する

出力CSVの文字コードが会計側の想定と合わず、取り込みが失敗します。ファイル仕様の確認が抜けたままリリースされ、稼働後に判明する形です。

CSV取り込み失敗
02 RISK

残存した不具合により生じる問題

リリース前の検証で潰せなかった不具合は、稼働後に集計値の誤りや通知の機能不全として表面化し、売電収入の修正と異常発見の遅れにつながります。

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

静的テスト(レビュー)でおさえるべき観点

動的テストの前に、仕様書と設計書の記述を静的テストで照合します。発電量監視システムでは、計測データの取得条件と集計ルールが文書上で食い違うだけで、本番の発電量レポートの誤りに直結します。

取得項目の単位の不整合を見逃すと、集計値が実際の発電量と一致しないままリリースされ、売電収入の修正につながるおそれがあります。

通信仕様書と設計書で取得項目と単位を照合する

パワーコンディショナーから取得する発電情報の項目名・単位・取得間隔が、通信仕様書と設計書で一致するかを照合します。機種変更や設備増設では、片側の文書だけが更新されたまま残ることがあります。

確認する資料
  • 通信仕様書
  • 設計書
  • 機器仕様書
丸めの規定が文書にないと、集計のたびに端数の扱いが変わり、精算側との差異として表面化するおそれがあります。

集計の計算順序と丸めの規定を精算側の単位定義と照合する

日次・月次・年次の集計について、計算順序と丸めの規定を設計書から読み取り、売電の精算側で使う単位定義と照合します。計測値は精算の根拠となるため、端数処理の差は収入の修正という形で表面化します。

確認する資料
  • 集計設計書
  • 精算単位定義
  • 画面仕様書
しきい値と運用手順の不整合を放置すると、誤報が続き、運用担当が通知を信用しなくなる状態が生じます。

しきい値と通知条件が運用手順書と矛盾しないか照合する

異常検知のしきい値と通知条件が、運用手順書に書かれた一次切り分けの手順と矛盾していないかを照合します。設計上の発報条件と運用側の想定がずれていると、誤報と見逃しの切り分けができなくなります。

確認する資料
  • しきい値定義
  • 運用手順書
  • 通知条件書
欠測時の扱いが未定義のままだと、欠損データを含む集計が日次レポートに計上され、発見が遅れるおそれがあります。

欠測や時刻ずれの扱いが設計書に記述されているか

通信断・計測器の欠測・時刻ずれが起きた場合に、補完・再送・欠損扱いのどれで処理するかが設計書に記述されているかを確認します。記述がなければ、実装者ごとの判断で処理が分かれるおそれがあります。

確認する資料
  • 通信仕様書
  • 設計書
  • 障害時手順
保持期間と表示期間のずれを放置すると、月次確認で小さな計上差異が蓄積しても発見できない状態が続きます。

データ保持期間と表示期間の整合を確認する

計測データの保持期間と、画面・レポートで表示できる期間の整合を確認します。表示期間が保持期間を超えていると月次の集計確認で欠損が起き、保持期間が短いと過去との比較による差異の発見ができません。

確認する資料
  • データ保持設計
  • 表示仕様書
  • レポート仕様
  • 運用設計書
04 TEST DESIGN

動的テストの設計・実行のポイント

発電量監視システムの動的テストは、集計・判定から受け入れ確認まで、工程ごとに確かめる観点を分けて設計します。

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

GENZが代行する発電量監視システムのテスト

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 異常系のテスト観点を一覧で整理します
  • 検証範囲の線引きを定型化し合意に使えます
  • 既存ベンダー体制を変えず検証を追加できます
  • リリース判断と監査で使える報告を残します
06 SERVICE

検証範囲の合意を支えるGENZ

改修のたびに検証範囲を検討し直す状態では、品質保証担当との合意の根拠が属人に残ります。GENZは処理の単位からテスト設計を起こし、異常系の観点を持ち込み、今の開発体制のまま受け入れ側の検証を担います。

SVC 01

処理の単位からテスト設計を起こす

計測・判定・集計の処理の単位に分け、仕様書と設計書のレビューから設計を起こします。集計期間の区切りやしきい値の境界値も対象に含めます。

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

異常系のテスト観点まで検証します

通信断・欠測・計測器の時刻ずれを意図的に発生させ、補完や再送、欠損の扱いを検証します。正常系に偏りがちな項目を観点の側から補います。

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

今の開発体制のまま、第三者検証を足せます

開発ベンダーとの契約や進め方は変えず、受け入れ側の検証だけを追加で担います。既存の工程に並行して進めるため、体制の置き換えは起きません。

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

テスト結果と不具合を記録して納品します

テスト項目書・不具合票・報告書を納品します。どこまで検証したかが報告書で追えるため、リリース判断の材料と監査の証跡として残ります。

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

ご相談から納品までの流れ

ご相談から報告書の納品まで、検証範囲の整理と見積もり、テストの実施、再確認までを一貫して担います。

ヒアリング

現状のテスト体制と改修要件、気になっている観点をお聞かせいただきます。

テスト設計と見積もり

境界値や通信断時の扱いを含めて検証範囲を整理し、見積もりを提示します。

テストの実施と進捗の共有

テスト設計から実行までを担い、消化した項目と不具合を定期的に共有します。

報告書の納品と修正後の再確認

テスト結果と不具合を記録した報告書を納品し、修正後の再確認も行います。

テストのご相談・お見積もり

発電量監視システムのどこを、どこまで検証するか。GENZにご相談ください

監視システムの改修や受け入れテストで、どこまで検証すべきか迷う段階からご相談いただけます。テスト範囲の整理、観点の優先順位、必要工数の考え方まで、第三者の視点で決めていきます。