徒然なるままに

学習メモがメインです

最近気づいたアウトプットのメリット

最近「アウトプットしていて良かった」と思ったことがあったので、雑に書いてみます。

私の過去

昔(4~5年前)は、すごいつよつよエンジニアがアウトプットしているイメージを持っていました。一方で私自身はアウトプットをしたことが無かったです。業務や学習だけではなく、趣味としてもブログを書いたこともなく、Twitterも殆ど投稿したことがありませんでした。元々、自分の意見を表現することに対する抵抗感が強く、アウトプットに苦手意識を持っていました。
アウトプットを始めたきっかけは、転職活動の準備のために始めたものでした。最初は「アウトプットしたほうが良いだろう」という考えから始めたものでした。

アウトプットのあしあと

この4~5年、ふりかえると多くの内容をアウトプットしてきました。昔の自分から見ると、結構な量をアウトプットしていたんだな、としみじみ思っています。

  • 社内LT:約15回
  • 社外LT:2回
  • 個人のブログ:約60記事
  • 会社のブログ:3記事
  • 社内ラジオ:約10回

アウトプットは、「〇〇を読んで得た学び」「△△やってつまずいたけどこうすれば対処できた」「××を実施して思ったこと」といった内容が多いです。また、自分のアウトプットに付加価値を与えるため、アウトプットする際には自分が「どう思ったか?」を書くことを大事にしています。

アウトプットのメリット

最近、現職で初めて会社のブログを執筆しました。ブログを書くことで 「すごい」と称賛され、そして一目置かれたと捉えています。そしてそれは前職で初めて会社ブログを執筆ときも同様でした。このように周りから評価されることはアウトプットの大きなメリットだと捉えています。評価されることで周りから話しかけてもらえるのでありがたいですね(承認欲求が満たされるw)。
また、個人で日ごろからアウトプットしておいて良かったなと思っています。会社のブログを執筆することに対するハードルが個人でのアウトプットによって低くなり、それが自信に繋がっています。逆に、全くアウトプットしたことが無いのに、いきなり会社のブログを執筆するのはハードルが高いと感じています。

現在、そしてこれから

現在、アウトプットに対してあまり苦手意識は持っていません。アウトプットのお願いに対して「いいっすよ」と二つ返事で答えることができます。これは昔と比較して成長したポイントだと考えています。(アウトプットの資料作成に毎回時間掛かり苦労している部分もありますが、そこはご愛敬ということで...)
今後は、社外登壇を増やしていきたいし、もっと読み手/受け手に対してすごい価値を提供ができるなアウトプットをしていきたいです。無理なくアウトプットを続け、成長し続けていきたいですね。

「単体テストの考え方/使い方」で学んだこと

この本を読んだので学んだこと記載します。
単体テストの考え方/使い方 | マイナビブックス

読んだ理由

この本は去年の12月年末くらいにtwitterで流れてきて知りました。単体テストがどのような役割を果たせるのか改めて学べそう、そして、効果的な単体テストを学べそうと思ったので読んでみました。

感想

分厚い本ですごく読み応えがありました。読むのが少し大変でしたが、その分学びになったことが多かったです!
古典学派とロンドン学派の考え方、初めて知りましたが面白かったです。この本は古典学派推しで、そして個人的にも古典学派の方が好みなので*1、この本を好きになれたのだと思います!
そして、「良いテストの4本柱」はすごく良いなと思いました。これを意識して4本柱は単体テスト、統合テスト、システムテスト、それぞれのレベルを考える時に役立ちそうだと思いました。また、リファクタリングへの耐性を得るためにテストケースをブラックボックスで作成することについても、すごく納得できました。

カバレッジについて、体温の例は分かりやすかったです。そして、「テストの質がいかに優れているか自動的に評価できる方法はない」とのことだったので、定量的に測る方法が存在してほしかったと少し思いました…。できないことを知れたということでプラスに捉えます...!

学びになったこと(抜粋)

