「システムテスト」を含む日記 RSS

はてなキーワード: システムテストとは

2020-06-16

オワコンSIerについて①

今朝、某ブックマークサイトにて大手SIerにおけるクソ設計書について少しばかり話題が盛り上がった。

SIerシステム開発方法や、所謂炎上案件」というのは具体的にどういうことなのか、できる限り思い出して書いてみたいと思う。

ちなみに、私は通称SE」で、SE歴は3年。

所属したプロジェクトは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の自腹になってしまう。

というのが、ここまでがSIer説明

それで最初に書いた「ウォーターフォール」ってのは何なのか?ってことになる。

ウォーターフォール」=「各工程要件定義設計テスト)で客の承認を得て合意を握った上で着実にマイルストーンを固めていく」

「何のために固めるのか?」=「手戻りを起こさないため(白目)、責任押し付けられないようにするために」

じゃあどんな手法で?なぜ工数が膨らむのか?

と、ここまで前置きを書いて疲れてしまったので、続く。

駄文失礼。

anond:20200615195109

2019-08-12

設計書を読んでプログラムを書くにも、その設計の前提知識理解がないと進まない

なので業務仕様説明理解のための時間は予め取られていた

しかにその期間で業務仕様はある程度頭に入った、けれど理解には程遠い

その後は自分担当機能実装必要知識を、その場その場で掻き集めるといった感じ、全体の仕様理解なんてカケラもできない

その後の結合テストシステムテストユーザーテストの補佐、そしてリリース後の運用フォローときて、ようやく何を使っていたか業務仕様全体像想像する程度にはなった

1年と少しかかった

振り返って思う

近々の自分仕事に関わらない情報説明されても頭にとどめて置くのは難しい

業務仕様についての2週間のトレーニングを1カ月、3カ月と増やしてもたぶん理解が大きく増えることはなかった

すぐに必要でない知識を大量に与えられても一定以上のものは受け取れないのだ

得た知識からなんらかのアクションを起こし(詳細設計実装テスト)、そのフィードバックがあることで、業務仕様理解が進むんだと感じている

2019-04-29

自分が知っているIT系修羅場

消費税導入

自分の同期は新卒からの配属初日徹夜したとか言っていた

国税庁KSKシステムでもデスマってた

汎用機の開発でソースコンパイルだけでも30分まちだったとか

アローダイアグラム上ではシステムテスト中の日程にコーディングしてたとか

基礎年金番号

年金バラバラだった年金番号を統合するというシステム

議案が検討されている段階で開発に入ったらしいがデスマ

2018-08-11

http://blogos.com/article/317015/

例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。

コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。」

テスト実施には、時間費用人材などのリソース必要だ。

リソース無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。

極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。

また、テストには局面というものがある。

「日時を扱う」処理はライブラリにするのが普通だ。

ライブラリ単体テストでは、「2100年に2月29日はあるか」というテストを行うかもしれない。

しかし、結合テストシステムテストテスト局面が進むたびに、いちいち「2100年に2月29日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。

「2100年に2月29日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。

2018-05-24

anond:20180524173835

元号対応で、過去の帳票についてシステムテストを繰り返していたところ、明治初年のテストデータパスしないバグが見つかった。

なんの帳票なんだそれ?

標準時の変更がもしも日本であったら。

元号対応で、過去の帳票についてシステムテストを繰り返していたところ、明治初年のテストデータパスしないバグが見つかった。

Javaのlocaldateが1968/1/1の深夜0時の場合、なぜか1967/12/3123時41分くらいとなぜか19分ちょい絶妙にずれるため

mmSSを切り捨てる系の日付処理で1967/12/31検索していることが原因だとすぐにわかったが、

なぜ19分ずれるのか、そもそも理由がわからない。

Javaか、Javaバグなのか?

最終的にきしださんのウェブサイトにて日本標準時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年前までシンガポール日本標準時のまま放置していたりしたそうだけど

この辺を簡単に変更できるのは独裁の特徴かしら。

海外で働くエンジニアにTimeZoneで悩まされた経験があればぜひ聞きたい。

2017-03-07

http://anond.hatelabo.jp/20170307213829

設計書が悪いだけじゃないか

要件定義資料とかで全体がわかるビジネスルール業務フローかいった資料で、

