検索改善Part1(辞書登録)

はじめに

こんにちは! 株式会社Voicyでデータアナリストをしている翔斗です。

今回は前回のvoicyの検索改善についての具体的な施策について話していきたいと思います。

上記記事を読んでから具体的な施策みていただけるとありがたいです。

辞書登録

今回話していくのはチャンネル名の誤検索を辞書に登録していき結果なしを減らすという対応になります。

現状把握

まず、今回のこの施策に至った経緯です。

前回の記事でも出しましたが、検索改善しようにもいくつも種類があります。 Voicyではまず結果0を減らしていくことに注力することにしています

その中でも今回注力していくのは、有名チャンネルなど聞きたい人が多いがチャンネル名が難しく検索できないというペインをなくす作業になります。

例えば: 精神科医で精神医学や心理学の話をしてくださっているkagshunさんという方がいます。

チャンネル:kagshun/EMANON@精神科医「精神科医のココロに効くラジオ」/ Voicy - 音声プラットフォーム

このチャンネルですが、今までのVoicyの検索ではひらがなやカタカナで かぐしゅん/カグシュンと検索された際に該当のチャンネル結果を返すことができていませんでした。

一般的な検索エンジンでは下記のように誤検索や検索結果が少ないものは関連の検索をした上で検索ワードを表示してくれます。

かぐしゅん

結果ユーザは多少ワードが意図と違っている状態で検索をしても目的にたどり着くことができます。

手法・実装手順

今回Voicyでは、手動で辞書を作成していくことにしました。

理由はいくつかありますが、 主にVoicyの検索はチャンネル名などが多いため、固有名詞での検索が多くなります。

  1. 過去の検索結果0件のキーワードを洗い出す
  2. キーワードからチャンネルと思わしき結果を抽出する
  3. 該当のワードに対してどんなチャンネルを意図した検索かその後の検索やフォロー・聴取状況などを利用し把握する
  4. 該当チャンネルが出るように誤検索ワードと紐付けを行う
  5. ユーザが誤検索ワードを検索した際に辞書で登録したワードを一緒にor検索でクエリに投げるようにする
  6. 定期的に1〜5を繰り返し新しく辞書を追加していく

結果

上記対応を行うことで表記揺れなどの曖昧な検索でも結果を補完して表示することができました。

まとめ

今回の対応でできたのは既に一定のユーザがペインに感じている、検索したが結果が出ないというという体験を減らすことができました。

しかし、データをもとに対応しているため、新規のチャンネルには機能しないのが欠点になります。今後は、新しく有名人がVoicyを初めてくれた際など事前に誤って検索されそうなワードを登録していくことでや間違いやすいチャンネル名でも最初から不自由を感じない体験にしていきたいと思います。

次回

今回は改善の1つとして辞書登録の話を記載したので次回は、さらに結果0を減らしていくために他にどんな施策を行ったのかを記載していきたいと思います。

「Voicy Tech Story Vol.4」を技術書典13に出稿します!

はじめに

こんにちは、エンジニアブログチームのきーくん(@komura_c)です。

技術書典13に、Voicy社内の有志メンバーによる新刊の「Voicy Tech Story Vol.4」を出稿します。

techbookfest.org

今回の技術書典13はオンラインだけでなく、オフラインでも開催されます。

  • (オンライン) 9月10日 〜 9月25日: 技術書典オンラインマーケット
  • (オフライン) 9月11日 (11時~17時) : 池袋サンシャインシティ 展示ホールD (文化会館ビル2F)

Voicyにとって4回目となる今回は、オンラインとオフライン会場へのブース出展で参加します。 過去の出展は全てオンラインのため、メンバー一同、より一層楽しみにしています!

「Voicy Tech Story Vol.4」とは

「Voicy Tech Story」は、Voicy社内の有志メンバーによる技術書典の部活動で作成している、音声の技術書です。 電子版+会場での物理本頒布となっており、価格は1,000円です。

  • Chapter 1 : 音声認識を応用して無声区間を自動削除する手法とその実装 - せんちゃん (@thousan_da)
  • Chapter 2 : IPPON グランプリ風のお題を読み上げる技術 - みっきー (@saicologic)
  • Chapter 3 : 音声テック企業が自社プロダクトで、音声イベントを成功させた話 - えも (@kitajima_snooze)
  • Chapter 4 : IndexedDB (Dexie.js) × Angular でブラウザにオーディオ ファイルをできるだけ保存する - きー (@komura_c)
  • Chapter 5 : 音声からノイズを除去する方法を学習する - やまげん (@yamagenii)
  • Chapter 6 : Angular で hls を再生してみた - しー (@shinobear01)
  • 表紙デザイン / 展示デザイン - きょーちゃん (@mi___ko120)

