読者です 読者をやめる 読者になる 読者になる

mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜 のレポート

f:id:mokky14:20170129072503p:plain

GaiaxでWebシステムのQA(Quality Assurance)をやってる@sakaimoさんによるQAレクチャーのレポート。

講演内容(抜粋)

「あたりまえ品質」を担保するためにやること。

テストでやること

  1. 仕様を理解しながらどんなテストが必要かイメージする
  2. テストケースの作成
  3. テストを実施
  4. バグトラッキング

開発者の視点として

  • 作るものを正しくQAに伝えることは大切
  • ドキュメント化が基本だが、全ては表現できない
    • 密なコミュニケーションが必要
    • 意図や熱意の共有
  • 開発者からの情報が全て、の場合も多い
    • 整理して説明してもらわないとテスト漏れする
    • あなたの当たり前は私の当たり前じゃない、の精神

実際の業務では
「仕様(書)の不明点や抜け漏れをどれだけ 実装前に 指摘できるか」が大事。
後工程で見つかったバグほど、修正コストは高くなる。 リリース後の不具合修正コストは、リリース前とは比較にならない。

CRUD(Create/Read/Update/Delete)のD

仕様を考える人も、コードを書く人もDが抜けることが多い。(経験上)
言われなくても、作るときに発想して下さい。

  • SNSでアカウント削除したら、投稿、他人へのコメント、友だち関係はどうするの?
  • 投稿がシェアされてたら? イベントの主催者だったら?
  • 削除後、同じアカウントで再登録できるの?

ソフトウェアテスト7原則

  • 原則1:欠陥があることしか示せない
    欠陥がないことは証明できない
    「バグのないシステムを作って下さい」と言われても、「バグがない」事は証明できない
  • 原則2:全数テストは不可能
    組み合わせは膨大。テストの焦点を絞る
  • 原則3:初期にテストすべし
    開発サイクルのなるべく早いうちにテストすべし
  • 原則4:欠陥の偏在
    バグの大部分は特定の少数モジュールに集中する
  • 原則5:殺虫剤のパラドックス
    同じテストを繰り返していると、そのテストではバグが出なくなる
    バグが出なくなったから品質が良くなったとは限らない
  • 原則6:テストは条件次第
    ECサイトとゲームではテスト方法が異なる
  • 原則7:バグゼロの落とし穴
    バグを修正してもシステムが「使えない(使い物にからない)」のでは役に立たない

品質観点からのテスト分類

  • 機能要件
    • 機能テスト
  • 非機能要件

機能ばかりに目が行って、非機能観点の要件は忘れがちなので注意。

実行方法によるテスト分類

  • 動的テスト
    • テスト対象を動作させてみて結果を確認する
  • 静的テスト
    • ドキュメント、ソースコードを「見る」「読む」ことで確認する(レビューも含む)
      • コーディング規約
      • 静的解析ツール
      • ソースコードインスペクション

テスト手法による分類

  • ホワイトボックステスト
    • 制御・パステスト
      • 理経路をどれだけ網羅したか(カバレッジ)
        • 命令網羅(C0) 全ての命令文(statement)が少なくとも1度は実行されるように設計
        • 判定条件網羅(C1) 全ての判定条件において、真と偽が少なくとも1回は通るように設計
          このあたりが現実的に出来るところ
        • 条件網羅(C2) 全ての条件について結果(真・偽双方)が少なくとも1回を確認するように設計
  • ブラックボックステスト
    • 同値分割
      • 同じ結果になる値を同値グループとして扱い、試験パターンを減らす
    • 境界値分析
      • 同値グループの端の値について試験を行う
    • ディシジョンテーブル
      • 複数の条件の真・偽の組み合わせを表にする
      • それぞれの場合に対応する結果(行動)を示す

QAチームでやってるのはほぼブラックボックステスト

「なぜそのテストで充分なのか」説明できるか?

品質特性(ISO9126)として以下のものがある。

  • 機能性(正確さ、セキュリティ等)
  • 信頼性
  • 使用性(使いやすさ)
  • 効率(性能)
  • 保守性
  • 可用性

このうち、どこの品質特性を満たすか、的を絞る。
品質特性は、モノを作り始める前に使い、「このプロダクトで求める品質は何か?」を検討する。

どの品質を確認したいのかで内容は変わる。 使用性を担保するためのテストと、信頼性を担保するためのテストは中身が違う。
プロダクトとしての確保が必要な品質特性に応じ、テストを実施する。

往々にして「動けばOK=機能テスト」に目が行きがち。でも動くのは「当たり前」。

Q&A

  • 「使用性」のテストは属人化する事が多いが、何か良いやり方はあるか?
    • 「使いづらい」については、とりあえず意見を出してもらって、みんなで判断する
    • 周りのWebサービスを触ってみて「世の中の当たり前」を確認、自分の作ったサービスと比較してどうかを判断する
  • アジャイル開発を行ったとき、仕様書の作成に力を入れなか結果として、テスト担当から「仕様書がないので何をテストすればよいのか分からなかった」と言われた事があった。開発チームに求める仕様書とか作成基準はあったら教えて欲しい
    • 仕様書について、条件は特にない
    • アジャイル開発では、チケットに完了条件を書いて、この「完了条件」を満たせばチケットクローズになる
    • 完了条件を書くのはチケット担当になった 人。他の人が完了条件を追記することは可能

感想とか

人への指導や説明に使える枠組み(公的なもの)の情報が欲しかったので、今回の「なぜそのテストで充分なのか」の話が聞けたのは良かった。
最近関わった開発で「どこまでテストすればいいか」について各自の意識がバラバラだった事があり、どうやって意識合わせすれば良かったのかと思っていたが、そもそもプロダクトに求められる品質を明確化していなかったので、意識合わせをする元がなかった事が原因だった事に思い至った。

