bryutus blog

お前もか

2021FYの振り返り

年度末なのでつれづれなるままに今年度の仕事をタイムラインで振り返ります。

04 - 06月

大きなマイルストーンのリリースを行った。
もちろんリリースしたら終わりというわけではないので、リリースに合わせた運用も始まり、日々発生する問題に対処することに追われていた。

新年度からは役職が付いて管理職になった。
2月ぐらいから前振りがあったけど、マネジメントに関する書籍を2冊読んだぐらいでほとんど準備ができていなかった。

07 - 09月

メンバーとの1on1を始めた。
評価者と被評価者という関係や1on1に対しての警戒心もあってか、始めたばかりの頃は「特に何もないです」で終わることもあったけど、最近は少しつつくと「実はあの時こう思っていて...」と話してくれるようになったメンバーもいる。

1on1に対する期待値を高く持ち過ぎて空回りしていたけど、あの時の発言はどういう意図があったんだろう?どんなことを考えていたんだろう?と、興味の対象を本人に移してからは良い方向に向かっていると思う。

ビジネス側とのやり取りに忙殺されており、これまでの開発手法に限界を感じていた。
極端に言うとメンバー毎に一人カンバン方式のような開発手法を取っていて、仕様や要件に関する確認が全て自分に集まっていたため、自分がボトルネックになっていた。また、チーム内でも隣の人がどんなことをやっているのか分からず、ヘルプもやりづらい状況だった。

社内のスクラムマスターに相談をして、スクラム開発やチームビルディングの書籍を読んでいた。

10 - 12月

スクラム開発をチームに導入した。
それと同時にこれまでやってきた業務の一部をチームにやってもらうことにした。単純に個人に委譲すると自分の大変さが別の人に移るだけで何も問題は解決していないので、チームや仕組みで解決できないかということを心がけている。
が、結局個人に大変さが移っただけの部分もある。マイルストーンをうまく置くことができず、方向性が定まっていないのが今の課題だと考えている。

これまでハレーションを恐れて気を遣った結果、マイクロマネジメントになってしまったりと誰も嬉しくない状況になってたけど、チームのことを信頼して責任を持ってもらおうと思うように徐々になってきている。

業務量のキャパシティは変わっていないが、業務の領域が少しスライドしただけで、またチャレンジできるところが見つかって仕事がより楽しい。メンバーも同じ想いになってくれてると嬉しい。

01 - 03月

仕様の認識違いやテスト漏れ、デグレによる不具合が続いたこともあり、クオリティを上げるためにはどうすれば良いか?ということを考えていた。
体系的にテストを学んだことがなかったため、練習帳なるものを購入してテスト技法についてを見かじった。

設計と開発、テストの距離をもっと近くするためにDDDの勉強を始めて、勉強してきた知見を共有する会を同じプロジェクトの人と密かにやっている。

振り返りと来年度に向けて

組織的にもメンバーからリーダーになったけど、成果の出し方の考え方が変わっていないので、自分1人のパフォーマンスで何とか頑張ろうとして長時間労働一択になっている。メンバーも見てて大変そうとしか思えなくて、リーダーという役割を魅力的に感じてくれる人は少ないだろう。

来年度はメンバーに面白そうだとか、チャレンジしてみたいと思えるような環境を作ることを頑張りたい。

昨年の今頃は来年度のことを考える余裕が微塵もなかったけど、今年は次のことを考えてアクションできているところもある。
少しずつだけどきっと前進してる。大丈夫。

「ソフトウェアテスト技法練習帳(Part 3・4)」の中で出てきたテスト手法を整理してみた

前回のPart 1・2に続いて、Part 3・4に出てきたテスト手法についてを整理してみます。

bryutus.hatenablog.com

Part3 状態遷移テスト

ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03には、このように記載されています。

コンポーネントやシステムは、現在の条件や過去の履歴(システムの初期化後から起きるイベントなど)によって、イベントに対して異なる振る舞いをする。過去の履歴は、状態の概念を使用してまとめることができる。状態遷移図は、ソフトウェアの取り得る状態、ソフトウェアが開始および終了する方法、ソフトウェアが状態間で遷移する方法を示す。
・・・
状態遷移表は、状態間の有効な遷移と無効だと思われる遷移のすべてと、イベント、有効な遷移の際のアクションを示す。状態遷移図は有効な遷移のみを示し、無効な遷移は除くのが一般的である。