今回も愉快な有志メンバーによる音声×技術の記事が集まっています! ぜひ、ご興味のある方は手に取ってみて下さい。

おわりに

この記事を読んでいただき、ありがとうございました。 一緒に技術書典を楽しんでいきましょう!

また、出展の感想は音声発信チームの「voi-chord」でも発信を行なっています。こちらの音声もぜひお聞きください! voicy.jp

GoのORMのSQLBoilerでDuplicateEntryのエラーハンドリングする方法

こんにちは!株式会社Voicyでバックエンドエンジニアをしているたーふーと申します。
簡単に自己紹介をさせていただくと、自分は去年の9月にVoicyに入社したので、入社してもうすこしで1年くらいになります!

今回はGoのORMであるSQLBoilerでDuplicateEntryのエラーハンドリングする方法についてお話しできればと思います!

自分自身Go歴は浅いのですが、 その中でSQLBoiler関連の情報が少ないように感じた経緯があり、今回この記事を書かせていただきます。

なので同じような方の参考になれば幸いです!もし興味があれば是非ご覧ください!!

続きを読む

「iOSDC Japan 2022」にVoicyのエンジニアが登壇します (チャレンジトークン有り)

2022年9月10〜12日に開催される「iOSDC Japan 2022」に、VoicyのiOSエンジニアが登壇します

iOSDCのチャレンジトークンは #ボイステック です

もう一つのチャレンジトークンは以下の放送にアクセスしてみてください

voicy.jp

「iOSDC Japan 2022」はエンジニアが主役の、iOSと周辺技術を題材としたカンファレンスです。今年はオフラインとオンラインのハイブリッドでの開催となります。

Voicyも一緒にiOSエンジニア界隈を盛り上げたくシルバースポンサーとして協賛をしています。

詳しい内容はHPをチェックしてください! iosdc.jp

登壇スケジュール

  • タイトル:音声プラットフォーム「Voicy」のiOS開発について
  • 登壇者 :立花 和也 / @kzytcbn315
  • 日時  :2022/09/12 16:50〜 Track D スポンサーセッション(20分)

fortee.jp

立花のインタビューはこちら

corp.voicy.jp

  • タイトル:音声配信アプリにおけるiOSを使った音声配信の全てと裏側
  • 登壇者 :遠藤 拓弥 / @entaku_0818
  • 日時  :2022/09/11 13:35〜 Track C レギュラートーク(20分)

fortee.jp

遠藤のインタビューはこちら

www.wantedly.com

採用情報

Voicyでは一緒に働くiOSエンジニアを募集しています!

発信情報

Voicyのエンジニアチームが音声発信しているVoicyチャンネルはこちら!

voicy.jp

Voicyのテックリードの仕事紹介

はじめに

