2017-08-31

利用者の視点を大事にしよう：品質モデル（JIS X 25010:2013）を改めて読んでみた

QA業界では有名な、品質モデルに関する規格である JIS X 25010:2013(ISO/IEC 25010:2011 )を読んでみた。

JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価（ＳＱｕａＲＥ）−システム及びソフトウェア品質モデル

以下、特に印象に残った点を挙げてみる。

印象に残ったところ（抜粋）

この規格は、「利用時の品質モデル」と「製品品質モデル」を規格している。
「利用時の品質モデル」はシステムと人間の対話に関すること。5つの特性をもつ。
「製品品質モデル」はシステムの特徴に関すること。8つの特性をもつ。
システムの全ての部分に対して、全ての副特性の仕様化または測定は事実上不可能である。品質特性の相対的な重要性は、プロジェクトに対する目標及び目的に依存する。そのため、プロジェクトごとにモデルを修正することが望ましい。
システムの利用者は3種類。
- 一時利用者：システムと対話をする人。
- 二次利用者：支援を提供する人。主に「コンテンツプロバイダ」と「保守者」の二種類。
- 間接利用者：システムを利用しないが、出力を受け取る人。
機能適合性、性能効率性、使用性、信頼性、セキュリティは、一時利用者の品質に大きな影響がある。 * 互換性、保守性、移植性は、二次利用者の品質に大きな影響がある。
ソフトウェアの特徴には、「固有の特徴」と「割り当てられた特徴」がある。
- 固有の特徴は、「機能面の特徴」と「品質面の特徴」がある。
  - 機能面の特徴は、ソフトウェアが何をすることができるかを決定する
  - 品質面の特徴は、どれだけうまくソフトウェアが動作するかを決定する
- 割り当てられた特徴の例は、価格、納入日など
機能適合性は、機能仕様にではなく、機能が明示的ニーズ及び暗黙的ニーズを満足させるかどうかにだけ関係している

所感

「全ての副特性の仕様化または測定は事実上不可能」なので「モデルを修正」して利用すべき、と書かれていることに驚いた。どこを重点的に確認すべきかは、製品の利用者のニーズによるということが分かった。

機能適合性は、機能仕様との合致性には関係しないことを初めて知った。この規格はあくまで利用者の視点を大事にすべき、という立場を貫いているんだな、と思った。

2017-08-14

リスクのないプロジェクトには手をつけるな。：『熊とワルツを』を読んだ読書メモ

『熊とワルツを』（トム・デマルコ著）を読んだ読書メモ。

http://amzn.asia/i3zcDif

品質保証のお仕事で普段からリスクを管理している身にとっては、結構身につまされることが書いてあったと思う。「リスクをいかに取らないようにするか」が書かれた本だと思っていたので、「リスクのないプロジェクトには手をつけるな」と最初に出てきた時はちょっとびっくりした。

特に心に残ったことを三つ挙げてみる。

潜在価値が高ければ重大なリスクでもとる価値がある。潜在価値が低ければ、たいていのリスクはとるべきでは無い
不確定性を口に出すことを許されない企業では、リスク管理はできない
不確定性を数量化して、不確定図を作成しよう

1点目は、「リスクが少なければ少ないほど良い」と普段は考えがちなので、これは目から鱗だった。「これはどれだけの価値があるのか？」を考えたい。

2点目は、チームの文化がこうならないように気をつけようと思う。

3点目は、試験計画を立てる時やスケジュールに関して関係者と合意を得る時に、不確定図を作ってみようと思った。

以下、超簡単に、重要そうなところを備忘録的にメモしておく。

第1部：なぜリスクを管理するのか？

・リスクのないプロジェクトには手をつけるな。
　リスクと利益は切っても切れない関係にある。
　リスクがあると言うことは、自分の能力を伸ばす機会であり、見事にやってのければ、ライバルは地団駄を踏むだろう。

・リスクとは、「将来起こりうる出来事で、望まない結果を産むもの」「望まない結果そのもの」。

・リスク管理とは、原因となるリスクを管理すること