テストケースの質

  • カバレッジが低い=テストの質が悪い。そして、カバレッジが高い≠テストの質が良いとなる。
  • カバレッジが高いことは良いことだが、そのことを強制することは開発の妨げになる。
    • 例)病院での体温計測
      • 患者の体温を計測した際に、計測した結果の体温が高ければ、発熱していることがわかる。もし体温を下げることだけを目標としている場合、クーラーを使って冷たい風を浴びせ続けることで体温を下げれる。しかしこれは治療ではない
  • テストの質がいかに優れているか自動的に評価できる方法はない。
  • 優れたテストスイートの特長
    • テストすることが開発サイクルの中に組み込まれている
    • コードベースの特に重要な部分のみがテスト対象となっている
    • 最小限の保守コストで最大限の価値を生み出すようになっている
      • 価値があるテストケースを認識できること
      • 価値があるテストケースを作成できること

単体テストにおける古典学派とロンドン学派の違い

単体テストの定義(古典学派)

  1. 1単位の振る舞い (a unit of behavior) を検証すること
  2. 実行時間が短いこと
  3. 他のテストケースから隔離された状態で実行されること
    • テストケースを隔離する=各テストケースをお互いに影響を与えることなく個別実行できるようにする

単体テストの定義(ロンドン学派)

  1. 1単位のコードを検証すること
  2. 実行時間が短いこと
  3. 協力者オブジェクトから隔離された状態で実行されること
    • テスト対象が他のクラスに依存しているならば、不変依存を除くすべての依存をモックに変える必要がある
隔離対象 単体の意味 テストダブルの置き換え対象 聖典
古典学派 テストケース 1つのクラス、もしくは、同じ目的を達成するためのクラスの1つのグループ(1単位の振る舞い) 共有依存 テスト駆動開発
ロンドン学派 単体 1つのクラス 不変依存を除くすべての依存
※ロンドン学派=モック主義者とも言われる理由
実践テスト駆動開発

良いテストを構成する4本の柱

  1. 退行 (regression) に対する保護
    • テストによって実行されるコードが多くなるほど、多くのバグを見つけることができる性質のこと
  2. リファクタリングへの耐性
    • いかに偽陽性を生み出すことなく、プロダクションコードに対してリファクタリングを行なえるかを示す性質のこと
    • ほとんどの場合、リファクタリングの耐性を備えれるか備えられないかしかできない(All or Nothing)
    • 偽陽性とは
      • 嘘の警告のこと。機能に影響がないのにテストが失敗すること。
      • 偽陽性よる影響
        • 嘘の警告に慣れてしまい、その警告に注意を払わなくなってしまうことで、プロダクションコードに潜む問題を解決しようとする意思を弱めてしまう
        • テストへの信頼が失われる
      • 発生する理由
        • テストケースがテスト対象の内部的なコードと結びつくことで発生してしまう。実装の詳細(例:手順が正しいか?)をテストしているから。回避するためには、テスト対象の実行結果を検証すべき。
  3. 迅速なフィードバック
    • テスト実行時間がどのくらい短くなるかに影響する性質のこと
  4. 保守のしやすさ
    • 何をテストしているかを理解することがどれくらい難しいのか??→テストケースのサイズが小さいほど、可読性が高い
    • テストを実施することがどれくらい難しいのか??→テスト時のプロセス外依存が少ないほど、テスト実施が簡単

  • テストケースの価値は、構成する4本柱がどのくらい備わっているか掛け算で求められる。
    • テストケースの価値 = [0..1] * [0..1] * [0..1] * [0..1]
      • テストケースが価値を持つためには、4本の柱を全て備えなくてはならない
    • これらは解析ツールなので正確な数値を算出できるものではない。
  • 4本柱全てを最大限に備えることは不可能
    • 退行 (regression) に対する保護、リファクタリングへの耐性、迅速なフィードバックは互いに排反するから。
      • 3つの柱を全て最大限にできないのはCAP定理と似ている
    • 保守のしやすさだけ独立している。
    • リファクタリングへの耐性を排除することはできない。備えるか否かの選択しかできないから。
    • 3本柱はテストレベルごとで調整をおこなう。トレードオフ
      • E2Eでは退行に対する保護が重要になり、単体テストは迅速なフィードバックの方がより重要になる

ブラックボックステストホワイトボックステスト