どんな業務が想定されてて、担当機能がどういう役割になってるとかわかる資料ないのかな。

あとはシステムテストで一連の作業やって、覚えるしかないような気がするけど

2016-11-05

なぜソースじゃなく詳細設計を欲しがるのか

Javaを始めとするオブジェクト指向言語による開発になると、設計手法も従来とは大きく変わる。

その結果、不要になるドキュメントが出てくる。

詳細設計のことだ。

ここでいう詳細設計とは、本来コード記述する処理を、逐一日本語で書き下したものを指す。

てか、そんな物を読むくらいなら、現物ソース読めよって話だ。

だいたい、ソースに書くレベル粒度記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。

何よりソース修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。

「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEPGという人種が、実質同じ内容を何度も書きたがるわけがない。

それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テストシステムテスト以降で、そんなことをしている余裕など現場にはない。

結果、実装と合ってないドキュメントけが放置されてしまう。


でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。

負担ばっかり増えて、尚且つ無意味作業やらせるなって感じ。

なんでそんなに「日本語訳」が欲しいの?

ぶっちゃけソースコードレビューでいいじゃん。

もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。

そして元請はITプロなんだからソースなんてスラスラ読めて当然なわけで。英語読めない英語専門家存在しないのと同じ理屈ね。

それこそ読み取り専用でリポジトリアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。


はいえ、別に何も「真実ソースただ一つ!」なんて言うつもりはない。

ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。

ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。

そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソース問題箇所を探し回る苦労から解放されるのだ。

ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソース確認すればいいと。

Javaだったら、ユースケース図、アクティティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドソースを読めばいい。

逆に言えば、記述粒度が同じ成果物は2種類以上も要らない。整合性を保つための手間が増えるだけなので。

詳細設計書は不要というのはそういうことだ。

つーか「ソースが読めないか日本語訳を渡せ」とか甘えんな

2015-06-25

http://anond.hatelabo.jp/20150624204147

・仮に、丸投げ構造想像した通りだったとしたら...

CTC → A社の発注が 5000万で、B社に丸投げだったら、2500万くらいだろう。

A社のCTCへの見積もりは、見積単価が 120万/人月ちょっと安いか?)で、40人月くらい。

A社の原価率を85% として、原価が 34人月

A社は、B社の見積もりを 34人月までは許容。

B社の単価を 80万/人月としたら、マックスで 2720万。

多少駆け引きがあって、2400~2500万ってところが妥当では。

ニトリは内製っぽいけど...

IBM系列ソフトハウスも関わってるのだと想像

ニヨニヨするとか言われてたページには、こんなコメントが入ってる。

<!-- 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 がど真ん中に挿入されているのも、さもありなん。

フッタのメニューなんか幅に応じて三段階に切り替わって、普通には作り込まれているのに。

2014-08-16

職場上司ハイタッチをしてしまった。相手は一回り上のPM

そんなことが許される今の雰囲気が、とても楽しい

PMの口癖はフィジビリティ調査だ。

フィジビリティ調査とは、システムの実現可能性を調べることを指すけれど、

PMは、多分プロトタイプ開発によるCIを狙ってるのだと思う。

典型的なウォータフォール開発がメインの業務プロセスにあって、

フィジビリティ調査という名目ドキュメントの山を飛ばして、

とりあえず何でも先に現物を作ってしまうことで、

使用感や見た目等の非機能要求を洗い出しながら、

80%→120%への細かい微調整とレベルアップを可能にする。

設計書の山に、エクセルスクショ貼付けも健在ではあるけれど、

現物があるので、机上でデバッグを繰り返すよりよほど楽だし、そんなに辛くはない。

最も、表立って工数は積めないから"調査"の範囲である程度動くものを求められるわけで、

プロトタイプを開発している間は時間に追われること必死だ。

異常系の処理に全てTODOを書き込んで、ワンパスを通すことに腐心する。

メソッド名は悩んでいる暇はないからほとんど直感だ。

本来プログラム行程はリファクタリング機能の呼び出しとコメントの追加が

主な作業だけど、致命的な欠点が見つかってロジックをごっそり変えたことはないから

火事場の馬鹿知恵は、便器の上でうなり続ける時間匹敵するのだろう。

先日、朝の進捗の打ち合わせでお客様から出た業務アプリの改修案件について、

いつものように、とりあえず調べてみようよということになった。

