2017年6月23日に行われた、JaSST'17 Kansai の発表資料です。 http://jasst.jp/symposium/jasst17kansai.htmlRead less
こんにちは。東京品質保証部 QAの矢引です。 今回は、今年の上半期に行った、試験設計プロセスの見える化の活動について紹介します。 製品チーム横断でQAのカイゼンを支援するチーム「SPITz」 サイボウズでは、製品ごとに開発チームが分かれており、QAメンバーがそれぞれの開発チームで活動し、担当製品のテストプロジェクト全般を担当しています。 QAの仕事内容についてはこちらの記事でもご紹介していますのでぜひご覧ください。 blog.cybozu.io また、上記の活動とは別に、品質保証部内のQA全般のカイゼンを支援するチーム「SPITz」( Software Process Improvement in Test の略)があり、有志のメンバーが活動しています。 これまで、探索的テストの情報収集やTPI NEXTの情報収集・試験的導入などを行いました。 背景 サイボウズではリリースに関する品質の基
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか?少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか? カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか? (テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
はじめに 本投稿は、ソフトウェアテストの小ネタアドベントカレンダー24日目になります。 試験項目は「テスト実行者が10人実行したときに10人同じ手順、確認結果を得られること」が一つの要件だと思っています。 そこで、これまでの現場で見てきた試験項目に書いてあって困った文言たちをここでは紹介します。 本件は、筆者の個人的な経験に基づく、考えです。異論、疑問はコメントにお願いします。 NG文言集 1. 正しいこと 正誤を判断するための条件が書かれているのが試験項目であって、「正しい」という文言は書いてはいけない。 あなたの「正しい」は、テスト実行者の「正しい」とはイコールではない可能性がある。 【NG】 メッセージの文言が正しいこと。 【OK】 メッセージが「サーバのエラーです。時間がたってから再度お試しください。」であること。 現実には、「正しい」と書かれた試験項目がまかり通っている。見かけた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く