Flying Cat Penguin

ゆるゆる仕事関連のことについて綴ります。

TMMiのPA同士のざっくりした関係をまとめてみた

表題の通り、レベルごとのPAとレベルを上げた際のその他のPAの扱い(参照して作成するのか、大きく見直して更新されるか)を示しておきます。

f:id:dandan_611:20190601102841p:plain
TMMiモデル_レベルごとの関係

f:id:dandan_611:20190601102918p:plain
ラクティス同士の関係

参考は下記
www.tmmi.org
www.software-quasol.com

Back to Back Testingについて

Back to Back Testingについて理解するために、下記記事の内容をざっくりGoogle翻訳したものを掲載します。

引用
www.professionalqa.com


ソフトウェア開発は、コンピュータプログラミング、文書化、テスト、および欠陥やバグの修正のプロセスです。これらはすべて、ソフトウェア製品を生み出すアプリケーションやフレームワークの作成と保守に関係しています。 ソフトウェア開発のこれらすべての段階は非常に重要であり、ソフトウェア開発ライフサイクル(SDLC)において重要な役割を果たしています。開発プロセス全体で実行されるソフトウェアテストは、製品の品質を検証し、そのパフォーマンスと有効性を保証します。

しかしながら、プログラム実行に基づくソフトウェアテストはかなりの開発工数を消費するかもしれません。 これに関連して、2つ以上の機能的に同等なバージョンのプログラムを互いにテストすることは、多数のテストケースに対するプログラム応答の正しさをチェックするための潜在的に単純な方法を提供するため、魅力的です。この手法の1つの名前はBack to Back Testingです。これは、新しいソフトウェアや大幅な変更後のソフトウェアのテストに使用される費用対効果の高い方法です。

Back to Back Testingの定義
1998年にSomervilleによって定義されたBack to Back Testingは、テストのためにソフトウェアアプリケーションの複数のバージョンが存在するときに常に使用されます。 ここでは、すべてのバージョンが同様の一連のテストでテストされ、その後、何らかの問題が存在する場合、結果が常にシステム/アプリケーションの問題について比較されます。 Back to Back Testingはソフトウェアテストの一種で、比較テストとも呼ばれます。これは、将来ソフトウェアに不一致が生じた場合に備えて、コンポーネントの2つ以上のバリエーションが常に類似の入力でテストされ、対応する出力が比較および検査される一種のテストです。 したがって、連続したテストでは、ソフトウェア製品の2つの実装バージョンで単一のテストセットが実行され、結果が比較されます。 結果に不一致が生じるたびに、コンポーネントの2つのバージョンのうちの1つがおそらく失敗を証明しています。
さらに、Back to Back Testingは、それに関連するイベントが適切に調べられ定義されるプロセスです。 このテストでは、常に機能同等のソフトウェアコンポーネントから得られる全体の応答を相互比較します。 このテストの間、テストチームによって違いが決定または観察されるたびにそれが測定され、必要に応じてそれも適用されます。

Back to Back Testingの例:
Back to Back Testingの完璧な例は、POSマシン(POSまたはカードスワイプマシン)で使用されているさまざまなバージョンのソフトウェアのテストです。 ここでは、データがバックエンドでどのように操作されるかにかかわらず、応答と出力はすべてのバージョンで同じですが、入力は同じです。 これは連続したテストの機能を完全に反映しており、それが世界中のテスターによって新しいソフトウェアのためだけでなく、それに大きな修正や変更を加えた後のソフトウェアのテストのために使われる費用対効果の高いアプローチであることを検証します。

