品質特性のすすめ

Transcript

1. スライドトップと
 してご利用ください
 マネーフォワード事業本部 
 山田 太郎
 © Money Forward, Inc. 品質特性のすすめ presented by honamin / QA Engineer © Money Forward, Inc.
2. 1. 品質特性の概念を完全に理解する 2. 💪日々やってることが品質特性と結びつくよ うになる
3. 品質特性とは about Quality Characteristic 「 要求事項に関連する製品、 　プロセス又はシステムに本来備わっている特性」 1. “本来備わっている”とは、そのものが存在している限り、もっている特性を意味す る。 2. 製品、プロセス又はシステムに付与された特性（例:製品の価格、製品の所有者） は、その製品、プロセス又はシステムの品質特性ではない。 3. 品質工学では、システムの機能を確保するために必要とされ、仕様で規定される特 性。
4. なぜ定義されたのか？ 品質は従来「目に見えないもの」 だったので、 確認するための基準を設けた。 （品質の構造をモデル化した）
5. ISO標準（国際標準）での分類：1991年
6. ISO標準（国際標準）での分類：2011年 ・JIS規格になったのが2013年 ・セキュリティ／互換性が品質 特性として追加 ・いくつかの特性／副特性はよ り的確な名称がつけられた ・時代と共に変わっていく可能 性大いにあり https://www.otsuka-shokai.co.jp/erpnavi/topics/column/ipapsq/softwarehinshitsunotokusei2.html
7. 品質特性／副特性の説明
8. ◆機能適合性 明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又は システムが提供する度合い。 ※機能仕様にではなく、機能が明示的ニーズ及び暗黙のニーズを満足させるかどうかにだけ関係 functional suitability 仕様書通り！ではなく ユーザーストーリーを満たす機能を 提供できているか。
9. ➖ 機能完全性 機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。 テスト観点：新しく追加された機能が正しく実装できているか functional completeness ➖ 機能正確性 正確さの必要な程度での正しい結果を、製品又はシステムが提供する度合い。 テスト観点：処理・出力データ正誤 functional correctness ➖ 機能適切性 明示された作業及び目的の達成を、機能が促進する度合い。 テスト観点：目的に合った機能が実装されているか functional appropriateness
10. ◆性能効率性 明記された状態（条件）で使用する資源の量に関係する性能の度合い。 ※資源には、他のソフトウェア製品、システムのソフトウェア及びハードウェア構成、並びに材 料（例えば、印刷用紙、貯蔵媒体）を含むことができる。 performance efficiency CSV出力や検索の速度がはやい。など。 ただし明記された状態（条件）が必要。 低スペックPCで速度出そうと思っても無理。 「どんな環境でどれくらいのデータ上限であれば 補償する」。
11. ➖ 時間効率性 製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間、並びにスループ ット速度が要求事項を満たす度合い。 テスト観点：適切な応答時間及び処理時間（一定の処理を完了するのに要する時間） time behavior ➖ 資源効率性 製品又はシステムの機能を実行するとき、製品又はシステムで使用される資源の量及び種類が要求事項 を満たす度合い。 テスト観点：使用領域を使いすぎない（CPU負荷・通信資源など） resource utilization ➖ 容量満足性 製品又はシステムのパラメータの最大限度が要求事項を満たす度合い。 テスト観点：パラメータを最大限までつかえること（保存できる項目数・同時に利用する利用者の数・ データベースの大きさ） capacity
12. ◆互換性 同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品、 システム又は構成要素の情報を交換することができる度合い、及び／又はその要求された機能を実行す ることができる度合い。 compatibility 想定出来うる利用者の利用環境にシステムが 対応できているか。 利用環境の優先順位についてはGAなどで調査 することが多い。
13. ➖ 共存性 その他の製品に有害な影響を与えずに、他の製品と共通の環境及び資源を共有する間、 製品が要求された機能を効率的に実行することができる度合い。 テスト観点：他のソフトウェアとの共存 co-existence ➖ 相互運用性 二つ以上のシステム、製品又は構成要素が情報を交換し、 既に交換された情報を使用することができる度合い。 テスト観点：他のシステム、装置との連動 resource utilization 📄memo 推奨環境との繋がりについて？？？と思う人もいるかもです。 本来推奨環境とは「このスペック以上の環境を用意してね。用意できないならもしかしてもしかするとアプリ ケーションが正常に動かないかもしれないけど、補償はしないよ」という環境のこと。 この環境には自アプリケーションの負荷がかかっていても他アプリケーションが正常に動く、という観点も含 まれる。ただしWEBブラウザ上のアプリケーションに対してはここらへんを考えて品質設計されてるものを 知らない🤔（ネイティブアプリではよくある）。そこらへんはブラウザアプリ側でよしなにしてくれている という仮説。（宿題にさせてください・・・）
14. ◆使用性 明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために、 明示された利用者が製品又はシステムを利用することができる度合い。 usability 明示された利用状況・明示された利用者。 というところがミソ。「誰でも」ではない。
15. ➖ 適切度認識性 製品又はシステムが利用者のニーズに適切であるかどうか（機能適切性）を利用者が認識できる度合 い。 テスト観点：利用者のニーズに適した利用。（スタートアップガイド・ヘルプページなども含む） appropriateness recognizability ➖ 習得性 明示された利用状況において、有効性、効率性、リスク回避性及び満足性をもって製品又はシステムを 使用するために明示された学習目標を達成するために、明示された利用者が製品又はシステムを利用で きる度合い。 テスト観点：覚えやすい使用方法になっているか。 learnability ➖ 運用操作性 製品又はシステムが、それらを運用操作しやすく、制御しやすくする属性をもっている度合い。 テスト観点：作業順序に応じた操作になっているか。 operability
16. ➖ ユーザーエラー防止性 利用者が間違いを起こすことをシステムが防止する度合い。 テスト観点：誤操作防止 user error protection ➖ ユーザーインターフェース快美性 ユーザインタフェースが、利用者にとって楽しく、満足のいく対話を可能にする度合い。 テスト観点：利用者が満足するシステムとの対話 UI aesthetics ➖ アクセシビリティ 製品又はシステムが、明示された利用状況において、明示された目標を達成するために、幅広い範囲の 心身特性及び能力の人々によって使用できる度合い。 テスト観点：身体障害者を含む全ての人が快適・有効に使用できるか（年齢による身体障害も含む） accessibility
17. ◆信頼性 明示された時間帯で、明示された条件下に、システム、製品又は構成要素が明示された機能を実行する 度合い。 reliability ソフトウェアが正常に稼働し続けられるか。 また、障害発生時はすぐに復旧できるか。
18. ➖ 成熟性 通常の運用操作の下で、システム、製品又は構成要素が信頼性に対するニーズに合致している度合い。 テスト観点：障害発生時に機能停止しない。（MTBF・・・Mean Time Between Failure） maturity ➖ 可用性 使用することを要求されたとき、システム、製品又は構成要素が運用操作可能及びアクセス可能な度合 い。 テスト観点：使用可能な状態の継続度。（24時間利用可能か） availability ➖ 障害許容性（耐故障性） ハードウェア又はソフトウェア障害にもかかわらず、システム、製品又は構成要素が意図したように運 用操作できる度合い。 テスト観点：回避（エラー表示・制限） fault tolerance
19. ➖ 回復性 中断時又は故障時に、製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する 状態に復元することができる度合い。 テスト観点：障害復旧（ロールバックなど） recoverability 📄memo 機能仕様に対する不具合は「機能適合性」に包括されます。 信頼性では障害（主には外的要因。AWS障害とか）時でもどれだけソフトウェアが正常に動くかが評価され ます。ただし、不十分なエラー処理などシステム障害の起因となる不具合については信頼性に影響を及ぼしま す。 例：AWS障害＞さくらに切り替えて回避・・・障害許容性を満たしていると言える。
20. ◆セキュリティ 人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合 いをもてるように、製品又はシステムが情報及びデータを保護する度合い。 security ハッキングやサイバーテロなどの全ての攻撃 に対応できるセキュリティシステムは存在し ない。今できうる最大の対策を継続する。 権限管理は機能仕様のひとつではあるが、セ キュリティを観点にした機能と言える。（必 要な人にだけ必要なアクセスを）
21. ➖ 機密性 製品又はシステムが、アクセスすることを認められたデータだけにアクセスすることができることを確 実にする度合い。 テスト観点：許可された者のみがアクセスすることができるか confidentiality ➖ インテグリティ コンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを、システ ム、製品又は構成要素が防止する度合い。 テスト観点：許可していない者がアクセスすることができないか integrity ➖ 否認防止性 事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明す ることができる度合い。 テスト観点：利用事実の証拠を証明できるか（利用規約の同意チェックの記録など） non-repudiation
22. ➖ 責任追跡性 実体の行為がその実体に一意的に追跡可能である度合い テスト観点：ログの追跡が可能か（ユーザークレームに対して本当にそのユーザーがその手順で作業を 行ったか確認できるのかなど） accountability ➖ 真正性 ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。 テスト観点：本物であるかどうかを確実に証明できる（ID／Pass、生体認証など） authenticity
23. ◆保守性 意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い。 maintainability 「修正」には、環境における変更、機能仕様 変更に対する訂正、改良または適応を含む。 主には静的テスト対象物（ドキュメント・ コード）の品質である。
24. ➖ モジュール性 一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように、システム又はコンピュ ータプログラムが別々の構成要素から構成されている度合い。 テスト観点：別々の構成要素の構成度合い modularity ➖ 再利用性 一つ以上のシステムに、又は他の資産作りに、資産を使用することができる度合い。 テスト観点：他システムへの再利用（ドキュメント類も含めることができる） reusability ➖ 解析性 製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合 評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別する ことが可能であることについての有効性及び効率性の度合い。 テスト観点：障害監視・ログ取得 analysability
25. ➖ 修正性 欠陥の取込みも既存の製品品質の低下もなく、有効的に、かつ、効率的に製品又はシステムを修正する ことができる度合い。 テスト観点：修正のしやすさ modifiability ➖ 試験性 システム，製品又は構成要素について試験基準を確立することができ、その基準が満たされているかど うかを決定するために試験を実行することができる有効性及び効率性の度合い。 テスト観点：試験のしやすさ testability
26. ◆移植性 一つのハードウェア、ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に、システ ム、製品又は構成要素を移すことができる有効性及び効率性の度合い。 portability オンプレなどインストール先の環境に変更 が入る可能性の高いシステムでは重要度が 高い。が、クラウド型サービスではクラウ ドという形自体が移植性をある程度までは 担保できるサービスの形ではとおもったり してます。（完全に個人談）
27. ➖ 適応性 異なる又は進化していくハードウェア、ソフトウェア又は他の運用環境若しくは利用環境に、 製品又はシステムが適応できる有効性及び効率性の度合い。 テスト観点：移植・OSの入れ替え adaptability ➖ 設置性 明示された環境において、製品又はシステムをうまく設置及び／又は削除できる有効性及び効率性の度 合い。 テスト観点：インストールのしやすさ、システムの初期導入手順 installability ➖ 置換性 同じ環境において、製品が同じ目的の別の明示された製品と置き換えることができる度合い。 テスト観点：他製品（またはスプレッドシートなどの管理機構）からの置換えが可能か。csvのイン ポート機能なども含まれる replaceability
28. 品質特性を知っておくと何がいい？ 1. 開発しているサービスの現状の品質を客観的に意識することができる 2. システムの成長フェーズによって注力する品質は異なる。 「今本当に注力したい品質（今ユーザーに届けたいもの）」について、 チーム内で認識するための共通言語が持てる 3. 競合サービスを品質特性から分析し、自社サービスと比較することができる
29. 品質は常に相対評価である 競合サービスと比べてどうか 時代と環境に合っているのか まずは実務に必要な機能があるのか、 あるとしたらコストはどうか、 コストに対して使用性はどうか。 いろんな面で比べられています。 自分たちではいい！と思っていても 周りと比べるとその品質ってどうですか？ ※品質がいい　≠　不具合がない 例えば2020年1月1日に「高品質」かつ かぎりなくパーフェクトな状態でリリース したシステムを2025年12月31日まで放っ ておいたらどうでしょう。 システムの品質は100%下がります。 子どもと違って、システムは一人では育た ないし、周りの環境は常にアップデートさ れていくからです。
30. まとめ 品質に正解はない。 何年も何十年もその先も、 ユーザーと伴走できるシステムになるには、 何が必要か考えてみよう！
31. 参考資料： ◆日本工業規格 http://kikakurui.com/x25/X25010-2013-01.html ◆ISO／IEC 25010の品質モデルを使って市場不具合を減らすテスト設計千尺〜品質を「見える化」する〜 http://www.jasst.jp/symposium/jasst21tokyo/pdf/A4.pdf ◆第8回 「ソフトウェア品質特性」（2） https://www.otsuka-shokai.co.jp/erpnavi/topics/column/ipapsq/softwarehinshitsunotokusei2.html ◆非機能要求とISO9126 https://www.ogis-ri.co.jp/otc/hiroba/technical/JavaPress_ISO9126/ ◆システム及びソフトウェア製品の品質要求及び評価（SQuaRE) -システム及びソフトウェア製品品質の測 定量 http://www.sic.shibaura-it.ac.jp/~tsnaka/lecture/ese/JIS%20X25023.pdf
32. スライド構成 👑「品質特性」を意識することでなにがいいのか • 品質特性とは ◦ 国際標準のはなし ◦ 品質要因のはなし ◦ なぜ作られたのか ◦ ソフトウェア製品の品質特性について（その他６つパターンなどもせつめい） • 個々の品質特性と副特性のはなし ◦ 機能適合性からじゅんばんに • 品質特性とユーザーフォーカス
33. Meety や Twitterでぜひお話ししましょう🐥