最近の Link/Tag の使い分けと一ヶ月経過後の Obsidian のグラフの様子。｜tokuhirom
Obsidian を利用し始めて一ヶ月経過したので、グラフがどのぐらい育ったのかを公開します。また、そういうふうにグラフを広げるにあたり、どのように Graph のリンクを作ってるかも含めて説明します。 Obsidian のグラフの様子青いノードは daily notes です。 新規で作ったノートは daily notes にも作ったことを記録していることが多いので、わりと daily notes とのつながりが多めになっています。 Obsidian における連携方法Obsidian には複数ページの連携方法には Link と Tag の二種類があります。この2つの使い分けについては、どういうふうに使い分けるのがいいのかについて、ちょっと試行錯誤した結果、以下のような方法に落ち着いています。 MOC の作成についてLinkingYourThinking で提唱されている MOC(Map
見逃しがちな細かい仕様整理をテスト技法で乗り切ろう #Zaim｜Yuki Sumida
はじめにこんにちは、Zaim で iOS チームのリーダーをしている @y_sumida です。 以前のエントリ、大規模サービス開発で起こりがちな「やり直し」が激減した私たちの仕様確認フロー #Zaim では、Zaim でやり直しを減らすために整備した仕様確認の流れをご紹介しました。 流れの中に 真剣にレビューする というものがあったのですが、もう少し掘り下げて、開発する上で見逃しがちな「細かい仕様」をどう発見し、手戻り少なく実装しているかについて共有したいと思います。 一口に「細かい仕様」と言っても色々あります。例えばサービス開発の中でも、入力フォームに文字数制限をかけたり、金額によって数字の色を変えたりと、値に関する仕様は基本かつ複雑になりがちです。これらを曖昧なままにしておくと、仕様には沿っているものの、不思議なバリデーションや、ユーザーから見て矛盾したデザインのままリリースされ
現場で役立つテストの基本 - Qiita
ウォーターフォールモデルの場合、テストフェーズと、テスト設計のインプットとなるドキュメントあるいはテスト観点がV字型に対応するVモデルという手法が広く知られています。 しかし、「テストタイプ○○は××フェーズでやるべき」「テストタイプ○○には××技法を使わなければならない」という決まりがあるわけではありません。 開発プロセスが何であれ、要は、テスト対象ソフトウェアに求められる品質特性を充足できるよう、テスト全体を戦略的に計画すれば良いのではないでしょうか。 2. テストマネジメント 2.1. テスト計画 前述した組織のテストプロセスに基づいて作成 テストフェーズと、実施するテストタイプを定義 品質管理の計画値を策定 コード網羅率（カバレッジ） KStepあたりのテスト項目数 KStepあたりの不具合摘出数 など テスト体制 スケジュール テストの完了条件 2.1.1. コード網羅率（カバレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