複数の実装にアクセスする理由
テスターと開発者がソフトウェア開発プロセス中に多数の実装を実行する理由はいくつかあります。 クライアントの要求からソフトウェアの技術的要求まで、さまざまな要因が、ソフトウェアまたはアプリケーションで複数の実装を実行するというテスターの決定に影響を与えます。 これらの理由のいくつかを以下に記載します。

  • 安全性が重要なシステムは、最終結果の正確性を保証するために、重要なモジュールの複数の独立した実装を使用することがあります。
  • 開発者やテスターは、2番目の実装として競合他社の製品、または以前のバージョンを使用する可能性があります。
  • ハードウェア設計者に仕様として役立つ新しいチップのソフトウェアシミュレーションを書くかもしれません。 チップを構築した後、チップハードウェアによって計算された結果をソフトウェアシミュレータによって計算された結果と比較することができる。

Back to Back Testingのプロセス:
Back to Back Testingのプロセスは、主にシステム内のすべての欠陥とエラーを見つけることに専念している経験豊富で知識豊富な専門家のチームによって実行されます。 このテストでは、すべての製品のさまざまな要素が既存の食い違いについてテストされていることを確認します。これらの食い違いは、その後完全で期待される結果を得るために解決されます。 Back to Back Testingのプロセスは、以下に説明する3つの重要な段階で構成されています。

  1. テストケースの準備:これはバックツーバックテストの最初の段階です。ここでは、ソフトウェアまたはアプリケーションでテストを開始するための一連の特定の目的のテストケースが用意されています。
  2. アプリケーションの実行:テストの最初の段階で準備されたテストケースのセットは、さまざまなシステムまたはアプリケーションのバージョンを実行するためにテスターによってここで使用されます。 テストが実行されると、結果は異なるファイルに保存されます。
  3. 比較と報告:これは、異なるファイルに保存されているすべての結果の自動比較が行われるバックツーバックテストの最後の段階です。 さらに、異なるシステムバージョン間に存在する可能性があるシステムまたはアプリケーションの問題を示す差分レポートが作成されます。

Back to Back Testingの利点:
前述のように、Back to Back Testingはソフトウェア製品の2つの実装されたバージョンで実行され、その後それらの結果は既存の矛盾やエラーと比較されます。 したがって、この種のテストはクライアントだけでなくソフトウェアエンジニアにとっても非常に有益です。 徹底的な比較の実行から費用対効果の高いものまで、Back to Back Testingがテストに最適な選択肢です。 その主な利点のいくつかは以下のとおりです。

  • ソフトウェアアプリケーションの2つ以上のバージョンの比較を実行します。
  • ソフトウェアの弱点と長所を簡単に判断できます。
  • 製品版の発売前に修正や確認が必要となる可能性のある製品のすべての重要な機能を知ることができます。
  • Back to Back Testingは、新しいソフトウェアに対する費用対効果の高いテストです。
  • システムまたはアプリケーションに大幅な変更や変更を加えた後でテストを実行できます。
  • 競合製品の設計構造を理解するのに役立ちます。競合製品は、ソフトウェアまたはアプリケーションの将来の改善および機能拡張を行うための信頼できるベンチマークとして使用できます。

結論:
今日の時代では、ソフトウェア業界には、優れた品質と技術的に高度なソフトウェアシステムおよびアプリケーションが豊富にあります。 しかし、この豊富さにより、組織は独自の優れた機能を備えたソフトウェアやアプリケーションの開発を余儀なくされています。 この開発目標を達成するために、世界中の開発者とテスターがさまざまな開発とテストの手法を使用しています。 このようなテスト手法の1つにBack to Back Testingがあります。これにより、テスト担当者はコンポーネントの2つ以上のバリエーションを同じような入力でテストできます。 テストが完了すると、将来ソフトウェアに発生する可能性がある矛盾がある場合に備えて、すべてのバリアントの対応する出力が比較および検査されます。 この適切なテストと比較によって、ソフトウェア内のすべての欠陥を発見し、ソフトウェアシステムとアプリケーションに関する深い知識を得ることができます。

AtCoder 参加日記#1

AtCoderを細々やっていこうかなと思い立って、実装したものの記録を残します。

参加コンテスト

  • diverta 2019 Programming Contest

