LINE Developer Meetup in Tokyo #39 Presentation (modified)A modified presentation for LINE Developer Meetup in Tokyo #39 on paradigm shift to and testing methodology for modern software development.
QAがテスト設計プロセスの見える化に取り組んだ話 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。東京品質保証部 QAの矢引です。 今回は、今年の上半期に行った、試験設計プロセスの見える化の活動について紹介します。 製品チーム横断でQAのカイゼンを支援するチーム「SPITz」 サイボウズでは、製品ごとに開発チームが分かれており、QAメンバーがそれぞれの開発チームで活動し、担当製品のテストプロジェクト全般を担当しています。 QAの仕事内容についてはこちらの記事でもご紹介していますのでぜひご覧ください。 blog.cybozu.io また、上記の活動とは別に、品質保証部内のQA全般のカイゼンを支援するチーム「SPITz」（ Software Process Improvement in Test の略）があり、有志のメンバーが活動しています。 これまで、探索的テストの情報収集やTPI NEXTの情報収集・試験的導入などを行いました。 背景 サイボウズではリリースに関する品質の基
通話品質に関する用語集 （総登録数：77）
お客様の視点からネットワークの全体最適化を図るコア技術を研究開発 インターネットの社会インフラ化が進む中、経済的で安定した情報通信ネットワークを構築・運用し、快適なブロードバンド・ユビキタスサービスをお客様に提供するためには、お客様の視点から、「設備と品質」の最適バランスをとりネットワークの全体最適化を図る「通信トラヒック・品質」技術が重要となります。 当プロジェクトでは、電話時代から長年培ったネットワーク技術と最先端の技術知見に基づき、お客様の満足する品質で経済的にネットワークを構築・運用するためのトラヒック・品質に関する方法論（評価法、設計法、制御法、管理法）の研究開発を進めてきました。 IOWN時代に向け、ネットワークに限らず社会システム/サービスの求める需要条件・求められる供給条件の双方を指標化・モデル化・定量化し、今まで言語化出来ていなかった内部状態をデジタルに可制御化していくこ
「カバレッジが高ければ、品質が高い」と誤解している危険な思想家の皆様へ - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
テストやレビューのプロになるために -- 計測力と洞察力強化のコツ・ノウハウ --
JaSST 2009 Hokkaido ソフトウェアテストシンポジウム２００９ 北海道 テストやレビューのプロになるために -- 計測力と洞察力強化のコツ・ノウハウ -- Nobuhiro Hosokawa (carvin@jp.ibm.com) Quality Assurance, Services Quality. IBM Japan Ltd. JaSST 2009 Hokkaido Takeaways � 計測は力なり – メトリクス計測と産業 – メトリクス・データ – 定量可視化技術 – …で、測ってどうするのですか？ • データ測定することの意味 � プロの洞察力・集中力 – 事例 - 問題意識 – 集中と没頭 � プロの発想力・創造力 JaSST 2009 Hokkaido メトリクス計測と産業 JaSST 2009 Hokkaido テスト技術者に必要な資質とは？ × In
経路の総数、ネストの深さ、循環的複雑度の特徴 - マイナー・マイナー
コードの複雑性を定量評価する尺度（メトリクス）には経路の総数、ネストの深さ、循環的複雑度（サイクロマティック複雑度）があります。しかし、経路の総数とネストの深さはフローの構造に依存するブレが大きく、循環的複雑度はそのブレが小さいことが、いくつかのコードを見ていて思いました。ここでは、その具体例と、それらのメトリクスの特徴について考察しました。 循環的複雑度については前回の循環的複雑度でフローの複雑性を把握するで解説しています。循環的複雑度は、簡単にいうと、エッジとノードで囲まれた領域の数です． 具体例 テストの点数を与えると、その評価を返すメソッドevaluationXを考えます。評価は次の通りです。 100点 優 80点〜99点 良 60点〜79点 可 0点〜59点 不可 簡単のため、与える点数は必ず0以上100以下と仮定します。 上記の機能を実装したメソッドを3つ考えます。 例1 『深
循環的複雑度でフローの複雑性を把握する - マイナー・マイナー
業務でコードの静的解析について調べていたら循環的複雑度（サイクロマティック複雑度：Cyclomatic Complexity）という「フローの複雑度」を評価する尺度に出会いました。コードの複雑さの比較性に優れた尺度だと感じてワクワクしたので紹介します。 定義 循環的複雑度の定義はいろいろありますが、そのうちのひとつは次のように定義されています。（wikipediaを参照しました） グラフの終点ノードと始点ノードを結んだとき、循環的複雑度は、 ここで、 ： グラフのエッジ数 ： グラフのノード数 ： 連結成分 簡単にいうと、エッジとノードで囲まれた領域の数です。 具体例 例1 『分岐1回』 if (c1) { t = 1; } 循環的複雑度 = 5 - 4 + 1 = 2 例2 『分岐先で分岐』 if (c1) { if (c2) { t = 2; } } 循環的複雑度 = 7 - 5 +
Rspecとペアワイズ法でテストケース網羅に挑む - Qiita
想定読者 テストケースの網羅に苦しんでいるみなさま。 この記事はなんだ？ 以前、ペアワイズ法を用いたテストケース削減の手法の紹介LTをしました。好評だったので、デモ部分も含めて紹介する記事です。 LT内容 ここが変だよ。このテスト〜テストケース爆発と戦う〜 デモ pict pictをインストールして、2因子間網羅率100%の場合のテスト件数、3因子間網羅率100%の場合のテスト件数を確認してみる。 $ git clone https://github.com/Microsoft/pict.git $ cd pict $ make $ sudo install -m 0755 pict /usr/local/bin/pict
試験項目NG文言5選 - Qiita
はじめに 本投稿は、ソフトウェアテストの小ネタアドベントカレンダー24日目になります。 試験項目は「テスト実行者が10人実行したときに10人同じ手順、確認結果を得られること」が一つの要件だと思っています。 そこで、これまでの現場で見てきた試験項目に書いてあって困った文言たちをここでは紹介します。 本件は、筆者の個人的な経験に基づく、考えです。異論、疑問はコメントにお願いします。 NG文言集 1. 正しいこと 正誤を判断するための条件が書かれているのが試験項目であって、「正しい」という文言は書いてはいけない。 あなたの「正しい」は、テスト実行者の「正しい」とはイコールではない可能性がある。 【NG】 メッセージの文言が正しいこと。 【OK】 メッセージが「サーバのエラーです。時間がたってから再度お試しください。」であること。 現実には、「正しい」と書かれた試験項目がまかり通っている。見かけた
システムテスト自動化カンファレンス2017-2 #stac2017
2017/12/10(Sun)に開催したシステムテスト自動化カンファレンスのつぶやきをまとめました。 誰でも編集できるようになっていますので、自由に追加をどうぞ。 https://testautomationresearch.connpass.com/event/71564/
QAと開発の関係を良くするパターン・悪くするパターン - mhlyc -practice
これはソフトウェアテスト Advent Calendar 2017 - Qiitaの8日目の記事です。 アドベントカレンダーの昨日の記事は、テストを書くときに心がけていること - Qiitaでした。 テストコードを書くときのコツについて分かりやすくまとめられています。ぜひ読んでみてください！ さて、わたしはQAと開発の関係を良くするパターン・悪くするパターンと題して書いていきます。 QAと開発の関係 QAと開発は、一般に（少なくとも私の経験上は）密接な関わりがあります。例えば私の周りでは、以下のような関わりがあります。 開発部門が作ったプロダクトをQAがテストする 開発部門の開発プロセスについてQAがアドバイスしたり、一緒にプロセスの改善を考える 開発部門の品質評価、不具合分析についてQAがアドバイス、サポートする しかし、ここで重要になってくるのがQAと開発の関係性です。 QAと開発の関
QAエンジニア - Qiita
概要 この数年 「QA(Quality Assurance)エンジニア職」 という職種が重要視されております。 所謂、品質保証です。 2000年代には、求人自体も少なかった職種ですが、昨今はIndeedやスタンバイなどの求人情報専門の検索エンジンで 「QAエンジニア」 「テストエンジニア」 「品質管理エンジニア」 で検索すると大企業からスタートアップまで多くの掲載求人がヒット・掲載されています。 最近は、企画段階から 「QAエンジニア」 が参加し、プロダクトUI・UXの意見交換や、仕様書レビュー、テストフロー、リリース判定基準、どのテストレベルを対象とするか策定する。 そのため、QA職種だからこの範囲（領域）だけという決まりはありません。 また、QA職種詳細については 「品質担当でも名称がいろいろ」 に記載しております。 「QAエンジニア」 って、そもそもどのような役割なのでしょうか？ 下
Selfkleptomaniac — QC、QAとテストエンジニアリングの違いについて
Blogging is a disease: selfkleptomania, your normal condition. About GPG Public Key 原文はこちら。面白かったので訳してみた。 テストの世界では、日々の業務を指すのにたくさんの用語が使われている。皆さんもQAやQC、テストエンジニアリングという用語がお互いごっちゃになって使われているのを耳にしたことがあるはずだ。開発者が相手ならそれでも話は通じるだろうが、これらの用語について、さらにはソフトウェアテスティングの世界では一体これらがどのように使われているのかを考えてみるのも有益だろう。QCの古典的な意味は品質管理（Quality Control）で、品質についてあらかじめ決められた要件をみたしているかどうかを検証するプロセスのことをいう。組み立て工場のラインでは、製造された部品を工程の最後の箇所で抜き取ったり、
Business b-ridge（ビジネスブリッジ）
部門・会社にまたがるプロセスと情報をつなげる Business b-ridgeは、部門間・会社間に存在する、紙やExcelを介して行われている業務をスピーディにデジタル化し、 情報の一元管理・業務の進捗管理を実現するクラウドの「業務システム構築ツール」です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「UI自動テストツールとAI」〜AIを使った自動テストの「今」と「未来」〜
メトリクスによるソフトウェア品質把握と改善－ 演習を交えた品質測定評価の落とし穴とコツの習得 －
循環的複雑度に関する再確認
プロダクトに貢献する～テスト計画コンシェルジュとリリース高速化で品質向上を牽引する～