システムテストまで含めて2.5人月かかるよと試算は出ていたが

俺とお前なら1週間かからないんじゃねえのとPMはこっそりうそぶく。

席に戻ったら、割り込み申し訳ないけど、と他のメンバーに謝って

該当機能調査PMと二人取りかかった。

今日のお題は、QRコードを取得している箇所でバーコードも使えないかという相談だ。

調査に取りかかる前に雑談をするのが最近の流れだ。

QRコードを開発したのは日本人だよと、トリビアから始まった会話の中で、

そういえば、と過去に行ったシステムテストで見つかったインシデントを話す。

バーコードを読んでいる箇所でふざけてQRコードを読み込んだら

通ってしまったので慌ててバリデーションチェックに追加したんですよと。

もしかしてバーコード関係API(GoogleのZxingをラップしたもの。他社開発)って

まりその辺を意識しなくていい?あ、やっぱりそうだ。今日中に終わるかもねみたいな流れから

Bluetooth機能のIF追加などやらなければ行けないことが決まって大雑把に機能分担して

コーディングに入った。

コーディングペアプログラミングだ。

Dドライブ下に同じドメイン配下の共有フォルダを置いてやり取りをする。

ここどうすればいい?みたいな質問をお互いのモニタを見ながら2,3回やって

残りの時間は黙々とコーディングをした。昼を挟んで小一時間

ほぼ同時に作業が終わったので、二人で個別に組んだコードマージする。

ビルドエラーもなく、すぐに終わった。アプリを立ち上げた後、

テスト用のバーコードQRコードはお互いに用意してくれているだろうと無言の目線を交わす一幕も。

バーコードスキャナを翳すと一発で読み込んでしまった。

上司が両手を上げる。普段空気が読めない自分が、何故かこの時は自然に手が出た。

普段表情が硬いメンバー女性クスクス笑っていたのでよほどテンションが上がっていたのだろう。

結果として、3週間PG時間を取るはずが、半日からずに終わってしまった。

別の作業に戻った後も、やり遂げたという高揚感にその日はずっと酔っていた。

今月末で上司プロジェクトを離任する。

上司はいつも笑っていて、仕事を楽しくさせることに努力を惜しまない人だ。

同じ会社だし、お会いする機会、仕事をする機会もまだまだあるのだろうが、

その時は今の距離感は許されないだろう。

短期で人が入れ替わり立ち替わりが当たり前の職場

自分はどこか人間関係も段々ドライに捉えるようになっていたから、

今はただこの寂しさに慣れない。

2014-04-24

システムテストの方が効率良いって言ってるけど

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

を読んでみたんだけど、これも結構理想論な気がすんだよな。

デザイナが全員HTML構造気にしてくれる訳でもないし、

歴史のあるサイトだったりすると読んでも意味の分からないユーティリティ的なセレクタがよく出てくる。

こういうのが現実

page.has_selector?(:xpath, '//table.tokushu1/tr.header/td[3]/div/div//span.click_left')

しかもA/Bテストが始まったりしてテスト書く負荷が高くなりメンテできなくなる。

ただスマートフォンアプリはデザイナがレイアウトいじる事が少ないので、

システムテストだけでもかなりテスト品質は保てる。

2013-01-23

SI土方からWeb行ってみます

試験業務中心だった。

その中でもシステムテストとかやったりしてるのでネットワークサーバーアプリは商用の状態に近い環境試験をしている。

具体的にはサーバーはLB使って冗長化/スケールアウトされていたり、クラスタリングされていたり、データセンターにあるサーバーリモートログインして試験をしたりとか。

rebootコワイヨーとかHW障害うざいよーとか思いながら。

ソフトウェア受託開発の会社で、Javaの業務アプリ設計・開発・試験していた様な人達が集まっているので、ネットワークLinuxなどアプリよりは低レイヤなところに詳しい人が地味にいなかった。

システムテストの項目書をExcelで作るお仕事や、試験実施するお仕事は凄くやる気しなかったが、試験実施方法検討するお仕事や、試験をするための環境を構築したり、仕様書を読んでミドルウェアアプリコンフィグを投入する仕事は楽しかった。コンフィグを投入する作業をスクリプト怠惰自動化したりするのは、けっこー楽しかった。