内容

A OK

# -*- coding: utf-8 -*-
 
# スペース区切りの整数の入力
a, b = map(int, input().split())
 
# 出力
print(a-b+1)

B 時間切れ

# -*- coding: utf-8 -*-
 
# スペース区切りの整数の入力
r, g, b, n = map(int, input().split())
 
# 最大の数をそれぞれ求める
max_x = (int)(n / r)
max_y = (int)(n / g)
max_z = (int)(n / b)
 
# 答えの数
answer_num = 0
 
# 計算
for x in reversed(range(max_x+1)):
    for y in reversed(range(max_y+1)):
        if x*r+y*g > n:
            continue
        for z in range(max_z+1):
            if x*r+y*g+z*b > n:
              continue
            elif x*r+y*g+z*b == n:
                answer_num += 1
            else:
                pass
 
# 出力
print(answer_num)

C 未着手

D 未着手

E 未着手

F 未着手

解説
https://img.atcoder.jp/diverta2019/editorial.pdf

所感

  • for文を単純に回したら時間切れになるので注意する
  • 余分な計算や判定をさせないようにあらかじめ数式を組んでおく
  • スマートじゃなくてごめんなさい…精進します。

とある方の回答を見て手直ししたBの回答

# -*- coding: utf-8 -*-

# スペース区切りの整数の入力
r, g, b, n = map(int, input().split())

# 答えの数
answer_num = 0

# 計算
for x in reversed(range(int(n / r) + 1)):
    for y in reversed(range(int(n - x*r/g) + 1)):
            if ((n - (x*r + y*g))% b) == 0 and (n - (x*r + y*g)) >= 0:
                answer_num += 1

# 出力
print(answer_num)


以上

ASTER-テスト設計コンテストのすゝめ

こんばんわ。
ぎりぎりで書き始めたおーだんです。

この記事はソフトウェアテストアドベントカレンダーの16日目の記事です。

さて、今回は2018年に色々あったASTER-テスト設計コンテストについて書きたいと思います。
ちなみに、私の参加経歴はこんな感じ↓

おーだんのASTER-テスト設計コンテストの参加経歴

  • テスト設計コンテスト'15 ⇒ 参加辞退
  • テスト設計コンテスト'16 ⇒ 関西予選未通過、審査員特別枠 決勝5位
  • テスト設計コンテスト'17 ⇒ 関西/東海予選通過、決勝5位
  • テスト設計コンテスト'18 ⇒ 関西/東海予選未通過、審査員特別枠 決勝優勝

今年は優勝ということもあり、4年間で一旦はチームでのコンテスト活動を終了としています。思えば色々あったなぁ…素材は良いけど、料理方法が最悪って言われたり、猫耳つける呪いの約束をしたり、意気消沈したけど役に立ったとコメントをくれる人がいて、実はちょっと涙ぐんだり などなど。
 このテーマにしたのは一つ理由があります。それは、参加者のポジティブな意見が中々発信されにくいからです。なので改めて「良いよ」ということを伝えるべく…。あとは、「良くない」と思われている部分も少し考えつつ…。あと宣伝。

良いこと

①「よくやる失敗はだいたい経験できること」

  • みんなのやりたいことを全部詰め込んだ目的のよくわからないテストを作る
  • テスト設計技法をあまり使ったことがないので、適当に使う
  • ISO規格をそのまま適用してとりあえず型にはめたテストをやる
  • テスト要求を考えすぎて、テストケース自体がつくれなくなる
  • 優勝者のやり方をパクってみたけど結局わからなくてやめる
  • 「やりました」だけを言う伝わらないプレゼンをする などなど

コンテストで一番良いのは、"きちんと失敗できること"です。普段、会社でやるテストは、そもそも失敗かどうかすらわからないことも多く、失敗なんて口にできないのではないでしょうか。私は、予選や決勝でキツイことを言われましたが、でもそれはやりたいことができていないと感じていたことで、清々しく認めることができます。
 そもそもソフトウェア開発は失敗の連続が当たり前なのですから、テスト開発でもそうなるのは当然です。
