業務状態遷移テストを語る夕べ

3
前へ 1 ・・ 10 11 次へ
あきやま🍠 @akiyama924

このページですが、あとで、ATMの状態遷移図を載せておけばよかったのになと反省しました。 ということで、第2夜はこれで、おしまいです。 今日も偶然、同じ20ツイートだったみたいです。 質問とか意見とかあればリプライしてくださいね。

2018-08-30 23:19:12
あきやま🍠 @akiyama924

連ツイの第3夜です。今日はスライド5です。今日が終われば全部で6ページですので半分終わったことになります。早い! さて、この語る夕べですが、知らないうちに(聞いていたのかもしれませんのが)、「ユーザー受け入れテストで行う業務シナリオテストの一手法」という副題がついていました。

2018-08-31 21:06:14
あきやま🍠 @akiyama924

この副題に気がついたのは開催まで1週間を切ったあたりでした。ユーザー受け入れテストは、私のイメージでは、SIerさんが開発した案件の最終テストです。 何度か経験はあるのですが、そのとき、業務状態遷移テストはもとより、業務シナリオテストもしませんでした。

2018-08-31 21:10:23
あきやま🍠 @akiyama924

私がしたことはスライド5の吹き出しに書いた『導入して良い業務を確定する』ことです。 具体的には、ユーザーの隣で、ユーザーが受け入れテストのテスト対象を業務に使うところをジッと観察して、1時間に一回くらいの頻度で感想を聞いて、何か問題があったらそれを開発者に伝えることをしました。

2018-08-31 21:15:17
あきやま🍠 @akiyama924

問題が出ても開発者にはその問題を直すことを禁止しました。受け入れテストの開始以降はコードは完全フリーズです。直してはいけません。

2018-08-31 21:17:51
あきやま🍠 @akiyama924

直す事が禁じられた開発者になぜ問題の発生を伝えたのかというと『回避策を考えてもらうため』です。 たとえば昔の特殊なデータベースからレコードが検索できなければ、検索できるように新しいシステムを直すのではなく、そこだけ旧システムを使って検索するといった回避策を考えてもらいました。

2018-08-31 21:22:41
あきやま🍠 @akiyama924

回避策が見つからなかった業務についてはNGなので、「(今回のリリースでは)その業務に新システムは使えません」と言います。 もちろん計画段階で「お客様の業務を止めてしまう事が最悪なこと」という合意をお客様と取った上です。

2018-08-31 21:26:28
あきやま🍠 @akiyama924

ですから受け入れテストでは「(意図的な)シナリオ」ではなく普段の業務で使ってもらうことをしたのです。業務シナリオテストはシステムテストで行なっています。 以上のことから、スライド5には受け入れテストとシステムテストの話が混ざっています。とても悪いスライドです。すみません。

2018-08-31 21:30:01
あきやま🍠 @akiyama924

そういう意味でスライド5は、悪いスライドなのですが、システムテストの後半や受け入れテストで業務を意識したテストを行う時に私は、ここに書いた、「機能と順序と事態」の3つを意識したテストをしていることには違いありませんので、その話を続けます。

2018-08-31 21:37:04
あきやま🍠 @akiyama924

まず『機能』ですが、業務のテストでは、入出力が仕様通りであることよりも、ユーザー(お客様)がしたかったこと……つまり[目的]……が果たせたかをみます。品質特性で言うところの合目的性のテストです。 要求の実現率を測る人もいますが、私はよくわからないものは測りません。

2018-08-31 21:41:40
あきやま🍠 @akiyama924

2つ目は『順序』です。私は受け入れテストで順序の話をお客様とよくします。受け入れテストが順調に進んだときには「いつもと変わった順番で使ってみてもらえませんか?」と、お願いすることもあります。 開発やテストで順序の設計・テストはするのですが、想像を遥かに超えてくる事があるからです。

2018-08-31 21:47:52
あきやま🍠 @akiyama924

