Software Testing - SWT301

Việc kiểm tra phần mềm trước khi phát hành là một phần quan trọng của quy trình phát triển phần mềm. Mục đích chính của việc kiểm tra phần mềm trước khi phát hành là để quyết định khi nào phần mềm đã đạt được chất lượng đủ để phát hành. Điều này có nghĩa là các nhà phát triển và kiểm tra viên sẽ kiểm tra phần mềm để đảm bảo rằng nó hoạt động đúng, không có lỗi và đáp ứng các yêu cầu của khách hàng. Việc kiểm tra phần mềm trước khi phát hành giúp giảm thiểu rủi ro phát hành phần mềm không ổn định hoặc không đáp ứng được yêu cầu của khách hàng. Ngoài ra, việc kiểm tra phần mềm trước khi phát hành cũng giúp tiết kiệm thời gian và tiền bạc trong dài hạn bằng cách phát hiện và sửa lỗi sớm.

Khái niệm preventative và reactive trong testing liên quan đến thời điểm và mục đích của các bài kiểm tra. Preventative testing là quá trình kiểm tra được thực hiện trước khi sản phẩm hoặc phần mềm được phát hành, nhằm phát hiện và sửa lỗi ngay từ đầu. Điều này giúp giảm thiểu rủi ro và đảm bảo chất lượng sản phẩm. Ngược lại, reactive testing là quá trình kiểm tra được thực hiện sau khi sản phẩm hoặc phần mềm đã được phát hành, nhằm phát hiện và sửa lỗi đã tồn tại. Preventative testing thường được thiết kế sớm hơn reactive testing, vì nó giúp ngăn chặn các vấn đề tiềm ẩn và đảm bảo chất lượng sản phẩm ngay từ đầu. Trong khi đó, reactive testing thường được thiết kế sau khi sản phẩm hoặc phần mềm đã được phát hành, nhằm đáp ứng các yêu cầu và phản hồi từ khách hàng.

Khi đánh giá sự khác biệt giữa việc kiểm tra phần mềm được phát triển bởi một nhà thầu bên ngoài quốc gia của bạn và phần mềm được phát triển bởi một nhà thầu bên trong quốc gia của bạn, cần xem xét nhiều yếu tố. Thứ nhất, sự khác biệt về văn hóa có thể là một yếu tố quan trọng. Các nhà thầu bên ngoài quốc gia của bạn có thể có nền tảng văn hóa, ngôn ngữ và quy trình làm việc khác biệt so với các nhà thầu bên trong quốc gia của bạn. Điều này có thể ảnh hưởng đến cách họ tiếp cận và giải quyết các vấn đề, cũng như cách họ tương tác với bạn và các thành viên khác trong dự án. Ví dụ, các nhà thầu bên ngoài có thể có cách tiếp cận linh hoạt hơn, nhưng cũng có thể gặp khó khăn trong việc hiểu và thích nghi với quy trình và quy định của quốc gia bạn. Ngược lại, các nhà thầu bên trong có thể có kiến thức sâu sắc hơn về văn hóa và quy trình của quốc gia bạn, nhưng cũng có thể bị hạn chế bởi các quy định và quy trình hiện có. Thứ hai, sự khác biệt về kiểm soát và quản lý cũng là một yếu tố quan trọng. Khi làm việc với các nhà thầu bên ngoài, bạn có thể gặp khó khăn trong việc kiểm soát và quản lý dự án, đặc biệt là khi họ không có kinh nghiệm làm việc với quốc gia của bạn. Ngược lại, khi làm việc với các nhà thầu bên trong, bạn có thể có nhiều quyền kiểm soát hơn và quản lý dự án dễ dàng hơn. Tuy nhiên, điều này cũng có thể dẫn đến sự phụ thuộc quá mức vào các nhà thầu bên trong và giảm khả năng linh hoạt của dự án. Cuối cùng, sự khác biệt về chi phí và thời gian cũng là một yếu tố quan trọng. Các nhà thầu bên ngoài có thể cung cấp giá cả cạnh tranh hơn, nhưng cũng có thể mất nhiều thời gian hơn để hoàn thành dự án. Ngược lại, các nhà thầu bên trong có thể mất nhiều thời gian hơn để hoàn thành dự án, nhưng cũng có thể cung cấp giá cả cạnh tranh hơn. Tóm lại, sự khác biệt giữa việc kiểm tra phần mềm được phát triển bởi một nhà thầu bên ngoài quốc gia của bạn và phần mềm được phát triển bởi một nhà thầu bên trong quốc gia của bạn phụ thuộc vào nhiều yếu tố, bao gồm sự khác biệt về văn hóa, kiểm soát và quản lý, cũng như chi phí và thời gian.