・リスク管理の5つの活動
　1. リスク発見
　2. エクスポージャー分析：それぞれのリスクが実現する確率と、影響度を数量化する
　3. 危機対応計画：リスクが実現した場合に何をすべきかを計画する
　4. 軽減：計画した危機対応措置が必要な時に実行できるように、移行前にとるべき対策をとる
　5. 継続的な移行監視：管理するリスクが実現しないかどうかを監視する

・リスク管理に失敗した代表的な例は「デンバー国際空港」。自動手荷物処理システムのソフトウェアの開発が遅れ、空港の開港が2年遅れた。

・リスク管理の責任は、リスクを無視した場合に代償を支払うことになる当事者が負わなければならない

・リスク管理を行うことで、積極的にリスクを取れるようになる
　　-リスクに対する評価、数量化、対策が済んでいれば、クライアント側は論理的に判断することができ、発注できる

・リスク管理は目に見えない責任転嫁を防ぐ
　　-例えば、ある種のリスクをカバーするための危険準備金をクライアントが用意することになった場合、そのリスクに対する責任は、請負業者からクライアントに移譲されたと考えて良い
・リスク管理をすべきでない理由はほとんど無い

第2部：リスクとは厳密にどのようなものか？それを管理するとは、どう言うことか？

・不確定性を口に出すことを許さない企業文化の中では、リスク管理はできない

・管理する価値がないリスクとは、「実現確率が無視できるほど小さい」or「もし実現した場合、現在管理している仕事など大したことではなくなる」ようなリスク。例：小惑星の衝突

第3部：リスク管理の方法とは？

・不確定性を数量化する。不確定幅を推測する。不確定図を作成する
　　-例：完成予想日は、最短でN。一番遅くてM。その期間中で、相対確率が最も高い日はN+αである。

f:id:yabit:20170814154053g:plain http://www.systemsguild.com/adultbehavior.htm からグラフを引用

・期日が固定されているなら、不確定な要素はその日に何を納品するかという問題になる。（インクリメンタルな開発手法が望ましい）

・ソフトウェア・プロジェクトのコアリスク
　1. 内在的なスケジュールの欠陥
　　　-一般的に、スケジュールの超過期間は30%以上になる
　2. 要求の増大（要求の変更）
　　　-一般的に、予想される変更の範囲は1ヶ月につき1%未満である
　3. 人員の離脱
　4. 仕様の崩壊
　5. 生産性の低迷

・費用対効果が最適となるリスク軽減戦略は、インクリメンタル開発である
　　-ただし、受け身のインクリメンタル開発手法（PMが要件の優先順位に指示を出さない）は失敗する
　　-システムのうち技術的に奇跡に頼る部分は、失敗した時の損失が少なく済むように初期のバージョンに組み込むべき。
　　-バージョンごとの受け入れ検査で、実質的な進捗状況を追跡しよう

第4部：リスクと機会のバランスをとるにはどうすれば良いか？

・企業にとっての最大のリスクは、価値の低いプロジェクトに無駄な労力をつぎ込み、価値の高いプロジェクトを逃して機会コストを負うことである

・潜在価値が高ければ重大なリスクでもとる価値がある。潜在価値が低ければ、たいていのリスクはとるべきでは無い
　　-デスマーチの正当化にはプロジェクトの重要性が使われるが、プロジェクトがそれほど重要なら、どうして会社は適切に時間と資金を使えないのか？

・コストと効果は同じ精度で表す必要がある

・予想される価値を基準に、どれだけリスクをとるかを決めるのが良い

第5部：成功したかどうかはどのように判断するのか？

1. リスク調査が行われている
2. 継続的なリスク発見プロセスを実行している
3. そこら中に不確定図がある
4. プロジェクトに目標と予想の両方があり、この二つが同じになることはない。
5. 全てのリスクに対して移行指標が決められている
6. 全てのリスクに対して危機対応計画と軽減計画がある

2016-02-23

テスト設計を改善するために最近考えていることのメモ

Webアプリケーションのテストプロジェクトのテストリーダをしています。

