Kiểm thử phần mềm là hoạt động không thể tách rời hoạt động phát triển phần mềm. Nếu ví quá trình phát triển phần mềm là xương sống tạo nên các chương trình phần mềm cơ bản hoàn thiện thì quá trình kiểm thử sẽ đắp lên cơ bắp theo đúng yêu cầu của khách hàng giúp hoàn thiện một hình hài đủ tiêu chuẩn. Việc nắm rõ mô hình phát triển mềm sẽ giúp bạn có cái nhìn định hướng và xây dựng hoạt động kiểm thử đúng đắn, hiệu quả và phù hợp hơn.

I. Khái niệm chung về phát triển phần mềm

1. Khái niệm: Quy trình phát triển phần mềm là một tập hợp các hoạt động tổ chức mà mục đích của chúng là xây dựng và phát triển phần mềm. 2. Các hoạt động cơ bản của quy trình phát triển phần mềm: Có 4 thao tác là nền tảng của hầu hết các quy trình phát triển phần mềm:

• Đặc tả phần mềm: Định nghĩa được các chức năng, điều kiện hoạt động của phần mềm
• Phát triển phần mềm: Là quá trình xây dựng các đặc tả.
• Đánh giá phần mềm: để chắc chắn phần mềm làm ra ít nhất có thể thực hiện những đặc tả yêu cầu của tài liệu.
• Tiến hóa phần mềm: Đây là quá trình hoàn thiện các chức năng cũng như giao diện để ngày càng hoàn thiện phần mềm cũng như các yêu cầu đưa ra thêm từ phía khách hàng.

II. Các mô hình phát triển phần mềm phổ biến

1, Water fall

1.1 Các giai đoạn phát triển

• Lấy yêu cầu khách hàng: thu thập thông tin về chi tiết và tính năng của sản phẩm từ khách hàng càng nhiều càng tốt.
• Thiết kế: lên kế họach xem bạn sẽ sử dụng ngôn ngữ lập trình nào (Java hay .NET, v.v), cơ sở dữ liệu nào (Oralce hay MySQL, v.v) cũng như những tính năng tổng quát cũng như kiến trúc của sản phẩm.
• Xây dựng: Sau khi thiết kế là giai đoạn xây dựng (viết code cho sản phẩm).
• Kiểm thử: kiểm tra xem sản phẩm được xây dựng có đúng theo yêu cầu ban đầu của khách hàng hay không.
• Triển khai: Triển khai sản phẩm cho khách hàng.
• Bảo trì: Sau khi triển khai sản phẩm cho khách hàng, bạn có thể sẽ nhận được yêu cầu từ khách hàng để tùy chỉnh hay chỉnh sửa sản phẩm. Ưu điểm:
• Các giai đoạn được định nghĩa đầu vào và đầu ra rõ ràng. Cơ bản dựa trên tài liệu.
• Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động có trình tự rõ ràng.

Nhược điểm:

• Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. Nhưng đa số dự án thực tế yêu cầu phần mềm thường ẩn chứa những vấn đề chưa chắc chắn.
• dự án thực tế ít khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án. Khi cận ngày gửi cho khách hàng chương trình hay được sửa đổi trực tiếp dẫn đến bản đặc tả phần mềm không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.
• Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của họ vào thời điểm cuối dự án.
• ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng và chi phí để sửa chữa có thể rất cao.

2. V-model:

2.1 Các giai đoạn phát triền

-Tương ứng mỗi giai đoạn của chu kỳ phát triển là giai đoạn kiểm thử tương ứng. Phía bên trái của mô hình chữ V là giai đoạn (vòng đời) phát triển phần mềm. Phía bên phải của mô hình chữ V là các hoạt động kiểm thử tương ứng.  Ưu điểm.

• Đơn giản dễ sử dụng.
• Có hoạt động, kế hoạch cụ thể cho quá trình test.
• Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall.
• Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt động liên quan đến đặc tả yêu cầu và thiết kế. Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu.

Nhược điểm.

• Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi step thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiệu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian.
• Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu. Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm.
• Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, update lại tài liệu.

