テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



121.テストプロセス その③

121.テストプロセス その③

テストプロセスは、テストの準備からテストの終了までの一連の作業を指しています。

テストプロセスを知ることで、テスト全体の流れを知ることができます。

全体の流れを知ると、現状足りなかった部分なども見えてくるでしょう。

 

テストプロセスには以下の活動があります。

概要や個々の活動の話は次回以降のマンガで行う予定です。

  1.  テスト計画
  2. テストのモニタリングとコントロール(テストプロセス全体を通して行う)
  3. テスト分析
  4. テスト設計
  5. テスト実装
  6. テスト実行
  7. テスト完了

 

テストプロセスが適用できるのはプロジェクト全体だけではない

テストプロセスの話をするとたまに勘違いされるのが

ウォーターフォール開発の時の話でしょ」

といったことです。

テストプロセスはいかにもプロジェクト全体の流れに見えるからでしょうね。

テストプロセスは「ジェネリックタイプ」のプロセスです。

ジェネリックタイプのプロセスとは、テスト全体に対しても、テストの一部である個々のテストレベルにも適用できるような「汎用的なプロセス」のことです。

なので例えばプログラムでテストする「コンポーネントテスト」を考えるときも、計画もしますし、何をどうテストするか分析も設計もします。そして実装して実行し、実行結果を確認、整理しますよね。

「いやウチ、アジャイル開発だから」

という話も同じです。

アジャイル開発でも、例えば1週間スプリントとして、そのスプリントでどうテストを組むか(計画)、何をテストするのか(分析)、それらをどうテストするのか(設計)、必要なものを用意(実装)、そして実行、結果を確認して次のスプリントのために整理(完了)などしますよね。

(というか短いスプリントなら余計に何をどうテストするかは考える必要ありそうですよね)

 

では、必ずこのテストプロセスを真っすぐ順守して行うかというとそんなこともなかったりします。

作者は、テスト計画と分析と設計を延々クルクルと繰り返したりして、プロセス通りに進めてないこともあります。

テストプロセスは開発ライフサイクルに合わせて変えていくこともよくあったりはします。

とはいえ、プロセスを知ってて変更するのと、知らずにゴチャゴチャしていたり不足しているのでは話がかなり変わります。

そういったこともあり、マンガ上では「基本の型」「基本を押さえること」といった説明をしてみたりしています。

 

テストプロセスを叩きこみたい人はご自由にお使いくださいw

 

 

最後のシーンの元ネタ

るろうに剣心というマンガより。

ちょっと古いかなーと思いつつ、思いついちゃったので描きましたw

 

 

 

 

 

 

120. テストプロセス その②

120. テストプロセス その②

さて、前回の話に例示を付けただけのような回でしたので今回は特にこれといって説明はなしです。

その昔はノリエさんのようなPMさんとそこそこ出会っていたのですが、最近は出会っていません(笑)

テストというのは、やり方によってどこまでも非効率になります。

何をテストするのかを決めず実行段階になってから「何をテストすればいいんだっけ?」とあたふたして、どのようにそれをテストするか決めず人海戦術で手あたり次第に触ってみる。UnitTestでテストした方がいい機能を見つけたけど伝えるには遅すぎる。誰がどこをテストするか決めていなかった結果みんな同じ機能を見ているし、人気がない機能はちょっと触って終わり。ひどいときは見ていない。

結果、本番障害……。

冗談のように聞こえます。

作者はこういった現場も見たことがあります。

逆に、何に対してどのようにテストをしていくか、そういったことを決めていると本当に本当に進めやすいです。

 

次回からきっとテストプロセス自体の話に入っていくはずです、きっと!

今回は「テスト完了」の話がこれだと入れられないと思っていたのですが、話を進めながら入れていきます。

 

 

 

 

119. テストプロセス その①

119. テストプロセス その①

テストは「テスト実行」が全てではない

テストについてあまり知らない人は、テストの実行する部分だけしか活動が見えておらず、それが全てだと思っていたりします。