仕様書でバグを見つける事は同意。仕様書を見れば検討不足とかは良く分かる。非機能要件は特に漏れがち。
ひどいPJだと仕様書見ただけで炎上する事が分かったりする。テスト目的に限らず仕様書の確認は重要。
JaSST'2015東北でレビューの話聞いてたので、後で見返しておく。

メモ

7つの習慣ボードゲーム公式ゲーム会に参加してきた 

2016/6/19(日)の「7つの習慣ボードゲーム 公式ゲーム会」のレポート。

7つの習慣ボードゲームとは

f:id:mokky14:20160619130520j:plain

スティーブン・R・コヴィーの名著「7つの習慣」(自分は読んだことない)で書かれている成功のエッセンスを体験できるゲーム。
クラウドファンディングで、ボードゲームのプロジェクトの中で史上初の1000万円を達成したゲームらしいです。

ゲームの概要(公式サイトより引用)

7つの習慣ボードゲームは、
「第1ステージ:私的成功」
「第2ステージ:公的成功」
「第3ステージ:成功の習慣化」
上記3つのステージが存在し、サイコロを振りながら駒を進めていきます。
 

プレイヤーは人材を雇用しながら「影響力」を高め、 プロジェクトを成功させながら「お金」と「信頼チップ」を集めます。
 

プロジェクトのキモは「交渉」!!
「交渉」では普段の決断力や判断力が実に問われてきます。
特に「7つの習慣を理解している」ことがカギとなる部分です。
 

このゲームは、決められたターン数の間に、
・第3ステージに到達する
・「肉体」「精神」「知性」「社会・情緒」4種類の刃を研ぐカードを揃える
・「ミッション・ステートメントカード」の条件を達成する
以上、3つの条件をクリアすることで、ゴールとなります。

やってみた

結果は、クリア条件のうち、「刃を研ぐカード」を揃えられなくてゴールできず。

7つの習慣ボードゲームということで,「7つの習慣」に照らしあわせた自己評価。

7つの習慣 評価
主体的である ○ 自分の頭で考えてゲーム進めてた。
終わりを思い描くことから始める × ゴールから逆算した進め方をしてなかった。目先で困っている事(資金不足、人材不足)を優先してしまった。
最優先事項を優先する △ 自分の中では優先事項を考えてプレーしてたが、そもそもの優先事項の選択が誤っていた。
Win-Winを考える ○ 交渉の時、相手の利益も考えて交渉した。
まず理解に徹し、そして理解される △ 全く気にしないでやっていた。(特に意識せずとも友好的にゲーム勧めてたと思う)
シナジーを創り出す △ 参加メンバー同士での協同効果は作れていたと思う。(自分以外のメンバーはクリア、自分もクリア条件満たしかける所まではいった)
刃を研ぐ △ ゲームの中では「刃を研ぐカード」集められなかったので×だけど,ゲームの中ではあまり意識するものでもなかった。

経営者モード

時間があったので、経営者モードでのゲームも実施。 経営者モードは以下のルールが変更になる。

  • スタート時の資金が10倍。
  • 雇用している人材の雇用費を毎ターン支払う

結果、二回連続で破産(資金がショート)。
↓全員、手元にお金が残ってない。 f:id:mokky14:20160619162627j:plain

その後,3回目の挑戦で全員クリア達成。

f:id:mokky14:20160619172245j:plain

経営者モードの感想。

  • 経営者って大変。
    • 収入の有無に関わらず固定費が毎ターン出て行くのは怖い。
    • 想定外のトラブル(イベント)が発生したら、その都度立て直しが要る。
      トラブルは発生することを前提に対応計画を考えておかないといけない。
  • 人を雇用する事は難しい。
    • ゲーム上、雇用した人材は解雇できない。
      雇用した人材に対して毎ターン支払いが発生するので、人を抱える事が負担になる。
    • 経営者目線で見ると、成長しない人材(レベル低の人材カード)はイライラする。
      うちの会社に、人材は人財にも人罪にもなるというのがあるけど、自分は人財になるようにしないといけない。
  • 一人ではどうにもならない。
    • 全員で協力するのは前提で、その上で入念に計画立てた上でやっとクリア。

改めて、7つの習慣とは?

f:id:mokky14:20160619145054j:plain

  • 私的成功
    • 第一の習慣・主体的である(Habit 1 Be Proactive)
    • 第二の習慣・終わりを思い描くことから始める(Habit 2 Begin with the End in Mind)
    • 第三の習慣・最優先事項を優先する (Habit 3 Put First Things First)
  • 公的成功
    • 第四の習慣・Win-Winを考える (Habit 4 Think Win/Win)
    • 第五の習慣・まず理解に徹し、そして理解される(Habit 5 Seek First to Understand, Then to Be Understood)
    • 第六の習慣・シナジーを創り出す(Habit 6 Synergize)
  • 第七の習慣・刃を研ぐ (Habit 7 Sharpen the Saw)

ここの内容が分かりやすかった。
前はハードカバーの分厚さで尻込みしてたけど、今はマンガも出てるし、一度読んでみるかな。

参考

7つの習慣 - Wikipedia

世界的ベストセラー『7つの習慣』ってどんな習慣なのか知ってる? | 美女読書

7つの習慣ボードゲーム 成功の鍵 公式サイト

書籍

JaSST東北2016に行ってきた

2016/5/20(金)のJaSST東北2016のレポート。

f:id:mokky14:20160521104503j:plain

今年のJaSST東北2016はVSTeP(ブイステップ)祭りだった。

基調講演 VSTePによるソフトウェアテストの開発 ー 西 康晴 ー

VSTePとは?

テスト設計の技法の一つ。
(他のテスト設計技法は、HAYST法、ゆもつよメソッドがある)