4種類のプロダクションコード

  • ドメインモデル/アルゴリズム
    • 単体テストに対する費用対効果が最も高い
      • 協力者オブジェクトが含まれないから保守コストが低い
  • 取るに足らないコード
    • テストする価値が全くない
  • コントローラ
    • 統合テストでテストされるべき
  • 過度に複雑なコード
  • コードの複雑さ=分岐の数
  • ドメインにおける重要性=コードがプロジェクトの問題領域においてどのくらい重要なのか
    • コードが複雑になればなるほど、ドメインにおける重要性は高くなる傾向
    • コードが単純になれば、ドメインにおける重要性は低くなる傾向
      4種類のプロダクションコード

統合テストについて

以下の1つでも定義から外れると統合テストとなる。

1. 1単位の振る舞い (a unit of behavior) を検証すること 
2. 実行時間が短いこと
3. 他のテストケースから隔離された状態で実行されること
    - **テストケースを隔離する=各テストケースをお互いに影響を与えることなく個別実行できるようにする**
  • 一般的に統合テストでは、1件の最長のハッピーパス、及び、単体テストでは扱えなかった異常ケースをできるだけ多く扱う。単体テストでは、ビジネスシナリオにおける異常ケースを可能な限り多く扱う。
    • 全てのプロセス外依存とのやりとりを検証できるような、長いハッピーパスを見つけ出す。そのようなパスが見つからないのであれば、テストケースを増やしていき、全ての外部システムとのやりとりが検証されるようにする。
  • 4本柱との関係性
    • 統合テストは、単体テストより優れた「退行に対する保護」と「リファクタリングへの耐性」を得ることができる。(単体テストよりも優れていないといけない)
    • 統合テストは「保守のしやすさ」と「迅速なフィードバック」の要素を失う。
    • これらのテストの種類が違うことで生じるトレードオフを表現したものがテストピラミッド。

疑問点

この本で言っている統合テストは、JSTQBでいうところのシステム統合な?それともコンポーネント統合?

*1:テスト対象メソッドやテスト対象クラスの振る舞いを確認していました。振る舞いを確認できない時に、必要最低限でモックと捉えていました。

「プロを目指す人のためのRuby入門[改訂2版]」と「Everyday Rails - RSpecによるRailsテスト入門」を読んで学んだこと

Rubyに関係する技術書を2冊読んだので、学んだことや感想を書いていきます! gihyo.jp leanpub.com

読んだ理由

一番の理由は、今後Rubyで作られているプロダクトに携わるためです。その上で、 Rubyのテストコードで多く使用されているRSpecを知り、何をどのようにテストするのか学びたかったので、上の技術書を読んでみました。

学びを得たこと

プロを目指す人のためのRuby入門[改訂2版]

Rubyの特徴

  • falseもnilも偽扱いとなる
  • if文もメソッドも最後に評価された式が戻り値となる
  • !がついていれば破壊的メソッドだが、ついていなくても破壊的メソッドの可能性もある
  • &.演算子:オブジェクトがnilだったらnilを返してくれる。エラーを防ぐためのif文を書かなくて済むメリットがある。

Bashと似ている部分

  • シングルクォーテーションとダブルクォーテーションの違い
    • ダブルクォーテーションは変数展開できる
  • ヒアドキュメント
    • Bashと違って、<<-指定することで半角スペースでインデントできる。

シンボル

  • Stringクラスのオブジェクトとシンボルはよく似ている。文字列を扱うもの。
  • 文字列を扱う際にStringクラスのオブジェクトでなくて良いならば、積極的にシンボルを使うこと
  • 内部的に整数として管理されるので高速に比較できる。
  • シンボルはイミュータブル
  • 文字列とシンボルの変換は、to_symto_s

オブジェクト指向

  • Rubyは単一継承
  • privateなメソッドは、そのクラス自身とサブクラスでも呼び出せる
  • protectedなメソッドは、そのクラス自身とサブクラスインスタンスメソッドから、レシーバ付きで呼び出せる
  • インスタンス変数=クラスをインスタンス化した際にオブジェクトごとに管理される変数
  • クラスインスタンス変数=クラス自身が保持している変数
  • クラス変数=クラスインスタンス変数と違い、スーパークラスとサブクラス間で共有する変数
  • クラスメソッド=特異メソッド

モジュール

  • include:継承を使わず、多重継承のようにクラスにインスタンスメソッドの追加/上書きすることをミックスインという。
  • entend:複数のクラスに対して共通の特異メソッドを追加する。
  • module_function:ミックスインとしても特異メソッドとしても呼び出し可能とする。
  • 名前空間の用途としても使える。

