【ソフトウェアテスト】直交表/ペアワイズ法　①

本記事では直交表について記載します。さまざまな資料を調べて情報をまとめているうちに、直交表、ペアワイズ、HAYST法はそれぞれ直交表を元に関連しているようだと思ったので、直交表から順を追って記載していこうと思います。しかし、それぞれが個別の手法として確立しており、その手法を使用するシーンも違うことから、記事としては独立させたほうが適切かと思ったので、まずは直交表についてまとめたのち、続いて別の記事でペアワイズ法をまとめていきます。

テスト(運用・保守・サポート)

【ソフトウェアテスト】直交表/ペアワイズ法　②

直交表そのものについては直交表/ペアワイズ法　①で記載しています。この記事では主にペアワイズ法についてまとめます。ペアワイズ法は組み合わせテスト技法の一つであり、直交表で考慮した各因子に想定されている水準が均等に分布するという条件を緩和し、各水準の組み合わせが少なくとも1回以上出現するようなペアを選択することで、直交法そのものよりもテストの粒度を粗くしてテストケース数を抑える手法です。

テスト(運用・保守・サポート)

【C# WPF】WPFを理解したいC#初心者の話【アプリ作成編3】

C# WPFについて学んでいく過程を備忘録として残して置きたいと思います。

製造・コーディング(PG/フロントエンド)

ICT支援員への道

近年、学校教育においてICT利活用を推進する動きが広がっています。その最たるものがGIGAスクール構想です。GIGAスクール構想とは、義務教育を受ける児童・生徒に対して1人1台端末と高速大容量の通信ネットワークを一体的に整備し、ICTを活用した創造性や思考力を育成する教育を行い、個別最適化された学びを提供しようとする、教育改革案のことです。新型コロナウイルスの流行もあり、当初の計画よりもスケジュールを前倒しして整備が進められ、令和3年7月末時点で全自治体における96.2％の自治体で端末が整備されている状態です。現状、整備された機器の設置準備や障害発生時の対応、機器を活用した授業の構想・改善は多くの場合教員が行っていますが、昨今はほとんどの教員が残業時間月45時間を超えている事が問題となるなど教員の負担が増しており、教員として勤務しながらICTを活用した教育活動に対する理解を深めていくことは難しい状況であると言えます。そこで、学校内で教員に代わり、学校ICTの専門家として配置が進められているのがICT支援員です。

その他(運用・保守・サポート)

クラウドの運用設計について

システムを安定して運用していくには、「運用設計」と呼ばれるプロセスが欠かせません。運用設計の概要や、必要な項目、作成のポイントなどを説明していきます。システム開発の依頼を受ける企業は、システムを安定的にサービス提供させてこそ、クライアントの満足度が上がります。クラウドの運用設計について話していきますが、実はオンプレミスでもクラウドでも取り決める要件や設計自体には大きな差はないですが、クラウドの利点を活用するために、共同責任モデルと、クラウドネイティブを意識した設計は必要になってきます。

その他(インフラ)

【初心者用】React フックについて

React フックとは、Reactのライブラリの一部として導入された機能で、state などの React の機能をクラスを書かずに使えるようになります。React フックを活用すると、簡潔で読みやすいコードを記述できます。

『基礎知識』 Active Directory

Active Directoryについて

負荷テストとインフラの基礎知識 〜現場で活きる実践的ノウハウ〜

今回は「負荷テスト」について、実務ベースで押さえておきたいポイントをブログ形式でご紹介します。最近ではWebアプリケーションの多様化とともに、アクセス集中や大量データ処理に耐えうるシステム構築が求められています。その中でも、システムの健全性を担保するための“負荷テスト”は非常に重要な工程のひとつです。「負荷テストって聞いたことあるけど、実際どんなことをするの？」「インフラの知識がないとできないの？」という方に向けて、実践に即した情報をまとめてみました。

テスト(インフラ)

【ソフトウェアテスト】欠陥分析手法について

「【ソフトウェアテスト】不具合報告のインシデントレポートについて」記事で記載したとおり、インシデントはチケット作成して報告されたのち、内容を分析して対応をし、作成から完了に至るまで管理します。そうして蓄積されたインシデントレポートは、報告対応されたそのレポート自体が、以降で類似の現象を検出した際の資料として用いられる面もありますが、内容を分析することで、今後の開発品質向上を目指すための判断材料として活用することができます。いずれのインシデントレポートも、何かしら問題があったから作成されているものであり、問題点は解決した時点で完了とはせずに、内容を振り返って同じ轍を踏まないように以降の活動を随時改善していくことが肝要です。近年のアジャイル化が進んでいるプロジェクトなどの場合は、直近の開発内容に対するインシデントレポート単体を都度分析するような時間も設けられずに次々進んでいくことがありますが、プロジェクト全体としてインシデントレポートを統合管理し、アジャイル開発の各プロジェクト進行とは別途で機会を設けて、振り返りと共に不具合分析を行うことは、高品質な開発を目指す上で必要な活動です。ソフトウェア開発現場の現状として、プロジェクト形式もインシデントレポート形式もさまざまある状況なので、欠陥分析の手法もこれが絶対という唯一のものではなく、状況や期間などに合わせて必要な手法でアプローチをすべきです。統計的内容に基づく分析、インシデントごとの要因に基づく分析、その両面からの分析など、どのような面からアプローチするかによって用いる手法もさまざまあります。

テスト(運用・保守・サポート)

【Java】ビルドツールについて学ぼう

Javaで開発を行う際、ビルドツールを利用された経験はありますか。Javaのビルドツールにはいろいろと種類があります。私はMavenとGradleしか知りませんでした。他に存在するビルドツールの種類についてや、メリット・デメリットについて記事作成を通して学んでいこうと考えてます。

【初心者向け】Packet Tracerでネットワークを学ぶ（スイッチング④）

Packet Tracerでネットワークを学びます

詳細設計(内部設計)(インフラ)

【三日目】Java学習

Java学習3日目