VSTePの流れ

  • テストケースをざっくり考えてから具体化する
    • いきなり細かく考えると抜け漏れが発生しやすくなる
    • まずは「負荷」とかざっくりした観点で考えて、具体化していく
  • 全体像を把握するための図を描く
    • Excelの表だと全体像の把握は難しい
    • 図の形式やツールにはこだわらない。全体像を把握するのが目的

テスト要求分析

テスト観点図を作成する。

  1. テスト観点を思い浮かべて、線でつなげる
  2. 観点を詳細化していく(親観点から子観点を引く)
  3. 関連する観点を線でつなぐ

テスト観点図の作成方法は、トップダウン型とボトムアップ型の2種類がある。

  • トップダウン型 ざっくり観点を挙げて徐々に詳細化していく
  • ボトムアップ型 試験内容を思いつくところから挙げて、挙がった試験項目から観点を導出していく

地図見るのが得意な人はトップダウン、苦手な人はボトムアップてやるのが良い(らしい)。
実際にはトップダウンボトムアップを循環させながら進める。

テスト観点を導き出した理由・意図を明確化することが大事。
意図が分かっていれば、意図が間違っていたのか、意図通りに行かなかったのかが後から分かる。

テストコンテナ設計

テスト観点をグルーピングする。
コンテナはテストのカテゴリを示す(機能テスト、負荷テスト、セキュリティテストなど)。コンテナは単数または複数のテスト観点をグルーピングしたものとなる。

  1. コンテナを設計し、テスト観点と対応させる
  2. テストコンテナ図を作成し、各コンテナの実施順序(テストの順序)を検討する

テストの順序はテストの戦略になる。

テストフレーム設計

テストケースのひな形(骨組み)を作る。

テストケースを実施するために、どの観点を組み合わせて試験を行うかを設計する。具体的な値は詳細設計で考えることとし、ここでは観点の組み合わせのみを考える。

テスト詳細設計、テスト実装

普通のやり方でよい

  • テストケースのひな形に具体的な値を入れる
  • 値を入れたひな形を手順に具体化する

導入にあたって

  • いきなり全部導入するのではなく、自分が困っているところに入れてみるのがよい。
    とりあえず導入してみて、ダメなら止めればよい。
  • 最初から完璧を目指してはいけない。
    大事なのは困ること。困ったことを自覚して、図にして、直して、納得すること。
  • 観点の抜け漏れはしょうがない。それが自分達の現在の技術レベル。 
  • 観点網羅を目的にしない。観点が「もう出ない」ことをチームで合意する事が大事。
  • 観点として必要だと思わないものも観点として明示した上で「不要」であることを合意する。
  • 「これさえあれば、何も考えなくても作業できる」とかはない。単純作業したい、自分の頭で考えない、言われたからやる、というような人や組織では導入しない方が良い。

演習

Lhaca+の解凍機能を題材にしたワークショップ。
以前のソフトウェアテスト勉強会でもやった題材。

テスト観点図

自分らのチームで作成したテスト観点。
ファイルのパターンを重点的に抽出。それ以外は、パラパラと出ていたテストケースに対して、ボトムアップで観点を付けた感じ。

f:id:mokky14:20160520145026j:plain f:id:mokky14:20160520145020j:plain

何だか網羅性がなくて気持ち悪いと思っていたら、その不安が後で的中する形に。

テストコンテナ

写真撮り忘れた。
うちのチームでまず作ったのはこんなコンテナ。

  • 解凍テスト
    • コンテナに含めた観点
      • (インプットとして)圧縮ファイルバリエーション
      • (実施手順として)人による操作
      • (アウトプットとして)出力先

実際にテストするときは、ファイルパターン×解凍機能の呼び出しパターン×出力先のバリエーションでの組み合わせテストになると考えて作ってみたけど、こんなんで良いのかとモヤモヤして、西先生に助言を頂くことに。
西先生からは「何をテストしたいのか?」「コンテナに入れる観点は、テストしたいもの。実施手順は観点ではない」というコメントを頂きました。
このコメントを受けて作りなおしたテストコンテナ。

  • 解凍テスト
    • コンテナに含めた観点
      • 圧縮ファイルバリエーション

「解凍ソフトとして、色々なバリエーションの圧縮ファイルの解凍ができる事」を確認するテストとして、コンテナ作成した。 演習はここで時間切れ。

振り返り

  •  ファイルの観点を先に深堀りしたのは失敗だった(と思う)。 ファイル観点を深堀りしただけで満足してしまい、それ以外の観点をあまり考えないままテスト観点の作成を終えてしまった。
    • テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
      • そもそも、ファイルの種類が重要な観点だとは考えてもいなかった
    • テスト観点の全体像を作成して、重要と思う観点をチーム合意して、その観点を深堀りするよう進めた方が良かったかも。
  • チームの意識が、観点の抽出よりも、細かいテストパターンを出す方に意識が行っていたと思う。
    テスト観点の抽出に意識を向けるよう、ファシリテートする技術が必要。
  • 「プロダクトとして大切なのは何か」をチーム内で合意出来てなかった。 それぞれが、考えがバラバラなまま進めてた。
  • VSTePを使うには慣れが必要。
  • 自分のチームではテスト戦略まで考えられなかったが、他のチームが言っていたテスト戦略は興味深かった。テストの順番がテストの戦略という事がよく分かった。
    • 性能テストは早い段階で実施する。理由は、性能に問題があった場合、改修が大変なので。
    • 製品の品質を上げる事が先なので、製品の魅力テストは「当たり前品質」を確認した後に実施する。

感想など

去年のソフトウェアテスト勉強会でやったゆもつよメソッドと比べると、ゆもつよメソッドは仕様書をインプットにして観点上げるのに対して、VSTePは仕様書をインプットとせずブレストで観点上げる形なので、現場導入のハードルは高いように思う。
一方、他のチームで出ていた「魅力テスト」というコンテナとかは、仕様書からは絶対に出てこないテスト。これは「仕様書を見ずに観点を上げる」事による効果だと思う。