例外処理

  • Rubyでのbegin...rescue...ensureは、 他言語でのtry...catch...finally
  • resucue内でretryがあると処理をやり直せる

Procオブジェクト

  • JavaScriptの関数オブジェクトみたいなもの
  • Procオブジェクトとlambdaはほとんど同じ
    • 前者は定義している引数と違う数の引数を指定してもエラーとならず柔軟性がある。後者定義している引数の数に過不足があるとエラーとなる。

パターンマッチ

  • case...in...
  • 評価したい式 in パターン ot 式 => パターンでも1行パターンマッチができる
  • 様々なパターンに該当するものを取得する

その他

  • DateTimeクラスは非推奨
  • deprecatedオプションまたは、WANING[:deprecated] = trueを設定すると非推奨機能使った際に表示してくれる

Everyday Rails - RSpecによるRailsテスト入門

  • バリデーションのエクスペクテーションは、Shoulda Matchersを使うと1行で終わる
  • RSpecはデフォルトでデータベースの後片付けをやってくれる
  • describeとcontextの使い分けの例

    describe ではクラスやシステムの機能に関するアウトラインを記述し、context では特定の状態に関するアウトラインを記述するようにします。

  • let:遅延評価、必要となった際にブロックの処理が呼び出され、変数が使用可能となる。
  • スタブに関して、できるかぎり検証機能付きのテストダブル(instance_double)を使うこと

モデルスペック

  • モデルスペックは、example(itで始まる1行)1つにつき、エクスペクテーションは1つだけ。exampleが失敗したときに問題が起きたバリデーションを特定できる。
  • Modelで作成しているコードの中に、真偽値を返す自作メソッドがあれば、be_自作メソッド名アサーションしてくれる

わかっていないこと

  • 事前に変数に定義しておく場合においてのletとbeforeの使い分け、変数参照時にデータを作ることで賄えるか、予め絶対変数にデータが入っている必要があるかどうかとか?
  • let!の使いどころはよくわからず...

感想

「プロを目指す人のためのRuby入門[改訂2版]」について、分厚いけどわかりやすく読みやすい本でした!ぼっち演算子の説明画像が個人的に好きでした。約3年前、Rubyのことよく理解せずにRailsだけやってて、Ruby基本的な考え方を知れてよかった。今思うのは、昔から読んでおけばよかったと思います。 「Everyday Rails - RSpecによるRailsテスト入門」について、これも約3年前に買うだけ買って全然読んでなく、今回初めて読み終えました。実際にサンプルコードを書きながらやったので、理解が深まったと思います。Factory Botについて、きっと便利だとは思うのですが、仕様をよく理解しないと想定外のテストデータが作れられる可能性がありそうなので、気を付けます。 RubyRSpecの基礎を学べたので基本的な部分は一人で作成できるはず...!

「実践アジャイルテスト」を読んだ感想

実践アジャイルテストを読んだのでその感想を書きます。余談ですが、この本は絶版らしく*1図書館で借りて読みました。 www.shoeisha.co.jp

なぜ読んだか

アジャイルで進めているプロダクトに対して、どのように品質と向き合うかということを知りたかったこと、そして「Agile Testing Condensed Japanese Edition」で語られている部分について、より詳細な部分を知りたくて読んでみました。
「Agile Testing Condensed Japanese Edition」を読んだ感想 - 徒然なるままに

学びになったこと

アジャイルテストの4象限

第1象限(チームを支援する技術面のテスト)

  • 単体テストコンポーネントテストを指す
  • 活動の目的は、内部品質を最も高めること
  • 支援する手段としてのTDD
    • はじめにテストを書くプロセスは、プログラマがコードを正しく設計することの助けとなる。
    • プログラマがシステムに意図しない変更が起きることを心配せずに、ストーリーの機能を自信を持ってコーディングすることが可能となる。
    • プログラマは自分の設計やアーキテクチャーが正しいことを確認できる。
  • テストコードがあることのメリット一例は、バグ探しの時間が減ること、テスタビリティの高いプロダクションコードができる、迅速なフィードバックをもたらす。