リグレッションテストや、バージョンアップでの改修テストなどで環境を再構築する際に、作成した自動スクリプトは腐らさせずに誰かに展開することが出来たので、自動化した工数無駄にはならなかった(ちゃんと効率化に!)大量にデータを投入するとき、さすがにだるい。ツールも使えば使うほどバグなくなるし良い感じ。PerlBashを覚えるきっかけにもなるし。

今思うと出向も楽しかった!メーカーSI会社社員食堂とかあったので、うわすげぇドラマみたい!とか朝はエレベーターの前に人が並ぶのでうわすげぇ人多い!とか。(最初だけだけど)

後はサーバー室でサーバーとかLBとかを目の前で見れたのがテンション上がった。うわこれF5じゃね?うわこれJuniperやん…いくらすんだよ…HPブレードサーバーだ!いくらするのかググった。

まぁ、普通に誰も興味示さないw あの時は商用ネットワーク機器という物に憧れている少年だったw

作業で疲れたときはぶらぶらして眺めてた。

何かの見学の時は「おいふらつくな」とか誰かに怒られそうだけど、仕事で来てると誰も何も言わないので見たい放題。転んでケーブル抜いた日には大問題になりそうなので、さすがにそこは気をつけた。

あの1UサーバーRHELインストールするとか、少年には楽しすぎた。でも手順はMacVirtualBoxCentOS入れるのと変わりはなかった…。ただ、仕事として1UサーバーRHELインストールした、という経験を持つことが嬉しかった(少年から

でもいいさ。

F5なんか使わずLVSやUltraMonkey-L7で負荷分散すればいいし、商用のアプライアンス機器なんか使わずオープンソースで解決してしまおう。AWS使うならELB使えばいいし。そういう環境行ってみようぜー。

2009-10-11

http://anond.hatelabo.jp/20091010235215

IDとかコテハンのない増田では議論しにくいですねorz

多分http://anond.hatelabo.jp/20091010232609

でいっている元増田トラバ元のあなたです。

システムテストに関してはhttp://anond.hatelabo.jp/20091010210506

で書いている通り

その修正が呼び出してる20機能に必要な修正なら、20機能全部でデグレード試験し直しは必要。

1機能にしか影響しなくて他の19機能のロジックを変えたくない(デグレード試験したくない)なら、

共通関数コピペして&修正して、修正が必要な該当1機能は新規にコピペ&修正した関数呼び出す

で、修正が必要な1機能しかデグレード試験しなくてよいと思っています。

私が言いたいのは

どのような共通化を行うか(共通関数をつくるか)内部設計書に宣言させて(して)、

責任者(そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間)とレビューして、

そのプロジェクトではどのような共通化が適切であるか合意をとるべきだということです。

合意とった内部設計書とおりに実装していなければ(勝手に新たな共通化関数つくっていれば)、

実装担当者責任ですし、

そもそも内部設計書に誤りがあれば、

どのような設計が、適切に共通化した設計か判断できる人間責任だと思います。

2009-10-10

http://anond.hatelabo.jp/20091010232609

元増田って

http://anond.hatelabo.jp/20091010180917

でいいですよね?

違ったら以下は無視してね。

 

内部設計書は書いてますよ。

でも元エントリーで私が言及してるのは

システムテスト工数であって

結合テスト工数じゃないです。

2007-08-14

[]http://anond.hatelabo.jp/20070814224358

まず疑うべきことはひとつ。

「ちゃんと客に迷惑メールブロックの解除させてるんだろうな」

たいていのケータイユーザ携帯キャリアからのメールか、

指定したドメインからのメール以外をシャットアウトするようにしているので、

そのせいでメール送れてないんじゃないのか。

登録するときに送るメールのFromと、ICカードにかざしたときに送るメールのFromが違うとか。

あと、

「事前にシステムに加入したユーザが、お財布ケータイ街角にある読み取り機にかざすと、

 登録されてるアドレスメールが届いて情報が得られる、というシステム

このシステムだけならイケてる奴なら仕様が固まってさえいれば2週間くらいで作れるから、

少なくとも開発現場にはそんなに大金は降りてないと思う。

(フルで動けるなら、設計実装2日・ローカルでのテスト2日・

システムテスト2日・フィールドテスト6日くらいの感覚かと)

 
ログイン ユーザー登録
ようこそ ゲスト さん