こんにちは、Voicyでテックリードをしている、みっきーです。 今回はVoicyのテックリードがどんな仕事をしているのかという話をしたいと思います。

 テックリードは職能の一つです。その仕事内容はVoicyのようなスタートアップの場合、投資ラウンドやエンジニア組織の大きさによって仕事の内容が変わっていきます。昨今さまざまなテクノロジーを活用したスタートアップが出てくる中で、会社によってテックリードの実際の仕事内容は変わってくるとは思いますが、Voicyの一つ事例としてご紹介します。Voicyのプロダクト開発組織は、執筆時点で27人です。この中には、PdM、デザイナー、エンジニアなどが含まれていて、テックリードの役割は私1人です。Voicyでテックリードの役割になったのは私が最初ですが、簡単にテックリードになった経緯を説明すると、2020年1月の入社当初はバックエンドエンジニアとして入社しましたが、様々な出来事があり、3ヶ月後にプロダクト開発のリーダー(開発責任者)をすることになりました。仕事内容としては、エンジニアリングマネージャーという役割をしていてエンジニアの採用やエンジニア組織作りを中心にしていましたが、テックリードらしい役割もしていて、将来、Voicyが音声プラットフォームとして安定して品質がよく長期に成長し続けられるように、開発生産性を上げるための技術の標準化、技術選定、情報セキュリティ(ISMS)、監視強化など、主に非機能要件といわれるようなところを中心にマネージメントをおこなっていました。エンジニア組織全体が20人を超えてきたところで、自分よりもピープルマネージメントに長けていたのと、組織全体がデータドリブンで動けるようになったこともあり、データ基盤を作っていた当時、データチームのリーダーであったやまもとにピープルマネージメントのバトンを渡し、私がテクノロジーマネージメントに注力していくことになりました。

 マネージメントというと、ピープルマネージメントをイメージする方が多いと思いますが、急成長していく組織においては開発をしていく上で必要な役割が3つ必要です。わかりやすい説明として、広木大地さんが、クネビンフレームワークを元に説明したツイートをご紹介します。

 クネビンフレームワーク(Cynefin Framework)とは、VUCA(Volatility、Uncertainty、Complexity、Ambiguity)の世界において、実際の世界をどのようにとらえて、どのように考えて行動したらいいかを体系づけたものです。創業当時はChaoticな問題がほとんどなのでその役割をになう人がCTOの役割として行動し、プロダクトマーケットフィットが上手くいくと組織が大きくなっていきComplexな問題が多発していきます。こうしていくるとエンジニア組織づくりを得意とした専任のVPoE/EMの役割の人が必要になってきます。サービスが順調に成長していくと、今度はさまざまな難易度の高い技術的な課題(技術的負債など)の解決が必要になってくるため、テックリード的な仕事が必要になってくるということが、実体験からもわかります。Voicyでは、創業時は共同創業者の窪田がChoticの時代をすすめ、シリーズAのComplexな時代なってくると様々なEMがエンジニアリング組織づくりをおこない、いよいよシリーズBになってくるとComplicatedな時代になってくるので、テックリードを専任で割り当てていくとバランスのよいエンジニア組織になっていきます。

前置きは長くなりましたが、実際にVoicyでやってきたテックリードの仕事を1つご紹介します。

ライブラリの標準化

 入社したときに最初に着手したのはGoライブラリの標準化です。入社して驚いたのが、バックエンドAPIで利用しているORMのライブラリが3種類あったことです。それは、xorm、 gorm、sqlboilerでした。前職ではRailsを使っていたのでActiveRecord一択しかなかったのですが、当時のGo開発はデファクトスタンダードがない状況だったのと、個人のエンジニアが好きなライブラリを選んで作られており、その時に決済サービスの新規開発やバックエンドAPIのリプレイスが必要だったため、このタイミングでライブラリの標準化をおこないました。また、これらのライブラリを用いたレイヤードアーキテクチャ構成のAPIサーバーの標準テンプレートも作成しましたが、私はライブラリ選定だけおこないました。

主な利用ライブラリ

注: 2020年時点の選定です。

 Webフレームワークはechoを採用しました。これはすでに同じフレームワークを利用していたこともあり、学習コストの面で継続しました。ORMは、1つのデータベースが複数のサービスから呼ばれていることもあったため、スキーマから自動で構造体を生成してくれるSQLBoilerにしました。それ以外はすでに使われていたライブラリでしたが、似たようなライブラリも存在するため固定することに意味がありました。

社内で利用実績があるというのも大事ですが、自分が自身をもってライブラリを選定するときに、私が参考にしている情報をいくつか紹介します。

実際に利用して習得しやすいか?

社内の利用実績があったとしてもすでに使っていた人が退職している場合もあって聞けないこともあるでしょう。そのため、実際に似たようなライブラリと比較して使いやすいか、コードを読んで理解できるか、修正可能かコードリーディングをします。

Githubスターの数

利用者が多いと不具合の改善が早いことが多いです。testifyはテストモジュールの中でもスター数が多く、テストコードを完結に書けます。

ソースコードの更新頻度が高い

リリースマネージメントが定期的におこなわれているかが大事です。もし、コードに脆弱性が見つかったとしてもセキュリティーパッチが早く適応される可能性があります。

コピーレフトなライセンスのソフトウェアを利用する

代表的なのは、MIT LicenseとApache License 2.0です。利用は自己責任ですが、商用利用が可能です。凖コピーレフトLGPLや、コピーレフト型のGPLは改変したソースコードの開示が必要ですので気をつけましょう。