とは言え、プロジェクトにも寄ると思うが、仕様書見ないでテスト項目上げるのは、実業務ではハードル高い。
むしろ、設計入る前とかのブレストの方が使えるかも知れない。 あと、設計が実装に寄りすぎて「そもそもこのプロダクト何したいんだっけ?」な開発では有効かも知れない。(そもそもそんなプロジェクトは炎上案件だけど)

あと、現場導入時はファシリテート出来る人がいないと崩壊するのが目に見える。
幸い、ソフトウェアテスト勉強会でまた実施するそうなので、引き続き実践してみる。

リンクなど

VSTeP

VSTeP – Qualab

当日のToggtter

JaSST'16 Tohoku ソフトウェアテストシンポジウム 2016 東北「テスト開発しちゃいなよ!~テスト設計との違い~」 #jassttohoku - Togetterまとめ

VSTePとゆもつよメソッド(とHAYST法)の違い

http://jasst.jp/symposium/jasst13tokyo/pdf/A2-1.pdf

仙台ソフトウェアテスト勉強会のレポート(2015/09)

2015/09のテスト勉強会レポート。
先月の勉強会 に引き続き、ゆもつよメソッドの勉強。

マトリクスのチェック

前回作成したマトリクスに対して、仕様書等を参照しながら、作成したマトリクスに、試験が必要と思う所に○を付けていく。 (今回は時間の都合で圧縮の所まで○付け)

f:id:mokky14:20150924124030j:plain

重み付け等で差を付けたい場合は適宜記号を工夫する事。

試験項目作成

作成したマトリクスを元に、試験項目を作成する。

f:id:mokky14:20150914195026j:plain

表に記述する内容は以下の通り。

項目 記載する内容
機能名 中項目-小項目(内容が分かれば小項目のみでも)
テストタイプ テストカテゴリの種類(ex.機能性、負荷テスト、パフォーマンステスト)
テストカテゴリ テストカテゴリの各項目
仕様項目 テストでの確認観点
期待結果/確認内容 期待する結果、確認する内容等
パラメータ テストで指定するパラメータ(上図では省略)

機能名~テストカテゴリはマトリクスに○を付けたものを抜き出して記載する。 この各項目に対し、確認対象、確認する内容を記載していく。
試験項目と、マトリクス、仕様書を相互確認しながら作成する。マトリクスに不足があったりしたら、そちらも適宜修正する。

マトリクスの用途

ゆもつよメソッドのマトリクスは、システムテストのチェックに使用するために考えられたもの。

以下、自分の解釈。

単純に機能のIN/OUTだけに着目した試験だと、機能的に確認しておくべき試験が漏れてしまう事が懸念される。
そのため、ユーザシナリオでユーザにとって重要な機能を確認した上で、内部構造にも着目して試験観点を抽出する。
マトリクスの内容は、結合試験の内容と多少オーバラップしたものになるが、機能や処理パターンを網羅する事が目的ではない。 「ユーザシナリオを提供する」ために必要な機能を試験観点として抽出する事が目的になる。

非機能観点の試験は、「ユーザシナリオを提供する」ために必要な機能を抽出した上で、 その機能を多方面(性能、連続運転、ユーザビリティ、セキュリティ、等)の観点から検証するために実施する。

非機能観点は対象のプロダクトが変わっても流用できるものが多くなる。 チームやプロダクトで育てていくと良い。

最後に

ねもとさん、ありがとうございました。

仙台ソフトウェアテスト勉強会のレポート(2015/08)

2015/8/20のソフトウェアテスト勉強会のレポート。

今回はゆもつよメソッドのテスト分析マトリクスを使ったテスト分析のワークショップ。

なお、今回の内容は、勉強会主催者の理解に基いたコンテンツを、更に自分の理解した内容で書いているため、オリジナルのゆもつよメソッドと違う事を書いてたりする可能性があります。しかも自分が内容を理解し切れていません。 予めご了承下さい。

テスト設計三大巨頭

  • 西先生 VSTeP/NGT ツリー型の分析
  • 湯本先生 ゆもつよメソッド マトリクス型の分析
  • 秋山先生 HAYST法 リスト型の分析

テスト分析マトリクスとは?

こんなやつ。

f:id:mokky14:20150821125856j:plain

このマトリクスに対して、テストが必要なところに○を付けていく。

このマトリクスで、テスト全体を俯瞰して漏れがないようにする。
また、関係者でテスト観点についての合意を取るためのネタにする。

なお、このマトリクスは、 +Lhaca に対して作ったもの。

マトリクス要素の抽出

f:id:mokky14:20150820204241j:plain

分割した3つの要素をそれぞれ作成していく。

機能一覧の作成

中項目の導出

f:id:mokky14:20150820194758j:plain

  1. ユーザストーリーを考える
    ストーリーはメイン(ユーザの主利用方法)のシナリオ、サブシナリオを考える。
  2. 作成したストーリーからキーワードを導出する。
  3. システム管理、設定の項目を追加する。
    これらの項目はどのシステムでも汎用的に使える。
    なお、設定は中項目に入れるパターンと小項目に入れるパターンある。
小項目の導出

f:id:mokky14:20150820194950j:plain

抽出した各中項目に対して、小項目を抽出する。

機能テストの導出

f:id:mokky14:20150820201941j:plain

完全なブラックボックスではなく、少し構造に踏み込んで検討する。

  1. 「論理的内部構造」のモデル(上図)に対して、対象機能が扱うデータや操作をマッピング
  2. マッピングしたデータを抽象化してキーワードとする。
  3. 「状態遷移」「異常処理」を追加する。