自分が担当しているプロジェクトで、常々テスト設計を改善したいなと思っていたのですが、この夏にちょうど大幅にテスト対象が変更されることになり、このタイミングで改善しようと思っています。

そこで最近考えていることのメモです。

問題

フルリグレッションの実施工数が高い（約200人日）
テストケースに問題があり、テスト自動化を進めにくい
テストケースが膨大で、そもそもどの程度網羅できているのか、何が重複・漏れているのかわからない状態

原因

既存の試験仕様書（固定3レイヤー法で作成）が適切でない

重複、無駄なテストケースがある
テストケースの趣旨が分かりづらい
操作手順が省略されていたり、間違いが多い（試験設計の一部をオフショアにしていることもあり、言語の壁も大きい）
テスト観点が列挙・整理されていない
テストタイプ・テストレベルが整理されていない

(2016/02/23 追記)上記の「原因」は西先生の資料を参考に挙げました。テスト観点に基づくテスト開発方法論 VSTePの概要 http://qualab.jp/materials/VSTeP.130510.bw.pdf

問題を解決するために必要なこと

テストケースとテスト観点とを必ず結びつけるようにテスト設計する
親子関係をきちんと明示し網羅性を保証する
テスト観点を列挙・整理し全体像を把握する
テストタイプ・テストレベルをテスト観点でより詳細に表して図示し、テストタイプやテストカテゴリ間の重複や漏れ、不要な依存関係をなくす

導入検討中の方法論

VSTeP
- テスト観点を漏れなく列挙し整理する qualab.jp
ゆもつよメソッド
- テスト観点からテストケースを導く www.amazon.co.jp
テスト観点テンプレートを使用したテストケースの充実
マインドマップを適用したソフトウェアテストプロセスの構築

2015-11-21

テストアナリストについて

テストアナリストについて調べたので、備忘録としてメモを残しておく。その中でも、リスクベースドテストについて書かれているところも抜き出してみた。

参考文献 http://jstqb.jp/syllabus.html ISTQBテスト技術者資格制度 Advanced Level シラバス日本語版テストアナリスト Version2012.J01

テストアナリストの仕事

要求エンジニアリングおよびマネジメント - 要件レビュー
プロジェクトマネジメント - スケジュール
構成管理および変更管理- ビルド検証テスト、バージョンコントロール
ソフトウェア開発 - 提供される内容とタイミングの予測
ソフトウェアメンテナンス - 欠陥マネジメント、ターンアラウンドタイム(欠陥を見つけてから解決するまでの時間)
テクニカルサポート - 回避策の正確な文書化
テクニカルドキュメント(たとえば、データベース設計仕様)の生成- これらのドキュメントへの入力とドキュメントのテクニカルレビュー

1.3 テストの計画作業、モニタリング、およびコントロール

テストのモニタリングとコントロールについて、特に面白そうだったので抜き出してみた。

テストのモニタリングとコントロールは、通常、テストマネージャの担当であるが、テストアナリストは、コントロールを可能にするための測定を行う。
ソフトウェア開発ライフサイクル全体を通して、さまざまな定量的データを収集する必要がある。
- たとえば、完了した計画作業の割合、達成したカバレッジの割合、合格および失敗したテストケースの数などを収集する。それぞれのケースについて、ベースライン(参照標準)を定義し、このベースラインに関して進捗を追跡する必要がある。
- さまざまな追跡ツールに入力する情報を可能な限り正確にして、メトリクスに現実を反映させることが重要である。
正確なメトリクスを使用することにより、マネージャはプロジェクトをマネジメント(モニタリング)し、必要に応じて変更を開始(コントロール)できる。
- たとえば、ソフトウェアの特定の領域で非常に多くの欠陥が報告されている場合、その領域に関してさらに多くのテスト作業が必要な可能性がある。要件とリスクカバレッジの情報(トレーサビリティ)を使用することにより、残りの作業に優先度付けを行い、リソースを割り当てることができる。根本原因に関する情報を使用することにより、プロセス改善が可能な領域を判断できる。
- データを正確に記録することにより、プロジェクトをコントロールすることが可能になり、正確なステータスの情報をステークホルダに報告できる。
- 過去のプロジェクトから収集したデータを計画作業で考慮することにより、プロジェクトをより効果的に計画できる。正確なデータの使用方法は無数にある。
- テストアナリストは、データが正確で、タイムリーであり、客観的であるようにする必要がある。