大丈夫、最初は失敗するから!そういうもんだって!

②「変なバイアスがなく、テストを考えることができること」
「テストって何のためだっけ?」を根本から見つめ直すことができます。それこそ今までのテストがゲシュタルト崩壊していきます。そして、個人のテストの思考が強く出るため、議論していくとチーム間で必ず衝突が起きます。
 単純な思いのぶつけ合いになる気持ちの良い喧嘩はとても大切です。あと、まともな喧嘩はチームメンバとちょっと仲良くなります。河原で殴り合いの喧嘩をするとちょっと仲良くなる奴です(笑)

③「チームメンバの個性を生かしたテスト設計ができること」
開発するテストの根源は、チームメンバになります。必然的に、開発するテストはチームメンバのスキルに依存します。そのため、スキルをテスト設計でどう生かすかをチームで考えることになります。チームリーダは非常に悩みますが…チームの個性を伸ばすテスト設計を考えることができれば、きっと業務でもそういった柔軟なテスト設計ができるようになるはずです。逆に、スキルがなければ、学ぶことを想定した活動ができます。
 あと、集まったチームメンバの意外と凄いところをたくさん発見できます。集まった人たちはみんな凄いがところあるんですよ。

良くないこと

①「過去の参加者や審査員が否定眼寄りになること」
テストには物事を否定的にみる側面があることは、なんとなく納得できます。ただ、参加者のブログ記事で気になるのは、"否定眼"の文面になっていることです。「あれができてない」「これができてない」といった話だけで終始する記事や審査員のコメントもあり、そういったことを目にすることが多いと新たな参加者となる、コンテスト聴講者はやりたいと思えなくなってしまうのでは... っと気にしています。直接フォローできるなら良いのですが、ブログ記事ではそういったことは難しいでしょう。
 あと、登竜門だなと思っているので、審査員のコメントに慣れるとそうでもないのですが、厳しいコメントは参加者じゃなくて聴講者が結構ヒくらしいです。

②「参加者が複数年続けて参加していないこと」
コンテストに出る場合、参加者は大抵一年ではテストを作り切れません。私も言われましたが、まず「自分だけの開発方法論」を作る必要があります。「自分だけの開発方法論」がない場合、コンテスト参加者は、審査員の「なぜこのようなテストにしたのか」という質問に答えられないため、コンテストに勝つことは難しくなります。また、大抵は自身の所属するテストプロセスか国際規格を利用して作成しますが、これも審査員の「なぜこのようなテストにしたのか」という質問に答えられず、同様の結果なります。
 大事なのは、「なぜ」に答えられることなのですが、大抵の参加者はこれに答えられないケースが多く、まじめな人も多いので、答えられないと「自分は何もわからない、ダメな奴なんじゃなかろうか…」と落ち込んで出なくしまうのではと考えられます。
本当はそんなことないんですけどね。完璧でなくともより良いテストが作れれば良いんです。

③「チーム間で切磋琢磨する機会が少ないこと」
コンテストは、結構な時間を掛けて活動します(私たちのチームは一年で600時間位…)。ただ、チームだけで活動するとなかなかモチベーションは維持しにくいです。私は、有志のコンテスト参加者ということもあり、関西で別チームと交流会をやっていましたが、そういったことも必要なように感じます。
 コンテストがコンペという立ち位置を取るのであれば、どういう風に他のチームが戦ってくるのかを知るのも大事ではないでしょうか。コイツには勝ちたい!…って思う気持ちは大事です。

