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

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



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

※この記事は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回ではなく「これどうなってます?」と結構あれこれ質問しますが)見落としていた部分、勘違いが生まれていた部分が出てきたりします。

続きを読む

115.テスターの一日 その⑥

f:id:m_training:20211004064504p:plain

115.テスターの一日 その⑥

  • 115.テスターの一日 その⑥
    •  
    • 探索的テスト
    • セッションベースドの探索的テスト
    • メンバーの得意不得意によって指示を変える
    • 戦術っぽい話を思いついたままに書いてみる
    • 「バグ登録はいつやればいいの」問題
    • 「探索的テストで出したバグは再現が…」問題
    • 「探索的テストのログを取りたい」問題
    • 1分でわかるテスターちゃんができるまで!

 

探索的テスト

作者はテスト経験のほとんどがテスト部隊で、探索的テストも基本的にはチームプレイでやることのほうが多かったです。

探索的テストの全体設計をする人がいて、その人の指揮に合わせて進めるという形。

探索的テストをチームプレイで行うときはセッションベースドの探索的テストが管理がしやすく進めやすいです。

デメリットとして、指揮する人がテスト全体の状況が見えていない、状況から次の打ち手を考えられないと明後日の方向に連れていかれます。

無駄な行動をすることになったりするので注意が必要です。

 

セッションベースドの探索的テスト

セッションベースドの探索的テストは時間で区切られたセッション、そのセッションでのミッション(目的)を設定して行う探索的テストです。

1回のセッションが終わったらデブリーフィング――終了後の相談を行って、次のセッションでの方針を決めます。

なので「学習→設計→実行→FBから次の行動を決める」という探索的テストの行動にさらに大きな枠「1回のセッションの実行→FBから次のセッションの方針を決める」のサイクルがあるわけです。

 

作者は1回のセッション時間は40分で設定していました。

よく理由を聞かれますが、web/appの現場の経験上です。

30分だと短いのですよ。やりたいことができずに終わったりします。

1時間だと飽きちゃうメンバー、同じことを繰り返しているメンバーが増えてきます。

その辺を見ながら調整をしていったら40分に落ち着いたといったところです。

 

この時間も、探索する規模によっては短くしたり長くしたり調整は入ります。

 

メンバーの得意不得意によって指示を変える

これは通常のマネジメントでも同じですね。

続きを読む

114.テスターの一日 その⑤

f:id:m_training:20210927064142p:plain

114.テスターの一日 その⑤

こんにちは。作者です。

お昼休み、ということで箸休め回になりました(笑)

ちなみにテスターちゃんの世界ではパンデミックは発生していません!

 

作者もお昼は外食派でした。

最初の頃は色んな所に行くのですが、だんだん行く場所が固定化してくるんですよねー。

作者はというと、もっぱら会社の近くの中華料理屋で担々麺を食べてましたw

 

今は在宅業務なので、昼は普通に家で自炊です。

自炊にしてわかったことは昼食代が全然かからないこと!

都心で昼ご飯に行くと一食1000円~1200円とかそんなところ。

なかなかな金額。

それが自炊だと恐らく使っても500円ほど。

この差は大きい……!

 

テスターちゃんができるまで

テスターちゃんができるまでの動画を1分でw

タイムラプスという機能を使って録画してみました。

www.youtube.com

113.テスターの一日 その④

f:id:m_training:20210920212918p:plain

113.テスターの一日 その④

バグ登録時のフロー

バグを登録するときの流れは組織によってまちまちだと思います。

ここで紹介するのはきゅんちゃんたちのチームはということで。

 

テストリーダーに全部の情報が集まる形です。

不正(アノマリー/期待と異なる結果)があった場合はチャットでリーダーに報告します。

口頭で済ましてしまうと他のメンバーに情報が伝わらなかったりします。

そうなると重複した報告が出てきてしまいます。

そしてリーダー側で、情報が不足してないかの確認(他の端末は見た?など)や、報告された情報が重複されてないかや、勘違い(偽陽性)などではないかの判断を行います。

で、わかった情報からバグ修正の優先度をつけて登録指示です。

メンバーはバグを登録したら、テストケースにバグ票のURLを紐づけて、登録報告です。

新人さんの場合は、登録完了の報告後にリーダーがバグ票のチェックを行ったりします。

 

まとめるとこんな感じです。

  1. チャットでバグ報告
  2. リーダー側でフィルタリング(重複、アノマリー、情報不足の確認)、優先度付け
  3. バグ登録
  4. バグ登録後報告&テストケースとのトレーサビリティ確立(紐づけ)
  5. (リーダー側でバグ票確認)
続きを読む