つまり、テストアナリストの仕事は、

テストマネージャがコントロールを可能にするためのデータ収集を行う
計測指標は正確にかつタイムリーに収集すること
計測により、評価と予測が可能になる
- 正確なステータスの情報をステークホルダに報告できる
- 将来の予測ができる

テスト分析

テストベースの分析
テスト条件の識別

第7回Quesに参加して、テスト分析の概要について学んだ。

テストベースをもとに「テスト分析」を行ってテスト条件を作成する。テスト条件をもとにして「テスト設計」を行ってテストケースを作成する。
テストベースは仕様書など。テスト条件はテスト観点。マインドマップなどを使ってまとめる。

2.2 テストの進捗モニタリングおよびコントロール

テスト進捗のモニタリングの対象には、次の 5 つの主要な要素がある。

プロダクト(品質)リスク
欠陥
テスト
カバレッジ
確信度合い
- 主観的な報告になることが一般的

リスクベースドテストアプローチを使用している場合、テストアナリストは次の項目を追跡する必要がある。

テストにより軽減されたリスク
まだ軽減されていないと考えられるリスク

リスク軽減の追跡は、ツール（テストマネジメントツールなど）を使用して行う。識別したリスクをテスト条件に対応付けし、テスト条件をテストケースに対応付ける必要がある。このテストケースを実行して結果が合格になると、リスクを軽減できる。

2.4 リスクベースドテストにおけるテストアナリストのタスク

テストアナリストは、次のリスクベースドテストのタスクに積極的に関与する必要がある。

リスク識別
リスクアセスメント
リスク軽減

2.4.2 リスク識別

テストアナリストは、ユーザおよび他のドメインエキスパートと緊密に連携して、テスト中に対応する必要のあるビジネスリスクの領域を決定する必要がある。リスク識別は、可能な限り多くのリスクを識別することを意味する。

2.4.3 リスクアセスメント

リスクアセスメントでは、それぞれのリスクを分類して、それぞれのリスクに関連する発生確率や影響を判定する。リスクレベル = 発生確率 * 影響度(ビジネスリスク)

2.4.4 リスク軽減

テストはリスク軽減策の一つである。テスト担当者は欠陥を見つけることにより、欠陥が認識されるようにし、リリース前に欠陥に対処する機会を提供して、リスクを軽減する。テスト担当者が欠陥をまったく見つけなかった場合、テストされた特定の条件下でシステムは正しく動作することが保証され、テストがリスクを軽減したことになる。

テストアナリストは、正確なテストデータ収集のための時機の調査、現実的なユーザシナリオの作成とテスト、および使用性調査の実践または観察を行うことで、リスク軽減のオプションを決定することを支援する。

リスクのレベルもテストの優先度付けに使用する。テストに使用するデータの収集や、テストの実行順の決定を行う。

リスクベースドテストでは、その時点における残りのリスクレベルについてテスト担当者がマネジメントにレポートし、マネジメントでテストを延長するか、あるいは残りのリスクをユーザ、顧客、ヘルプデスク/テクニカルサポート、運用スタッフに移転するかを決定できる。

3.4 経験ベースの技法

経験ベースのテストは、テスト担当者のスキルと直感、および類似のアプリケーションや技術での経験を活用する。

メリット
- 欠陥を見つけるのに有効
- システムドキュメントが適切でない場合やテスト時間が厳しく制限されている場合、またはテストチームがテスト対象のシステムに精通している場合には、経験ベースのテストは、より構造化された方法よりも優れた代替策となることがある
デメリット
- 特定のカバレッジを達成したり、再利用可能なテスト手順を生成したりする場合は、他の技法ほど適していない
- 詳細なテストドキュメント、高い再現性、またはテストカバレッジを精緻に評価する能力を必要とするシステムでは、不適切なことがある

2015-02-11

