みなさんこんにちは。
ブログを6月から再開しましたが、またNews記事とKindle記事とあまりブログ主体のソフトウェアテストの記事がかけてなかったので、今後は月末に、その月で学んだこと/取り組んだことのアウトプットを記事化していきたいと思います。
自身の備忘録にもなりますので、できる限り投稿していきたいと思います。
また、本ブログも6月末で3周年を迎えました。
これもアクセス頂いた皆様、Twitterでフォロー頂いている皆様のおかげです。
改めて、ありがとうございます。
3周年も記念し、等ブログの構成も少し変えてみました。
主体としては、ソフトウェアテスト関連、テスト自動化をターゲットとしていますが、今後はそれに追加して「品質/ISO関連」「Workout」「食事管理/料理」等についても投稿していきたいと思います。
■記事内リンク
□1.ソフトウェアテスト
こちらでは、ソフトウェアテストに関して学んだことを取り上げています。
◇7月に読んだ書籍
【初めてのテストプロセス改善】
こちらはテストプロセスについて、記載されている書籍で、実業務に活かせるのではと思い購入しました。
書籍を1巡読みましたが、用語等はまだ完全に理解できていないため、繰り返し読み返したりしたいと思います。
私が普段行っているQA業務でも、「プロセス」について重視している現場ではありますが、正直工程やルールが重いと感じることがあります。
ただプロセス通りに行うことで、不具合を開発工程の上流から混入を防いだりする事ができるのも確かです。
開発プロセスは会社ごと、チームごとによっても色々あり、プロセス通りにやっているけどうまく行かなかったりする場合もあります。
それは、開発期間や開発するプロダクト、開発プロジェクトメンバーなど状況により異なるためと考えられます。
また、プロセス通りにすすめていても、終盤に人海戦術で対応したというケースもあると思います。
そのような場合に、標準的な「プロセス改善モデル」を導入し、少しでもプロセスが上手く進められればと思い、概要レベルではありますが、紹介したいと思います。
書籍の構成は、以下3部構成となっています。
・第一部：テストプロセス改善について
・第二部：テストプロセス改善のメリット
・第三部：テストプロセス改善の課題
【第一部】
第一部では、ISTQBシラバスに記載されている、標準的なテストプロセス改善アプローチが紹介されています。
「モデルベースドアプローチ」
モデルはベストプラクティスから作成されたもので、どのような手順でテストプロセスを改善していけば良いか示している。
トップダウンでプロセスを改善することが多いため、トップダウンアプローチとも呼ばれる。
・TPI Next
テスト戦略メトリクス、テストツール、テスト環境などテストプロセスの特定の側面をカバーする。
4つの成熟度レベルを定義 。
テストプロセスを16のキーエリアに分類し、４段階の成熟度によってレベル分けをすること
各レベルには、2～４のチェックポイントがある.
・TMMi
TMMiはプロセス改善のために、ステージ構造になっている。
そして組織のテストプロセスを成熟度レベルまたは、レベルで規定している。
「コンテンツベースドモデル」
・STEP
STEPは、TMMiやTPI Nextと違って、CTPと同様に改善特定の順序で行う必要がない。
STEPはコンテンツ参照モデルで、要件策定からシステム背筋にわたりテストの活動が継続するライフサイクル活動であるという考え方に基づいている。
・CTP
クリティカルテストプロセス（CTP)アセスメントモデルでは、モデルの中で特定しているテストプロセスが最重要（クリティカル）であることが前提。
モデルは12のクリティカルテストプロセスを識別している。
12のプロセスは、計画、準備、実行、改善の4つに分類される。
・QUINTEE
バルテス社がソフトウェアテストを習熟に、品質向上・生産性向上に関連する治験を体系化したもの。
限られたリソース、期間、コストの中で以下に最適なテストを効率よく実施するかを主眼において開発された。
ドキュメントの成果物は、IEEE８２９（ISO/IEC/IEEE29119）に準拠している。
「分析的アプローチ」
・原因分析
分析方法としては、原因結果ダイアグラムとして、フィッシュボーンチャート、インスペクションプロセス中の原因分析、標準例外分類の３つを紹介。
トヨタ自動車が開発した「なぜなぜ分析」もここに該当。
・GOMアプローチ
Goal、Question、Metricsの３つの要素。
具体的なゴールを設定。
どのような状態となったらゴールに達成するか。
ゴールが達成したかどうかを測定するメトリクス設定。
「ハイブリッドアプローチ」
モデルベースドアプローチと分析的アプローチを組み合わせてテストプロセスを改善していくアプローチ。
「その他アプローチ」
開発者のスキルによる改善、ツールを使用した改善、別のテストアプローチによる改善、規格の適合による改善、特定リソース優先による改善の５つがISTQBで紹介されている。
「第二部」
プロセス改善のメリットについて、記載されています。
メリットについては、以下3点が挙げられています。
1.市場バグを削減できる
市場バグが多く発生している状態は、前工程であるテストでバグを適切に検出できていないことを示す。
これは、テストの品質が悪い。
テストプロセスを改善すればテストの品質が向上し、バグ検出能力が向上する 。
その結果として市場バグを削減することができる。
2.相対的にコストが安くなる。
バグの修正は、バグがつくりこまれてからそれが見つけられるまでの期間が早ければ早いほど、コストが安くなる。
3.メンバーのスキルが向上する
テストプロセスを改善していくと、プロセスの明確化、仕組みか、マニュアル化が促進される。
メンバーのスキル向上に付与する。
「第三部」
テストプロセス改善のメリットと課題について記載されています。
ここでは、「PDCA」と「IDEAL改善フレーム」の２つのプロセス改善について記載されています。
・PDCAは、ISO9001にで取り上げられている計画（P）、行動（D）、チェック（C）、アクション（A）が有名。
・IDEAL改善フレーム
開始（I）、診断（D）、確率（E）、行動（A）、学習（L）で構成
【書籍について】
テストプロセスの改善にこれから取り組んでみたいという方には、導入として良い書籍ではないかと思います。
ただ、紹介されている内容は、ISTQBシラバスのアドバンスレベルのテストマネージャーに紹介されているプロセス、ISO29119の内容が占めていたと思います。
概要的な説明となっており、個人的には具体的な使用例があればと思いました。
テストプロセスについて、標準的なものについてまとめられているので、業務のテストプロセスを改善したい、参考にしたいなどの場合に、役立つ1冊と思います。
□2.業務関連
◇不具合分析
私が行っている業務において、対象のプロダクトに不具合が一定以上検知された場合、検知した不具合をもとに「不具合分析」を行っています。
「不具合分析」を行い、プロダクトで他不具合が混入していないかの追加テストを行ったりします。
前述で紹介した「初めてのテストプロセス改善」にも記載されていた「原因分析」にあたる内容です。この「不具合分析」なのですが、「一定以上検知」と記載しましたが、この件数が不透明であったりしました。
会社やチームよっては、5〜10件、10件以上と指標があるかもしれません。
ただ、指標通りに行う場合、規定数の10件など、不具合が一定数検知されたタイミングで、不具合分析を行うと分析が大変になるかと思います。
「学んだこと」
今回、私が学んだこととしては、「不具合分析」は、不具合が検知された際に、都度都度分析情報を整理しておくことです。
不具合が発生する画面、機能、発見したプロセスはもちろん、不具合の要因となったことを控えておくことです。
この「不具合分析」は、現職ではまだ数回実施しただけですので、「不具合分析」のテンプレートシート用意する、または一部の自動化して「不具合分析」の時間を抑えるなどの取り組みを行って行きたいと思います。
「不具合分析」の取り組み方など、詳細については、別途記事化してみたいと思います。
◇オフショア開発メンバーとのコミュニケーション
私は、前職や現職では、オフショア開発メンバーとのやり取りを行う機会が多々あります。
オフショアの開発メンバー（QA,QCも含む）とコミュニケーションを行う場合は、基本的にブリッジSEの方がいらっしゃる為、言葉の意思疎通に大きなズレは生じません。
ただ、日本で「当たり前と思っていることが通じない」ことが、往々にしてあります。
また、共有されているであろう情報が、実は伝わっていなかったりするケースも多々あります。
特に、途中からオフショアメンバーとやり取りを行うチームに、途中からアサインされた場合に、起きる傾向があります。
今回、私の実体験として、オフショア開発メンバーに、情報が正しく伝わっていないケースが有り、そこで学んだことがありました。
「学んだこと」
今回学んだことは、「情報の棚卸し」です。
特に、オフショアチームとやり取りするチームに、途中から参加した場合は、必ず行うべきと思いました。
例としては、以下が挙げられます。
・マニュアルなどのドキュメントは共有フォルダ等にアクセスできるか
・優先タスクは明確になっているか
・日本側とオフショア側でふりかえりを行っているか
共有フォルダ等については、セキュリティ関連により、アクセスを禁止している場合があります。
その際、最新のマニュアルや最新の情報をオフショアチームに別の手段で連絡する必要があります。
優先タスクにおいて、適時明確にしておく必要があります。
アジャイル開発を行っている場合、優先度の高いタスクが割り込むケースがあると、元々予定していたタスクの優先度を下げる必要があります。
更に、オフショア開発チームは、日本からのタスク依頼を実直に行っていただくケースが多いと思います。
ただ、設計、実装、テストは双方行っていても、「ふりかえり」を行っていないケースがあるのではないでしょうか。
日本→オフショア開発チームに、タスク依頼、要望・改善提案をするのはあると思いますが、逆のケースは稀であるかと思います。
彼らにも、日本側に思うところや、要望があると思います。
そういった場合は、「ふりかえり」を行い、双方の意見、コミュニケーションを行う必要があると改めて思いました。
もしオフショア開発チームとやり取りされている方がいらっしゃったら、「ふりかえり」等のコミュニケーション機会を増やすことをおすすめします。
□3.ブログ関連
こちらでは、ブログ関連で学んだことを述べていきたいと思います。
当ブログは、3周年を迎えましたが、一時期更新が止まっていた時期があり、アクセス数は、一時期減ったりしていました。
ブログサイトやブログ記事の改善について、今まで複数の書籍やサイトで学んだことをまとめています。
今後はブログ関連の記事情報も、自身の備忘録も含め、投稿していければと思います。
◇書籍【ブログ飯】
こちらは、ブログ再開をきっかけに、ブログの改善を図ろうと思い購入しました。
ブログ自体は、学習を行いつつ、それが業務でも活かせ、かつちょっとしたお小遣い稼ぎができればと思い始めました。
結果、Google Adsenseでの収益が少し入り、昨年では転職のきっかけにもなりました。
正直、レンタルサーバー代、ドメイン代、Wordpressテーマ代のトータルを考えると、まだまだ収益としては不十分ですが、自己投資としてはスキルアップにもつながったので、辞めずによかったと思います。
直近半年は、現職の業務に慣れず、ブログ記事投稿を中断してしまったため、再度ブログ改善を進めていきたいと思います。
そんな中、この本は、ブログ運営の本質を再度気づかせて頂きました。
書籍の中で特に為になったことをピックアップしました。
・SEOの設定に時間をかけるのであれば、記事の質を上げる
自分も前は、SEOについてかじったりしましたが、これはごもっともな内容でした。
Google、Yahoo等の検索は、「調べたい」「知りたい」を目的に活用し、ヒットした記事を参考にします。
企業が書いた記事、個人が書いた記事などはさほど気にせず、記事の内容や質が求められます。
自分もなるべく有益な記事を作成するように、努力はしていますが、日々の改善や創意工夫がおろそかになっていたと思います。
これを機に、改めて書く記事は、アクセス頂くユーザーの為になるもの、興味を持ってもらえるものを発信していけるように、努めたいと思います。
・自分の経験、知識、オリジナリティを記事で発信する
こちらについてもブログ立ち上げ当時は、ソフトウェアテスト、テスト自動化にフォーカスした個人ブログはほとんどなかった（Quiita、note、はてなブログなど媒体を利用したブログはあり）ため、自身がそれを築いていきたいという思いがありました。
JSTQBシラバスやSelenium Python、自動化テストページといった内容を個人ブログで掲載していたのは、あまりなかったと思います。
最近は、News記事、kindle記事のみといった惰性で書いてしまっていたので、自身の経験、知識、オリジナリティを活かした記事を投稿していきたいと思います。
・ブルーオーシャンを創り出す
これは、一つ上のオリジナリティと関連するのですが、ブログやyoutube等の動画では、様々なコンテンツをターゲットととしたものがあふれており、ほぼレッドオーシャンです。
筋トレ、ダイエット、料理、ゲーム実況など様々なものがあります。
その中で、成功している人はほんのわずかです。
ブログやYoutubeの初期から活動していた人、アイデアを駆使して様々なコンテンツを生み出している人が主に該当するのではと思います。
私もソフトウェアテスト、テスト自動化、業務効率化の他、ISO、品質、筋トレ、食事管理などを今後発信していこうと考えています。
ソフトウェアテストと筋トレが全く関係ないではないかと思う方もいらっしゃると思います。
ただ、ソフトウェアテストの業務を行いつつ、健康や体調管理に気を遣うようなブログはあまりいないのではないかと思います。
ソフトウェアテスト業務やISO（9001、27001）業務を行いつつ、ベンチプレスプレス120kgを持ち上げるのは、さほどいないでしょう（笑)
私は、このようなオリジナリティを活かし、ブルーオーシャンを生み出せていけたらと思うようになりました。
【書籍について】
ブログなどの製作活動を行っている方には、とても参考になる一冊ではないかと思います。
自分のように、ブログを改善したい、集客を増やしたい等思う方には、ベストな1冊だと思います。
◇GoogleアナリティクスGA4の移行
こちらについて、ブログ等Googleアナリティクスを利用されていない方はピンとこないと思いますが、Googleアナリティクスが7月1日から「UA」⇒「GA4」へ切り替わることとなりました。
これは、約1年前あたりからアナウンスがあったのですが、私はつい最近になって変更を終えました。
変更をやろうと思っていたのですが、正直わかりづらくおこなっていませんでした。
Webで探しても、企業ページが上部にヒットし、問い合わせをしないと記事内容の全体が見えなかったり、書籍でも各項目の解説は丁寧に書いてあるのですが、導入部分が省かれていたりしていました。
最終的には、Googleアナリティクスのヘルプページを参考にしました。
（正直こちらもわかりづらい内容でしたが）
備忘録として、簡単な流れを記載しておきます。
【GoogleアナリティクスGA4への切り替え】
①ステップ１：GA4プロパティを作成
・管理タブで、プロパティを作成
②ステップ２：データストリーム接点
・データストリームで、ストリームURLを設定
③ステップ３：データ設定
・データ設定⇒データ保持：14ヵ月に設定
④ステップ４：サービスとリンク
・Google広告、Serch Console等リンク設定
⑤ステップ５：設定アシスタント設定
・アシスタントの各項目を設定し、設定後は「完了」へ
上記設定をしないと、アナリティクスアクセスする度に以下エラーメッセージが表示され、ブログにアクセスしたユーザーのデータ等が集計されません。
参考になれば幸いです。
□4.筋トレ関連
こちらは、筋トレが長続きしない自分に、改めて筋トレを「習慣化」したいと思い、直近の取り組みを記載します。
・週1、２回のジム通い→毎日通いへ
習慣化しない理由としては、週に1回、2回の頻度だと、さぼってしまう傾向があります。
人によると思いますが、仕事やプライベートが多忙で、週末行こうとしたジムに行かないなどあると思います。
自分がそのパターンで、疲れたからジムに行かず、自宅でこもってしまい、一歩も外に出ないなどありました。
特に自分の場合は、リモートワークがメインなので、朝早くから夜遅くまで仕事をして、12時間以上が続いたときなど、翌日が休みの場合は遅くまで寝ていたりしていました。
この状態が数か月続き、疲れやすい体質になり、発熱で1週間ほど休む事態までになりました。
原因は、ストレスによる過食や、運動不足だったと思います。
疲れていたとしても、適度な運動（ウォーキングなど）を行うべきだと思い、体調を崩して回復した後から、早朝にウォーキングを毎日おこなうようにしました。
15分、30分と短い時間でも、歩くようにして、日光を浴びるように努めました。
このウォーキングを約1ヵ月続けることができました。
帰りにコンビニのコーヒー（機械で入れるタイプ）を買うことが続けられた理由かと思います。
2ヶ月が経ったころに、ジムに切り替えて、ウォーキングと筋トレを行うようになりました。
・１，２年続けているが筋肥大しない
週1回、2回の筋トレは、約2年ほど継続していたのですが筋肥大しませんでした。
ベンチプレス（胸トレ）をしていて、胸はある程度厚みが出ましたが、他の部位は変わりませんでした。
これを脱したいと思い、部位ごとに筋トレをして、間にウォーキングを行うようにしています。
胸、背中、肩、ウォーキング、腕、足、腹といったように、日ごとに部位を絞って、筋トレを行うことで、約30分でトレーニングを済ませることができるようになりました。
ジムの毎日通いは、3週目ですが、肩が以前よりくっきりしてきています。
少しずつではありますが、効果が表れてきていると思います。
■最後に
以上、７月に学んだこと、取り組んだことは以上となります。
これら学んだことは、情報を整理し別途記事化を行っていきたいと思います。
最後まで見て頂き、ありがとうございました。
