  |
はてなキーワード: システムテストとは
ブラックボックステスト (英: black-box testing)は、内部構造や動作を覗き見することなく、アプリケーションの機能を調べるソフトウェアテストの手法のこと。アプリケーションを見えない箱として扱い、入力と結果の整合性を確認する。このテスト方法は、ソフトウェアテストのすべてのレベル（単体テスト、統合テスト、システムテスト、受け入れテスト）に適用できる。仕様ベースのテストと呼ばれることもある[1]。
「ブラックボックス？飛行機に付いてるやつ？」という反応が多かった。
ドッグフーディング (英: dogfooding) または「自社のドッグフードを食べる」「ドッグフードする」(Eating your own dog food、Drinking your own champagneとも言う)は、コンピュータ業界において、自社製品を開発して利用する組織の習慣で[1]、組織が実際の使用法で日々自分たちで製品を利用しながら製品テストを行うことである。日本語では単に「ドッグフード」ということもある。そのため、ドッグフーディングは品質管理として機能し、開発者自身による製品の自信を表す証言広告となる[2][3]。尚、日本企業では自社実践(じしゃじっせん)という言葉が相当する意味の言葉として使われている。
今朝、某ブックマークサイトにて大手SIerにおけるクソ設計書について少しばかり話題が盛り上がった。
SIerのシステム開発方法や、所謂「炎上案件」というのは具体的にどういうことなのか、できる限り思い出して書いてみたいと思う。
所属したプロジェクトは3件で、1つ前に所属したプロジェクトはコロナ騒動の直前の2020年1月である。
これを読んでいる人の中には、私よりも玄人なSE、もしくはPMがいるかもしれない。
手持ちのサンプルが少ない故に「ちげーよ！」ということもあるかもしれないが、そこは大目に見ていただけると幸いだ。
まず、ITに携わるシステム屋とはいえ、SIerとベンチャーWeb系は規模と客層も違うし、開発手法も違うと思われる。
開発手法というのは、「ウォーターフォール（各工程を最初から着実に終わらせる手法）」、「アジャイル（短い機能追加を繰り返していく手法）」が一般的にも有名だと思う。
開発手法には「ウォーターフォール」のさらに上の「メテオフォール」というのがある。本気の炎上、アジャイルのようにウォーターフォールする開発という意味だ。
（何を言っているのかわからないかもしれないが、私も何を言ってるのかわからない。https://eiki.hatenablog.jp/entry/meteo_fall）
多重下請けに所属しているSEが「メテオフォール」をかけられたら、もう刃傷沙汰にでもならないと逃げられないと思っていい。
炎上案件のSIerの客層は、金融系・公共インフラ系がほとんどだ、7割そうだろう。（※適当）
自社開発系はさておき、受託Web系やパッケージベンダ系の客層は、小規模案件のプロジェクトもある程度あると思う。
金融・公共インフラ系はべらぼうに規模がデカい。馬鹿みたいな工数が掛かる。
【要件定義 ＋設計開発UT＋結合テスト＋システムテスト＋ユーザー受け入れテスト＋システム移行】 ＋追加要件開発（保守運用）。
大雑把に言うと、「ちょっと顧客情報DBを参照してWebに表示させるシステムが欲しい」として受注した場合、約4000万円がお会計となる。
現行システムのリプレイスだとしても、2000～3000万円はかかる。高い（※謎仕様の現行システムだと炎上不可避案件となりさらに膨れ上がる）
当然、数千万円案件となるとプロパーの社員では人手が足らなくなる。
すると登場するのが「派遣社員（SES）」あるいは「下請け」というシステムだ。
会社によって異なるが、だいたい4～9割が「派遣」や「下請け」の割合となっている。
それでも工数不足になってしまったプロジェクトは、そこから鬼出勤をカマす。
納期を過ぎたらさあ大変、開発経費・損害賠償がSIerの自腹になってしまう。
それで最初に書いた「ウォーターフォール」ってのは何なのか？ってことになる。
「ウォーターフォール」＝「各工程（要件定義、設計、テスト）で客の承認を得て合意を握った上で着実にマイルストーンを固めていく」
「何のために固めるのか？」＝「手戻りを起こさないため（白目）、責任を押し付けられないようにするために」
と、ここまで前置きを書いて疲れてしまったので、続く。
駄文失礼。
設計書を読んでプログラムを書くにも、その設計の前提知識の理解がないと進まない
たしかにその期間で業務仕様はある程度頭に入った、けれど理解には程遠い
その後は自分の担当機能の実装に必要な知識を、その場その場で掻き集めるといった感じ、全体の仕様理解なんてカケラもできない
その後の結合テスト、システムテスト、ユーザーテストの補佐、そしてリリース後の運用フォローときて、ようやく何を使っていたか、業務仕様の全体像を想像する程度にはなった
1年と少しかかった
振り返って思う
近々の自分の仕事に関わらない情報は説明されても頭にとどめて置くのは難しい
業務仕様についての2週間のトレーニングを1カ月、3カ月と増やしてもたぶん理解が大きく増えることはなかった
すぐに必要でない知識を大量に与えられても一定以上のものは受け取れないのだ
得た知識からなんらかのアクションを起こし（詳細設計、実装、テスト）、そのフィードバックがあることで、業務仕様理解が進むんだと感じている
例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。
「コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「２１００年に２月２９日はあるか」という処理までチェックするものです。」
リソースが無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。
極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。
ライブラリの単体テストでは、「２１００年に２月２９日はあるか」というテストを行うかもしれない。
しかし、結合テスト、システムテストとテスト局面が進むたびに、いちいち「２１００年に２月２９日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。
「２１００年に２月２９日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。
元号対応で、過去の帳票についてシステムテストを繰り返していたところ、明治初年のテストデータをパスしないバグが見つかった。
Javaのlocaldateが1968/1/1の深夜0時の場合、なぜか1967/12/31の23時41分くらいとなぜか19分ちょい絶妙にずれるため
mmSSを切り捨てる系の日付処理で1967/12/31で検索していることが原因だとすぐにわかったが、
最終的にきしださんのウェブサイトにて日本標準時が1880年を境に江戸城から現在の明石に変更していることを知った。
http://d.hatena.ne.jp/nowokay/20150109
有志が常にtimezoneの変更をJREに行っていることをついでに知る。
http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html
直近だと北朝鮮がつい先日の5月に標準時を変更したらしい。韓国=日本と同じ時間だそうだ。
2015年からたった3年間だけ使われたKorea Timezoneが韓国との融和をうたうパフォーマンスのために一蹴。
北朝鮮にシステム会社がどれだけあるかは知らないけど、中の人たちお疲れ様です。
有名どころで言えば、つい30年前までシンガポールが日本標準時のまま放置していたりしたそうだけど
Javaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。
詳細設計のことだ。
ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。
てか、そんな物を読むくらいなら、現物のソース読めよって話だ。
だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。
何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。
「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。
それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。
でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。
負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。
なんでそんなに「日本語訳」が欲しいの？
もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。
そして元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。
それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。
とはいえ、別に何も「真実はソースただ一つ！」なんて言うつもりはない。
ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。
ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。
そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。
ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。
Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。
CTC → A社の発注が 5000万で、B社に丸投げだったら、2500万くらいだろう。
A社のCTCへの見積もりは、見積単価が 120万/人月（ちょっと安いか？）で、40人月くらい。
A社の原価率を85% として、原価が 34人月。
B社の単価を 80万/人月としたら、マックスで 2720万。
多少駆け引きがあって、2400～2500万ってところが妥当では。
・ニトリは内製っぽいけど...
ニヨニヨするとか言われてたページには、こんなコメントが入ってる。
＜!-- Customize for NITORI start--＞
＜!-- Mod for Nitori End --＞
WebSphere をミドルウェアに決めたときに、カスタマイズも発注してたことは十分考えられる。
「これは仕様通りです」とかなんとか、そんなやり取りをいっぱいしたんだろうな...
・ベータ版なんて作らない
ウォーターフォールで一直線。
ニトリ社のレビューというか、受け入れ試験があったとして、そこで出されるのは
完成品、もしくシステムテストがある程度残っている本物。
リニューアルオープンが延期したのは、本当に間に合ってないだけ。
6月1日が延期したのも、ろくに動くようなものじゃなかったんじゃないか。
リニューアル後の性能問題も、何だかんだで一週間で復旧できたわけだし。
・表に出ないだけで...
ふわっとした仕様書を杓子定規に実装した、というよくあるパターンな気がする。
別ウィンドウで表示される「リニューアルオープンの遅れに関するお詫び」にまで販売サイトのヘッダ、フッタがきっちりと表示されている。
http://www.nitori-net.jp/store/ja/ec/%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B6%E6%9C%8823%E6%97%A5
この硬直さもウォーターフォールっぽい。
css がど真ん中に挿入されているのも、さもありなん。
職場で上司とハイタッチをしてしまった。相手は一回り上のPM。
フィジビリティ調査とは、システムの実現可能性を調べることを指すけれど、
PMは、多分プロトタイプ開発によるCIを狙ってるのだと思う。
典型的なウォータフォール開発がメインの業務プロセスにあって、
80%→120%への細かい微調整とレベルアップを可能にする。
設計書の山に、エクセルスクショの貼付けも健在ではあるけれど、
現物があるので、机上でデバッグを繰り返すよりよほど楽だし、そんなに辛くはない。
最も、表立って工数は積めないから"調査"の範囲内である程度動くものを求められるわけで、
異常系の処理に全てTODOを書き込んで、ワンパスを通すことに腐心する。
本来のプログラム行程はリファクタリング機能の呼び出しとコメントの追加が
主な作業だけど、致命的な欠点が見つかってロジックをごっそり変えたことはないから
火事場の馬鹿知恵は、便器の上でうなり続ける時間に匹敵するのだろう。
先日、朝の進捗の打ち合わせでお客様から出た業務アプリの改修案件について、
いつものように、とりあえず調べてみようよということになった。
システムテストまで含めて2.5人月かかるよと試算は出ていたが
俺とお前なら1週間かからないんじゃねえのとPMはこっそりうそぶく。
席に戻ったら、割り込みで申し訳ないけど、と他のメンバーに謝って
今日のお題は、QRコードを取得している箇所でバーコードも使えないかという相談だ。
QRコードを開発したのは日本人だよと、トリビアから始まった会話の中で、
そういえば、と過去に行ったシステムテストで見つかったインシデントを話す。
バーコードを読んでいる箇所でふざけてQRコードを読み込んだら
通ってしまったので慌ててバリデーションチェックに追加したんですよと。
もしかしてバーコード関係のAPI(GoogleのZxingをラップしたもの。他社開発)って
あまりその辺を意識しなくていい？あ、やっぱりそうだ。今日中に終わるかもねみたいな流れから
Bluetooth機能のIF追加などやらなければ行けないことが決まって大雑把に機能分担して
コーディングに入った。
Dドライブ下に同じドメイン配下の共有フォルダを置いてやり取りをする。
ここどうすればいい？みたいな質問をお互いのモニタを見ながら2,3回やって
ほぼ同時に作業が終わったので、二人で個別に組んだコードをマージする。
初ビルドはエラーもなく、すぐに終わった。アプリを立ち上げた後、
テスト用のバーコードやQRコードはお互いに用意してくれているだろうと無言の目線を交わす一幕も。
上司が両手を上げる。普段空気が読めない自分が、何故かこの時は自然に手が出た。
普段表情が硬いメンバーの女性がクスクス笑っていたのでよほどテンションが上がっていたのだろう。
結果として、3週間PGに時間を取るはずが、半日かからずに終わってしまった。
別の作業に戻った後も、やり遂げたという高揚感にその日はずっと酔っていた。
上司はいつも笑っていて、仕事を楽しくさせることに努力を惜しまない人だ。
同じ会社だし、お会いする機会、仕事をする機会もまだまだあるのだろうが、
その時は今の距離感は許されないだろう。
短期で人が入れ替わり立ち替わりが当たり前の職場で
自分はどこか人間関係も段々ドライに捉えるようになっていたから、
今はただこの寂しさに慣れない。
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
歴史のあるサイトだったりすると読んでも意味の分からないユーティリティ的なセレクタがよく出てくる。
こういうのが現実。
page.has_selector?(:xpath, '//table.tokushu1/tr.header/td[3]/div/div//span.click_left')
しかもA/Bテストが始まったりしてテスト書く負荷が高くなりメンテできなくなる。
試験業務中心だった。
その中でもシステムテストとかやったりしてるのでネットワークやサーバー、アプリは商用の状態に近い環境で試験をしている。
具体的にはサーバーはLB使って冗長化/スケールアウトされていたり、クラスタリングされていたり、データセンターにあるサーバーにリモートでログインして試験をしたりとか。
rebootコワイヨーとかHW障害うざいよーとか思いながら。
ソフトウェアの受託開発の会社で、Javaの業務アプリを設計・開発・試験していた様な人達が集まっているので、ネットワークやLinuxなどアプリよりは低レイヤなところに詳しい人が地味にいなかった。
システムテストの項目書をExcelで作るお仕事や、試験を実施するお仕事は凄くやる気しなかったが、試験の実施方法を検討するお仕事や、試験をするための環境を構築したり、仕様書を読んでミドルウェアやアプリにコンフィグを投入する仕事は楽しかった。コンフィグを投入する作業をスクリプトで怠惰に自動化したりするのは、けっこー楽しかった。
リグレッションテストや、バージョンアップでの改修テストなどで環境を再構築する際に、作成した自動化スクリプトは腐らさせずに誰かに展開することが出来たので、自動化した工数も無駄にはならなかった（ちゃんと効率化に！）大量にデータを投入するとき、さすがにだるい。ツールも使えば使うほどバグなくなるし良い感じ。PerlやBashを覚えるきっかけにもなるし。
今思うと出向も楽しかった！メーカーSIの会社は社員食堂とかあったので、うわすげぇドラマみたい！とか朝はエレベーターの前に人が並ぶのでうわすげぇ人多い！とか。（最初だけだけど）
後はサーバー室でサーバーとかLBとかを目の前で見れたのがテンション上がった。うわこれF5じゃね？うわこれJuniperやん…いくらすんだよ…HPのブレードサーバーだ！いくらするのかググった。
まぁ、普通に誰も興味示さないw あの時は商用ネットワーク機器という物に憧れている少年だったw
作業で疲れたときはぶらぶらして眺めてた。
何かの見学の時は「おいふらつくな」とか誰かに怒られそうだけど、仕事で来てると誰も何も言わないので見たい放題。転んでケーブル抜いた日には大問題になりそうなので、さすがにそこは気をつけた。
あの1UサーバーにRHELをインストールするとか、少年には楽しすぎた。でも手順はMacのVirtualBoxにCentOS入れるのと変わりはなかった…。ただ、仕事として1UサーバーにRHELをインストールした、という経験を持つことが嬉しかった（少年だから）
でもいいさ。
F5なんか使わずにLVSやUltraMonkey-L7で負荷分散すればいいし、商用のアプライアンス機器なんか使わずにオープンソースで解決してしまおう。AWS使うならELB使えばいいし。そういう環境行ってみようぜー。
多分http://anond.hatelabo.jp/20091010232609
システムテストに関してはhttp://anond.hatelabo.jp/20091010210506
で書いている通り
その修正が呼び出してる20機能に必要な修正なら、20機能全部でデグレード試験し直しは必要。
で、修正が必要な１機能しかデグレード試験しなくてよいと思っています。
私が言いたいのは
どのような共通化を行うか（共通関数をつくるか）内部設計書に宣言させて(して)、
責任者（そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間）とレビューして、
そのプロジェクトではどのような共通化が適切であるか合意をとるべきだということです。
合意とった内部設計書とおりに実装していなければ（勝手に新たな共通化関数つくっていれば）、
そもそも内部設計書に誤りがあれば、
まず疑うべきことはひとつ。
指定したドメインからのメール以外をシャットアウトするようにしているので、
そのせいでメール送れてないんじゃないのか。
登録するときに送るメールのFromと、ICカードにかざしたときに送るメールのFromが違うとか。
あと、
「事前にシステムに加入したユーザが、お財布ケータイを街角にある読み取り機にかざすと、
登録されてるアドレスにメールが届いて情報が得られる、というシステム」
このシステムだけならイケてる奴なら仕様が固まってさえいれば2週間くらいで作れるから、
少なくとも開発現場にはそんなに大金は降りてないと思う。