④「参加者の発信が少ないこと」
参加者は、予選や決勝の後などを含め、「私、こんなテスト設計考えたの!どう?どう?」となかなか言えない気がしています(いや、いないわけじゃないんですが…)。ネット上には重鎮がいるのでとても恐れ多いという感覚を持っている人も多い気がしています。
 部分的でも、優れた面は堂々と発信するのはどうでしょうか。パクられる?いやいや、パクられたらいいじゃないですか。オリジナルがいつだって先を行っているんです。じゃんじゃん出しちゃいましょう。
できてなくても出したチーム(てすにゃん)もあるくらいですから(笑)

良くないことを変えるために…

まず、「自分だけのテストを極める、開発する」という意識を持ちましょう。
そして、すぐには完成しないと覚悟しましょう。
少なくとも三年はやるつもりで!
何言われても気にしないで、とりあえずコンテストにだしちゃいましょう!
コンテストじゃなくても、とりあえず誰かに出してみましょう。
きっと誰かがコメントをくれます。
でも、そのコメントは全部受けなくてもよいのです。
いいと思ったことを取り入れて「自分のテスト」を育てていきましょう!

結論
コンテストの参加は、参加者の想いがとっても大事です。
参加する方は、テスト設計コンテストをうまく活かして、
自分のテストスキルの成長につなげていきましょう!
コンテスト審査員なんて審査の数が多くなって困らしたらいいんですよ。
私、U30の審査員になりましたが、その方がきっといいんです!!
じゃんじゃん出しちゃいましょう。

あと…参加開始の案内もう少しだから!

テスコンに参加したいけどよくわからないとかあれば相談乗るので声かけてね!

参考文献
ASTER-テスト設計コンテスト'19-過去のテスト設計コンテスト
http://jasst.jp/symposium/jasst16kansai/pdf/S4-1.pdf
てすにゃんblog – アジャイルテストについて書くにゃん
http://www.jasst.jp/symposium/jasst18kansai/details.html#S3B-3

www.slideshare.net
www.slideshare.net

他のチームの方の記事
テスト設計コンテストって何? | TEF-DO
テストカタマリーを活用したテスト設計プロセス案(まとめページ) | どしろうと製作所:WebLog

地味にまだまだ更新するかも…

テスト開発環境を構築する(ちょっと改良) #2

こんにちは、おーだんです。

不精なので上げずにそのままにしてしまっていました。

一応、粛々と進めているので話だけ…

今、開発環境構築ツールを作成しています。

ツールの名前も変えて少しカスタマイズしてみました。

一応、前回の反省点も踏まえ、gitlabは自動的に入るようにしています。

まだ、prodev環境とdeploy環境は作り途中ですが、
これで大筋の環境は下記のコマンド一発でできるはずです…。

$ cd ..
$ cd env_devmng
$ mkdir data/
$ vagrant up
$ ssh vagrant@192.168.10.100

github.com

基本の処理構造はこんな感じ

f:id:dandan_611:20181110105534p:plain

あとは、この環境に対して、実際に作るプロダクトとテストをCIのコードとで紐づけるパイプラインコードを書けば何とか…。

次回以降は、すでに用意している現段階のプロダクトとテストのコードを解説していきます。

目指せ…毎日更新。

テスト開発環境を構築する(Gitlab立てるまで) #1

こんばんわ。

おーだんです。

夏はC94にでてました。

 

ただ、下記のタイトルで同人誌を出そうと思ったのですが、

なかなか時間とモチベーションが取れず落としてしまいました…。

次回は、10月08日の技術書典5に参加予定です。

ということで、現在はつらつらとそれに向けての下準備中。

 

題名:

テスト開発者のための

  TDDして、

   CI回して、

    E2Eのテスト自動実行して、

        なんやかんやする テスト開発環境構築」です。

 

実は、テスト開発をしようとしたとき、最近は開発環境に目を向けることが多いです。

なぜ、そう思うのかというと…それは、実際に利用している環境で、プロダクト開発者とテスト開発者の認識が合わないことがあるからです。

合わせなくてもよいということもあるのですが、個人的には認識が合わないことによるデメリットが強くあるように感じています。