Khi đánh giá một sản phẩm phần mềm, mục tiêu chính là xác định các lỗi hoặc sai sót trong sản phẩm đó. Điều này bao gồm việc kiểm tra các sản phẩm phần mềm như yêu cầu, thiết kế, mã nguồn, tài liệu và các sản phẩm khác. Mục tiêu này là nhằm đảm bảo rằng sản phẩm phần mềm đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra. Trong quá trình đánh giá, người đánh giá sẽ sử dụng các kỹ thuật và công cụ khác nhau để xác định các lỗi hoặc sai sót trong sản phẩm phần mềm. Điều này có thể bao gồm việc kiểm tra mã nguồn, chạy thử nghiệm, kiểm tra lỗi và các kỹ thuật khác. Mục tiêu chính là đảm bảo rằng sản phẩm phần mềm là chất lượng cao và đáp ứng được các yêu cầu của khách hàng.

Khi thiết kế thử nghiệm sớm trong vòng đời, lợi ích chính là ngăn chặn các lỗi được đưa vào mã nguồn. Điều này đạt được bằng cách xác định và sửa lỗi ngay từ đầu, trước khi mã nguồn trở nên phức tạp hơn. Thiết kế thử nghiệm sớm giúp phát hiện và sửa lỗi ngay từ đầu, giảm thiểu số lượng lỗi cần sửa trong giai đoạn sau. Ngoài ra, thiết kế thử nghiệm sớm cũng giúp cải thiện chất lượng mã nguồn, giảm thiểu thời gian và chi phí cần thiết để sửa lỗi. Điều này giúp tiết kiệm thời gian và chi phí trong giai đoạn thử nghiệm sau này. Thiết kế thử nghiệm sớm cũng giúp tăng cường sự tin tưởng của khách hàng vào sản phẩm, vì sản phẩm đã được kiểm tra kỹ lưỡng và đảm bảo chất lượng.

Mức độ rủi ro của một sự kiện bất lợi được xác định bởi hai yếu tố chính: khả năng xảy ra sự kiện (likelihood) và tác động của sự kiện (impact). Khả năng xảy ra sự kiện đề cập đến xác suất xảy ra sự kiện, trong khi tác động của sự kiện đề cập đến mức độ ảnh hưởng của sự kiện nếu nó xảy ra. Ví dụ, một sự kiện có khả năng xảy ra cao nhưng tác động thấp có thể không được coi là rủi ro cao. Ngược lại, một sự kiện có khả năng xảy ra thấp nhưng tác động cao có thể được coi là rủi ro cao. Do đó, mức độ rủi ro của một sự kiện được xác định bởi sự kết hợp của hai yếu tố này.

Impact analysis là một kỹ thuật được sử dụng trong kiểm thử phần mềm để đánh giá tác động của một thay đổi hoặc một lỗi vào hệ thống. Trong bối cảnh kiểm thử lặp lại (regression testing), impact analysis giúp xác định xem một lỗi đã được sửa chữa đúng cách hay chưa. Nói cách khác, impact analysis giúp đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống để xác định xem cần phải thực hiện kiểm thử lặp lại hay không. Trong câu hỏi này, có bốn lựa chọn khác nhau, nhưng chỉ có một lựa chọn đúng. Lựa chọn đúng là: "Impact analysis assesses the effect of a change to the system to determine how much regression testing to do". Điều này có nghĩa là impact analysis giúp đánh giá tác động của một thay đổi vào hệ thống để xác định xem cần phải thực hiện kiểm thử lặp lại bao nhiêu. Lựa chọn sai là: "Impact analysis assesses the effect on the system of a defect found in regression testing". Điều này có nghĩa là impact analysis chỉ giúp đánh giá tác động của một lỗi vào hệ thống, nhưng không giúp xác định xem cần phải thực hiện kiểm thử lặp lại hay không. Lựa chọn sai khác là: "Impact analysis assesses the effect of a new person joining the regression test team". Điều này có nghĩa là impact analysis giúp đánh giá tác động của một người mới tham gia vào đội kiểm thử lặp lại, nhưng không liên quan đến việc đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống. Lựa chọn sai cuối cùng là: "Impact analysis assesses whether or not a defect found in regression testing has been fixed correctly". Điều này có nghĩa là impact analysis giúp đánh giá xem một lỗi đã được sửa chữa đúng cách hay chưa, nhưng không liên quan đến việc đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống. Tóm lại, impact analysis là một kỹ thuật quan trọng trong kiểm thử phần mềm giúp đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống để xác định xem cần phải thực hiện kiểm thử lặp lại hay không.

