テストのエビデンスはどう残すべきなのか
こんばんは。ラオです。
今回は少し前に体験したことを話そうと思います。
先日、閉鎖環境での製品の納品を行うにしたがい検証をしたのですが
それに伴い納品時の検証リストの提出もお客さんの要望により
行うことになりました。
検証リスト自体は極稀にですが提出することもあったので
ここまではいいのですが、納品後に先方からひと言
『ラオさんの会社ではエビデンスを取る習慣はないのでしょうか？』
話を聞いてみると、どうやら検証を行ったエビデンスとして
スクリーンショットを残していなかったことが癪に障ったらしい。
確かにわかりずらいところや特殊な画面では撮ることもあるが
基本的に設定値や入力値はメモし検証リストに記載するだけで
毎回スクリーンショットを撮っているわけではない。
もし毎回撮るようなことをしていたら、検証時間が倍以上になるだろう。
※もちろん部署内での方針としても毎回撮るようなことは行っていない。
なのでお客さんから指摘されたときはとても驚いたのだが
それに伴い他社ではどうしているのか疑問に思いました。
次回はその点をまとめられたらなーと思います。
ブラウザ依存の問題とか
こんばんわ。ラオです。
テストを行う上でよく出会うブラウザ依存問題
ブラウザって基本的にIE、FireFox、Chromeあたりを指すとは思いますが
実際はかなりの数があり、すべてを網羅して担保するのって
なかなか現実的ではないですよね
なので会社によっては***推奨みたいな感じで記載しているとは思います。
今回はブラウザによってはうまくいかないことが多いところをまとめてみました！
表示のズレ
わりと気になるやつ。
動作としては問題ないこともあるけど
たまにブラウザによっては変に見えることが多いですね。
CSS周りの知識があれば簡単に解決できそうではあります。
モーダル
表示のされかたが異なる場合があったり
はたまた動作しなかったりすることがありますね。
ここはブラウザ間もそうですが、同じブラウザのバージョンによって
問題が起きたりする印象があります。
ここはJSあたりの知識があれば解決しますでしょうか？
文字化け
今はほとんどUTF-8に統一されている(はず)なので
あまり確認することも少なくなってきている印象があります。
旧来の運用ルールに影響を受けた「Shift_JIS」や「EUC-JP」といった
日本語の文字コードを利用されている場合など
HTMLファイルの文字コードと、HTML内のmetaタグの文字コード指定を
一致させるように気をつけましょう。
IT業界にも派閥はある
こんばんわは。ラオです。
突然ですが、みなさんはこの食べ物をなんて読んでますか？
地域とか世代によって読み方が異なると思います。
ちなみに私は今川焼きと呼んでいます。
ここまでくれば察するとは思いますが、今回はそんな業界独自の
正解はないけどいろんな読み方や書き方があるよねって話をしようかと思います。
命名規則
関数や変数をつけるときにわかりやすくそれぞれ名前をつけると思うのですが
現時点では主に以下の4つのケースが主流らしい。
- スネークケース
- ローワーキャメルケース
- アッパーキャメルケース
- チェインケース
私はアッパーキャメルケースを使うことが多いですね。
チェインケースなんて使うことある？と思っていたのですが
調べてみるとドメインやURL、ファイル名などに使われることが多いらしい。
ちょっと納得しました。
分岐方法
if分などで分岐を行う際に{}の位置が
if (条件){
}
なのか
if (条件)
{
}
でわかれるよねって話。
私的には大学の時から上の方の書き方だったので
下の書き方を見たときは少しばかり驚きましたｗ
erのつく専門用語
handlerやheaderとか。
基本的にハンドラとかヘッダみたいに短く呼ぶ人のほうが多いイメージ。
実際参考書などにもそのように記載されてることも多いですよね。
ただどうしてもハンドラーとかヘッダーみたいに呼びたくなるやつ。
なんで短く呼ぶことのほうが多いのか誰か詳しく知っている人はいますかね？
製品名
ASUSみたいに短い英単語が続く製品名。
エイスースとかアスース、エイサスなんて多々呼ばれてましたね。
※2012年に正式名所がエイスースになったらしい。。。知らんかった。。。
割と人によって呼び方が異なることが多いので
違う呼び方をされると頭の中に？が出ること多いですよね！
さてさて、いくつかまとめてみましたが結局のところ何が一番言いたいかというと
資料などにまとめるときはせめてどれか1つの呼び方に統一しろってことです。
以上！！！
テストの7原則ってなんだっけ？
こんばんは。ラオです。
実は来年前期に開催されるであろうJSTQBの資格を取ろうと思い
絶賛勉強中なのですが、タイトルの通り7原則を忘れていました。。。
少なくとも4年くらい前に講習を受けて勉強していたはずなのですが
すっかり忘れていました。えぇそれはもうすっかり。
この原則ってなんだっけ？ってレベルではなく
へぇ、こんな原則があるんだ！みたいなレベルです。
ということで、今回は忘れないようちゃんとアウトプットしようと思いました。
- 原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない
- 原則2：全数テストは不可能
- 原則3：早期テストで時間とコストを節約
- 原則4：欠陥の偏在
- 原則5：殺虫剤のパラドックスにご用心
- 原則6：テストは状況次第
原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない
割と原則の言葉通りの意味ですね。
バグが不具合を発見したら欠陥があると示せますが、
逆にバグや不具合がないからといって欠陥がないとは示せません
って話です。
つまりは意図しない動作をするとバグや不具合があるかもしれない
みたいな感じですかね。
原則2：全数テストは不可能
あたりまえ体操！！！
入力する可能性のあるデータと条件の組み合わせを
全パターン確認することは不可能ですよって話
数パターンならまだしも多くなると何千、何万って出てくるので
流石にそこに時間をかけるわけにもいきませんね。
原則3：早期テストで時間とコストを節約
極端に言うと、リリース前とリリース後に不具合を見つけた時の
時間とコストが全然違うよねって話
リリース後に対応するとなると、リリース前にプラスで
コードを思い出す時間が必要だったり、欠陥を特定する必要がありますし
費用もものによっては回収しないといけなかったり
返金作業も入る可能性がありクソ高い損害を受けますよね
原則4：欠陥の偏在
ソフトウェアはいろんな要素から構成されているので
品質は均一されず、特定の部分に集中することが多いよねってこと。
ソフトウェアの欠陥の8割は全体の2割の箇所に集中して存在する
という話もあるらしい。知らんけど。
原則5：殺虫剤のパラドックスにご用心
実はこの単語を見た瞬間にこれ習ったことあるくね？って気づきました。
あまりにも特徴的な原則だったので。。。
で、肝心な原則についてですが
1つのソフトウェアに対して同じテストを何度も繰り返すと
最終的にそのテストでは新しい欠陥は見つからなくなるって内容です。
回帰テストなどでは有効ですが、新機能を作った際は
システムのほかの部分を狙ったテストをしてみるとか
異なったパターンを入力してみるなど視点を変える必要って話。
原則6：テストは状況次第
顧客が利用する状況や目的、ソフトウェアの作り方によって
テストの方法を変えましょうねーってこと。
これもわりと原則通りですね。
原則7：「バグゼロ」の落とし穴
これはわりと性能面に関することが多いかな？
一応仕様通り動きます！不具合ないです！となっても
このページに移動するのにめっちゃ時間がかかります！
みたいな感じになると嫌ですよねｗ
確かに動作はするけど、ストレスがたまるのは勘弁。
今期は何見てる？
2021年夏アニメは始まり、だいたいどのアニメも
3話くらいは進み、今後も見るか見ないか決める時期になりましたね。
私は今期は以下のアニメを見ています！
- 出会って5秒でバトル
- ラブライブ！スーパースター!!
- 転生したらスライムだった件 第2期
- 月が導く異世界道中
- 小林さんちのメイドラゴンS
- SCARET NEXUS
- ひぐらしのなく頃に 卒
- 迷宮ブラックカンパニー
- 乙女ゲームの破滅フラグしかない悪役令嬢に転生してしまった...X
- 探偵はもう、死んでいる
あたりですかね。
ちなみに今期の一番の推しはメイドラゴンです！
今期は全体的にみると代表的な作品がなく、不作判定されがちですが
平均的にみるとなかなか面白い作品が多く、私的にはいいほうでは？
と思っています。
あとカノジョも彼女やぼくたちのリメイク、ピーチボーイリバーサイドあたりも
気になっているのですが、体力がなくなってきて
今はなかなか見る気力が起きないんですよね。。。
界隈が盛り上がってきたり、評判がよくなってきたら
頑張ってみてみようと思います！
本の感想とか
気になってた本を購入し、読み終えたのでその感想でも書こうと思います。
どんな本を読んだか
今回僕が読んだのは「3分間ハッキング サイバー攻撃から身を守る知識」
という本です。
きっかけは本屋に行って技術本で何か面白い本がないかなーと本を漁っていた時に
たまたまこの本が目につき思わず手が伸びましたｗ
本の名前的に某BGMが脳内で再生され、これは面白そうだなと思った次第です。
どんなことを感じたか
名前でつられて買った本ですが、私的にはかなり読みやすい本でした。
技術本みたいに堅苦しいものではなく、どちらかというと小説を読んでいる感じで
ちゃんとストーリーがあり、本の終盤ではいろんな意味でドキドキしていましたｗ
また本書のレベル感としては、基本情報のセキュリティレベルくらいで
そこまで難しい題材を扱っているわけではなく、がっちり学びたいという人より
セキュリティに対しての意識づけをしたい、という人にオススメなのかもしれません。
個人的な意見
正直な話、買った理由がアレだったので正直中身までは
期待していたわけではありませんでした。
ですが、意外と読みやすく、学べることも多くありました。
元からこの手のセキュリティの知識はあり、それを防げれば大丈夫だろう
という認識だったのですが、クラッカーの動向なども載っていて
視野が広くなったように感じました。
話の中でファイルをロックして請求させようとしても払う人が少なくなり
個人情報を盗み売買した方が効率的だという
手口が移り変わりつつある現状を知り、感慨深くなりました。