第2象限(チームを支援するビジネス面のテスト)

  • 第1象限より高いレベル(おそらく抽象度が高いとか、大まかな概要という意味)が対象
    • 顧客チームから提供される例からテストが導き出される。
  • ビジネス面のテスト
    • ビジネス用語で記述される。
    • 顧客も参加するテスト
    • 顧客が読んで理解できるように書く
  • 外部品質を検証するためのテスト
  • 自動と手動でのテスト

第3象限(製品を批評するビジネス面のテスト)

  • 製品を批評するテスト
    • 探索的テスト
    • デモ
  • 人間の知性や経験、本能に依存するため、この部分のテスト自動化は難しい。
    • テスト準備、テストデータの作成、その他繰り返し作業などは自動化できる。
  • 第1、第2象限を自動化しておくことで、第3象限のテストを行なえる時間を得れる。

第4象限(技術面のテストを使った製品の批評)

  • ~性のテスト
  • 非機能テストについて考える時間はリリース計画時やテーマ計画時

テスト自動化について

テスト自動化のメリット

  • 手動でのテストだと間違いを誘発しやすいので、それを防ぐことができる。
  • リグレッションテストによって意図しない振る舞いの変化に気付けるため、セーフティネットとしての役割を持つ。
  • 早く、頻繁にフィードバックを与えることができる。
    • 変更が加えられるまでは自動テストは成功し続ける必要がある。
    • もし自動テストが予期せずに失敗する場合は退化している可能性がある。それをいち早く開発者に伝えることができる。
  • 退屈な手作業を減らすことで、探索的テストやユーザー受け入れテストなど重要な仕事のための時間を捻出できる。
  • 文書化
    • システムが実際にどのように動作するかを表した生きた資料
    • メンテナンスしないとテストは失敗する。「グリーン」に保つために自動テストを更新し続ける必要がある。
      • 静的な文書との最大の違い。失敗することで、資料を特徴更新する必要があるタイミングを知れる。

単体テストコンポーネントテストでの特徴

  • すべてのテストタイプの基礎
  • アジャイル開発ではこのレイヤーに可能な限り多くのテスト実施することで、ROIの向上が期待できる。
  • テスターがTDDと単体テストの自動化を習得するにつれて、この層は成長し始める。

受け入れテスト(APIテスト)

  • 顧客が理解可能なドメイン固有の言語で記述しようとする。
  • 単体テストレベルより多くの作業ができる一方、DBなどにアクセスするため遅くなる。ただしGUIのテストよりは早い。

GUIテスト

  • (AIテスト自動化ツールが無い時代の本なので、そこは留意する必要あり)
  • 保守工数が結構かかるため、一般的には低いROIとなる。
    • HTMLの要素を変更すると失敗となるケースがある。
  • 常に製品を批評するために記述される。
  • 重要なフィードバックをもたらすが、実行に時間がかかる。そのためなるべくこの層のテスト数を減らしたい。
  • GUIテストの自動化に開発者が携わることは、システムの全体像の理解を深めることに役立つ。
  • やり過ぎてすべての可能なシステムを自動化するようなことはしないように。
    • すべての自動化されたテストを開発局面の間リグレッションスイートとして持ち続ける必要はなく、ビルド時間とバグを見つける可能性のトレードオフを考慮すること。

CIの重要性

  • CI>単体テスト自動化>APIテスト>E2Eテストの順番に自動化を検討すべき。

    高速で実行される継続的インテグレーションとビルドプロセスは、あらゆる自動化の取り組みに絶大なROIをもたらします。これは、あらゆるチームが自動化する必要のある、最初に行うべきことです。それが適所にある時には、チームは自動化されたテストから迅速なフィードバック方法を得ることができます。

自動化しないほうが良いテスト

  • ユーザビリティテスト
  • 探索的テスト
  • 絶対に失敗しないテスト
    • 要求を満たすために1つの実装の方法しかない場合など
  • リスク分析して、仮に変更が発生しても影響が少ないもの
  • 1回限りのテスト

検討時に必要なこと

  • 「なぜ自動化が必要か?」「どんなゴールを達成したいのか?」「どこが最大の痛みか?」「もっとも退屈な領域は何か?」
  • 影響度、将来の変更可能性、繰り返し実施する必要性があるか