そして、アプリをなんかいっぱい動かして「ちゃんと動くね!」とやればOKだと思っていることさえあります。

しかしこれでは、非効率な上に抜け漏れだらけのテストになってしまうのです。

限られた時間の中で確認すべきことをしっかりと確認するためには、テスト実行の前に、何を、どの段階で、どのようにテストすればいいのかを計画、分析、設計しておく必要があるわけです。

またテストが終わった後も次のテストのために整理をしておく必要もあったりします。

こういった一連のテスト活動を「テストプロセス」と呼びます。

今回からはこのテストプロセスの説明をしていきます。

 

テストプロセスについてはJSTQBにあわせて説明する予定です。

 

 

昔作者はこのシチュエーションはよくあったけれど

その昔はプロジェクトの最後に突然つっこまれて「ちょっとテストして!」ということがよくありました。

テスト=リリース前に仕様通り動くか軽く触って確認する活動、みたいな雰囲気の時代です。

ここ数年は、業界全体のリテラシーが上がったのか、はたまた作者の運がいいのか、そいうことにはならなくなっていますw

 

 

管轄外への本店移転のオンライン申請の方法【一人社長】

※この記事は2022/1/22に最終編集された記事です

※この記事は「合同会社」の「管轄外」への本店移転のオンライン申請を扱っています。

 

私が経営する合同会社の本店を管轄外に移転することとなりました。

といってもひとり社長で、今まで自分の部屋を本店にしていて、引っ越しに伴い場所が変更になったというものです。

法務局への申請を、申請用総合ソフトを使ってオンライン申請を行いましたのでそのやり方を記載しておこうと思います。

 

  •  
  • 本店移転の際に行う手続きは何があるか
  • 法務局へのオンライン申請する前の準備
    • 会社の電子証明書
    • 登記ねっとのアカウント
    • 申請用総合ソフトのダウンロード
  • 法務局への申請の際の添付書類(同意書、決定書)の作成
  • 合同会社本店移転登記申請の概要説明
  • ログイン~移転前用の申請書作成までの説明
    • 1.ログイン
    • 2.「申請書の作成を行う」をクリック
    • 3.商業登記申請書→登記申請書→登記申請書(会社用)を選択
    • 4.「件名」「納付情報」「登記申請書」部分の記載
    • 5.会社情報の自動入力
    • 6.「登記の事由」「登記すべき事項」の記載
    • 7.登録免許税額、納付方法、添付書類の記載
    • 8.申請年月日、申請人の記載
    • 9.経由の有無の記載
    • 10.上部にある「チェック」をクリックしてチェック、そして「完了」
  • 移転前の申請書に添付する書類の署名とファイル添付
    • 1.ファイルへの電子署名
    • 2.移転前の申請書にファイル添付
  • 移転後の申請書の作成
    • 1.「申請書の作成を行う」→商業登記申請書→登記申請書→登記申請書(会社用)を選択
    • 2.「件名」「納付情報」「登記申請書」部分の記載
    • 3.会社情報の入力
    • 4.「登記の事由」「登記すべき事項」の記載
    • 5.登録免許税額、納付方法、添付書類の記載
    • 6.印鑑届出の有無
    • 7.申請年月日、申請人の記載
    • 8.経由の有無の記載
    • 9.上部にある「チェック」をクリックしてチェック、そして「完了」
  • 申請書の電子署名
  • 「連件」で申請書を送信
  • 電子納付する
  • 印鑑(改印)届書の作成と郵送
  • 他の申請について

 

本店移転の際に行う手続きは何があるか

この記事では法務局への本店移転のオンライン申請について記載しますが、全体でどういった手続きがあるか列挙しておきます。

