底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

ワンピースの連載が無駄に長くなってる理由を考察

2021年2月現在、最新刊98巻が刊行されてる週刊少年ジャンプの長期連載漫画ワンピース。連載当初から単行本は集めていなかったけど、雑誌連載で読み続けていた。

 

連載開始当初は「見やすい絵柄」と当時ジャンプ誌上になかった「冒険もの」というジャンル、また「○○の実を食した○○人間」という異能者が繰り出す異能の数々がユニークで、ドラゴンボール連載終了後の新しい次代の旗手が現れた!と興奮したのを覚えている。

 

それから20年。いまだにワンピースは連載が続いていて、結局ワンピースってなんなのかは漫画の中では一切謎が解決しないまま。そして、連載開始時の特徴であった「見やすい絵柄」は「ごちゃごちゃと見にくいコマの集合」になり、「冒険もの」という内容はいつしか辿り着いた島で暴れ回るだけとなり、異能の数々は今でも健在だが、異能者しか存在しないような世界になってるので、個性でもなんでもない状況。

 

とにかく不必要なメンバーが多すぎる

ルフィが船長を務める麦わら海賊団の団員たちの存在理由がそもそもよくわからない。

  • 医者(チョッパー)
  • 操舵手(ジンベエ)
  • 楽家(ブルック)
  • 考古学者(ロビン)
  • 船大工(フランキー)
  • コック(サンジ)
  • 航海士(ナミ)
  • 狙撃手(ウソップ)
  • 戦闘員(ゾロ)

 

全員それっぽい役割を与えられているが、そもそも海上にいることがほぼないので、大半のメンバーは存在理由が薄い。というかない。

 

  • 登場人物たちもほぼ無敵の人たちばかりなので大怪我をしても死ぬことがないから、医者がいる理由も薄い。
  • 狙撃で何かするよる直接ぶん殴って終わりになるので、狙撃手という存在がいる理由もない。悪魔の実の能力者は攻撃射程範囲が短いわけでもないので、「狙撃ができる」というだけではアドバンテージは何もないし。
  • 料理を振る舞う必要があるのは非常に短い航海期間中と、島でボスをぶん殴って終わった後の宴の時のみ。コックが常駐する必要性もない。
  • 航海期間がほとんどないので、船が壊れたりする可能性もほぼなく船大工が常駐する必要もない。
  • 航海士も同様。
  • 楽家も同様。音楽家がいて良かったシーンとかあったっけ?
  • 操舵手も同様。
  • 考古学者なんてそもそもなんで仲間にしないといけないのかがわからない。どこか安全な場所にいてもらった方が良いだろう。

 

ほとんど必要のないメンバーが集合していることがわかる。必要性は皆無なのにやたらと仲間だけは多くてそれぞれ必ず何かの戦いに参加するので、無駄にページが割かれることになる。ワンピースの話が無駄に長い大きな要因だ。

 

例えばRPGで、街につくたびにそれぞれパーティメンバーごとに何かイベントがあって、それを一つずつクリアしないと次に進めない感じだ。クリアするのに500時間はかかることになる。

 

島から島へ移動するシーンもあるが、漫画の中では大半が「島に上陸した後」の話なので、彼らが本来の役割を果たすべきシーンもほとんどない。本来ならそれぞれ役割を持っているのなら余計な戦闘能力を与えるべきではないのだけど、島で上陸した後の騒動が治るまで非常に時間がかかるため、船で待機していると数年漫画に登場しなくなってしまう。そのため、本来不要な戦闘を航海士であるナミや船大工のフランキーを参加させてしまうことになる。

 

そもそも航海士であるナミや考古学者のロビンや音楽家のブルックが暴力手段を使って敵を倒したとして、なにか面白いだろうか。それ以上の暴力で物事を解決するルフィやゾロがいるのに彼らと同じ舞台に立ってそれよりも見落とりする内容で何かしても意味は薄い。考古学者ならではの知識を使って窮地を脱出するとか、音楽の知識や音楽を奏でることで何か起きる、とかならまだわかる。しかしやってることは個性の強い外見のメンバーが揃ってるが、実際中身は皆同じでやってることも同じでしかない。ワンピースの漫画がいつ見ても同じことを繰り返してるように見えるのもそのせいだろう。

 

 

おそらく今後も次の島に行っては全員参加しての延々バトルが続くのだろう。「ワンピースとは何か?」に興味を持ってる読者がどれだけいるかわからないが、果たして最終回でどうやって回収するのか。そこに驚きはあるのか....

 

 