テストを記述するための戦略

  • テストを成功し続ける
    • テストが成功した後は、要求が変更されない限り失敗すべきではない。
    • 変更を検出するための役割があるので、要求の変更についてテストで忘れられた部分があるのであれば、失敗することを期待している。その後成功させるように変化させる必要がある。
  • どんな時でも、継続的インテグレーションやビルドプロセスにおいてテストが失敗した時は、チームの最優先事項(致命的な稼働環境での問題を除き)はビルドプロセスを再び通過させること。
    • 失敗したテストをコメントアウトして後で修正すると、すぐに大量のコメントアウトされたテストでいっぱいになってしまう。そして、多くの技術的な負債がのしかかってくる。
    • バグが埋め込まれたのか、意図されまた振る舞いの変更に対して単にテストを更新する必要があるのかを判別する必要がある。課題を解決し、すべてのテストが成功することを確認すること。

チーム全体のアプローチ

  • テスターがプログラマと組になり、より良いテストを記述できるように支援する。
  • 順番にテストピラミッドのレンガの基礎層を固めていく。
  • テストは開発を推進するため、チーム全体が常に最大のテスタビリティを求め、テストピラミッドは正しい形に成長していくことができる。

自動化の評価

  • 自動化の労力の見返りを評価する時は、ツールが技術チームと顧客チームの共同作業を促進したかといった、はっきりとしない側面を考慮する。
    • テストを記述することの第一の理由は、開発を推進することの助け。自動化された受入テストを記述する過程が、ビジネス要求の完璧な理解をもたらすのであれば、後でテストが1つのリグレッションのバグを見つけることがなくても、それは十分な見返りとなる。

要求を引き出すための質問の例

  • このストーリーは問題を解決しますか?
  • そうだとすると、私たちが解決しようとしている問題は何ですか?
  • 問題を解決しないソリューションを実装することができますか?
  • このストーリーは、どのように価値をビジネスにもたらしますか?
  • この機能のエンドユーザーは誰ですか?
  • 彼らはどのような価値を得るでしょうか?
  • ユーザーがこの機能を利用する直前あるいは直後にすべきことは何ですか?
  • どのようにして、このストーリーが達成されたかを知ることができますか?
  • 起こり得る最悪なことはなんですか?起こり得る最も良いことは何ですか?

開発者との協調(共同作業)

  • ペアテスト
  • 開発中のGUIを見せてもらう
  • 顧客または顧客の代理に、コーディングが始まる前にテストケースをレビューしてもらう。
  • チーム全体は新しい機能を手動でテストするのと同様、手動リグレッションテストを実施する時間を計画する。
    • アプリケーションのテスト自動化ができるように、どのように設計するかを学ぶためのモチベーションを提供できるため。

チーム運営

独立した品質保証チーム

  • 独立しないことによるデメリットの1つは、テスターがあまりにも開発者と近くで作業をした場合、みな開発者のように考え始め、 顧客の視点を失ってしまう。
    • アジャイルチームのテスターは、顧客の代理としての役割も必要
  • テスターと開発者の正しい比率はないので、比率にこだわるよりも必要としているテストスキルを評価する必要がある。

チームメンバー全員が平等

  • あなたがテスターで、ミーティングに呼ばれることが忘れられているとしたら、自分から参加する。
    • 技術に強くないテスターは、設計の打ち合わせでは、場違いで気後れするかもしれないが、たまには技術屋が思いつかないような鋭い質問をすることもある。
  • 自動化の問題を抱えて困っているテスターなら、チームメンバーに助けを求める勇気を持つ。
    • マネージャーやチームリーダーならば、こういう協力が得られるようにし、もし得られないのであればチームに問題提起する

まだわかっていないこと

  • テスト自動化について、どうやったら有効なメトリクスが得られるか知りたいですが、まだわからず。
  • TDDのデメリットは何なのか。テストコードを書く工数がかかることとか?

感想

ページ数が多く読むのが大変でした...その分学びになる点も多かったです!自動化の部分に関心が強いので、自動化がらみの内容が多くなってしまいました...でも、アジャイルで品質向上のためにどう向き合うかという点を、「Agile Testing Condensed Japanese Edition」以上に知ることができました。
今回学びとなったことは多いので、ある程度時間が経ってから見直すことでより理解を深めようと思います!

*1:絶版だというのは図書館で借りた後に初めて知りました

ふりかえりのファシリテータを1年くらい実施して気付いた変化