Testing là một phần quan trọng trong quy trình phát triển phần mềm, và mục đích chính của nó là xác định xem phần mềm có hoạt động đúng như dự kiến hay không. Trong bốn lựa chọn trên, câu trả lời đúng là "Testing is executing Software for the purpose of finding defects". Điều này có nghĩa là mục đích của testing là thực hiện phần mềm để tìm kiếm các lỗi hoặc sai sót trong nó. Điều này giúp phát triển phần mềm ổn định và hiệu quả hơn. Các lựa chọn khác, mặc dù có liên quan đến testing, nhưng không chính xác về mục đích chính của nó. Ví dụ, "The goal of testing is to demonstrate that the program works" chỉ là một phần của mục đích testing, nhưng không bao quát được tất cả. "The purpose of testing is to demonstrate that the program is defect free" cũng không chính xác, vì testing không thể đảm bảo rằng phần mềm hoàn toàn không có lỗi. Cuối cùng, "The purpose of testing is to demonstrate that the program does what it is supposed to do" cũng không đúng, vì mục đích chính của testing là tìm kiếm các lỗi, chứ không phải chỉ là đảm bảo rằng phần mềm hoạt động đúng như dự kiến.

Severity và priority là hai khái niệm quan trọng trong quy trình kiểm thử phần mềm. Severity thường được định nghĩa là mức độ ảnh hưởng của một lỗi đến hệ thống hoặc người dùng cuối cùng. Điều này có thể bao gồm mức độ nghiêm trọng của lỗi, mức độ ảnh hưởng đến hiệu suất hoặc mức độ ảnh hưởng đến trải nghiệm người dùng. Ví dụ, một lỗi nghiêm trọng có thể khiến hệ thống không thể hoạt động hoặc gây ra thiệt hại tài chính cho người dùng. Priority, mặt khác, thường được định nghĩa là mức độ ưu tiên của việc sửa lỗi. Điều này có thể dựa trên mức độ ảnh hưởng của lỗi, nhưng cũng có thể dựa trên các yếu tố khác như thời gian còn lại trước khi phát hành sản phẩm, mức độ phức tạp của việc sửa lỗi hoặc mức độ ảnh hưởng đến doanh thu. Ví dụ, một lỗi có mức độ ảnh hưởng cao nhưng có thể sửa được nhanh chóng có thể được ưu tiên cao hơn một lỗi có mức độ ảnh hưởng thấp nhưng cần thời gian và công sức để sửa. Do đó, severity và priority không phải là hai khái niệm tương đương, mà là hai khái niệm khác nhau phục vụ cho mục đích khác nhau trong quy trình kiểm thử phần mềm. Tóm lại, severity và priority là hai khái niệm quan trọng trong quy trình kiểm thử phần mềm, phục vụ cho mục đích khác nhau. Severity được định nghĩa là mức độ ảnh hưởng của một lỗi đến hệ thống hoặc người dùng cuối cùng, trong khi priority được định nghĩa là mức độ ưu tiên của việc sửa lỗi.

Một cuộc kiểm tra (inspection) và một cuộc đi bộ (walkthrough) là hai phương pháp đánh giá khác nhau trong việc đánh giá chất lượng của một sản phẩm, dự án hoặc quy trình. Cuộc kiểm tra thường được dẫn đầu bởi một người giám sát (moderator) có kinh nghiệm và chuyên môn trong lĩnh vực đó. Người giám sát sẽ đánh giá các tiêu chí, yêu cầu và tiêu chuẩn đã được xác định trước và đưa ra đánh giá dựa trên các tiêu chí này. Trong khi đó, một cuộc đi bộ (walkthrough) thường được dẫn đầu bởi tác giả (author) của sản phẩm hoặc dự án. Tác giả sẽ dẫn dắt người tham gia đi qua sản phẩm hoặc dự án và giải thích các tính năng, đặc điểm và mục đích của nó. Người tham gia sẽ có cơ hội hỏi các câu hỏi và nhận được thông tin chi tiết từ tác giả. Sự khác biệt chính giữa hai phương pháp này là người dẫn đầu và mục đích của cuộc đánh giá. Cuộc kiểm tra tập trung vào việc đánh giá chất lượng và tuân thủ các tiêu chuẩn, trong khi cuộc đi bộ tập trung vào việc giải thích và trình bày sản phẩm hoặc dự án.