個人スポンサーや企業がサポートしている

OSSはそれ自体が利益を生み出すことが難しいですが、エンジニアは無給メンテナンスはいずれ限界がきます。Githubの個人スポンサーや企業がメンテナンスしているとお金に余裕があるため安心感があります。もちろん、企業経営に左右されるコードが突然ダウンロードできなくなることもあるため、利用する場合はフォークしておくのがおすすめ zapはUber社のOSSです。またVoicyで利用しているフロントエンドフレームワークはAngularでGoogleが開発しているフレームワークです。

後方互換性をv2、v3などで明示されている

echoとsqlboilerです。長期にメンテナンスされるということは、後方互換性を維持していくのは大変困難になってきます。ライブラリをインストールするときに明示的に選べるほうが、利用する側もバージョンを固定できるので利用しやすいです。

コントリビューターの数

ライブラリによっては1人で開発されているのはありますが、長期的に見たときには作者の心が折れて更新が止まってしまうことがありそうするとセキュリティーパッチの対応もできなくなります。コントリビューターの数が多ければ、改善もされますし、オリジナル作者がギブアップしたときもバトンタッチされることもあります。

マイナーだけどどうしても使いたい

それでも、自分でライブラリは作りたくないが、どうしても作者1人しかいないときのライブラリを使いたい時はどうすればよいでしょう? それは自分自身の信頼度を上げれば良いので、責任を持って全部のソースコードを読んだ上で使うか判断するのと、後任のためにドキュメントを残しておくとベストです。 でテックリードになりました。

最後に

他にも、話せることはたくさんあるのですが、もっとテックリードの話しが、聞いてみたいという方、ぜひMeetyでお話しましょう

meety.net

そして、これからのキャリアを考えるときに、どの道に進んでいくか具体的な役割について知りたい方は下記の書籍を読むのをおすすめします。

www.oreilly.co.jp この本は、テックリードとは何をする人なのか説明した数少ない本です。

www.oreilly.co.jp テックリードは、普段の仕事をしているだけでは必要な知識を身につけるのは難しいです。何事も基礎は大事ですので、この本では効果的なソフトウェアアーキテクチャの設計、構築、維持をするために必要なスキルや知識が体系立てて解説されています。全体を俯瞰してみるのにとても良い本ですのでおすすめします。

それでは、また次回、投稿されるのをお楽しみに!

ffmpeg.wasmをブラウザ上で動かしてみた

はじめに

こんにちは、主にWebフロントエンドエンジニアをしているきーくん(komura-c)です。今回は業務とは関係なく、ffmpeg.wasmに興味を持ったため、ブラウザ上で動かしてみました。主にフロントエンド側の処理について追って、書いてみたのでぜひ読んでみてください!

ffmpegとは

ffmpegはオーディオ、ビデオなどを変換、処理するためのライブラリ、ツール群です。 https://github.com/FFmpeg/FFmpeg

ffmpegのコードは主にLGPLライセンスで公開されていますが、依存ライブラリにより多様なライセンスが適用されています。 https://github.com/FFmpeg/FFmpeg/blob/master/LICENSE.md

歴史のあるソフトウェアのため、オーディオや動画コンテンツを変換、圧縮するために使ったことがある方も多いのではないでしょうか。

ちなみに、ffmpegのコードサンプルが弊ブログの記事にあります。良かったらこちらも読んでみてください。 tech-blog.voicy.jp

ffmpeg.wasmとは

ffmpeg.wasmは、ffmpegをWebassembly / Javascriptコンパイルし、ブラウザ上で動くようにするためのOSSです。 https://github.com/ffmpegwasm/ffmpeg.wasm

ffmpeg.wasmは、次の2つのライブラリによって構成されています。

@ffmpeg/coreは、Emscriptenを使用してffmpegのC / C++コードをWebassembly / Javascriptコードにコンパイルするものです。ライセンスはffmpegやそれに依存する外部ライブラリが適用されます。

@ffmpeg/ffmpegは、@ffmpeg/coreを使用しやすくするためのラッパーライブラリです。MITライセンスが適用されています。 https://github.com/ffmpegwasm/ffmpeg.wasm#what-is-the-license-of-ffmpegwasm

今回は、@ffmpeg/ffmpegの方を見ていきます。