Herokuでアプリ開発を始める準備

Herokuでアプリ開発を始めるための手順。

CodeZineのこちらのページが大変参考になります。この記事は、このページのコマンド実行部分を抜き出したメモです。 <a href="http://codezine.jp/article/detail/8051">PaaSの基礎知識とHerokuで開発を始める準備</a>

無料枠でできる範囲
作るのはJave Servletアプリ（掲示板）
言語はPython
DBはPostgreSQL

手元環境はMac OSX上に立てた Ubuntu14 です。

Herokuアカウント登録、Toolbeltインストール、Herokuログイン

Herokuにアカウント登録します。

Herokuのコマンドラインツール「Toolbelt」をインストールします。バージョン確認コマンドを実行して確認。

heroku version

gitも同時にインストールされます。バージョン確認コマンドを実行して確認。

git version

herokuコマンドと先ほどサインアップしたアカウントをひもづけるためにheroku loginコマンドを実行。

heroku login

紐付いているアカウントを確認するコマンド。

heroku auth:whoami

hello worldを作成して動かすまで

ローカルで実行するまで

Servlet コンテナには、Herokuの中の人が作成した「Webapp Runner」を使用します。ベースとなるコードは冒頭に記載のページで紹介されているGitHub レポジトリから拝借します。ローカルにリポジトリのクローンを作成するコマンドを実行。

$ git clone https://github.com/shunjikonishi/codezine-sample.git -o upstream

実行に成功するとカレントディレクトリに「codezine-sample」というディレクトリが作成され、そこにリポジトリの内容がコピーされます。

リポジトリの中身を確認します。

$ git remote -v

まずはローカルで実行します。コンパイルして実行。

$ mvn package
$ ./run.sh

Webブラウザで http://<VMのIPアドレス>:5000 にアクセスするとHello Worldの文字列が表示されるはず。

デプロイして本番環境で確認するまで

Heroku上にアプリケーションを作成します。

$ heroku create [APPNAME]

上記のコマンドを実行した結果、以下が行われます。

[APPNAME]というアプリケーションが作成され、そのstackは「cedar-14」であること
「http://[APPNAME].herokuapp.com/」というURLが用意されたこと
「git@heroku.com:[APPNAME].git」というgitリポジトリが用意されたこと
ローカルのgit remoteに「heroku」という参照名が追加されたことローカルのリポジトリを確認するには以下のコマンドで。

$ git remote -v

いよいよデプロイの段階になりました。デプロイするのは git push コマンドです。

$ git push heroku master

コードを修正してまたデプロイする

コードを修正したら、一度ローカルでコンパイルして実行し、動作確認します。問題なく実行できたら、修正内容をgitリポジトリに反映し、git pushでデプロイします。

$ git status
$ git add .
$
$ git status
$ git commit -m "Modify message."
$
$ git status
$ git push heroku master

git add
- 引数のファイルをコミット対象リストに追加するコマンド。
- 引数を「.」とした場合はカレントディレクトリ以下の変更のあるファイルすべてが対象となる。
git commit
- コミット対象リストのファイルをリポジトリに反映する。
- -mはコミットメッセージの指定。

アプリを掲示板にする

Heroku Postgresを追加する

使用しているアドオンを確認するコマンドを実行。

$ heroku addons

アドオンを追加するにはheroku addons:add を実行します。

$ heroku addons:add heroku-postgresql

heroku configコマンドで、DBの接続情報を確認します。

$ heroku config

出力されたDATABASE_URLは、アプリケーションがメインで使用するデータベースの接続情報。

データベースにコマンドラインでアクセスします。psqlコマンドをローカルにインストール後、以下のコマンドを実行。

$heroku pg:psql

掲示板アプリのコードを取得してデプロイするまで

掲示板のコードは冒頭に記載したページから拝借します。

$ git fetch upstream
$ git branch 03 upstream/03
$ git checkout 03

git fetch …upstreamからリポジトリの内容を取得するコマンド
git branch …upstreamの03ブランチからローカルに03ブランチを作成するコマンド
git checkout …ローカルのブランチを切り替えるコマンドです