状態遷移図

どのような状態があるのか、その状態が変化するイベントはなにか、これらの状態をイベントでつなげることで状態遷移図を作成します。

f:id:bryutus:20220219220045p:plain
状態遷移図

状態遷移表

作成した状態遷移図をもとに状態遷移表を作成すると、状態とイベントの組合せの漏れや仕様にない遷移を見つけやすくなります。

状態X 状態Y 状態Z
イベントA 状態Y 状態X N/A
イベントB N/A 状態Z 状態Z
イベントC N/A N/A 状態Y

関係行列

縦軸に遷移前の状態を、横軸に遷移後の状態を、各セルに状態が遷移するときのイベントを記載した関係行列を作成します。

状態X 状態Y 状態Z
状態X a
状態Y a b
状態Z c b
  • a: イベントA
  • b: イベントB
  • c: イベントC

1スイッチカバレッジ

2回のイベントで遷移するパスを全て網羅するカバレッジです。
1スイッチカバレッジは、関係行列の積を取ることで求めることができます。

状態X 状態Y 状態Z
状態X aa ab
状態Y aa + bc bb
状態Z ca bc bb + cb

テストケース

1スイッチカバレッジの状態遷移のパスをテストケースとして起こしていきます。

No 遷移前の状態 イベント 期待値
1 状態X イベントA → イベントA 状態Xに遷移すること
2 状態X イベントA → イベントB 状態Zに遷移すること
3 状態Y イベントA → イベントA 状態Yに遷移すること
4 状態Y イベントB → イベントC 状態Yに遷移すること
5 状態Y イベントB → イベントB 状態Zに遷移すること
6 状態Z イベントC → イベントA 状態Xに遷移すること
7 状態Z イベントB → イベントC 状態Yに遷移すること
8 状態Z イベントB → イベントB 状態Zに遷移すること
9 状態Z イベントC → イベントB 状態Zに遷移すること

その他にも、C1カバレッジ(遷移網羅)や有限オートマトン、プッシュダウンオートマトンといったキーワードがありましたが、正直に言うとこれらについては理解が追いついていません。
今は理解はできていないですが、そういった考え方や手法があったなと頭の片隅に置いておき、実践を交えつつ理解を深めようと思います。

Part4 組合せテスト

ISTBQの用語集には、このように記載されています。

ブラックボックステスト技法のひとつ。複数のパラメータの値を特定の組み合わせで実行するためのテストケースを設計する。

すべての組合せをテストするには非現実的なこともあります。そういった場合に、効率的な組合せテストを行うためにペアワイズ法を使います。
ペアワイズ法は、バグは1~2因子の組合せに多く存在することが経験的に知られていることに基づいてテストケースを作成する方法です。

  • 因子: 入力のパラメータや条件
  • 水準: 因子の取り得る値や範囲
    • 同値分割法や境界値分析を使って最適化する

次のような因子と水準があった場合に、全てのケースをテストしようとすると27通りのテストパターンが存在しますが、ペアワイズ法を用いると9通りまで数を削減することができます。

  • 因子: 水準
  • Type: Single, Span, Stripe
  • Size: 10, 100, 500
  • File: FAT, FAT32, NTFS
$ pict model.txt 
Type    Size  File
Stripe  100   FAT32
Span    100   FAT
Stripe  500   NTFS
Span    10    NTFS
Span    500   FAT32
Single  100   NTFS
Stripe  10    FAT
Single  10    FAT32
Single  500   FAT

このように2因子間の組合わせの網羅は行いますが、3因子間の100%の網羅性は保証していません。3因子間以上の網羅性を犠牲にして組合せ数を削減しています。


ペアワイズ法を使ってテストケースを作成するために、Microsoft社が公開しているPICTを利用しました。

github.com

「ソフトウェアテスト技法練習帳(Part 1・2)」の中で出てきたテスト手法を整理してみた

仕事でテスト漏れによるバグが発生したことでテストのやり方について思うことがあったので、「ソフトウェアテスト技法練習帳」を買って問題を解いています。

この書籍は問題集として特化しているため、その中で使っているテスト手法についての言及はあまりありません。
自分の理解のためにPart 1・2で出てきたテスト手法についてを整理してみます。

Part1 同値分割法と境界値分析