例えば、作られているプロダクトの情報が遅く伝わることや、プロダクトの構成要素に対する理解不足が挙げられます。

私は、こういったデメリットが発生してしまうと、テスト開発に強く影響すると考えています。(少なくとも、デメリットが発生しなければ、テストを作る前にプロダクト開発者へ情報提供できたり、より重要なバグの指摘に専念できる可能性があります。)

なぜ、そういったデメリットがあるのか?

それは、開発で利用される環境の差なのではないかと思います。

開発で利用される環境を明確に定義し、維持・改善していくことで、より意識を合わせ、より素早いプロダクト開発やテスト開発につながるのではないでしょうか?

 

加えて、私が主に該当しますが、基本的にテスト開発者はコードに弱いと思います。

確かにコードに強くなくてもテスト開発はできると思うのですが、それでもテストを開発するには全て手動でやらなければならないわけではありません。

時にはテストに特化した便利なツールを利用したり、開発する必要も出てきます。

そうした時に、テスト開発者もサクッと利用したり、作れるような準備が必要ではないかと、日々感じていますし、焦りも感じています。

 

ということで、そういった理由からテスト環境構築からテストツール開発と対応するテスト開発までの一連の流れをまとめていきたいと思います。(頑張って2年くらいでまとめたい…多分3年)

 

やりたいことは2つ

  • テストツールを開発すること
  • テスト開発環境を構築すること

現在はツールはちょっと置いておいて、下記の環境を構築することを目指します。

 

f:id:dandan_611:20180816182408p:plain

使う人のイメージはこんな感じ。

最終的に全部一人でやるんですがイメージとしてはこんな感じ。

f:id:dandan_611:20180816183304p:plain

ひとまず簡単なものを実装。 

     f:id:dandan_611:20180816193544p:plain

コードは下記で公開中。(まだまだ絶賛開発途中)

github.com 

 

ひとまず、現在のタスクとしては下記を想定。

f:id:dandan_611:20180816183135p:plain

 

 

詳細の手順やツールの解説はもうちょっと待ってください(汗)

途中までは下記に…。

 

所要時間:90分くらい:多分ほとんどプロビジョンの時間

■初期環境をインストールする(Cygwin,vagrant,Virtualbox,git)

  上記のReadmeに記載されている ツールをインストールしてください


Githubから開発環境構築コードを取得する

$ git clone https://github.com/dandan611/D-environment.git


■開発環境(env_prodev)を作成する

 ひとまず、python3.6が入っている環境

$ cd D-environment/env_prodev
$ mkdir data/
$ vagrant up
$ ssh vagrant@192.168.10.10

  ※メモリが不足しそうな場合は、’vagrant halt’で停止してください。


■開発環境(env_devmng)を作成する

$ cd ..
$ cd env_devmng $ mkdir data/ $ vagrant up $ ssh vagrant@192.168.10.100

  下記にアクセスする。

  http://localhost:10080/

  ※アクセスできなかったら下記のコマンドを実行して、Gitlabのコンテナを取得し起動する。

$ sudo docker run --name gitlab-postgresql -d --env 'DB_NAME=gitlabhq_production' --env 'DB_USER=gitlab' --env 'DB_PASS=password' --env 'DB_EXTENSION=pg_trgm' --volume /srv/docker/gitlab/postgresql:/var/lib/postgresql sameersbn/postgresql:10
$ sudo docker run --name gitlab-redis -d --volume /srv/docker/gitlab/redis:/var/lib/redis sameersbn/redis:4.0.9-1
$ sudo docker run --name gitlab -d --link gitlab-postgresql:postgresql --link gitlab-redis:redisio --publish 10022:22 --publish 10080:80 --env 'GITLAB_PORT=10080' --env 'GITLAB_SSH_PORT=10022' --env 'GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alpha-numeric-string' --env 'GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alpha-numeric-string' --env 'GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alpha-numeric-string' --volume /srv/docker/gitlab/gitlab:/home/git/data sameersbn/gitlab:11.1.4

 

  下記にrootのアカウントでログインする。(初期パスは5iveL!fe)

  