このコードでは、環境変数DATABASE_URLから接続情報を取得してデータベース接続を行ってます。そのためローカル環境でも環境変数の設定が必要です。（UbuntuへのPostgreSQLのインストール方法はこちらを参考に。UbuntuにPostgreSQL 9.1をインストールする - 涼風コンピュータblog）

$ export DATABASE_URL=postgres://[username]:[password]@localhost:5432/[DB名]

ローカル用のデータベースには create.sql を実行して、テーブルを作成しておきます。

ローカルで動作確認し、問題なく実行できたら、heroku上にもDBを作成します。

$ heroku pg:psql
codezine-sample::BLUE=> CREATE TABLE message_board (
codezine-sample::BLUE=>   id serial primary key,
codezine-sample::BLUE=>   nickname varchar(40) COLLATE "C" NOT NULL,
codezine-sample::BLUE=>   message text COLLATE "C" NOT NULL,
codezine-sample::BLUE=>   post_date timestamp default current_timestamp
codezine-sample::BLUE=> );

そしてgit pushでデプロイします。

$ git push heroku 03:master

2015-02-07

TwitterAPI学習：Python + Streaming API + SQLiteで特定のキーワードを含むツイートを抽出して保存する

TwitterAPIの学習として。「特定のキーワードを含んだツイートを抽出したい！」と思ったので、作ってみました。

こちらの記事を大いに参考にしました。とっても助かりました。 PythonでStreaming APIを使用して特定のキーワードを含んだツイートを取得しつづける - Qiita

やったこと：

Streaming APIを使って、特定のキーワードを含むツイートをリアルタイムに取得
取得したツイートのうち、認証済みアカウントのツイートのみを抽出する
抽出したツイートをSQLiteに保存
言語はPython

アクセストークン等を取得

Streaming　APIを使うためには、Twitter側での設定が必要です。 Twitterにログインした状態で、https://apps.twitter.com/　にアクセス。アプリを作成します。

アプリを作成後、「Keys　and　Access　Token」タブをクリックし、 APIKeyなどの４つのキーをメモします。

ソースを作成

http://qiita.com/mima_ita/items/ecdf7de2fe619378beee のソースコードをもらい、twtter_stream.pyという名前でローカルに保存します。

テスト実行

実行します。

$ python twitter_stream.py consumer_key consumer_secret access_token_key access_token_secret hogehoge

ちなみに、自分は上記実行時に認証エラーになりました。原因は、ローカルPCのVMの時刻がずれていたため。ntpで時刻同期して実行したら、ちゃんと動作しました。

データベースを確認します。

$ sqlite3 twitter_stream.sqlite 
sqlite> select * from twitte;

ずらずらっと保存されているはず。

ソースを修正

認証済みアカウントのツイートのみを抽出するようにします。なお、Twitterオブジェクトの解説はこちらが便利です。

TwitterAPIのデータの中身をまとめてみた - 生涯未熟

修正したのは２箇所。

まずはTwitteクラスにverifiedを追加します。Booleanで。

class Twitte(Model):
    createAt = DateTimeField(index=True)
    idStr = CharField(index=True)
    contents = CharField()
    verified = BooleanField()

次に、DBに保存する部分に条件分岐を入れます。verifiedはuserの中にあります。

    for item in GetStreamFilter(api, track=track):
        if 'text' in item:
            if item['user']['verified']:
                print (item['id_str'])
                print (dateutil.parser.parse(item['created_at']))
                print (item['text'])
                print (item['user']['verified'])
                row = Twitte(createAt=dateutil.parser.parse(item['created_at']),
                             idStr=item['id_str'],
                             verified=item['user']['verified'],
                             contents=item['text'])
                row.save()
                row = None

これで保存して、プログラムを実行すればok。ちなみに、修正前にプログラムを実行した際のDBが残っていると、カラムが違いますねというエラーが出るので、.sqliteを削除するのを忘れずに。

2015-01-13

QAがWebサービスを作ってみる奮闘記 - 終章

QAがWebサービスを作ってみる奮闘記 - 序章で作ると書いたWebアプリケーション、作ってみました。