同値分割法

ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03(以下、シラバス)には、このように記載されています。

同値分割法は、同等に処理されると想定したデータすべてを同じパーティション(これを同値クラスと も呼ぶ)に振り分ける技法である(『Kaner 2013』および『Jorgensen 2014』を参照)。有効な値と無効な値の両方に対して同値パーティションがある。

システムに入力が可能な値を、有効な値(システムに受け入れられる値)と無効な値(システムに拒否される値)とにパーティションを分けてグルーピングし、そのグループの中の代表的な値をテストする手法です。

同値クラスは「その範囲はどの値でも同等に処理されることが合理的に予想される」集まりです。
有効な値の同値クラスを「有効同値クラス(有効同値パーティション)」と呼び、無効な値の同値クラスを「無効同値クラス(無効同値パーティション)」と呼びます。

例えば、年月日のうちの「月」の値を入力する場合、月の入力値の同値クラスは以下の3つにグルーピングすることができます。

境界値分析

シラバスには、このように記載されています。

境界値分析(BVA)は同値分割法の拡張であるが、パーティションが数値または順序付け可能な値で構成される場合だけ使用できる。パーティションの最小値および最大値(または最初の値と最後の値) が、境界値である(『Beizer 1990』を参照)。

同値クラスの上限値、下限値とその前後の値(境界値)を入力としたテストを実施します。 境界付近では間違いが起こりやすいため、その付近を狙ってテストを行います。
同値分割法と組み合わせて実施することが多いです。この練習帳でも2つの手法を組み合わせた問題が出題されています。

例えば、年月日のうちの「月」の値を入力する場合、境界値は以下のようになります。

Part2 デシジョンテーブル

シラバスには、このように記載されています。

デシジョンテーブルは、システムが実装すべき複雑なビジネスの規則を表現するのに有効である。デシジョンテーブルを作成する際には、テスト担当者は条件(主に入力)と結果的に起きるシステムのアクション(主に出力)を識別する。条件とアクションは表の行となり、条件を上部、アクションを下部に記述する。

条件(入力)に対して、プログラムがどのように動作(出力)するかを表形式にまとめたものです。入力条件の組み合わせと対応する出力結果を整理することでテストケースを作成する技法です。

JIS X 0125では、Y/NやXで記述する方法を制限指定と呼び、数値や選択肢で記載する方法を拡張指定と呼んでいます。

1 2 3 4 5 6 7 8
クーポン持参 Y Y Y Y N N N N
平日/休日 平日 平日 休日 休日 平日 平日 休日 休日
65歳以上 Y N Y N Y N Y N
割引なし - - - - - - X X
10%OFF - - X X - - - -
30%OFF - X - - - X - -
50%OFF X - - - X - - -

結果が同じ動作がある場合、その組み合わせを省略して書くこともできます。しかし、ロジックが不明であり、処理順序が分からない場合に省略すると必要なテストケースが漏れてしまう可能性があるので注意が必要です。
条件が増えるとテストケースが増え、表が大きくなります。ほかの条件と比べて関連性の低い(独立性の高い)条件で分割することで、表を小さくすることができます。

良い1on1を待っている

良い1on1を受けると、心の中に何となく引っかかっていたことが、会話を通して徐々に輪郭を持つようになり、それを言葉にすることで内省が進み、次に何をすれば良いか具体的なアクションが見えるようになります。

チームのメンバーにも同じような体験してほしいという思いから1on1を定期的に行っているのですが、なかなか成果を出せていないように感じています。
そこで、これまでに受けてきた良い1on1を振り返って、自分がやっている1on1に反映できそうなところがないか、何が違うのかというところを見つめ直してみようかと思います。

ここでは、1on1の中で聞き手やサポートをする人のことをメンター、話し手や主役になる人のことをメンティとして記載しています。


良い1on1では、何を話しても大丈夫だという安心・信頼感があります。
安心・信頼感があると、話をする時に余計な言葉の変換が挟まらなくなり、より生の考えを話せるようになります。 人に悩みを話すことにも勇気が必要です。 たとえ1on1という場を設けてメンターとしての心構えを持ってたとしても、安心・信頼感が足りなければメンティは正直に何でも話すことはありません。
メンターとメンティが人事評価の評価者と被評価者という関係になることが多いかもしれませんが、人事評価をするための場ではないということを伝えることは重要だと思います。