Excelでドキュメントを作るのは、原始人並に文明が遅れてる

始まりの言葉

「え、いまだにGoogleSpreadSheetなんかでドキュメント(テスト設計)書いてるの?原始人じゃないんだから!これは早急に対処が必要だぞ〜〜〜」

 

これは我がQAチームの管理者が発した言葉です。それまで当たり前のようにテスト設計をGoogleSpreadSheetで作成していた自分からすれば青天の霹靂でした。GoogleSpreadSheetでテスト設計するのは猿並みの文明人の所業なのか?

 

 

ドキュメントツールあれこれ

SESでシステム開発の仕事に従事していた頃、設計書といえば「Excel」で作られたものが大半だった。要件提議書・基本設計書・詳細設計書・テスト仕様書・バグ管理票...またはWBSなどのスケジュール管理系についても。要件提議書についてはWord文書だったりもするので、一概に全てExcleというわけでもない。

 

これらは印刷されることが前提で、書式もかっちりと決まっており書式からずれた記載であった場合などはレビューの場で設計内容よりも書式に合ってないことを真っ先に指摘を受けたりもした。苦い思い出だ。

 

基本的にこれらのドキュメントは「納品」するもので、データとしても残すのだけど、印刷して物理的に保管されることも想定していたと思う。だいたいプロジェクトが終わるか、その途中でプロジェクト先から退場することが多かったので、その後どうやってドキュメント類が運用されていたのかがあまり分かってない。もし保守やフェーズ2に関わるようなことがあれば、ドキュメントを参照することもあったのだろうとは思う。

 

2021年現在、今のSES先では設計書のベースになるのはConfluenceといったWEB上で作成するツールだ(GoogleSpreadSheetもWEB上でドキュメントを作っているけど)。コンフル(エンス)の何が便利かというと、WEB上に格納することで「キーワード」で検索することが容易という点。Excelベースのドキュメントもファイルサーバに格納したりすることでWindowsのファイル検索などで検索をしていたが、それよりもだいぶ検索した時にキーワードが引っかかるので、目的のドキュメントにたどり着きやすい。

 

何より「印刷することを目的にドキュメントが作られていない」のでプロジェクト内容やその記述目的によって柔軟に設計の記載が行える点が良い(記載レベルが統一されていないことで理解しやすい、理解しにくいの差が顕著だったりするので、この辺は運用ルールというかある程度指針が必要な気はしている)。

 

Excelの時のように、いちいちページの上部と下部にページ設定やドキュメントタイトルなどをしなくて良いのだ。タグを貼り付けることで関連するドキュメントをひとまとめに管理することも可能だし、ドキュメント間の繋がりをURLを貼り付けることで対応することができるのでスマート。

 

 

じゃあ全てのドキュメントをConfluenceに移行したかというとそうでもなく、テスト設計中のテストアプローチとして機能一覧を抽出するときや、テストケースの作成にはバリバリExcel(=GoogleSpreadSheet)を使っている。なぜか?冒頭の管理者の発言に対しては以下のように意見を述べている。

 

「表形式で項目を作る時にはやはりExcel形式のドキュメントの方が使いやすいからというのが大きな理由。コンフルはどちらかというとWordタイプのツールなので、表形式も使えないわけではないが本職ではなく、そこは使い分けをしている。」

 

全てコンフルで賄うことも当然可能だが、それだと「ツールを用途に合わせて使う」ではなく、「ツールに合わせて人間が工夫する」ことになる。Confluenceも使わず、Jiraでバグ管理を行わず、ということあれば批判も甘んじて受け入れるけれど、そうじゃない。特定のツールを使うことそれ自体が目的化するのは間違っている。移動するのに飛行機が便利だからと近所のスーパーに買い物に行くのも飛行機を使うのか?というのと同じだと思う。

 

個人的には現在WBS(WorkBreakdownStructure)としてGoogleSpreadSheetを使っているが、良いツールがあればそれに置き換えたいと考えている。探せば色々あるのだけど、それを選定して導入するというのはまた別の苦労がある...

 

 

 

 

 

引っ越しして1年経ったので感想

コロナによる影響で、自宅で仕事をせざるを得ない状況になり、ワンルームのアパートでは仕事もしにくいため引っ越しをしてから1年。引っ越ししてよかったこと・悪かったことをまとめてみたいと思う。

 