法務局だけで終わりではないんですよ。。。

 

  • 法務局
    • 合同会社本店移転登記申請書 ←この記事で説明する場所
      • 移転前と移転後(移転前の法務局で「連件」という同時申請を行う)
        • 各3万円で計6万円かかる
    • 印鑑届(管轄外の移転の場合必ず必要となります)
    • 合同会社変更登記申請(代表社員の住所も変わった場合)
  • 税務署
    • 異動届出書
    • 給与支払事務所等の開設・移転・廃止届出書
  • 都道府県税事務所
    • 異動届出書
      • 移転前と移転後のそれぞれの都道府県税事務所に提出
  • 市区町村役場(東京23区以外の場合)
    • 異動届出書
  • 年金事務所
    • 健康保険・厚生年金保険適用事業所名称/所在地変更(訂正)届
  • 労働基準監督署(労働者を雇っている場合)
    • 労働保険名称・所在地等変更届
  • ハローワーク(労働者を雇っている場合)
  • 郵便局
    • 郵便物の転送
  • 銀行
    • 住所変更

とっても多いですね(^-^;

これらすべてを代行してくれるサービスがあると楽そうですw

(引っ越しでお金がなかったので探してなかったけど><)

続きを読む

2021クリスマススペシャル「探索的テストを投げられたら…」

f:id:m_training:20211225210356p:plain

f:id:m_training:20211225210410p:plain

f:id:m_training:20211225210424p:plain

f:id:m_training:20211225210437p:plain

f:id:m_training:20211225210449p:plain

2021クリスマススペシャル「探索的テストを投げられたら…」

ソフトウェアテストアドベントカレンダー2021の最終日の記事(マンガ)です!

qiita.com

 

「探索的テストのときどういうこと考えながらやってますか?」といった質問を受けて描いてみました。

 

どう考えていくかの方法はたくさんあって、今回はそのうちの一例といったところです。

きゅんちゃんの「私だったらどう使うか?」は、ユーザーの使い方でのアプローチといったところ。

他にも例えば

「こういうところのバグ修正が多かったから……」

とか

「ここの機能とあそこの機能は似てるから同じようなバグがあるのでは……」

など、アプローチ方法はとてもたくさんあります。

この辺は経験を貯めたり、人のブログを読んだり本を読んだりすることによって自分の中のアプローチ方法のネタが増えていったりします。

 

探索的テストの思考の流れ

プロダクトを触ってみて学習して、テスト設計を頭の中でして、テスト実行して、実行結果を分析して次にどうしていくか考え……。

といったサイクルで探索を進めていくのですが、言葉にするとなんかややこしい。

作者はマンガのような「連想ゲーム」が頭の中で回っていることが多い気がしています。

日付がおかしい→

そろそろお正月だから年のまたぎは大丈夫か?→

お正月といったら海外旅行行く人もいるしタイムゾーン変更は大丈夫か?→

タイムゾーンを変えてみて日本時間と海外の時間の差分(すきまの時間)で記録すると?

たぶんこんな感じで考えがつながっていく気がします。

 

時間の管理

テストをするとき、スマホやパソコン側の時間を変えたりすることもあります。

しかしデータの保存時の時間の管理はスマホ側は使わずサーバー側で行っていたりすることも多いです。

けどスマホ側の時間をサーバーに送ってそのまま保存することもあるかもだし、スマホ側から送られた時間とサーバー側の時間を比較して「これはダメ!」みたいに弾くシステムなんかもあったりします。

自分が扱っているプロダクトの時間の管理はどうなっているか把握しておこう。

もしかしたら的外れなテストをしているかもしれません。

 

日付の確認

日付の確認だとみんな「うるう年!」というところに走っていく人が多いけど、まずは日のまたぎ、月のまたぎ、年のまたぎを押さえましょう。

デイリーのバッチでのデータ処理、月締めの処理なんかがあったりするわけです。

 

 

 

 

118.テスターの一日 その⑨

f:id:m_training:20211122063235p:plain

118.テスターの一日 その⑨

「テスターの一日」のお話は今回で終わりです。

作者のテスター時代の流れの話や、テスターとして入社された方に教えていたようなことを散りばめてみました。

背景として、最近新しく作ったテスト組織をマネジメントすることになったことがあります。

そこで、テストの実行速度をあげたいとか、報告のときに何を気をつけたほうがいいかとか、ちょっとした話題もちょこちょこ出たりしたんですね。

そういったtips的なことを描いてもみなさんのお役に立つのかなーなんてことを考えて描いた次第です。

 

次回は箸休め回を挟んで、恒例のアドベントカレンダーでクリスマススペシャルと題して何かを描こうと思っています。

何を描くかは今の段階ではまだ考えていないけど!

 

そろそろ……

マンガも貯まってきたので、テスターちゃん同人誌版8巻を作ろうと思います。

おそらく技術書同人誌博覧会(2022/2月?)にあわせて作ろうかと考えています。

 

続きを読む

117. テスターの一日 その⑧

f:id:m_training:20211109125213p:plain

117. テスターの一日 その⑧

YWT (ふりかえりの方法)

YWT(わいだぶりゅてぃー)は、

  • やったこと
  • わかったこと
  • 次にやること

でふりかえり、次に経験を活かすやり方です。

 

まずは「こういうことあったなぁ」と考えながら、やったことを書き出します。

そしてそれらを思い出しながら「そういえばこんなことわかったっけ」とか「これいい感じだった」とか「こういう風にやればちょっと速かったんじゃない?」といった、わかったことを書き出します。

それらから「じゃあ次はこういうことをしよう!」と出していくわけですね。

経験のふりかえりに良い、といったところです。

続きを読む

第11回「まつ流テストの目的別・探索的テストの戦術」を公開【テスターちゃんねる】

テスターちゃんねる第11回「まつ流テストの目的別・探索的テストの戦術」という動画をアップしました!
システムテストの段階で「こういう場合にはこういう探索的テストをやってるよ」という紹介をする動画となっていますー!
参考になりましたら幸いです!

再生リストはこちらから!

テスターちゃんねる - YouTube

第10回「セッションベースドの探索的テストのやり方」を公開【テスターちゃんねる】

テスターちゃんねる第10回「セッションベースドの探索的テストのやり方」を公開しました!
13分の動画です。今回は1本にまとめました~!
あとBGMもうっすらつけてみてます

www.youtube.com

 

再生リストはこちらから!

テスターちゃんねる - YouTube

116.テスターの一日 その⑦

f:id:m_training:20211018061610p:plain

116.テスターの一日 その⑦

  • 116.テスターの一日 その⑦
    • 案件の情報共有ミーティング
    • そのミーティングで作者がすること
    • 企画側の観点と開発側の観点とテスト側の観点は違う
    • 「たぶん大丈夫だと思います」
    • テスターちゃんができるまで!

案件の情報共有ミーティング

作者は会社では横断的にテストの社内コンサルしたり、テスト計画作成をしたりしています。

その時最初に行うミーティングがコレ。

プロダクトに関わるメンバーで集まります。

プロダクトの概要を聞いて、その後に気になっていることや不安なことを聞きます。

つまりリスクだと思っている部分です。

これ「リスクだと感じている部分は?」と聞くより「気になってること、不安なことありますか?」の方がちょっとしたことまで話が出やすかったりします(体感だけど)

このリスクがプロダクトリスクなら、その部分をテストすることでリスク軽減することができます。

テスト分析(何をテストするか考える)時の良い材料収集の場となるわけです。

 

こういった場があると、プロダクトに関わるメンバーがあらかじめ気をつけたほうがよさそうなところが共有されるため、その部分について「だから言ったのに」なことが減ります。

 

そのミーティングで作者がすること

事前に資料を読み込んでいって、質問を書き出しておきます。

ミーティングの場では内容の共有というより認識合わせの意味合いが強いです。

概要説明時に、対象になるシステムは何か、フローはどうなっているのか、などをさらに聞きます。

そうするとたまに事前に資料を読み込んで想像していた内容と違ったり、関係がありそうなのに話に出てこない部分があったりします。

そういった部分をマンガのような質問をすると(1回ではなく「これどうなってます?」と結構あれこれ質問しますが)見落としていた部分、勘違いが生まれていた部分が出てきたりします。

続きを読む