f:id:mokky14:20150820204129j:plain

非機能テストの導出

f:id:mokky14:20150826123602j:plain

非機能の観点は世の中に出回ってるのでこれをベースに考える。
中項目、小項目で上げた機能に対して、機能を揺さぶる観点から、必要な非機能観点を抜き出す。

マトリクス化

中項目、小項目と、機能性項目、非機能カテゴリを掛け合わせたマトリクスを作成する。

感想、疑問など

  • 何で大項目がないんだろう?
  • 非機能カテゴリ、「機能を揺さぶる観点から」考えると、頭の中で中小項目と非機能のカテゴリを掛け合わせて、必要なものを考える事になるように思う。 突き合わせ結果はエビデンスとして明に残しておいた方が良さそう。
  • 中項目、小項目と機能性項目の掛け合わせ、フルのマトリクスでやる必要ある? 中項目/小項目単位で機能性項目考えてもよいのでは? 無駄に対象を大きくしてるようにも見える。
  • ユーザシナリオをベースに項目を考えること、ユーザのメインシナリオ中心で項目抽出するのは、大事な所からテストするという点で有用そう。

今回は消化不良気味。
次回続きを行うそうなので、その時にはもう少し理解出来るかな。

JaSST'15 東北 に行ってきました

今更公開するのも何だけど2015/5/29のJaSST東北のレポート。 今年のテーマは「レビュー」。

togetter: JaSST'15東北まとめ - Togetterまとめ

現在のレビューに必要な次の一手を把握するレビュー実践ウォークスルー

www.slideshare.net

ドキュメントレビューについて

100の問題があるプロダクトを与えたときの問題検出率は、

  • レビュー:80%
  • テスト:50%

レビューの方が問題が見つかりやすい。 バグは混入してから直すまでの時間が短いほど効率的に修正出来る。

レビューによるコミュニケーション効果

  • レビュー後に、チーム内の認識を一致させることができる
  • チーム作りができる
  • レビューを通して、プロダクトへの理解を深められる

レビューの開始基準

もし、突然レビューを頼まれたら?

  • まともな欠陥は見つからない
  • 何となくレビューすると、書いてあることだけのレビューになる
  • 思いつきでレビューが出来るほどのスキルを持っている人はほとんどいない

構造化されたドキュメントは、短い時間で多くの指摘が出来る。

人にレビューお願いする前にセルフチェックは実施しておいてもらう。
そのスキルもない人だった場合は事前方針を決めてからレビュー。

レビュー対象だけではなく、その対象物のInput情報も一緒に見る。

安達さんがレビュイに求めるレビュー条件

  1. レビュー観点が言えるか
  2. どう作ったかを言えるか
  3. 単純な指摘(誤字、脱字等)ばかりが出てこないか(レビューに耐えうるものか)
  4. 設計相談にならないか

レビュー観点

立ち位置(役割)によって観点は変わる。

  • 開発者:「作れるか?」
  • テスター:「テストしやすいか?」
  • 企画者:「使いやすいか?」
  • マネージャ:「売れるか?」

レビュー観点にも粒度がある。
レビュー観点の粒度の例:

  • 使いやすいものになってるか?
  • 文字は見やすいか?
    • フォントサイズが適切か?
    • フォントカラーは適切か?
  • ボタンは適切なものになっているか?
    • 押しやすいサイズになっているか?
    • 誤解を招く名前になっていないか?

レビュアのスキルによって、観点の粒度(どこまで具体化するか)も調整がいる。

何をどこまで書くか? IEEE830 1998 に情報がある

よくある欠陥

  • 開始・終了条件のアンマッチ
  • 非機能用件の抜け

観点の体系化は目的の整理になる

レビュー実施方法

ラウンドロビン:章毎に別担当にレビューを割り当てる インスペクション:効果は最大だがコストも最大

状況によりレビュー方法も使い分ける必要がある

この本がお勧め。

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

確認方法のシナリオ化

表現形式

図・表を自分の解釈で書き直してみる

テスト因子の洗い出し ラルフチャートを使うとよい

意地悪漢字
裏のワードも書かれているか?

全てやっていると時間が足りなくなるので、どこまでやるかはPJ毎に考える必要あり。

メトリクス

何に使うか?

ソースレビューは、150~200行/時間 くらいが効率が良い。

レビューは個別->全体 の順に。いきなり全体レビューは効率が悪い。

レビューコメントの書き方

レビュー指摘の仕方は一歩間違うと雰囲気が悪くなる。 主語を「あなた」ではなく「私」でコメントする。
× 「あなた」のこの書き方はおかしい
○ 「私」はこの書き方は修正した方がよいと思う

レビューの振り返りはレビューの後すぐやる。短い時間でやる。

改善をより効果的に回すためのレビューへの取り組み (CookPad 松尾さん)

www.slideshare.net

見るものをGitHubに集約

振り返りで人的な負荷が毎回課題に上っていた。
個人の意識だけでは継続が出来ない。
見るものを分散すると、人の負荷になる。
一カ所に集約することで、忘れることもなくなる。

レビュー観点

  • ソフト全体 価値あるソフトになっているか?
  • 計画、ドメイン、設計
  • コード誤り
  • 成果物
  • ドキュメント

チェックリスト

PullReqを出す前にセルフチェックする

静的解析(Dokumi)

変更差分に対してのみ静的解析を行い、コメントする仕組みを用意。 自動的に行う。

まとめ

  • 計算機が出来ることは計算機にやらせる
  • 分散させない

効率的なレビューの運用について (村上さん)

PMPは書類が多い
打ち合わせが多い
実作業<管理作業になる

バグトラッキングシステムで指摘を管理するように

  • 指摘と修正もチケットで管理
  • コミットログで修正履歴を管理