■以前住んでいたアパートのスペック

駅からの距離:徒歩4分

家賃:6万円台

広さ:1K(6畳)・庭(バルコニーより広い)付き

設備:風呂トイレが同じユニットバス式、冷蔵庫が備付け(ミニサイズ)、電気式コンロ(一口)

近隣の生活環境:良し

備考:壁が薄いため、隣の家の生活音が全て筒抜け、日差しほぼなし

 

ペット飼育可能物件でありながら、家賃6万円台で駅から近くアパートの周りに生活に必要なほぼ全ての施設が揃っていたので非常に便利だった。ただし、築年数が30年以上の木造2階建アパートで壁も薄い上に、日差しが取れる窓が一方向しかないのに隣接している戸建て住宅の影になっているため日中非常に暗かった(夏は良い)。風呂とトイレが同じ場所にあるタイプのユニットバスだったので、常に床が湿った状態だった。

 

本来洗濯機は室内に置けるようなスペースがあったが、そこを洗濯機の場所としてしまうと収納がないため、基本はコインランドリーを利用していた。また、冷蔵庫は備え付けの1ドアタイプ(シティホテルにありそうなコンパクトサイズのもの)だったため、食料品がほとんど入れることができず機能していなかった。

 

氷すらまともに作れなかったので、氷を入れて飲み物が飲みたい時は、スーパーなどで氷を買っていた。ファミリーパックのアイスは入れることが不可能だったのと冷蔵機能自体も貧弱だったため、アイスなど冷蔵が必要なものは「その日のうちに食べる」というルールだった。またキッチンも電気式のコンロが一口だけしかなかったので同時に火を使う作業ができなかった。そのためスムーズな調理を考えて作業するという習慣が身についた。例えばスパゲティを作るときなどは、最初にソースを作り、その後で麺を茹で、茹で上がった麺にソースを絡めればOK、というような。面倒だった。

 

また6畳のスペースで睡眠と食事をするのに精一杯で、仕事をするためのスペースを確保するのが難しい。本来「家で一日中仕事をするために選んだ物件ではない」ので、仕事のしにくさは仕方ないと思う。

 

■現在の住居のスペック

駅からの距離:徒歩12分

家賃:9万円台

広さ:2DK(5畳+6畳+ダイニング)の木造2階建ての一軒家

設備:風呂、トイレ別、洗面台、ガスコンロ(三口)、洗濯機は屋外設置

近隣の生活環境:まぁまぁ良し

備考:隣家と微妙に連結されてる箇所があり、隣家の振動が伝わり不快。動物病院が徒歩圏内になく、何かあった時に不安。

 

どうしても以前のアパートでは「仕事がしにくい」ということもあり、引っ越しを考えていたところ見つけた物件。以前のアパート設備のショボさに慣れきっていたことなどから、新居に関しては「ピカピカの立派な物件」であることは優先順位が高くなくて、

 

仕事に十分な広さ

風呂トイレは別

 

を重点的に物件探しをしていて、その中でも家賃とのバランスなどを考えて見つかった物件だった。とにかくスペースが欲しかったため、この物件の前にほとんど決まりかけていたのは「風呂トイレが同じユニットバス形式」の物件だった。部屋の作りがなんかおかしな感じではあったが「とにかくアパートより広い」ということで違和感はありつつ決まりかけていたが、戸建ての物件(今の住居)が見つかり内見したところそちらよりだいぶ良い状態だったので今の住居に決めた。ちなみにその決まりかけた部屋はその後1年くらいずっと空き家のままだった。

 

2DKということで、一つの部屋を仕事部屋として、一つの部屋を寝室として、そしてダイニングは食事の場所としてそれぞれ使えることで非常に快適。NUROの回線を引くことも出来たので、通信環境も整備されており不都合なこともない。木造なので2階は夏は暑く、また冬も普通に寒い、というのはある。

 

冷蔵庫は新たに買う必要があったが、ちゃんとした冷蔵庫があると「アイスがずっと溶けない」「氷を買う必要ない」「野菜や果物を冷蔵室に入れておけばすぐに腐ることがない」など大変便利だと実感している(本当に現代人か?)。また屋外設置ではあるが洗濯機が家にあることで、「必要な時に必要なタイミングで洗濯をすることができる」という便利さを実感している(本当に現代人か?)。これまでコインランドリーを利用してきたので、「なるべく費用節約するために、週に1回まとめて」というルールでやってきたが、晴れてさえいれば好きな時に洗濯機を回すことができるので、洗濯物が溜まりすぎて何度もコインランドリーと家を往復する必要がない。

 