■Gitlabでグループ、アカウントを作成する

  スパナマークをクリックして、グループとアカウントを作成する

    Group:Test

          User:<個人の名前とメールアドレス>

  作成したアカウントの初期パスワードを設定する


■Gitlabでgitのssh設定を行う

       個人のアカウントでログインする

  Settings->SSH keysの項目をクリックする

  開発環境で、ssh keyを作成する

$ ssh-keygen -C "<登録したメールアドレス>" -t rsa
$ cat ~/.ssh/id_rsa.pub

        表示したssh keyを貼り付けて登録する


■Gitlabでサンプルプロジェクトを作成する

    Project:Test

 

以上です。(次は、gitlabでCIジョブの作成からシステムテスト成功まで)

f:id:dandan_611:20180816191112p:plain

 

 

参考

github.com

 

qiita.com

 

湯るセキュ Micro Hardening in 草津温泉に行ってきました。

おはこんばんちは、おーだんです。

タイトルにありますが、ちょっと普段と違うイベントに参加してみました。

友人にセキュリティ専門の人がいるので誘われて、参加へ…。

connpass.com

 

そもそも、Hardeningってなんだ?という感じだったのですが、

用語としてはこんな感じ。

 

【Hardening】

コンピューティングにおいて、ハードニング とは、脆弱性を減らすことでシステムのセキュリティ堅牢にすること。システムは多面的な脆弱性を抱えており、原理的には、単一の機能しか持たないシステムは、複数の機能を持ったシステムよりも堅牢である。必要のないソフトウェアの削除、不要なユーザアカウントやデーモンを停止などで、攻撃可能な側面を減らすことができる。

ハードニング - Wikipedia

 

競技としても存在しているようです。

テストのように、じっくりとテストと調査をやったりするのとは違い、

即時に原因を分析して、システムを復帰させたりするものみたいです。

 

今回は、主催の川口氏らが作られたMicro Hardeningに参加しました。

内容としては、ECサイトをいかにダウンさせずに売り上げを増やせるかというのを45分を1セットの3セットを実施しました。

 

成績は以下。

【自チームの成績】

  一回目:35000点

  二回目:17000点

  三回目:67000点

 

【自チームの三回目の成績の推移】

f:id:dandan_611:20180401151129p:plain

 

【チームでやってみたこと】 

 

【参考になったこと】 

  • 開始後にすぐバックアップを取って、売上が止まったらすぐ戻す(攻撃が一回であればかなり有効)
  • 異常事態になったら取ったバックアップの差分を見ておく

 

ゲーム感覚を目指して作成されたこともあり、参加できて楽しかったです。

あっという間に時間が過ぎていきました…。

最高チームは12万点台でした。中々実力差をまじまじと見せつけられるのは悔しいです。

そして、バグ出しだけのコンテストよりも、やはりシステムを復帰させるというのが味噌で、できなかったりすると結構悔しいです。

ただ、点数のつけ方が明確で、チームとして取り組んで、点数が上がるのはかなりうれしかったです。

(今回は全然貢献できませんでしたが…💦)

終わった後の対応がどうだったかなどを他の方とお話していましたが、

そういえばそうだ!、なんで気づかなかったんだろう?というようなこともあり、

色々気づきが得られました。

 

そして、セキュリティの方々は、システムやそれにつながる人へのサイバー攻撃と戦う大変価値ある技術的な分野を支えている方々なんだなと実感しました。 

 

もし、普段テストをしていて、Hardningをやられていない方は、

やられてみると案外楽しいかもしれませんよ。

 

これからも続けて参加してもいいかも。

もし、一緒にやりたいという方がいたら声かけてください!

 

以上です。

 

【参考資料】

speakerdeck.com

 

wasforum.jp