수동 소득 아이디어 2023
올해는 2022년이며 이제 회사를 디지털화하고 일부 프로세스를 자동화하거나 온라인 사용자를 위해 문을 열기로 결정했습니다. 좋은 아이디어! 그러나 소프트웨어 개발 에이전시로부터 견적을 받고 스스로에게 묻습니다. “품질 보증”이 예산의 2/3를 차지하는 이유는 무엇입니까? 글쎄, 이것이 어떻게 작동하는지, 당신이 지불하는 것이 정확히 왜 그렇게 중요한지 봅시다.
일부 소프트웨어의 버그로 인해 인공위성이 궤도에서 떨어지거나 제3차 세계 대전이 곧 발발할 것이라는 기사를 읽고 과거에 비디오를 본 적이 있을 것입니다. 물론 소프트웨어는 사람에 의해 개발되었고 개발되었기 때문에 영향의 정도가 다양한 모든 종류의 결함이 발생할 수 있습니다. 이러한 영향을 최소화하는 것이 품질 보증 또는 간단히 말해서 소프트웨어 테스팅이 존재하는 이유 중 하나입니다. 회사의 자동화/디지털화를 다루는 모든 기업가는 일반적으로 이것을 알고 있습니다.
문제는 테스트에 다양한 수준과 접근 방식이 있다는 것입니다. 논의를 시작하기 전에 한 가지 알아야 할 사항이 있습니다. 소프트웨어 개발자는 빈 공간에 대한 테스트를 거의 좋아하지 않습니다. 따라서 고객은 능동적으로 전체 프로세스에 참여해야 합니다.
소프트웨어 개발 프로세스
소프트웨어 개발은 일반적으로 개념을 만들고 새로운 소프트웨어 또는 웹 애플리케이션이 제공해야 하는 요구 사항을 정의하는 것으로 시작합니다. 개발 프로세스가 “민첩”한지 또는 기존 폭포수 모델에서 구현되었는지에 관계없이 제품에 대한 요구 사항은 실제 작업이 시작되기 전에 정의되어야 합니다. 최종 개발을 시작하려면 기본적으로 작동하는 제품의 선언된 정의가 필요합니다. 당신이 자동차 세일즈맨에게 가서 자동차를 사고 싶다고 말한다고 상상해보세요. 가능성은 무궁무진합니다. 오토바이, 자동차, 스프린터, 트럭 및 스쿠터에서 Tesla 전기 자동차에 이르기까지 가장 다양한 장비를 갖춘 모든 것입니다. 다음 대화에서는 올바른 모델을 구매할 수 있도록 차량에 대한 희망 사항과 요구 사항을 설명합니다. 우리에게도 마찬가지입니다. 소프트웨어와 웹 애플리케이션은 다양한 방향으로 생각하고 프로그래밍할 수 있습니다.
그리고 그것이 소프트웨어 테스트와 어떤 관련이 있습니까?
음, 품질 보증은 소프트웨어가 고객 요구 사항을 충족하는지 확인하는 프로세스입니다. 기본적으로 클라이언트는 궁극적으로 다양한 수준에서 요구 사항을 정의할 수 있어야 합니다. 예를 들어 웹 애플리케이션이 여러 조건에 따라 서비스 가격을 계산하기를 원한다고 가정해 보십시오. 그런 다음 웹 응용 프로그램이 제대로 작동하도록 하기 위해 가능한 모든 요소와 공식을 작성해야 합니다.
다양한 수준의 소프트웨어 개발 품질 보증 및 테스트
알파 테스트
이미 언급했듯이 여러 수준의 품질 보증이 있습니다. 소프트웨어 또는 그 일부가 준비되는 즉시 안정적인 버전이 제공되고 “알파 테스트”라고 알려진 작업이 시작됩니다. 여기에서 개발자 및/또는 고객 담당자는 소프트웨어를 클릭하고 더미 데이터를 추가하고 문제 또는 충돌을 기록합니다. 이것은 기능/소프트웨어가 실제 최종 사용자에게 표시될 만큼 충분히 안정적이라고 간주될 때까지 반복됩니다.
베타 테스트
소프트웨어 테스트에 대한 이러한 접근 방식은 기능 테스트라는 프로세스의 일부입니다. 전체 애플리케이션 또는 해당 구성 요소는 사용자 행동, 입력 데이터, 센서 판독값 등이 미리 정의된 결과를 제공해야 하는 경우 “블랙 박스”로 취급됩니다. 이러한 정의는 최적화할 비즈니스 프로세스를 기반으로 합니다. 일반적으로 기능 테스트는 “코드 작성”에 직접 관여하지 않는 팀 구성원이 수행합니다(기능 테스트의 일부는 자동화할 수 있음) – 고객 담당자, 전담 QA 팀 등 효율적이려면 추상적인 시나리오(예: 필드 A 또는 B가 비어 있는 경우 양식에 유효성 검사 오류가 표시되어야 함)와 일반적인 비즈니스 흐름(예: 양식을 작성하면 사용자가 생성되고 해당 사용자에게 이메일로 알림이 전송됩니다.
이것은 어디서나 사용할 수 있는 최소 수준의 소프트웨어 테스트입니다. 그리고 솔직히 말해서 프로젝트의 60%에 충분하지만 그러한 응용 프로그램에는 더 많은 유지 관리가 필요합니다.
테스트 시나리오는 이론적으로 애플리케이션과 사용자 상호 작용의 전체 프로세스를 다루어야 합니다. 여기에서 가장 중요한 기준은 재현성입니다. 기본적으로 동일한 입력은 동일한 출력으로 이어져야 합니다. 긍정적인 행동과 부정적인 행동을 모두 테스트해야 합니다. 앞서 언급한 바와 같이 대부분의 애플리케이션(특히 소규모 애플리케이션)에는 공식적으로 작성된 사용 사례나 테스트 시나리오가 없지만, 결국 모든 것을 머릿속에 가지고 있는 사람이 전체 별자리에 있습니다. 따라서 고객은 무모한 추측과 잠재적인 시간 낭비를 피하기 위해 개발 팀과 승인 기준을 공유하는 데 관심을 가져야 합니다.
자동화된 테스트
물론 다양한 수준에서 기능 테스트를 자동화하는 도구가 있습니다. 일반적으로 소프트웨어의 다양한 인터페이스와의 사용자 상호 작용을 시뮬레이션하고 결과가 예상한 것인지 확인합니다. 그러나 제품에 지속적인 개선이 필요하지 않은 경우 좋은 알파 또는 베타 테스트(후자는 곧 출시될 응용 프로그램이 실제 최종 사용자에 의해 테스트됨을 의미)이면 충분한 경우가 많습니다. 그러나 이렇게 하려면 개발 팀이 특히 각 릴리스 후에 실행 중인 소프트웨어를 능동적으로 모니터링하는 데 약간의 시간을 할애해야 합니다. 우리(및 대부분의 개발자)는 소프트웨어가 예기치 않은 작업(예: 충돌 또는 데이터베이스 오류 발생)을 수행할 때 알림을 설정하여 대부분의 문제를 격리하고 상당히 신속하게 해결할 수 있습니다.
단위 테스트
물론 수동이든 자동이든 기능 테스트는 중요합니다. 그러나 실제 구현(“코드 작성”)을 담당하는 개발팀 외부에서는 달성할 수 없는 코드 품질 및 안정성에 대한 품질 보증이 있습니다. 여기에서 단위 테스트가 시작되어 개별 코드 블록 또는 전체 모듈이 예상대로 작동하는지 확인합니다. 여기서 아이디어는 모든 중요하지 않은 기능이나 절차에 바로 그 목표를 달성하는 프로그램 테스트가 있어야 한다는 것입니다. 개발 프로세스 중에 코드가 변경되기 때문에 업데이트 및 개선으로 인해 기능이 중단되지 않는다는 점을 아는 것이 중요합니다(회귀라고 함 – 이전 작업 코드 블록의 버그).
단위 테스트는 종종 비용을 절약하기 위해 최소한으로 유지됩니다. 이미 언급했듯이 테스트 사례 작성을 좋아하는 개발자는 거의 없지만 더 나은 최종 제품을 위한 요구 사항입니다. 모든 상용 최신 프로그래밍 언어에는 프로그래밍 단위 테스트를 더 빠르게 구현할 수 있는 다양한 단위 테스트 프레임워크가 있습니다. 이러한 테스트를 최대한 효율적으로 수행하려면 고객이 정상 및 경계선 사례의 가능한 입력 및 결과 측면에서 비즈니스 논리를 명확하게 정의할 수 있어야 합니다.
코드 “품질”을 결정하는 데 사용되는 메트릭 중 하나는 “코드 적용 범위”로 알려진 것입니다. 여기서 이론적 근거는 작동하는 소프트웨어 모듈에서 코드의 모든 라인/블록이 해당 테스트가 실행되는 동안 실행되는 테스트에 의해 “덮혀야” 한다는 것입니다. 코드 적용 범위는 사용된 프로그래밍 언어/프레임워크에 따라 달라지는 외부 특수 도구를 사용하여 평가됩니다. 일반적으로 100% 코드 적용 범위를 달성하는 것은 불가능하며 자동으로 테스트할 수 없는 시나리오가 있으므로 KPI로 사용해서는 안 됩니다. 그러나 각 테스트 실행 사이에 코드 적용 범위가 크게 변경되면 문제가 있다는 신호입니다.
제품 개발 자체의 일부로 단위 테스트를 적극적으로 사용하는 소프트웨어 개발 패러다임도 있습니다. 소위 “테스트 기반 개발”에서 단위 테스트는 기본적으로 실제 코드 전에 작성되어야 하며 다른 수준의 작업 정의 역할을 해야 합니다. 그러나 이 개념을 순수한 형태로 사용하는 팀은 거의 없으며 새 코드가 추가될 때 테스트 사례를 업데이트하는 보다 실용적인 접근 방식을 선호합니다.
단위 테스트 위의 한 단계는 통합 테스트의 개념입니다. 소프트웨어 제품이 여러 모듈로 구성되어 있고 여러 개발 팀이 관여할 수 있는 경우(또는 외부 소프트웨어 라이브러리 및/또는 서비스를 사용하는 경우가 더 많음) 이 별자리에서 무언가가 변경될 때마다 함께 작동하는지 확인해야 합니다. 여기에 “블랙 박스” 간의 상호 작용에 관한 자동 테스트를 추가해야 하며 가능한 한 자주 수행해야 합니다.
지속적인 통합 시스템
일반적으로 “지속적인 통합 시스템”이라는 도구를 사용하여 이를 자동화합니다. 코드 리포지토리가 업데이트되면 지속적 통합 도구는 현재 코드 기반에서 소프트웨어 빌드를 생성하고 모든 종속성을 설치하고 테스트 환경을 준비하고 장치 및 시스템 수준 모두에서 모든 자동화된 테스트 및 검사를 수행하고 결과적으로 테스트를 빌드합니다. 개발자를 위한 보고서. 일반적으로 여기에는 “코드 적용 범위” 측정 및 코드 스타일 문제 찾기도 포함됩니다. 때때로 이 도구는 내부 개발 및 데모에 사용되는 웹 애플리케이션 인스턴스도 업데이트합니다. 그러나 핵심 아이디어는 릴리스된 모든 코드 변경이 전체 프로세스를 트리거하여 잠재적인 문제가 가능한 한 빨리 수정되도록 해야 한다는 것입니다.
스트레스/침투 테스트
더 큰 애플리케이션의 경우 정상적인 비즈니스 운영 중에 예상대로 작동하는지 확인할 뿐만 아니라 불가항력 상황에서 안정성을 보장하기 위해 스트레스/침투 테스트도 수행됩니다. 일반적으로 이것은 웹 애플리케이션에 대해 수행되며 극단적인 상황을 시뮬레이션하기 위해 다양한 도구가 사용됩니다: 높은 사용자 활동, DDoS 공격 시도, 애플리케이션을 종료하기 위해 새로운 익스플로잇을 사용하는 해커/스크립트 키디 등. 이러한 상황을 모방하려면 많은 것이 필요합니다. 노력과 지식: 이를 담당하는 특별한 전문가가 있습니다. 그러나 개발 팀이 웹 응용 프로그램 서버를 정기적으로 업데이트하는 경우(외부 종속성 측면에서) 99.999%의 시간 동안 안전해야 합니다.
고객으로서 소프트웨어 테스팅과 관련하여 무엇을 더 잘할 수 있습니까?
1. 소프트웨어 테스팅에 투자하는 것을 두려워하지 마십시오. 그러면 웹 애플리케이션의 품질도 향상됩니다.
2. 가능한 한 많은 테스트 사례를 제공하여 개발자를 지원합니다.