3, mô hình agile

3.1 Các giai đoạn phát triển

Là dạng mô hình phát triển “lặp”. Trong mô hình loại này, việc phát triển phần mềm được tiến hành theo từng chặng và mỗi chặng chỉ tập trung phát triển 1 hoặc vài tính năng của sản phẩm. Mỗi dự án được chia thành nhiều mảng nhỏ để dễ sử dụng và thay đổi khi khách hàng yêu cầu thay đổi. Từng phần nhỏ của dự án sẽ được test ngay trong quá trình làm dự án. Yêu cầu gặp mặt trao đổi thường xuyên vì trong Agile tại mỗi thời điểm cả nhóm phải cùng tập trung phát triển một mảng của dự án. Ưu điểm

• Agile là sự lựa chọn rất tốt cho những dự án nhỏ bởi những dự án nhỏ thường có những yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên.
• Với Agile khách hàng có thể được xem trước từng phần dự án trong suốt quá trình phát triển vì Agile phát triển phần mềm theo hướng tăng dần, có thể đưa cho khách hàng xem từng phần đã thực hiện hoàn thành. Từ đó có thể bám sát dự án và luôn sẵn sàng cho bất kỳ thay đổi nào từ phía khách hàng yêu cầu về dự án.
• Agile chia dự án thành những phần nhỏ và giao cho mỗi người, hàng ngày tất cả mọi người phải họp với nhau trong khoảng thời gian ngắn để thảo luận về tiến độ và giải quyết những vấn đề nảy sinh nếu có nhằm đảm bảo đúng quy trình phát triển dự án. Tỉ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác.

Nhược điểm

• Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết
• Quy mô nhân lực thường giới hạn từ 7 đến 10 người, sẽ có trở ngại lớn nếu nguồn nhân lực yêu cầu vượt quá con số này ví dụ trong các cuộc họp trao đổi.
• Số lượng yêu cầu có thể nhiều và khó quản lý nếu như nó bao gồm nhiều khía cạnh khác nhau về dự án.

III, Vòng đời kiểm thử phần mềm

Kiểm thử thực tế là một chuỗi các hoạt động được thực thi một cách khoa học nhằm đánh giá chất lượng của sản phẩm phần mềm. Các hoat động (giai đoạn) này cấu thành nên vòng đời kiểm thử (hay còn gọi là software testing life cycle-STLC). Các giai đoạn trong vòng đời kiểm thử phần mềm bao gồm:

Giai đoạn #1: Phân tích yêu cầu

• đánh giá xem yêu cầu nào có thể test được, yêu cầu nào không. làm việc với các bên liên quan như khách hàng, phân tích hệ thống, trưởng nhóm, kỹ sư hệ thống, v.v để làm rõ yêu cầu về chức năng (mô tả tính năng của phần mềm) cũng như non-functional (yêu cầu hiệu năng, tính bảo mật, tính hữu dụng của phần mềm).
• đánh giá khả năng làm kiểm thử tự động ở giai đoạn này. Các hoạt động liên quan:
• Xác định loại kiểm thử sẽ được thực thi
• Xác đinh độ ưu tiên của các hoạt động kiểm thử
• Chuẩn bị tài liệu để đánh giá độ bao phủ của yêu cầu (Requirement Traceability Matrix)
• Xác định môi trường test cần chuẩn bị khi tiến hành kiểm thử
• Phân tích tính khả thi của kiểm thử tự động (nếu cần thiết)

Đầu ra: Tài liệu đánh giá về độ bao phủ của yêu cầu. Bảng báo cáo về tính khả thi của kiểm thử tự động

Giai đoạn #2: Lập kế hoạch kiểm thử

QA Manager sẽ quyết định cũng như ước lượng chi phí cho dự án cũng như chuẩn bị và thống nhất kế hoạch kiểm thử.

Các hoạt động liên quan:

• Chuẩn bi tài liệu kế hoạch/chiến lược kiểm thử cho các loại kiểm thử khác nhau.
• Chọn công cụ kiểm thử.
• Ước lượng khối lượng công việc kiểm thử.
• Lên kế hoạch nhân sự cũng như định ra vai trò và trách nhiệm tương ứng.
• Lên kế hoạch đào tạo nếu cần thiết.

Đầu ra: Bảng kế hoạch kiểm thử (test plan). Bảng ước lượng khối lượng công việc.

Giai đoạn #3: Thiết kế các trường hợp kiểm thử (test case)

bao gồm các hoạt động như tạo test case, review test case, chỉnh sửa test case cũng như chuẩn bị dữ liệu kiểm thử (test data) Các hoạt động liên quan:

• Tạo test case, kịch bản test (dành cho kiểm thử tự động).
• Tạo dữ liệu kiểm thử

Đầu ra: Bộ test case/test scripts. Bộ dữ liệu test

Giai đoạn #4: Chuẩn bị môi trường test

chuẩn bị môi trường kiểm thử như phần mềm, phần cứng nào cần thiết cho việc test Các hoạt động liên quan:

• Hiểu được yêu cầu về môi trường test của dự án để chuẩn bị phần mềm, phần cứng tương ứng.
• Chuẩn bị môi trường test tương ứng.
• Chuẩn bị dữ liệu test tương ứng.
• Kiểm tra xem môi trường test chạy có ok không

Đầu ra: Môi trường test được chuẩn bị sẵn sàng.

Giai đoạn #5: Thực thi kiểm thử

tiến hành kiểm thử dựa trên kế hoạch kiểm thử và bộ test case đã chuẩn bị trước đó. Lỗi sẽ được báo cho đội phát triển để sửa lỗi và kiểm tra lỗi có được fix đúng hay không. Các hoạt động liên quan:

• Chạy test case.
• Ghi nhận kết quả và báo bug cho những trường hợp chạy bị failed.
• Map bug với test case trong bộ test case
• Kiểm tra các lỗi được vá.
• Đóng lỗi (nếu lỗi được fix)

Đầu ra: Kết quả chạy test case. Bảng báo cáo lỗi

Giai đoạn #6: Kết thúc chu kỳ test

ngồi lại với nhau để thảo luận về kết quả thực thi test để lên kế hoạch cũng như rút ra bài học. Ý tưởng là loại bỏ nhưng giai đoạn thắt cổ chai cũng như chia sẻ best practices cho những dự án tương tự trong tương lai. Các hoạt động liên quan:

• Đánh giá mức độ hoàn thành của việc test dựa vào Thời gian, Độ bao phủ test, Chi phí, Mục tiêu busines đạt được, v.v.
• Chuẩn bị các tiêu chí đo lường dựa trên những yếu tố trên.
• Ghi nhận những bài học rút ra được.
• Chuẩn bị bảng báo cáo đóng dự án.
• Đánh giá chất lượng của sản phẩm.
• Phân tích kết quả kiểm thử để tìm ra việc phân bổ và độ nghiêm trọng của lỗi

Đầu ra: Bảng báo cáo đóng giai đoạn. Tiêu chí đo lượng chất lượng kiểm thử

IV, So sánh vòng đời kiểm thử trong các mô hình phát triển trên

Hầu như với mô hình phát triển phần mềm nào cũng đều thực hiện các giai đoạn trên của vòng đời kiểm thử. Tuy nhiên có một vài điểm khác biệt sau:

Tóm lại, dưới sự phát triển như vũ bão của thời đại sẽ sớm muộn tạo nên những mô hình phát triển phần mềm mới nhanh, gọn , nhẹ và hiệu quả hơn. Những nhân viên kiểm thử cũng linh hoạt hơn trong công việc của mình để đảm bảo sản phẩm đưa đến tay khách hàng luôn là sản phẩm chất lượng nhất và có tâm nhất. Tham khảo: https://viblo.asia/p/tong-quan-ve-agile-va-kiem-thu-phan-mem-trong-mo-hinh-agile-Az45bpBQZxY http://hockiemthu.com/vong-doi-phat-trien-phan-mem/