コインランドリー自体、1回300円で洗濯して、10分100円くらいで乾燥機を回すという感じだった。すると大体1回の洗濯で5〜600円は使うことになる。週に1回ということは月に4回ということで大体1ヶ月で2000〜2500円くらいのコスト。数ヶ月程度なら洗濯機を買うよりいいと思うが、1年経過すると25000円を超える。そうすると中古でも洗濯機を買った方が良い感じになる(10年アパートで生活してたので、20万円以上をコインランドリーに費やしてたことになる計算だ)。1回洗濯機を回すときにかかるコストは100円もしないはずなので、初めから買っておけばよかった、とちょっと後悔した。ただ、実際問題として以前のアパートでは「置く場所がなかった」ので仕方ない。

 

キッチンは備え付けのガスコンロ(三口)があり買う必要がなかった。電気(ガスと変わらない強さのIHなどとは違う、電気でジワジワ熱くなるタイプのもの)コンロと違い、火力があるので、お湯はすぐに沸かせられるし、鍋を同時に複数使うことができるので非常に便利。アパートにはなかった魚焼きグリルもあるので、魚介類を焼きたいと思ったらフライパンじゃなくて焼くことができるのも良い(あまり頻繁にはないが)。

 

風呂とトイレが別なのも良い。風呂の中で「体を洗う」「頭を洗う」という習慣からやっと脱出できた。風呂の中で体を洗うと風呂水が汚れるので嫌だったが、それがなくなったのは嬉しい。自動で湯張りや保温などの機能はないがなくても問題ない。

 

以前のアパート周りの生活環境は非常に優れていて、スーパー、コンビニエンスストアレンタルビデオショップ、中古ゲームショップ、100円ショップ、銀行、病院、図書館、銭湯、それと買い物に便利な商店街、美味しいお店が徒歩10分以内に全てあったため引っ越すのが10年かかった(服など地元では買えなかった)。特にスーパー、コンビニは徒歩1分以内のところにあったため、ほとんど冷蔵庫がわりだった気がする。

 

今の物件は駅から商店街を通って12分程度かかる。スーパーはいずれも徒歩10分圏内、コンビニは5分以内、病院は揃っている、銀行はあるがメインバンクではないため手数料がかかるのがネック、図書館は歩いて20分くらい、食事も「そこそこ」と言った感じでめちゃくちゃ贔屓にしたい感じはない。プールが近いのは良いが何故か全く行ってない。レンタルビデオショップがないため、週末の映画視聴の習慣がなくなった。アマゾンプライムなどでもいいが、できれば棚から選びたいし、レンタルショップなら1週間借りても100円だったりするので、安かった。全体的に環境は60点、という感じ。必要なものが揃ってそうに見えてそうでもない及第点という感じ。

 

比較すると住居自体の快適さは比べようもないくらい差があるが、家の周りの環境以前の方が良かった、という感じだろうか。なので、可能なら以前のアパート付近で今の住居レベルの物件があれば最高なのだが。

 

もし、コロナが広がってなければどうなっていただろうか?自宅を仕事で使うこともないから多分引っ越ししてなかったような気がする。洗濯機も冷蔵庫もない不便な家だったが、それを不便なことであると強く認識してなかった気がする。

 

パソコンを開くテーブルは狭く小さい。ノートパソコンを開けばいっぱいになるので、同時に本を開くことすら難しかった。その本がしまってある本棚も、本を出し入れする機能が失われていた。以前のアパートは部屋が狭すぎたため、本棚に物を詰めまくっていたからだ。縦に並べた本の上に横に本がぎゅうぎゅうに詰め込まれていて、本を出して読むということができなくなっていたので、ほとんどの本が死んでいた。今の家は部屋の広さが十分あるため、本棚を3台おけているので本棚の本を出し入れが普通にできる。いらない本は断捨離できたし。

 

こんなことを言うと語弊があるが、「コロナのおかげで環境を強制的にでも変えることができた」という感じだ。ランニングコストである住居費は1.5倍になったが、住居の快適性はそれ以上だから良かったと思う。それに快適に仕事ができることで、収入も安定して(個人事業主だけど)、貯蓄も貯まってきた。仕事ができているのは住居のおかげというよりコロナにより自宅で仕事することで「遅刻がなくなった」ことが要因だと思うけど...

 

