broccoli @nihonbuson ハードウェアの自動化に良いアイディアはあるか？ どれだけデジタル化が進んでいるかによる アルゴリズムのみをテストするならば可能だと思う #JaSST 2018-03-07 10:52:44 broccoli @nihonbuson トランジションの話の前提として、どれぐらいのカバレッジが達成できているのか？ 別のシステムを設けて、カバレッジを測定している。 コードカバレッジはチームに寄って違う。 80%以上のチームもあれば計っていないチームもある 収入が高いチームはカバレッジが高い。成熟度によって変わる #JaSST 2018-03-07 10:54:23 broccoli @nihonbuson テストができている段階の話をしていたが、どういうテストを作るというような指針はあるか？ 一般的なルールは、コードレビュー時に同時にテストコードをサブミッ
テストの観点として、システムが要求や仕様通りに動くことは最低要件であり、より品質を高めるためにはシステムの構造を評価する構造テストが重要になってきます。構造テストの知識について理解しておくと、効率良く品質を作り込めるでしょう。そこで本稿では、「構造テスト」の定義と、活用されるテスト技法についてご紹介していきます。 もくじ ソフトウェアの内部構造を検証する「構造テスト」 構造テストとは 構造テストの対象範囲 構造テストのテスト技法 条件テスト 判定条件テスト 改良条件判定カバレッジ（MC/DC）テスト 複合条件テスト まとめ 1．ソフトウェアの内部構造を検証する「構造テスト」 1-1 構造テストとは 構造テスト（構造ベースドテスト）とは、コードやアーキテクチャ、データなどのシステム内部の構造を元にテストケースを作成していく手法です。定義によってはホワイトボックステスト技法と同一とされる場合も
システム開発を行う上でテストは非常に大切なフェーズです。何かしらの開発を行っているのであれば、ほぼ必ずと言っていいほどテストを行う機会はあるかと思われます。テストを行わずにリリースや納品を行うことはまずあり得ません。 開発の技術はここまでにかけられた時間もあり多くの手法が生まれては消えていきました。それだけの長い時間を費やしてきただけあり、今現在残っている手法というのはデメリットはあるでしょうがそれを越えるメリットがあるものだと思います。 反面テストについては、同じだけの時間が費やされているはずですが開発技法と比較すると、思っているほどの浸透はなされていません。自動化テストも登場してからかなりの年月が過ぎているのですが、実際に導入できている現場はまだまだ多数派までいけていないのではないか、そう思える程には出会う機会が少ないと感じています。 テストエンジニアの方々が啓蒙活動を広く行っているの
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■Windowsのエビデンス 一応私はサーバエンジニアだ。Windows系のサーバを触ることが多い。WindowsではサーバでもGUIから設定を行うのがいまだに主流だ。メンテナンスでエビデンス（作業記録）を取る場合、やはりスクリーンショットを画像で保存するのが多い。 ここでWindowsに愚痴りたい。標準のペイントがしょぼい。いや、ペイントがしょぼいというより、なんでPrint Screen押して直接画像を保存できないのだろうか。Metoroインターフェイス作ってる暇があったなら、そういう地味な改善をしてほしいものだ。 GUIで動く仕組みには、やはり画像でエビデンスを取ることになる。ウインドウの内容を機械的にテキストに出力してくれるような仕組みでもあれば楽なのだが、
こんにちは。kintone 開発チームの長谷川＆宮田です。 みなさんテスト書いてますかー？ 品質の高い製品をリリースし続けるためにはテストを書くのは当たり前。でも実際にテストを書いたりメンテナンスをするのは大変なこと。特に、ユニットテストではなく Selenium のようなブラウザテストはコストが高く、運用が難しい面も。。 kintone チームでも Selenium を使って自動化試験を行なっています。 ここ1年ぐらいで随分テスト周りの仕組みが整備され、製品の品質向上に繋がっていることを実感していますが、 最初の頃は失敗も多く自動化試験としてはあまり機能していませんでした。今回はそんな kintone チームの自動化試験への取り組みの失敗とその改善について紹介したいと思います。 Selenium の失敗あるある 始めに昔の取り組み（失敗談）をいくつか簡単に紹介します。 テストの目的が曖昧
こんにちは、第3バイオリンです。 「WACATE 2011 冬」参加レポート、いよいよ完結編です。今回は、クロージングセッションと後夜祭、今回のWACATEで得た気付きをお届けします。 ■クロージングセッション「現場主義が道を拓く ～WACATE編～」 「WACATE 2011 冬」の最後を飾るのは、NECの誉田（ほんだ） 直美さんのセッションです。 誉田さんは、NECでサーバや運用管理ソフトを開発する部署の品質管理の業務に携わっています。「品質会計」というNEC独自の品質管理手法の書籍を執筆された方でもあります。 誉田さんは、まず2つの組織の品質改善活動の事例について紹介しました。メンバー数や開発条件が良く似た2つの組織に「品質会計」をはじめとして同じ手法を適用して、出荷後のトラブル、クレーム数などを比較したときのことです。同じような組織に、同じ手法を適用したのだから結果は同じくらいにな
こんにちは、第3バイオリンです。 「WACATE 2011 冬」参加レポート第3弾、今回は2日目のセッションの様子をお届けします。 ■セッション「ISSREに参加してきた！」 WACATE実行委員で、智美塾（さとみじゅく）一号生の小山 竜治さんと坂（ばん） 静香さんのセッションです。 智美塾とは、テストのライフサイクルを進化させるため、各自がテスト開発方法論を作る、という理念のもとに運営されている私塾です。小山さんと坂さんも塾生として、いつも活発な議論を繰り広げています。そんなおふたりが智美塾の代表として、ISSRE（イズリー、と読みます）というシンポジウムに参加してきました。 ISSREとは、「IEEEソフトウェア信頼性工学国際シンポジウム」のことです。2011年は広島での開催ということ、智美塾がISSREの中で開催された、InSTAとよばれるソフトウェアテストアーキテクチャのワークショ
こんにちは、第3バイオリンです。 最近では恒例行事になっていますが、ソフトウェアテストのワークショップ「WACATE 2011 冬」に参加してきました。今回も面白いお話がたくさん聞けて、またエンジニアとしてこれからどうあるべきかについても深く考えることができました。 それでは、さっそく参加レポートをお届けしたいと思います。 ■日時と場所 日時：2011年12月17日〜18日 場所：マホロバ・マインズ三浦（神奈川） 今年も前日の夜に、会場で前泊する参加者が主催する「前夜祭」がありました。しかしわたしはこの日、会社の忘年会だったので、忘年会終了後に夜行バスで会場に向かいました。毎年、冬のときは前日に忘年会が入るのですが、これは偶然でしょうか。 ■テーマ 今回のテーマは「咲かせてみせようテスト道」 参加者それぞれが、自分とテストのあり方を見つめなおし、これから進む道を考えるという意味が込められて
こんにちは、第3バイオリンです。 2012年最初のコラムは「WACATE 2011 冬」参加レポートの続きです。今回は、1日目の午後のセッションとディナーセッション、夜の分科会の様子をお伝えします。 ■ワークショップ「『お隣さん』は誰？ ― インプット、アウトプット、テストプロセスから整理してみよう」 WACATE実行委員の近江 久美子さんのセッションです。 最初に近江さんは、このセッションのテーマとして「テストプロセスとお隣さんを意識すると自分の立ち位置が見える。無駄や改善点も見えるようになる」と言いました。 まずは「テストプロセス」と「お隣さん」の定義です。近江さんは、このセッションにおけるプロセスについて、「インプット→アクティビティ→アウトプット」つまりインプットに対してアクティビティをほどこし、アウトプットを生成する、という一連の流れのことである、と定義しました。 このインプット
三菱東京UFJ銀行のインターネットバンキングシステム開発。品質確保は最大のテーマだった。世界最大規模のプロジェクトで、総数50万件もの過酷なテストをどう乗り越えたのか。プロジェクトを率いた大森久永氏に聞いた。（聞き手は池上 俊也＝日経SYSETMS） 大森さんがプロジェクトマネジャー（PM）を務めた、三菱東京UFJ銀行のインターネットバンキングシステムの開発とは、いったいどんなプロジェクトだったのでしょうか。 旧東京三菱銀行と旧UFJ銀行のインターネットバンキングシステムを統合するプロジェクトで、開発期間は2006年4月から約3年間にわたりました。統合完了は2008年末。ピーク時のメンバー数は600人に上り、インターネットバンキングのシステムとしては、世界最大規模のプロジェクトだったといえるでしょう。 私はその中で、日立製作所のプロジェクトマネジャーを務めながら、三菱東京UFJ銀行側の立場
テストツールの満足度はどの程度なのだろうかーー。今回の調査の回答者のうち、単体テストツールの利用者は457人、結合テストツールの利用者は228人、システムテストツールの利用者は212人であった。この方たちにツールの満足度を聞いたところ、約8割がおおむね満足していることが分かった。 単体テストツールに「満足」と答えたのは20.1％で、「やや満足」（58.4％）と答えた人と合わせると78.5％になる（図1）。結合テストツールに「満足」と答えた人は18.9％で、「やや満足」（64.9％）と合わせると83.8％（図2）。同様に、システムテストツールに「満足」している人は3種類のツールの中で最も高く22.2％で、「やや満足」（59.0％）と合わせると81.1％になる（図3）。テストツールの利用率は低い（前回記事）が、実際にツールを利用している人の満足度は高い。
今回の調査で明らかになったのは、テストツールの利用率は低いものの（前々回記事）、テストツールを利用している人の満足度は高い（前回記事）ということだ。では、なぜテストツールは使われないのだろうか――。 その理由を明らかにするために、テストツールを使っていない人にその理由を聞いている。単体テスト/結合テスト/システムテストツールのそれぞれで使わない理由を聞いたところ、1位～3位はいずれも同じ。1位は「導入コストが高い」、2位は「手作業で行った方が早い」、3位は「どんなツールがあるのか知らない」であった（図1、図2、図3）。
テストツールは大きく、「市販ツール」「オープンソース」「自作ソフト」に分別できる。その割合を見てみると、単体テスト/結合テスト/システムテストツールのいずれも5割強が市販ツールである（図1、図2、図3）。次いで多いのは、単体テストはオープンソース（32.8％）、結合テストは自作ソフト（24.6％）、システムテストはオープンソース（23.6％）であった。 今回はそのうち「市販ツール」と「オープンソース」に注目する。市販ツールは有償で、オープンソースは無償で利用できる。サポート費用を含めると単純にオープンソースが安価とは言えないかもしれないが、総じてコスト面ではオープンソースが有利と思われる。では、総合的な満足度はどうだろうかーー。 テストツールの満足度を尋ねたところ（「満足」「やや満足」「やや不満」「不満」の四つの選択肢がある）、「満足」と答えた人の割合は、オープンソースより市販ツールの方が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