Trong quá trình thực hiện và thực thi thử nghiệm, một trong những nhiệm vụ quan trọng là báo cáo sự không phù hợp hoặc bất thường trong kết quả thử nghiệm. Điều này bao gồm việc xác định và báo cáo các sự kiện không mong muốn hoặc không dự kiến xảy ra trong quá trình thử nghiệm. Mục đích chính của việc này là đảm bảo rằng các vấn đề hoặc lỗi có thể được phát hiện và giải quyết một cách nhanh chóng, từ đó cải thiện chất lượng của sản phẩm hoặc dịch vụ đang được thử nghiệm. Việc báo cáo sự không phù hợp cũng giúp cho các nhà phát triển và quản lý dự án có thể đánh giá và điều chỉnh các quy trình thử nghiệm để đảm bảo rằng chúng được thực hiện một cách hiệu quả và chính xác.

Test planning là một phần quan trọng của quá trình kiểm thử phần mềm. Mục tiêu chính của test planning là xác định các yêu cầu và mục tiêu của quá trình kiểm thử, bao gồm việc xác định các trường hợp kiểm thử, tạo kế hoạch kiểm thử và phân bổ nguồn lực cần thiết. Một trong những nhiệm vụ chính của test planning là lập kế hoạch và lên lịch cho các nhiệm vụ phân tích và thiết kế kiểm thử. Điều này bao gồm việc xác định các yêu cầu kiểm thử, tạo ra các trường hợp kiểm thử và lên kế hoạch cho việc thực hiện kiểm thử. Việc lên lịch này giúp đảm bảo rằng quá trình kiểm thử được thực hiện một cách hiệu quả và đầy đủ, đồng thời giúp giảm thiểu thời gian và chi phí cần thiết.

Khi chọn phương pháp kiểm thử, có nhiều yếu tố cần xem xét. Tuy nhiên, kỹ năng và kinh nghiệm sẵn có trong phương pháp đề xuất là yếu tố quan trọng nhất. Điều này vì sao? Khi một đội kiểm thử có kỹ năng và kinh nghiệm trong một phương pháp cụ thể, họ có thể áp dụng phương pháp đó một cách hiệu quả hơn. Họ có thể nhanh chóng hiểu được các khái niệm cơ bản, xác định các bước cần thực hiện và tìm ra các giải pháp cho các vấn đề phát sinh. Ngoài ra, kỹ năng và kinh nghiệm sẵn có cũng giúp đội kiểm thử tiết kiệm thời gian và nguồn lực, vì họ không cần phải đầu tư quá nhiều vào đào tạo và chuẩn bị. Thêm vào đó, kỹ năng và kinh nghiệm sẵn có cũng giúp đội kiểm thử có thể tự tin hơn khi áp dụng phương pháp mới, giảm thiểu rủi ro và tăng cường hiệu quả của quá trình kiểm thử.

Định nghĩa hoàn hảo về kiểm thử hoàn toàn là một khái niệm quan trọng trong lĩnh vực kiểm thử phần mềm. Kiểm thử hoàn toàn là quá trình kiểm thử tất cả các trường hợp kiểm thử được định nghĩa trong kế hoạch kiểm thử. Điều này đảm bảo rằng tất cả các tính năng và yêu cầu của chương trình đã được kiểm tra một cách đầy đủ và chính xác. Kiểm thử hoàn toàn không phải là việc phát hiện ra tất cả các lỗi trong chương trình, mà là việc kiểm tra tất cả các trường hợp kiểm thử được định nghĩa trong kế hoạch kiểm thử. Điều này giúp đảm bảo rằng chương trình hoạt động đúng và không có lỗi nào được bỏ qua.

Khi báo cáo lỗi tìm thấy cho các nhà phát triển, người kiểm thử nên thể hiện sự tôn trọng, xây dựng và hữu ích. Điều này có nghĩa là họ nên trình bày vấn đề một cách rõ ràng và cụ thể, tránh sử dụng ngôn ngữ tiêu cực hoặc gây phẫn nộ. Họ cũng nên cố gắng hiểu được quan điểm của nhà phát triển và tránh gây ra sự bất đồng không cần thiết. Đồng thời, họ cũng nên kiên quyết trong việc khẳng định rằng một lỗi không phải là một "tính năng" nếu nó cần được sửa chữa. Điều này đòi hỏi sự nhạy cảm và khả năng giao tiếp tốt. Ngoài ra, người kiểm thử cũng nên nhạy cảm với cách nhà phát triển có thể phản ứng với sự chỉ trích, và cố gắng tránh gây ra sự bất đồng hoặc căng thẳng không cần thiết. Tóm lại, người kiểm thử nên thể hiện sự tôn trọng, xây dựng, hữu ích, kiên quyết và nhạy cảm khi báo cáo lỗi tìm thấy cho các nhà phát triển.