結果的に引っ越して良かったと思う。いまだに住んでる街が地元、という感覚は薄いけど...。もしリモートワークしてて「どうしても今の住環境じゃ厳しい」かつ「引越が容易にできる」という人がいれば、引越することを考えた方がいいかもしれませんよ。

 

 

 

【ソフトウェアテスト】全部はテストできない問題【QA】

QAという立場になってしばらく経つ。いわゆるソフトウェアテストの検証専門の仕事だ。開発職から離れてテストエンジニアとして業務をしてから本当に思うのだが、時間が限られている中では当然テストできる範囲というのも限られる。一定の期間で優先度や重大度を見極めてまず優先的に消化するテストを行い、また優先度や重大度を下げたものを消化する。そして、テストが終わればそれら結果を判定してリリースに持っていくかどうかを決める。

 

この「できるテストは限られている」という根本は崩せないのだが、場合によっては優先度や重要度を度外視してテストを増やさないと気が済まないことがある。それは理論的というよりも心理的な要因でテストケースを増やしたくなる。どういう時か?というと、自分が関わった過去のQAのプロジェクトで残存バグが見つかった場合だ。過去のプロジェクトで「対象外」としていた箇所(もしくは「対象」としていた箇所)からの残存バグが見つかった場合、「見過ごしていた」ことになり、その経験から「次のプロジェクトでは見過ごさないようにしよう」という心理が働き、テスト対象を広げてテストケースを増やすことになる。

 

業務仕様が複雑かつプロダクト対象がWEBアプリ、API、Mobileなど多岐にわたる場合そもそもテストケースは膨らみがちだが、なんにせよ時間が有限で見積もり段階で工数を出しているので、テストケース設計段階であれもこれもとテストケースを追加していては、期日に間に合わない。期日に間に合わないとどうなるか?

 

QA完了予定期日に間に合わない

リリースの遅れ

(開発自体に問題なかった場合)「QAは何やってんだ」

QAチーム自体の評価下落

 

このようにQAチーム自体の評価下落につながることになり、よろしくない。特に開発をしているわけでもなく、ビジネス要件を決めているわけでもないQAは、期日内にきちんとした評価をどれだけ出せるか、パフォーマンスが見定められてるので、根拠もなしに「気になるのでテストケースが増えちゃいました」で期日が延びるのはチーム自体の存続に関わる。

 

見積もった工数を提出した段階(要件がある程度まとまっている段階で工数を出すと思う)と、実際にテストケース設計するときに見積もり段階ではきちんと見えてこなかった確認観点が出てきて工数が膨れ上がることはややあるため、そのあたりはPM(プロジェクトの管理者)との相談にはなると思うが、相談もなしにどんどんケースだけが膨れ上がるのは良くない。PMは出された工数の範囲で仕事が終わるだろうと当然思っているので。

 

逆に、PMや開発側などから「ここもテストしてください」などと要求が追加されることもある。その場合は当然追加工数に加えて良いと思う。

 

※なんとなく書いてみたエントリーだったが、タイトルと内容が一致しているか?

 

 

 

【UIテスト】クソみたいなテストケースを設計してたので反省している

これまでSEとしてシステム開発の現場でコーディングと共に単体テスト(UT)や結合テスト(IT)もやってきたが、これこそがテスト設計の本質、というようなものが自分の中ではっきりなかった気がする。客先常駐での期間の短さもあるし、現場ごとに「やり方」が異なるというのもあるし、最大の要因は自分の中で考えて設計してなかった、ということだと思っている。ただ単に日々のタスクというかノルマというかそういったものを消化することが念頭にあり、良い設計とは?という意識がなかったと思う。

 

「じゃあ今は『良い設計とは何か?』という意識のもとでしっかりテスト設計できているのか?」と言われると正直「できてません」と答えてしまう状態。徐々にそういう意識が芽生えつつある、という感じ。

 

芽生えつつある、というか必要に迫られてそういう意識に切り替えてる、という方が近いかもしれない。きちんと設計されていないテストケースをベースとしてチームでテストを実施すると、「実施できない」「確認内容が不明」などテスト実施中に中断して確認作業やテストケースの修正などで時間が取られることが増えたからだ。

 

少しでもそのような余計な時間を取られないためには「実施するにあたってテスト実施以外で時間を取られないようにしよう = だったら最初から良い設計をしておこう」という認識にならざるを得ない。

 