ちなみに@ffmpeg/coreの部分である、ffmpegコンパイルする手順もメンテナーの方が公開しています。 https://github.com/ffmpegwasm/ffmpeg.wasm#how-can-i-build-my-own-ffmpegwasm

ffmpeg.wasmをブラウザ上で動かす

今回は、趣味で作成したmusic-waves-visualizerというサイトで試しました。webm形式で書き出した動画をmp4形式に変換する処理で使用しました。 music-waves-visualizer.vercel.app

ffmpeg.wasmの導入手順としては、次の通りになります。

まず、一般的なnodeパッケージを使用するのと同じように、npmを使ってinstallします。(npmの説明は省略)

npm install @ffmpeg/ffmpeg

その後、次のようにコードを書きます。

// この辺りはffmpegとは関係ありませんが、使用例として記します
...
// ファイル名を定義
const movieName = "movie_" + Math.random().toString(36).slice(-8);
const webmName = movieName + ".webm";
const mp4Name = movieName + ".mp4";
...
// 動画を生成するMediaRecorder(ffmpegと関係ないため説明は省略)から
// 取得したrecordedBlobsをwebm形式のBlobに変換します
const webmBlob = new Blob(recordedBlobs, { type: "video/webm" });
// webmBlobを8ビット符号なし整数値の配列であるUint8Arrayに変換します
const binaryData = new Uint8Array(await webmBlob.arrayBuffer());
// ffmpeg.wasmでwebm形式の動画データをmp4形式に変換します
const video = await generateMp4Video(binaryData, webmName, mp4Name);
// 返ってきたvideo(Uint8Array)をmp4形式のBlobに変換します
const mp4Blob = new Blob([video], { type: "video/mp4" });

https://github.com/komura-c/music-waves-visualizer/blob/master/pages/index.tsx#L167-L171

import { createFFmpeg } from "@ffmpeg/ffmpeg";

const ffmpegCoreVersion = "0.10.0";
const corePath = `https://unpkg.com/@ffmpeg/core@${ffmpegCoreVersion}/dist/ffmpeg-core.js`;

export async function generateMp4Video(
  binaryData: Uint8Array,
  webmName: string,
  mp4Name: string
) {
// ffmpegのインスタンスを生成します、読み込むjsのファイルパスをcorePathに渡します
  const ffmpeg = createFFmpeg({ corePath, log: true });
// ffmpegを読み込みます
  await ffmpeg.load();
// Emscriptenが提供するFSにより、Node.jsのインメモリファイルシステムのライブラリである
// memfsにwebm動画のバイナリデータを保存します
  ffmpeg.FS("writeFile", webmName, binaryData);
// runでコマンドラインツールと同じようにffmpegにオプションを渡し、webm動画をmp4動画に変換します
  await ffmpeg.run("-i", webmName, "-vcodec", "copy", mp4Name);
// 変換したmp4動画のバイナリをmemfsから読み込みます
  const videoUint8Array = ffmpeg.FS("readFile", mp4Name);
  try {
// WebWorkerスレッドで行われている、ffmpegの実行を強制終了し、memfsを削除してメモリを解放します
    ffmpeg.exit();
  } catch (error) {
// 今のところ確実にprocess.exit(1)の例外が投げられてメインスレッドの処理が止まってしまうため、catchしています
//(検証ツールで見る限り正常にWebWorkerが削除されているのでメモリは解放されているっぽいです)
}
  return videoUint8Array;
}

https://github.com/komura-c/music-waves-visualizer/blob/23893b79c556fed3965d50cd2143d1a6d634e5ce/scripts/Ffmpeg.ts

親切にもライブラリの提供するAPI一覧は、リポジトリにまとめてありdocs/api.mdを見れば、何をしているかが大体わかります。 https://github.com/ffmpegwasm/ffmpeg.wasm/blob/master/docs/api.md

ここで、実装する際の注意点が3つあります。

1つ目は、デフォルトでローカル環境のcorePathが/node_modules/@ffmpeg/core/dist/になっており、必要なファイルが読み込まれない場合があることです。 https://github.com/ffmpegwasm/ffmpeg.wasm#why-it-doesnt-work-in-my-local-environment

@ffmpeg/ffmpegffmpeg.load()時に、createFFmpegのcorePathに指定したファイルパスから、次のファイルを読み込みます。

