プログラマの思索
JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。 気づきを書き残す。 まだ理解があやふやなので、間違えていたら後で直す。 【参考】 テストアイテムとは何か？概要や定義、現場での使われ方について解説 【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。 たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。 テストオラクル、テストベースなどはJSTQBで初めて知った。 たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。 テストオラクルの用語定義: プログラマの思索 また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツール
プログラマの思索
「世界一流エンジニアの思考法」を読んでみた。 気づきをラフなメモ書き。 【1】試行錯誤は悪であること。 本番障害の原因調査でも、手当たり次第、ログから調べて探すのは生産性が悪い。 事実から仮説を1つずつ立てて、その仮説を1つずつ検証して可能性を潰していく。 試行錯誤が良くない理由は、後で得られる経験知がないからだ。 やみくもにモグラ叩きのように潰して、ああ終わったというだけ。 障害解決した一つの経験が後で活用できない。 事実から推測して、起きそうな仮説を複数パターンで立ててみる。 そこから1つずつ潰していくことで、自分のロジックを検証していることにもなる。 どこに原因があったのか、後で振り返るときにも役立つ。 すぐに手を動かさない。まず仮説を立ててアプローチを選択して一つずつ動かす。 分かっていれば当たり前なのだろうが、納期に迫られて焦っているときほど忘れやすい気はする。 【2】コードリー
TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？ - プログラマの思索
チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか？」という質問が来る。 僕はまだその質問に完全な回答は持っていない。 その質問について考えていることをメモ。 【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。 粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。 かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。 チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。 RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば
プログラマの思索
第27回redmine.tokyo勉強会で講演された「RedmineのUbuntu+Docker構築への移行」は内容が参考になったと思う。 ラフなメモ書き。 【参考】 第27回勉強会 - redmine.tokyo 発表 #1609: 第27回 講演: ＜RedmineのUbuntu+Docker構築への移行＞ - redmine.tokyo 【1】今回の講演の背景としては、問題意識として、RedmineをCentOSで利用している場合、どのOSへ移行したら安全なのか、容易に移行できるのか、がある。 おそらく、Redmineはフリーで現場で使っているので、OSやサーバも自前で構築する時にCentOSを利用しているケースは非常に多い。 そこで、CentOSはサポート切れになってしまった状況では、セキュリティリスクがあるために、どこかのOSに移行せざるを得ない。 OSSのLinuxOSは数多く
チケット駆動開発がもたらした新しい観点part3～トラッカーの考え方 - プログラマの思索
Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。 トラッカーについて考えたことをメモ。 ラフなメモ書き。 【1】Redmineのトラッカーはワークフローそのもの。 Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。 デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。 個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。 トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。 ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。 バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。 だから、それら作業はワークフローに複数人の担
Redmineのトラッカーやステータスの付け方 - プログラマの思索
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合／バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合／バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