議事録も全てチケットで管理。 全文検索が出来るので便利。

達人の指摘から学ぶレビューのポイント (根本さん)

不具合の印象は強く残っているが、レビュー指摘の印象はあまり残っていない。 喉元すぎると忘れてしまう。

知識がないのにレビューをしなければいけない立場になった。
→達人のレビュー指摘から学ぶことにした

達人のレビュー指摘から観点とキーワードを導出。 自分が同じ指摘出来るようなレビュー観点を作成する 注意するキーワードを見つける

分からない事はすぐに確認。後に回さない。

業務改善コンサルからソフトウェアテスト効率化へ ~ 株式会社SHIFTサービス紹介 ~

テスト支援ツール chibinekoの紹介 https://chibineko.jp/

ライブコードレビューで学ぶ!「納品のない受託開発」を支えるコードレビューの取り組み

倉貫さんパート

レビュー=成果物に対する指摘
マニュアル通りに書けるプログラムはない

人を育てるには、作らせて、指摘するしかない。 教育効果も狙える

相手の事を考えられる人を増やすには?
全てを担当する。 毎週、「成果」を提供する。「時間」を提供するのではない。

仕様変更はビジネス価値最大化のための選択。

ビジネスモデルとビジョンを共有する。
作る物をミーティングで合意して、翌週届ける。
動くソフトウェアが設計書。
設計内容はボード等で説明。後に残す必要はない。

ソフトウェアに求められる特性

  • 常に仕様を追加・変更できること
  • 常にリリース可能であること
  • スピード感を持ち開発できること
  • 不具合はすぐ修正可能であること
    完全にはなくせないが、検知できること。放置しないこと
  • 上記の特性により、持続して変化できること

ソフトウェアは塩漬けにはできない。 外的環境が許さない。何もしなくてもOSやミドルウェアのバージョンアップが発生し、追随しなければならない。

西見さんパート

www.slideshare.net

ソースコードで全てを回す

以前はペアプロでコードを共有していた。効果はあるが時間がかかる。 レベルの高い人同士であれば、コードレビューで理解し合えると気づいた。

出来ない人がコードレビューするのは時間の無駄。
一人前の人は「良いコードは何か?」の共通認識を持っている。

ランチタイムのディスカッションで共通認識の醸成をやっている。

レビュータイミング

  • ローンチ前の全体レビュー
  • 本番リリース前レビュー
  • リリース前レビューは毎回実施

レビュー観点

  • 意図を読み取れるソースコード
  • テストコードは書かれているか
  • リリース時に問題が起こらないか
  • 障害時のリカバリは考えているか、問題時にすぐ対処できるか
  • 環境周りの変更はないか

読みにくいソースコードは「読みにくい」と素直に言う。

価値観

コードレビュー 7つの秘訣

  • レビューの観点を明確にすること
  • 我が身に返る事を恐れずに指摘すること
  • 何故悪いコードなのかを論理的に説明すること
  • 良いコードについての共通認識を持つこと
  • 小さい単位でレビューを繰り返すこと
  • 指摘は素直な気持ちで受け入れること
  • 指摘は人格否定でないことを理解すること

ディスカッション みんなにとって分かりやすいものにする

個人の趣味で指摘をしないこと

まとめ

  • 自分たちの開発プロセスに適したレビュー観点を設定する
  • レビュー観点に基づく、良いコードの共通認識をチームで持つ
  • レビューは小口化して継続的に実施する

人の目を入れてコードを腐らせない

レビューに関するQA

自分の質問と、パネラーから頂いた回答。

質問) 効率的にレビューを実施するにはどうすればよいか?
十分な時間がない中でレビューを実施する事があり、短い時間の中でもレビューを有益なものにするにはどうすればよいか?

  • 小さく作ってレビューする。
    いきなり全部作ってではなく、5~10%くらい作った時点でレビュー。
    大きい固まりが一度に「ドン!」と来たら既に負け戦。
  • 「気になるところ」をチームでレビューする。
  • どういうところが大事かを事前に決め、そこを見る。

  • 時間割を決めてやる

  • 大事な所からやる
    リスク部分、難しい所、重要な所など
  • ゴールを決める 何が出来るようになればOKか?
  • 人間特性、手薄い所、異常系の記述量が薄い所を見る。

他のQAでなるほど、と思ったコメントなど。

  • 「レビューをやって良かった!」と思わないと継続できない。 レビューの効果を測定し、見える化する。

  • レビューの時間は予め予定に組み込んでおく。

  • 大きいプロダクトのレビュー終了条件は「時間」。 レビューが遅れたら後行程の作業はその分遅れる。
    期間を予め決めて、その期間の中でプロダクト品質を高めるにはどうすればよいかを考えた方がよい。

改めて思った事など

ドキュメントは読み手のレベルに合わせる必要がある。 万人に対して大丈夫なドキュメントなど存在しない。

ソースがドキュメントになるには、プログラマのスキルは必須だが、言語も選ぶと思う。
Rubyはともかく、手続きのコードが多くなりがちなC言語のソースを「ドキュメント」というのは辛いように思う。 ソニックガーデンさんがRubyを選択してるのはRuby on Rails使える以外に、ソースがドキュメントになり得るという所もあるのかな、と思ったりした。

前のプロジェクトで、こっちが作った設計書に「あれ書いてない」「これ書いてない」「フレームワークが分からない」と散々ダメ出しされた事があって、チームの雰囲気が最悪になった事を思いだした。
気にするポイントはその設計書を見る人の数だけあるので、事前にサンプル出して相手と意識合わせする事が重要。

レッツゴーデベロッパー555に行ってきました

2015/7/25のレッツゴーデベロッパー555のレポート。

ソフトウェアエンジニアとして心がけてきたこと 柴田芳樹氏

当日のスライド

www.slideshare.net