約1年間、チーム内で1~2週間に1回の1時間のペースで実施していました。 ※途中全く実施していない期間もあるので、厳密には1年では無いですが細かい話なので置いておきます。 最近、変化があったことに気付いたので、記事にしました。

ふりかえりをやろうと思ったきっかけ

ふりかえりガイドブックを読んだのがきっかけです。感想の記事はこちら

自分自身の変化

視点の切り替え

全体レベル(大きい視点)と詳細レベル(小さい視点)での会話を意識的に切り替えができるようになりました。
話の内容に応じて「まだ話してもらう」or「そもそも何を話すべきだったかを伝えて戻す」をしています。
話が広がりすぎているときは、「この話そもそも何だったっけ?」「何をゴールとすればいいんだっけ?」が何となくわかるようになってきたからだと思います。

出来事への見方

悪い出来事だったとしても、(小さくても)良かった点を見つけることができるようになりました。
世の中の出来事は、悪い出来事の中でも良かった点は必ずあるはず。ふりかえりの中で他者の視点が出るからこそ、改めて気付けました。
また、相手に対して良かったことを素直に伝えるれるようになってきました。否定的な単語ではなく肯定的な単語に言い換えができ、「すごい」といった簡単な賞賛の言葉も素直に伝えられるようになってきました。

ふりかえり手法の組み合わせ

自分なりにふりかえり手法をカスタマイズして、目的に応じて組み合わせを変更できるようになりました。

例えば...
チームストーリー+ハピネスレーダー+タイムライン
→良かった/良くなかった/普通の出来事、コミュニケーション/コラボレーションしたことを、チーム内で再認識するため。

タイムライン+希望と懸念
→良くなかったことを問題点(懸念)として捉え、それがどうなったら理想(希望)なのかを知り、ギャップを埋めるために何ができるかを考えるため。

チーム内の変化の話

最近はプロセスのカイゼンのための場として活用できるようになってきました。 今までは、「ふりかえりに慣れること」、「出来事を共有して困りごとに別の視点を持つ」を主な目的としていました。そこでは、他メンバーの考え方を知れるといったメリットがあり、メンバー間の信頼度の向上に役立っていたと思います。 ただ、最近はより良くするために「表面的ではなく根本的に変化していきたい」という状態だったので、プロセスのカイゼンを目的としてふりかえりを実施しています。

書きたいことはまだあるのですが、ここは会社ブログではなく個人ブログなので詳細は割愛させていただきます。 自分自身の気付きとしては、ふりかえりの効果は、チーム内のメンバーの考え方を知れる機会プロセスのカイゼンというのがある、という点です。

おわりに

このブログ自体がふりかえりなのかもしれないですね!
なお、変化したという話は、「以前より変わったかもしれない」という全て定性的なもので、「※当社比ならぬ当人比」が付きます。あらかじめご了承ください。
ただ、自分自身で変化に気付けて言語化できるようになったのも、良かった点です!※当人比
これからも成長できるように頑張ります!

※この記事は個人の感想であり効果効能を保証するものではありません。
※感じ方には個人差があります。

「The BDD Books - Discovery (Japanese Edition)」を読んだ感想

The BDD Books - Discovery (Japanese Edition)を読んだので、その学んだことと感想を書きます。

なぜ読んだか

BDD(振る舞い駆動開発)、ATDD(受け入れテスト駆動開発)という単語は知っていたが、中身を全く知らなかったため学びたかった。
強いて知っていることと言えば、BDDはGiven/When/Then を使ってCucumberのようなツールを動かす、くらいでした。

学んだこと

BDDとは

  • BDDとATDDと実例による仕様は、同じものに対して名前が違うもの
  • 開発担当者だけでなくビジネス担当者も読めるもの
  • 具体例で構築され、十分な具体例=システムの振る舞いとなる
    • 具体例はビジネス言語で表現され、具体例に注目するとルールの意図が明確になる
  • 目標
    • 要件分析と詳細仕様の間に導入し、本番環境での問題を防ぐこと
    • ビジネスチームとの早期の直接的なコミュニケーションに焦点を当て、誤解を減らし、やり直しを減らすことで、コミュニケーションの効率を向上させること
  • 使用することのメリット
    • やり直し/受け入れ拒否の削減
    • バグの削減、ビジネス側が求めていることへの理解促進
  • ラクティス
    1. 発見
      • この本では発見のプラクティスを中心に解説されている
    2. . 定式化
    3. . 自動化