異常なテストケースを疑問に思わない

今のSES先にQAエンジニアとしてアサインされて、テストケースを確認したときに、こんなテストケースでも疑問に思わずにテストを進めてしまっていた。

 

f:id:starscream1999:20210710215328p:plain

悪い見本

だいぶ記述を端折ってはいるけれど、このようなテストケースが当たり前のように使われていた。ログイン画面に対して、IDとパスワードをそれぞれ入力し、次の画面に遷移してその画面の表示を確認するというような感じのテストケースにはなっている。どのあたりがテストケースとして正しくないかわかりますか。

 

このテストケースを一目みて、違和感を覚えることがQAというかテストエンジニアとしての第一歩かなと思います。ちなみに私は、このケースに違和感を覚える前に「こういうものか」と納得してテストを実施してしまっていました。程度が知れますね。

 

こんなケースが1年くらい前まで散見されたのが今のQAチームだった。これでは良いテストにならない。

 

それでは、どこが正しくないか見ていきましょう。

 

期待値があいまいなテストケースはとにかくダメ

「XXXXが正しいこと」という期待値はやりがちなのだけど、テスト設計者の意図とテスト実施者の意図が一致してれば良いだろうけど大概一致しないので、期待値としてはダメな記載です。何を持って正しいと判断するのか、を判定できないため。

 

ちなみに今のSES先のテストケースにはこのような記載がめちゃくちゃ散見されていた。それについて「これではきちんとした確認ができないのでは?」と主張すらしていなかったので自分も当然同罪だし、実際に設計時に「XXXが正しいこと」と期待値に記載していた。疑問には感じてはいたが、「妥当性をきちんと書くと手間が増える」という滅茶苦茶な理由でそのままにしていた。情けない話である。これでベテラン顔していたのだから始末に負えない。

 

別の話題になるけど、「XXXが表示すること」「XXXが表示されること」などの表現の差異に時間を取られるのは馬鹿馬鹿しいと思ってる。システム側が表示するので「表示すること」が正しいというのはわかるが、別にそこを「表示されること」と記載したとして影響はない。こんな指摘は設計書の文字サイズが揃ってないとかの指摘と同じだと思う。

 

実施手順が書いてない

そんなテストケースあり得るのか、という感じだが、あり得たというかそんなテストケースでテストを実施していた。「なぜテストケースに実施手順がないのだろう」と疑問に思わなかったのだろうか?「ここの現場はそういうやり方なのだな」という意識だったと思うけど、それにしても手順がないことそれ自体に対して違和感を覚えるべきだった。言語道断だと今は思う。

 

では、実際にテスト実施手順が書かれていないテストケースをどのようにすすめていたか?それはもう単純に業務システムの仕様を覚えて、頭の中で実施手順を描きながらすすめていたのです。これが何を意味するか。つまり、業務システムを知ってる人でないと実施できないということ。

 

例えばその業務システムを知らない人に急にテストを実施してもらうことになっても、その都度「X画面はこのA画面でBボタンを押して、Cを入力すると〜」というようにいちいち説明することが必要になる、ということ。非効率極まりない。

 

実際に、「どこまでの粒度でテスト実施手順を書くか」という部分についてはテスト実施者のレベル(例えば昨日今日入ったアルバイトにもテストしてもらう必要がある場合など)を考慮して設定する必要があるだろう。ただ、どのような場合でも「テスト実施手順が書かれていない」というのはあり得ない。

 

 

テストタイトルが同じものがいくつもある

例えば同じ画面内で同一項目の複数のテストを実施するにあたって、「X画面_Y項目」というタイトルのテストケースが並んでいたらどうだろうか。実施者は期待値や実施手順、前提条件などを見比べて異なるテストケースを実施していることを確認しなくてはいけない。

 

設計者の怠慢という部分もあるだろうが、設計時にどんなことを確認するテストなのかを端的に書けないというのはテストの期待値を誤っている可能性も出てくる。どんなことを確認するかわかっていないのに期待値をきちんと書けるだろうか?

 

同じ表示系の確認であっても単に数値が表示されることを確認するのか、計算結果を確認するのか、計算結果に例外が起こることを確認するのか、パターンは考えられる。

 

テストタイトルがない、単に「10A-1」というような管理番号でテストケースを管理する場合もあるだろうからテストケースタイトルをつける設計の場合に必要な意識だと思ってください。(シナリオテストとか)

 

また思い出したら続き書きます。