ソフトウェアは「人」が作る

ソフトウェアを書くことは芸術。うまくなるには10年を要する。

優秀なプログラマであれば、低レベルの言語、扱いにくいシステムであっても克服するが、 優れたプログラム環境は出来の悪いプログラマを救済してはくれない

優れたソフトウェアは人が作る。ツール技法が作ってくれるわけではない。

プログラマー現役続行するために

読みやすいコードを書く

ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すこと。
保守できないコードは、負債となる。初心者だからといって、汚いコードを書くことが許されるわけではない。

コンピュータが理解できるコードは誰でも書ける。優れたプログラマは、人が理解できるコードを書く。

ネーミングは設計の中心。良い名前を付けることは訓練を必要とする。熟練したプログラマとなるためにはこのスキルを伸ばすことが重要。

  • 優れたネーミングはシステムの理解を助け、作業を容易にする
  • 貧弱なネーミングはシステムの理解を妨げ、後でシステムを扱うプログラマに辛い日々を送らせる。
論理的思考
  1. プログラムの失敗を観察する
  2. 観察と矛盾しない失敗の原因についての過説を立てる
  3. 仮設を使って予想する
  4. 予想を実験でテストして、更に観察する
    1. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする
    2. 満たされないなら、別の仮設を立てる
  5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す

キーボードを早く触りたい気持ちを抑えること。思考はそれに勝るとも劣らない行為。 まず深呼吸をしてから、バグを引き起こした原因について考える。

継続した学習

ソフトウェア業界で取り残されないようにするには

  1. 重要な本、出版物を読み、主なカンファレンスに参加すること。
  2. 今日読んだ情報は3年から5年で古くなるため、常に終わることのないプロセスであると言うこと。
  3. あなたの会社は、良くても限られたサポートしか提供しない。最悪何もサポートしてくれない。

ソフトウェア業界で取り残されないためには、自分から進んで自分の時間や自分のお金を投資しなければならない。

一冊の良い本を選べば、他の人が何十年もかかって習得してきた見識を、数日で得ることができる。
技術を創りだした人が執筆した書籍を読むとよい。
アメリカでは、プログラム言語を作った人が本を書くことが多い。

技術書には誤りがあると思って読む。 誤りがあると思ったら、間違いだと思って流さずに問い合わせたりすると新たな知見が得られたりする。

柴田さんは、Effective Java(英語版)を読んで衝撃を受けたそう。 (その後、この本を翻訳してしまう行動力がすごい)

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

コンピュータの基礎知識

何年立っても陳腐化しない。

コミュニケーション力
  • 相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明する。
  • 相手の説明をきちんと理解できない場合に、相手が何を言いたいのかを逆に質問して、正しくコミュニケーションを取るように務める。
英語力
  • 専門的な技術の継続した学習と同様かそれ以上に、英語力を身に付けるための継続した学習が必要
  • 内容を理解し、技術書をある程度のスピードで読むには、TOEIC900点以上が必要

追い越される人、追いぬく人

新卒と一人前のエンジニアの差は縮まることはない。
一方、何の努力もしていない人を追い抜くことは、立ち止まってる人を追い抜くような簡単なもの。

立ち止まることなく、ソフトウェア開発を楽しみましょう。

セッション1 多階層組織の中でのエンジニアのありかた 村上正則氏

多階層組織とは

  • 社長を頂点とした階層組織
  • プロパが上がれる階層は決まっている
  • 組織図からは読み取れない、人のつながりがある
  • 業務で縦割りが基本
  • プロジェクトの構成も業務で縦割り
  • 1次受け 2次受け 3次受け...

プロジェクトの中で、プロジェクトを進める人の割合は1%!この人たちだけが本当のエンジニア。
この人たちだけが「プロジェクトを進めるために何をするか」考えている。この人が抜けたらPJ炎上はする。
でもこの人たちは上には行かない(出世コースに乗れない)

エンジニアの取れる選択肢
  • スキルチェンジして、管理をやる
    コード書くのは辞める
  • 組織外のコミュニティに参画する
    会社での出世は諦める
  • 内部改善をする

モチベーションの話

優れたエンジニアは、給与とかポジションとか気にしてない

技術は面白い
  • 勉強会はいたずらして遊ぶ時間
  • 動いたら楽しい
  • うまくいったら楽しい
楽しむためにやっていること
  • 無知を装う
    • 作業を丸投げされるのを防ぐ
    • 作業のゴールを曖昧にさせない
    • 作業のやり方、ゴールを言わせる
      「お前がやると言った」と言われないように
  • 管理しない
  • でも、コミュ力はそこそこ必要
    • 露骨な否定はしない
    • 話は聞くだけにする
    • 同意はしない
コミュニティに参加する
  • 自分の興味のある部分だけ
  • 無理しない。背負わない
  • できたら貢献する

エンジニアに朗報!

管理のピラミッドの他に、技術のピラミッドが作れる環境がもうすぐ出来てくるはず。

外圧と新陳代謝

  • 組織内の人も5年もすれば変わります
  • 人が変われば、仕事も変わる
  • 組織外の圧力には、そうそう逆らえない

組織の良い部分を使う

  • 数がある
  • 組織同士のコネクションがある
  • 組織は時間があれば変えられる

最後に

  • 作れる人が一番偉い
  • 技術の価値は必ず現れる
  • 組織は時間があれば変えられる

セッション2 ザ・ジェネラリスト ソフトウェア開発を勉強し始めて6年でトップレベルになるためにやったこと kyon_mm

当日のスライド

www.slideshare.net

エンジニアとは

ソフトウェア工学を知見を活かして仕事する人

トップレベルとは?
  • 既存の技術を作り直せる人
  • 次のステップを作れる人

always cool engineer

最高のエンジニアに対して最高の評価をする人が現れたらどうする? その時になってから勉強しても間に合わない