具体例について

  • 十分な具体例(システムの振る舞い)は「コンテキスト」、「アクション」、「結果」で構成される
  • 具体例は"明確"で具体的なデータを使用する必要がある
  • 全ての情報を指定すると非常に長くて退屈になるので、具体例は振る舞いに直接関連する具体的なデータを使用する
  • 複数のルールを表す具体例を書いているとき
    • 1つのルールに対しての具体例であって、他のルールに焦点をあてない
  • 具体例は「すでに知っていることを説明するため」と「仮定に疑問を投げかけるため」の両方に使用される

要件ワークショップ

  • 目的
    • 明確な具体例を用いて要件をすばやく調査し、求められている内容を全員が正確に理解すること
    • 詳細レベルを得ることではない
  • 要件ワークショップで具体例を集める
  • Given/When/Then を使用しないで書くべき

その他

  • アジャイルテストの基本コンセプト
    • アプリケーションの問題を見つけて報告することから、そもそも問題をコードに含めないようにすること
      • シフトレフトの考え方に近いかも?
  • ハッピーパス=正常系の中でも特に大事なもの
  • テスターは、通常、要件と解決策の間の仲介役として機能するため

感想

BDDは名前しか知らず内容を知らなかったので、今回BDDが何であるかを知れたのは非常に有益でした。協調という点で、良いものを作るために様々な役割の視点から具体例を使用してイメージをしていくことの重要性を学べました。
実例マッピングのやり方についての具体的な例があるのはイメージしやすかった部分なので良かったです。
一方で、アジャイルは机上でしか理解してないので、スクラムにおけるBDDと,リーンカンバンにおけるBDDの話はあまり理解できず...ここら辺はアジャイルを経験したらまた読み直したい部分です。
そういえば、Given/When/Thenに関することはあまり触れていなかった気がします。定式化についてはこの本の対象外なので、おそらく定式化で使うのかなーと思っています。

あとは、ドメイン駆動設計の話も少し出てきたので、いずれそれも学びたいです。
これからも色々と学んでいきます!

「Agile Testing Condensed Japanese Edition」を読んだ感想

Agile Testing Condensed Japanese Editionを読んだので、その学んだことと感想を書いています。 https://leanpub.com/agiletesting-condensed-japanese-edition

読んだ理由

アジャイルでのソフトウェアテストを学びたかった

学びになった点

詳細レベルに応じたテスト計画

  • リリース/フィーチャーレベル
  • ストーリーレベル
    • 高レベルの受け入れテストの検討。例えば、探索的テストのチャーターの検討。
  • タスクレベル

フィーチャーとストーリーの開発を導くため具体例を使用する

非機能要件

  • 非機能要件は、「チームがすべてのフィーチャーやストーリーで考慮しなければならない」という考え方。
  • 機能を提供する前から非機能要件を考慮して、アーキテクチャや設計をしなければならない。

アジャイルテストの4象限

  • 概要
    • 左側のテストは、コーディングが行われる前または進行中に同時並行して作成され、欠陥の防止に役立つ。
    • 右側のテストは、コーディングが完了した後に行い、コード内の欠陥を見つけるか欠落しているフィーチャーの特定に役立つ。
    • 上側のテストは、ビジネスで定義されている外部品質に関するもの。
    • 下側のテストは、内部コードまたはインフラの正確性といった内部品質にかかわるもの。
  • 役立つとき
    • 必要なテスト活動を考えるとき
    • チームや組織と共通のテスト言語を構築するとき

プロダクトをよくするために行うべき質問例

「このフィーチャーを実装しても問題を解決できない可能性はありますか?」、「このフィーチャーを使用する前にユーザーは何をしますか?」など

感想

内容は濃密ですが、ページ数が約90Pと多くないので読みやすかったです。また、アジャイルでテストを行う上での手法やマインドセットを学べたのも良かったですが、将来的な話としての今後新しい役割として行っていくべきタスク例を学べたことはすごく良かったです。

具体例について、今まで手法等は意識してなくても行っていました。ただ、会話ベースでしか行ったことがないので、手法を通してよりよく具体例を出せるか試してみたいですね。まずはBDD、ATDD、SBEを理解できていないので、それらを学んでいきたいです。