先述したコードでは、corePathにhttps://unpkg.com/というnpmのライブラリを非公式で有志がCDNとして公開しているURLを使用しました。 ローカル環境以外では、corePathを指定しなければ同様にデフォルトで、unpkgのCDNのURLで読み込まれます。 https://github.com/ffmpegwasm/ffmpeg.wasm/blob/master/src/browser/defaultOptions.js

2つ目は、ffmpeg.wasmはSharedArrayBufferを使用しているため、対応ブラウザが限られることです。 自分はChromeでしか確認していません。 https://caniuse.com/sharedarraybuffer

SharedArrayBufferを使用するにはホストしているサーバーに次のHTTPヘッダーを含める必要があります。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

3つ目は、読み込むファイルには2GBの制限があることです。 これはWebAssemblyの制限ですが、将来的には4GBになる可能性があるそうです。 https://github.com/ffmpegwasm/ffmpeg.wasm#what-is-the-maximum-size-of-input-file

おわりに

ffmpeg.wasmのフロントエンド側の処理について、少しではありますが紹介しました。 @ffmpeg/ffmpegが読み込むcorePathに関しては、実プロダクトで使うのであれば@ffmpeg/coreをビルドしたファイルか、CDNのファイルを静的に置いてセルフホストし、そのパスにした方が良いと思いました。 ただ、前述したffmpegのライセンス周りがややこしいことや、wasmバイナリのライセンス表示などの問題があるため、デモで試しに使ったものであるということもあり、今回はそうしませんでした。 ffmpeg.wasmはまだ実験的なプロジェクトのため、実プロダクトで使うのは厳しいのではないかなと思いつつ、ffmpegがフロントエンドで動かせるのはとてもロマンのあることだと感じました。 この記事が少しでも参考になれば嬉しいです!

QAをする上で心がけていること

はじめに

はじめまして!VoicyでQAエンジニアをしているまっつんです。

スタートアップ企業1人目のQAエンジニアが普段心がけていることについて話してみようと思います!

チームビルドや品質向上施策を行うのも仕事なのですが、1人目のQAエンジニアということもあり、自分で手を動かす(テストの設計や実施)ことも多く、今回はそのテストの部分が中心になります。

心がけていることその1:とりあえず疑え!

​​ テスト設計を行う際、仕様書が正しいと盲目的に信じていませんか?
もちろん基本的には正しいはずです。
「悪意を持って仕様をおかしくする」なんてことはないと思います。
しかし仕様書を作るのも人間です。誤りが絶対にないとは言い切れません。

そういう意識を持ってテスト設計をするとあら不思議
「この条件の仕様定義されてない?」
「この動作って要件と合致してない?」
といったような疑問が出てくるはずです。

出てきた疑問点を確認・クリアにすることで、サービスや新しい機能がリリースされる前に仕様バグを減らすことができます。

また、疑うのは何もテスト設計時だけではありません。

テスト実施時にもその精神があるとなおよしです!
テスト実施時の気付きも遅くはありません。

何よりもリリース前に検知することが重要です。

心がけていることその2:視野を広く持て!

テストの実施時に以下のようなテストケースがあった場合どう言ったことを確認しますか?

・テスト手順
「フォローボタンを押すする」
・期待結果
「フォロー中に変わること」
「フォロワーが1人増えること」

「フォロー中に変わること」「フォロワーが1人増えること」だけを確認しますか?

もちろんしっかりテスト設計した上で作成されたテストケースであれば、期待結果の確認だけでも重大なバグは見つけることができると思います。

でももしかするとこれ以外に思わぬ影響が出ているかもしれない。
せめて同じ画面くらいはサラッと確認しませんか?

そういったバグを検知するためにも視野を広げて、少しだけでも期待結果以外の部分にも目を向けてみませんか?
テストケース外のことまで気にし始めたらキリはないのですが、ほんの少し意識するだけでも効果があると思います。

実際に複数の人に同じテストケースをやってもらっても、全然見つかるバグの数が違うことがあります。
多くのバグを見つける人は、テストケース外のバグも見つけてくれる人がほとんどです。

最後に

上記の2点は知識や経験問わず、誰でも意識すると効果があると私は思っています。

実際にテストの設計や実施をする方は、ほんの少しでもこういったことを意識してみると、テストの効果が上がるかもしれません。

ぜひ試してもらえると幸いです。

次回私がブログを担当する際にはもう少し、技術的な面にも触れてみようと思います。