3つ目は『事態』です。『事態』というより、『不測の事態』や『緊急事態』という方がわかりやすいかもしれません。お客様にそれを想像してもらい受け入れテストしてもらうのですが、あまり良い想像をしてくださることはなく、問題は出ません。 でもお客様の納得度と安心度が上がるので続けています。

2018-08-31 21:53:10
あきやま🍠 @akiyama924

以上で、第3夜の連ツイはおしまいです。 11ツイートということで、少なめでしたが、まあ、作成に失敗したスライドなのでそんなところです。

2018-08-31 21:56:41
リリカル @mhlyc

@akiyama924 ちょっと前のツイートなのですが、状態を広く捉えすぎなのではと思いました。なんでも状態遷移テストで網羅したいということなのですか?

2018-08-31 23:06:51
リリカル @mhlyc

状態遷移テストで全部網羅しようとしたらあれもこれも状態になるから大変なんじゃないのって思う

2018-08-31 23:07:32
リリカル @mhlyc

@mkoszk なるほど まずは先週のログを追うことにします

2018-08-31 23:36:43
あきやま🍠 @akiyama924

@mhlyc そういう意識はありません。どの辺りでそう思われましたか?

2018-09-01 04:32:20
リリカル @mhlyc

@akiyama924 「ソフトウェアは、入力した値を出力に変換するために入力値だけでなく預金残高などのシステムのどこかにある値を使う事があって、その値こそが状態の正体」 のあたりです。確かにそうなのですが、そうなるとあらゆるものを状態として定義しなくてはならないです 本会で話されていましたらすみません

2018-09-01 08:18:16
あきやま🍠 @akiyama924

@mhlyc 「内部変数の組合せが状態」というと、数が多いということですね。 実用上は、内部変数の中で“管理対象となるリソース型エンティティ” ただし管理対象かどうかは「顧客番号や商品コードといった個体に対してそれを識別するための“認知番号”が付いているか否かで判断する」 と絞っても良いです。

2018-09-01 08:26:49
あきやま🍠 @akiyama924

@mhlyc 簡単に言うと、 理論上は『全ての内部変数の組合せ』なのですが、ソフトウェアの開発・テストの実務においては『コイツが重要って決めた内部変数の組合せ』に絞ったものを状態として取り上げればOKです。

2018-09-01 08:34:20
あきやま🍠 @akiyama924

@mhlyc リリカルさんの疑問は、とても大切なので、(私の立場を)もう少し丁寧に答えます。 HAYST法では、佐藤正美がいう番号が付いているかとうかや、先程ツイートした『重要かどうか』で状態変数判断しません。何故かというとそれだと状態変数を漏らすからです。

2018-09-01 08:43:26
あきやま🍠 @akiyama924

@mhlyc では、どうするか?というと、JaSST東北で話したラルフチャートを使います。 「ラルフチャートの状態変数(ラルフチャートの下に書く因子)は、ソースコード(などの内部設計)から拾ってください」と説明しました。

2018-09-01 08:45:42
あきやま🍠 @akiyama924

@mhlyc 目的機能ごとにソースコードを読んで、入力因子(正しい用語では信号因子)を出力因子に変換するまでに読み書きする変数を全て探して、それをラルフチャートの状態変数(状態因子)に書き出すという(大変な)作業をしてくださいと。

2018-09-01 08:48:39
あきやま🍠 @akiyama924

@mhlyc 簡単な静的解析ツールを作ると、楽ができるのですが、入り組んだプログラムですとそれなりに時間がかかります。 でも、状態変数を介してラルフチャートを超えて不具合が伝染するので、仕方ないのです。 2回目からはシンプルなプログラミングをしてくださるので楽になります。

2018-09-01 08:53:55
リリカル @mhlyc

@akiyama924 理解が違っていたらすみません。 もしかして状態が爆発するような設計は設計自体が悪いということでしょうか?

2018-09-01 14:33:16
前へ 1 ・・ 10 11 次へ