この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
事業開発部でQAエンジニアをしている長友です。
品質シリーズの投稿です。
今回は品質特性について書きます。
私たちの生活の中では、本当にたくさんのシステムが支えてくれています。 今現在私は在宅勤務で仕事をしています。 こんなに快適に、そしてスムーズに在宅で仕事ができているのは、とても多くのサービスが連携して機能しているからです。
ネットでつながった世界で、さまざまなサービスがつなぎあわさって、とても便利な世界を作り上げていくのはとても大変でもあります。
いろんな規格などがあって、それをもとに作られているサービスを、やはりいろんな観点からテストが行われていて、今のような便利さを私たちは感じられているんだと思います。
前回の記事の最後にアジャイルテストの4象限というものをあげさせていただきました。 いろんなテストがいるということを見てほしかったからです。
いろいろな種類のテストをするときに、テストの抜け漏れを防ぐためには、品質特性を参考にするといいです。
今回もその品質特性について、開発者の方々と話してみるきっかけにしてもらえたらと思います。
品質モデル
テストピラミッドも自動テストのモデルでした。
品質モデルは、品質特性を定義したもので、品質特性の相互の関係を示したモデルです。
品質モデルは、かつては、ISO/IEC 9126 だったものが今は、ISO/IEC 25010に置き換わっています。(データ品質モデルというものが ISO/IEC 25012 にあります。)
品質モデルは品質要求の定義のときなどに活用されます。
品質について開発者の方と話してみましょうという記事の中で触れましたが、誰にとっての品質なのかを意識しましょうということでした。
その誰かがいい悪いを判断するので、その誰かとこの品質要求について話してみることが大事です。
また、その誰かは、とてもたくさんの方々が該当することも多くなっています。そのため、品質要求を話す場合、モデルがあることで抜け漏れなどが防ぐこともできます。
より良いものを作るために多くの方々と(開発者やQA担当者、その他の関係者を含めて)、品質モデルにある各品質特性をベースに、自分たちのサービスでは、その各品質特性にあたる内容がどんなことなのかを議論しておきましょう。
それをベースにどんなことを確認できたらいいのかがわかり、その確認を行うための方法を開発者と一緒に話せることはQA担当者の方々にはとても大切な時間になります。
また、開発者の方々にとっても、品質を作り込んでいくための開発プロセスがイメージしやすくなり、見通しがたってくるので、不安が解消される部分もあると思います。
多くの方々と話すときにも、これまでのさまざまな方々の知見がつまった品質モデルは、有効に活用するととても役に立ちます。
なお、ISO/IEC 25010 を含む、25000シリーズは日本の方々もとてもたくさん関わって作られています。
(参考文献)つながる世界のソフトウェア品質ガイド
品質ライフサイクル
ISO/IEC 25000 では、品質のライフサイクルという視点が加わっています。
その品質のライフサイクルを簡単に図にすると以下のような感じです。
大きくは利用者の視点で見たときの部分と、開発者の視点で見たときの部分に分かれています。
また、開発者の視点で見たときの部分の中では、外部品質と内部品質で分かれています。
私の所属する事業開発部で作成している prismatix では、この品質ライフサイクルを1回のスプリントでぐるっと回しているイメージです。
利用時の品質モデル
利用時の品質モデルでは、主にシステムの全体と利用者という人のプロセスに注目をしたものになっています。
※色のついた５つが品質特性で、その下に並ぶ白い枠のものは、品質副特性です。
前にお話したように誰がというのが関わってくる品質モデルです。
特定の利用者が使うときの状況をイメージして、そのニーズを満たすかどうかを考えていきます。
たとえば、サービスを利用してくださるお客様が何か効率をアップしてほしいといった要求が出されたとすると、それを実現するには、こういう機能がいるし、そうかこんな非機能の要素も必要だなといったことを具体的に思い描くことができるでしょうか。
上ではニーズから品質特性に結びつけて考えましたが、逆にもしかしたらこの品質特性について自分たちはこれまで考えてこなかったものかもと思うものもあるかもしれません。そうしたら、その品質特性は自分たちのサービスでどんな利用時のときに考えられるかなどを検討してみて、あらたにニーズを発見することもあるかもしれません。
品質特性はいろいろなものに適用できるように抽象的な言葉になっているので、具体的なものとのイメージの行き来をして発想を一旦は広げてみることも必要になってきます。
最初にこうしたことを開発者やQA担当者の方々、そして関係者の皆さんと話しておくといろいろ掘り出すことができます。
システム・ソフトウェア製品の品質モデル
システム・ソフトウェア製品の品質モデルでは、主に対象のソフトウェアに注目したものになっています。
※色のついた８つが品質特性で、その下に並ぶ白い枠のものは、品質副特性です。
開発者の方々にとってよく聞く品質特性は、保守性や移植性かもしれません。
アジャイル開発だと、これらの品質特性が大切になってきます。これらの品質特性が考慮されていることで、完成した製品やサービスを短いサイクルで作っていくことができるからです。
外部品質のあたりでは、品質を考えるときの誰かが開発者を考えることにもなります。開発者の皆さんの中でお近くの方々ともいろいろ話されてみてはいかがでしょうか。
また、保守性の中には試験性というものもありますから、QA担当者の方々ともいろいろ話してみることが大切です。互いに質問しあえるくらいに。
以前かなりご経験を積んだベテランの開発者の方に聞いた話です。
テストコードがちゃんと書かれているコードでは、保守性や移植性のことまで突っ込んでレビューすることがしやすくなるとおっしゃっていました。
開発中に何度かレビューをすることがあるのだと思います。最初にテストコードの内容がちゃんと確認すべきことをしていることをレビューしておいて、あとはそのテストコードが書かれていて、ちゃんとテストが通っていたら、機能が動くことはテストコードで確認できていることになる。だからあとは保守性や移植性などに集中してレビューができるとのことでした。
コードを書かれた開発者の方にとっても、テストコードがあれば安心していろいろ試せますし、ベテラン開発者の方のご知見を聞くことができ、エンジニアリング的な内容の保守性や移植性までレビューしてもらえることで、ご自身の成長を実感できることにもなると思います。
ぜひこの機会に品質特性について、話し合ってみましょう。
今日は品質特性について書きました。 ちょっと堅苦しいと感られることもあるかもしれません。でも多くの関係者の方々と話すときに、品質特性というものを使って話されることで、信頼感が増して、早く話が進むことがあるようにも思いますよ。
今回はここまでです。
また次回をお楽しみに！