No Time Release

リリースまでの時間を0にしよう。 実際に0にすることは出来ないが、これをどこまで努力するかがエンジニア。

Cyber Punk

この仕事のモチベーションは攻殻機動隊
攻殻機動隊の世界を作るために必要なスキルは何でも欲しい 。

Generalist or Specialist

ジェネラリスト:何でも出来る人 ドラクエで言うところの勇者 スペシャリスト:特化型

8:2の法則を使うと、スキルレベル全体の8割を満たすまで達成するのは2割の時間で出来る。 残り2割を勉強するのは時間がかかるので諦める。 これらを全ての分野で行うことが大切。 たいていの人は多くの分野を知ろうとしないし、つなげることもしない。

言語学を勉強したことが、オブジェクト指向言語の理解につながったりする。(オブジェクト指向は海外で生まれた考え方なので、その国の言語学で勉強したことがオブジェクト指向の理解につながったりする)

8割を目指すのであれば形式知(本)でいける。

ある程度の技術書1冊はあるコミュニティの3年間の歴史が入っている。 技術書を年間に3冊読む人は1年で9年分の歴史を手にしている。 kyon_mmさんは技術書を年間40冊以上読むことにしている。 計算すると1年で120年分の歴史を手にしている。

愚者は経験に学び、賢者は歴史に学ぶ 。

Reading

技術書は2周以上読む。1周目は必ず3日以内に読む事。分からなくても問題ない。
どこかに詰まって読めないと、いつまで経っても読めない。

  • 短期記憶とうまく付き合う
    時間を空けると前の方に書いてあったことを忘れる。書いてあった事を忘れないうちに一通り読んでしまう
    読んで詰まった事が後に詳しく書いてあったりする
  • 本の中の言葉の使い方に慣れる。繰り返し出てくる言葉には気をつける
  • 書籍のクセ(構成、濃淡)を知る

本の読み方についてのkyonさんのスライド。

www.slideshare.net

Speaker, Blog, Article, Book

セルフブランディングについて考える機会。 組織やプロダクトをより良くするためにとても重要な考え方。

  • 自分では気づかないことを知っている人と出会える
  • 世界の広さを知ることができる。(良い面、悪い面とも)
Speaker

自分の考えを整理するスキルを身につける時間を作れる。

わかりやすく表現することに積極的に取り組んで、多少の失敗が許される。 マサカリを受けても、基本は受けた側が痛いかどうかだけ。投げている側はマサカリだと思ってない。

Concern

Scrum

権限が十分にあるプロフェッショナルな小さなチームがリズムを保って動くことで、生産性がとても高くなることをうまくルールにしている。
Scrumがうまくいってない人は、スクラムガイドに書いてある必要な事を全部やってないだけ。

BDD

フォーマルメソッドでは上手く行かない分野でうまく開発するための新しいプロセス。

kyonさんが書いたTDD/BDDの記事。

「いまさら聞けないTDD/BDD超入門」最新記事一覧 - ITmedia Keywords

MicroService with OO

PaaSとオブジェクト指向の出会い。これからどんどん世の中はSmalltalkのようになっている。 テスト不可能よりも、エンドユーザがサービスを作る時代。 (例. IFTTT、Wikipedia)

Conclusion

  • ジェネラリストになるということは、ある意味でソフトウェア開発におけるマニアというか研究者である
  • なんでもできるやつが絶対強い。

Extreme Fishbowl 川口恭伸氏、井上岳大氏

Pair Programming

経験が隣で見ている人に伝播させることが出来るやり方。 暗黙知は実際にやらないと伝わらない。

mob programmingという、ディスプレイにコードを映しながらみんなで議論してコーディングしていくやり方もある。

その後、ポーカーの役を判定するお題でmob programmingを実践。 迷ったけど、前に出てプログラムやってみた。 以下、やってみた感想。

  • お題の内容を少しずつ実装していくとして、最初にどこまで作るか悩んだ。
    Cardクラス実装しようか、判定する役が増えた場合に向けた処理構造どうしようか、等。
  • 少しAPI調べれば書けるコードだと思ったけど、何も見ずに書く事が出来なかった。
    ワンペア、ツーペア判定のコードはJava8のstreamAPI使えば簡単に書けるだろうなとは思ったけど、どう書けばよいのか出てこなかった。 普段から刀研いでおくの大事。
  • ルール、やる事を明確化して進めれば良かった。 自分はポーカーのルール知ってるけど、ルール知らない人もいたので、最初に明確化した方が良かったかも。
  • 人のマシン使うのは難しい。

この後、本もらいました。ありがとうございます。

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

明日から何やる?

参加者各自で、明日から何をするかを検討した。 自分が取り組む事にしたのは以下。

  1. 溜めてる本を全部読む。
    途中で詰まったりして読むのを中断してた本が結構あるので、それを読みなおす。
  2. プログラムを書く。 少しでもいいので、プログラムに触る機会を作る。
    書いたプログラムはGitHubに上げたりQiitaに投稿したりする。

感想とか

今回のレッツゴーデベロッパーのテーマは「エンジニア」。 自分は、エンジニアとして生きていくなら、ずっと勉強をし続ける必要があると思っている。 凄い人達は、自分より勉強してて、今も勉強し続けてるんだと分かった。

一方、コードを書く技術も磨き続ける必要がある事を改めて実感した。 昔は書けてたコードも、しばらく書かないでいると、かなり錆びついてたりする。 たとえ仕事でコードを書く機会がなくても、個人でコード書く事はやっておかないとダメ。 あと、後日のTDD勉強会でfishbowlの続きをやった時、柴田さんが言っていたネーミング技術の大事さを実感した。 読みやすいコード書くには、名前付けの技術は必須。

英語力の向上は継続課題。(-"-