環境

ローカル開発環境はMac OS X
擬似本番環境としてローカルでVirtualBoxでVM立てる
本番環境としてさくらのVPS借りる

ツールとしては、Eclipse等のIDEは使わないようにしました。（なぜかというと、IDEが自動でやってくれる部分がよく理解できなかったので、なるべくシンプルにしたかったから。）

苦労したこと

サーバーOSのインストールと設定等

OSはCent OSにしました。ネットワーク設定（FWなど）等もほぼ初めてだったので、「開発環境で作る→擬似本番環境に設定→様子を見る→大丈夫そうであれば本番環境に適用」という感じで進めました。

Servletの理解

Servletナニソレ？という状態だったので、まずは富士通さんのホームページを読んで概要を理解しました。

<a href="http://jp.fujitsu.com/solutions/sdas/technology/web-apl/">Java技術によるWebアプリケーション開発入門 : 富士通</a>

とっても分かりやすいです。特に今回はIDEを使わないようにしたので、第４章（プログラムの配備と設定情報）が役立ちました。これが無ければいろんなところで躓いていたと思います。。

MySQLの理解

仕事柄、MySQLの中身を見て試験をすることは多々あるのですが、テーブルを自分で作るのは初めてでした。プライマリキーがどうのとか、文字コードがどうのとか、いろいろ考えることがあるんですね。ここら辺を参考にさせていただきました。

Version 3.2.1 | MySQLの文字化け。原因と修正方法がけっこうややこしくて途方に暮れかけた・・・けど！

http://d.hatena.ne.jp/miukoba/20110327/1301201078

TomcatとMySQLの接続

いやーこれが難所だった。。ただJavaの関数としてちゃちゃっと使えるものだと思っていたら（知っている人にとっては簡単なことなのでしょうけど）、JNDIの設定等が必要で初めはちんぷんかんぷんでした。Tomcatのログを読んでもあまりぴんとこず。。ここら辺を読んで徐々に学習しました。

http://www.javaroad.jp/opensource/js_tomcat8.htm

Javaプログラミングそのもの

C言語しか勉強してこなかったので、Javaのプログラミングも初めてでした。例外処理の書き方も学んだりして。

脆弱性対策

基本的な脆弱性対策を行いました。 IPAが公開しているここら辺の資料を参考に。

<a href="http://www.ipa.go.jp/security/vuln/websecurity.html">安全なウェブサイトの作り方：IPA 独立行政法人情報処理推進機構</a>

普段は脆弱性を突く側ですが、初めて作る側に回ると、開発者の方々のすごさが分かりますね。。。個人的な感覚としては、「機能を1作るとすると、その脆弱性対策が3必要になる」と感じました。いやはや、これは脆弱性がぼろぼろ出てくる訳だ。

CSSなど

ぱっと簡単にイケてる見た目にしたかったので、Bootstrapを利用しました。

<a href="http://www.atmarkit.co.jp/ait/articles/1403/19/news034.html">Webデザイン初心者でもできる、Bootstrapの使い方超入門 (1/4)</a>

<a href="http://getbootstrap.com/">Bootstrap · The world's most popular mobile-first and responsive front-end framework.</a>

テーマは今っぽくFlatlyを選択。かっこいいですね。

http://bootswatch.com/flatly/

CSSを適用するとすごいテンションあがりました。（単純

まとめ

今回は、QAがWebサービスを作ってみる奮闘記　と題して、「普段仕事でWebサービスを試験しているが、Webアプリケーションの仕組みがよく分かっていない」状態の人が実際に作る上で参考にしたサイト・ツールをまとめてみました。

個人的な学びは以下です。

Apache, Tomcat, MySQLの連携についての具体的なイメージを持つことができた。
Servletの基礎知識（ディレクトリ構造、jarファイル等）を学ぶことができた。
簡単なJavaプログラミングを行い、Webアプリの脆弱性対策の大変さを理解した。

所感としては、開発者とのコミュニケーションを行う上での背景知識を得るのに役に立ったという感じです。

何かしらの役に立てたら幸いです。