Khi nào nên dừng thử nghiệm là một vấn đề quan trọng trong lĩnh vực thử nghiệm phần mềm. Có nhiều lý do khác nhau để dừng thử nghiệm, nhưng một số lý do phổ biến nhất bao gồm: - **Thời gian thử nghiệm đã hết hạn**: Khi thời gian thử nghiệm đã được lên kế hoạch và sắp hết hạn, thì việc dừng thử nghiệm là cần thiết để đảm bảo rằng thử nghiệm được thực hiện một cách hiệu quả và không bị kéo dài quá mức. - **Số lượng lỗi đã đạt đến ngưỡng cho phép**: Nếu đã đạt đến 75% số lỗi đã được định nghĩa trước đó, thì việc dừng thử nghiệm có thể là cần thiết để tránh lãng phí thời gian và nguồn lực vào thử nghiệm không cần thiết. - **Tất cả các trường hợp thử nghiệm đã được thực hiện**: Nếu tất cả các trường hợp thử nghiệm đã được thực hiện và chỉ phát hiện được một số lỗi nhỏ, thì việc dừng thử nghiệm có thể là cần thiết để đảm bảo rằng thử nghiệm đã được thực hiện một cách đầy đủ và hiệu quả. - **Không có lý do nào khác**: Nếu không có lý do nào khác để dừng thử nghiệm, thì việc dừng thử nghiệm có thể không cần thiết. Tuy nhiên, trong trường hợp này, đáp án đúng là **"Stop when scheduled time for testing expires"**, vì việc dừng thử nghiệm khi thời gian thử nghiệm đã hết hạn là một lý do phổ biến và hợp lý để dừng thử nghiệm.

Functional testing là một loại kiểm thử phần mềm được thực hiện để xác minh rằng sản phẩm hoặc phần mềm đáp ứng các yêu cầu chức năng đã được xác định. Có nhiều mức độ kiểm thử khác nhau trong quá trình phát triển phần mềm, bao gồm kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận và kiểm thử chức năng. Trong đó, kiểm thử chức năng được thực hiện để xác minh rằng sản phẩm hoặc phần mềm đáp ứng các yêu cầu chức năng đã được xác định. Kiểm thử chức năng có thể được thực hiện tại tất cả các mức độ kiểm thử, bao gồm kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận và kiểm thử chức năng. Điều này cho phép phát hiện và sửa lỗi sớm trong quá trình phát triển phần mềm, từ đó cải thiện chất lượng sản phẩm cuối cùng.

Một hệ thống ghi nhận sự kiện (incident logging system) là một công cụ quan trọng trong quá trình kiểm thử (testing) của một dự án. Hệ thống này giúp ghi nhận và theo dõi tất cả các sự kiện xảy ra trong quá trình kiểm thử, bao gồm cả các lỗi (defects) và các vấn đề khác. Việc ghi nhận và theo dõi các sự kiện này giúp cung cấp thông tin quý giá cho các thành viên trong dự án, bao gồm cả các nhà phát triển, kiểm thử viên và quản lý dự án.

Coverage measurement là một khái niệm quan trọng trong lĩnh vực kiểm thử phần mềm. Nó liên quan đến việc đo lường mức độ hoàn chỉnh của các thử nghiệm được thực hiện để đảm bảo chất lượng phần mềm. Coverage measurement không phải là một khái niệm đơn giản, mà nó bao gồm nhiều loại đo lường khác nhau, chẳng hạn như branch coverage, statement coverage, function coverage, và decision coverage. Mỗi loại đo lường này đo lường mức độ hoàn chỉnh của các phần khác nhau của mã nguồn phần mềm.

Trong quá trình phát triển phần mềm, quá trình kiểm thử có thể bắt đầu khi nào đó là một vấn đề quan trọng. Quá trình kiểm thử là một phần không thể thiếu trong phát triển phần mềm, giúp đảm bảo rằng phần mềm hoạt động đúng và đáp ứng được yêu cầu của người dùng. Có nhiều điểm khác nhau để bắt đầu quá trình kiểm thử, nhưng điểm quan trọng nhất là khi yêu cầu phần mềm đã được phê duyệt.