良い1on1では、メンターからの問いかけを通して内省が促進します。
オープンな質問や発言の曖昧さを排除してくれるような問いかけをされると、それを言葉で説明するために頭の中を整理します。 頭の中ではふわっとした曖昧なままで済ませていたことも人に説明するために、自分の中で詳細に理解しようとします。 その理解する行動の中で、どうして課題だと感じていたのか、どうしてもやもやしていたのかという本質的な問題に気づけます。
また、愚痴やネガティブな表現をメンターが要望に言い換えて聞き返すことで、メンティが本当に伝えたかったことが言語化され、前向きな提案にもつながります。

良い1on1では、次にとるべきアクションをメンティが見つけます。
ほとんどメンティだけが話して壁打ちをしてもらっているだけなので、メンターから直接答えを教えてもらうことはないのですが、不思議と何かしらの答えを導き出します。 その答えが有効でない場合もありますが、一度問題を認識しているため、次のアクションも一人で考えるようになります。

こうやって改めて書き出してみると耳が痛いですが、どういう状態になったら良い1on1ができていると言えるのか自分なりの評価軸を持つことができました。

todo.txtでのタスク管理方法

仕事のタスク管理方法としてtodo.txtを利用しています。

これまでMicrosoft To Doといったタスク管理ツールを利用してきましたが、最近はこのシンプルなタスク管理方法が気に入っています。

todo.txtとは

todo.txtというテキストファイルでタスク管理を行います。

最も重要なルールは、todo.txtファイルの1行が1つのタスクになっていることです。 それ以外については細かいルールがありますが、どれを使うかは自由に選択ができます。

github.com

フォーマット

シンプルなルールですが、管理しやすいように少しアレンジしているところを紹介します。

ファイル

  • マークダウン形式( todo.md )を使用
  • GTDを参考にタスクを分類
# Waiting for

- ボトルネックになりそうな他の人に依頼していたり、ウォッチしているタスク

# Inbox

- 新しく発生したタスク

# My Day

- 今日やるタスク

# Important

- 期日が決まっていたり、重要なタスク

# Tasks

- 次にやるタスク

# Done

- 完了したタスク

タスク

  • projectdue date の項目のみをカスタマイズして使用
- (プロジェクト)タスク 期日
    - タスクに関連するリンクや補足情報

サンプル

このブログ記事を書くことをタスク管理した場合に、どのようになるかのサンプルです。

# Waiting for


# Inbox


# My Day

- (B)todo.txtの使い方を書いている記事を参考に構成を考える

# Important

- (B)記事を投稿する 2021/12/06

# Tasks

- (B)下書きを完成させる

# Done

- (B)todo.txtのルールが体系的にまとまっているページを探す
    - https://github.com/todotxt/todo.txt/blob/master/README.md

- (B)タスク管理で心がけていることを書き出す 2021/12/02

タスク管理方法

  • 今日やるタスクをMy Dayに移動する
  • 完了したタスクはDoneに移動する
  • 新しく発生したタスクはInboxに入れる
  • 一旦自分の手から離れたが、気にかけておきたいタスクはWaiting forに入れて、定期的にチェックする
  • 優先度に合わせてInboxからMy DayかTasks、Importantにタスクを入れる
    • 2分以内に終わるタスクは、分類せずにその場で完了させる

心がけていること

todo.txtに限ったことではないですが、個人のタスク管理を行う上で心がけていることです。

  • My Dayには達成できそうなタスクのみを入れる
    • 1日の終わりにタスクが全て完了させて、前向きな気持ちにするため
  • 不安のリストにしない
    • タスクが明確になっていないものは、何をすれば気がかりや心配から開放されるかを書き出す
  • 一時的なタスク置き場として利用する
    • 長い間Doneにならないタスクがリストに残り続けるのは良くない傾向
      • 個人のタスクとして持ち続けても、そのタスクは全く進まない
    • URLを付けてチームの他のメンバーからも見えるようにすることで、タスクが進むようになる

todo.txtでタスク管理してみて

このタスク管理方法に切り替えてから、タスクを漏らしていたということが少なくなりました。

小さいタスクもこのファイルに残すようにしているので、あのタスクに関連したチケットってどれ?となった時にインデックスとしても利用できます。

サッとメモを残して後から整理するという自分のやり方に、1テキストファイルでタスクを管理する方法は合っているような気がします。