Mô hình kiểm thử phần mềm là gì? Các mô hình kiểm thử phần mềm

Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát hiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và đầy đủ theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Software testing cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm điều này cho phép đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Cụ thể là gì? Hãy cùng ACC tìm hiểu thông qua bài viết dưới đây

1. Kiểm thử là gì?

Đây là một trong những loại kiểm thử phần mềm quan trọng để xác nhận xem hệ thống có hoạt động đúng yêu cầu hay không. Ở tất cả các mức độ kiểm thử đều được kiểm thử chức năng. 

Testing of function là một trong những loại kiểm thử phần mềm quan trọng

Testing of function có thể thực hiện theo 2 quan điểm: business – process – based và requirements-based. Với business – process – based, kiểm thử viên sẽ sử dụng các kiến thức về quy trình nghiệp vụ (mô tả các kịch bản liên quan đến nghiệp vụ của hệ thống mỗi ngày).

Trong khi đó, requirements-based sử dụng các đặc tả yêu cầu của hệ thống làm cơ sở để design test. Để đảm bảo những thành phần quan trọng nhất đều được kiểm thử, hãy xem xét độ ưu tiên của yêu cầu dựa trên tiêu chí rủi ro, theo đó, chúng ta sẽ sử dụng độ ưu tiên để kiểm thử. 

Các bước kiểm thử chức năng gồm: 

Bước 1: Xác định phần mềm sẽ kiểm thử và chức năng của nó 

Bước 2: Dựa trên tài liệu đặc tả chức năng để tạo dữ liệu đầu vào 

Bước 3: Dựa vào tài liệu đặc tả chức năng để xác định đầu ra

Bước 4: Thực hiện các trường hợp kiểm thử phần mềm  

Bước 5: So sánh kết quả thực tế với mong muốn đạt được 

2. Phương pháp kiểm thử

Phương pháp kiểm thử (Testing Methods) Kiểm thử hộp trắng (White Box Testing) Kiểm thử hộp đen (Black Box Testing):

• Phân vùng tương đương (Equivalence partitioning)

• Phân tích giá trị biên (Boundary value analysis)

• Bảng quyết định (Decision table)

• Đoán lỗi – Error Guessing

3. Các thành phần chính, quan trọng trong việc lập kế hoạch

3.1 Chiến lược kiểm thử

• Lập kế hoạch kiểm thử mức cao

• Test scripts

• Test Cases

• Test data

Sau đây chúng ta sẽ đi vào từng thành phần

Chiến lược kiểm thử Đây là tài liệu ghi lại cách tiếp cận kiểm thử cho các thành phần còn lại Các chiến lược kiểm thử có thể được phát triển rất sớm trong một dự án và chỉ yêu cầu thông tin ban đầu để có thể viết. Bất cứ khi nào một loại dự án hoặc công nghệ mới đang được kiểm thử, chiến lược kiểm thử là một trong những tài liệu quan trọng nhất cần thiết lập và cho ra đời sớm nhất.

Lập kế hoạch kiểm thử mức cao Đây là tài liệu mô tả cho việc kiểm thử “ai, cái gì, khi nào, ở đâu và như thế nào”. Kế hoạch kiểm thử có thể được phát triển ở nhiều mức độ khác nhau, nhưng chúng tôi sẽ tập trung chủ yếu ở cấp độ dự án hoặc hệ thống trong phạm vi tài liệu này.

Kiểm thử mức chi tiết hơn ( Test scripts, Test cases, Test data) Kế hoạch kiểm thử mức cao sẽ cho thấy các function và thuộc tính nào của ứng dụng sẽ được kiểm thử. Các mô tả kiểm thử chi tiết thể hiện các thử nghiệm này theo nghĩa là người kiểm thử có thể thực thi hoặc có thể được viết test scripts để có thể thực hiện kiểm thử tự động. Chúng tôi sẽ xem xét làm thế nào để phát triển tất cả các thành phần trên và hiển thị các ví dụ của mỗi thành phần.

3.2 Các nhiệm vụ (tasks) chính trong việc lập kế hoạch kiểm thử

• Phát triển chiến lược kiểm thử

• Xác định mục tiêu kiểm thử

• Xác định các nguồn lực cần thiết

• Lập kế hoạch môi trường kiểm thử

• Xác định thủ tục kiểm thử (Test Procedures)

• Xác định các function cần kiểm thử

• Xác định các giao diện cần kiểm thử

• Viết Test Scripts

• Xác định Test cases

• Thiết kế Test Data

• Xây dựng Test maxtric

• Thiết lập Test schedules

• Giả định thông tin

• Kết thúc việc lập kế hoạch

Nhiệm vụ 1: Phát triển chiến lược kiểm thử

Định nghĩa các khía cạnh riêng của kiểm thử

Xác định

Nhân tố quan trọng tạo nên thành công của dự án (Critical Success Factors – CSF)

Loại ứng dụng

Loại dự án

Loại môi trường

Phạm vi kiểm thử

Rủi ro (Criticality)

Xác định

Ai sẽ là người kiểm thử

Khi nào kiểm thử sẽ được tiến hành

Kết hợp các yếu tố

Chi phí

Lịch trình (schedule)

Phạm vi (scope)

Chất lượng

Chiến lược kiểm thử là tài liệu cấp cao mô tả tính chất cơ bản và các khía cạnh riêng của kiểm thử. Chiến lược kiểm thử là một công cụ để giao tiếp để mọi người trong dự án biết cách kiểm thử sẽ được tiến hành. Các chiến lược kiểm thử có thể được xây dựng sớm trong dự án cho phép kiểm thử tiến hành một cách sớm nhất Một chiến lược kiểm thử điển hình sẽ xác định:

1. Nhân tố quan trọng tạo nên thành công của dự án (Critical Success Factors – CSF)

Các nhân tố quan trọng tạo nên thành công của dự án là các thuộc tính của một ứng dụng phải có mặt để nó được coi là thành công. Ví dụ về CSF bao gồm tính chính xác, khả năng sử dụng, độ tin cậy, tính di động, khả năng tương tác và bảo mật. Các CSF liên quan trực tiếp đến kiểm tra các rủi ro và rủi ro dự án. Điều quan trọng là chỉ chọn 4 hoặc 5 yếu tố quan trọng, vì mỗi yếu tố sẽ yêu cầu các công cụ, con người và quy trình cụ thể.

2. Loại ứng dụng Mô tả mục đích và mục tiêu của ứng dụng, chẳng hạn như: batch, on-line, web-base, Windows 32 bit, thương mại điện tử, truy cập dữ liệu, mạng nội bộ của công ty, extranet của khách hàng, v.v.

3. Loại môi trường Mô tả loại môi trường hoạt động hoặc nền tảng ứng dụng sẽ tùy thuộc vào. Có thể bao gồm môi trường người dùng, cũng như môi trường vật lý, chẳng hạn như ngoài trời, truy cập công cộng, quyền truy cập bị giới hạn, v.v.

4. Phạm vi kiểm thử Mô tả cái sẽ được test và không được test

5. Rủi ro (Criticality)

Là bất kỳ khía cạnh nào của ứng dụng được kiểm thử làm tổ chức bị ảnh hưởng, mất mát.

Nhiệm vụ 2: Xác định mục tiêu kiểm thử

Xác định những gì sẽ được kiểm thử ở mức cao (high level)

Tốt nhất nên dựa trên yêu cầu

Ngoài ra có thể dựa trên:

Quy trình và nghiệp vụ

Nhu cầu của khách hàng

Những chức năng cơ bản

Mục tiêu kiểm thử nên liên quan trực tiếp đến các mục tiêu của dự án hoặc hệ thống. Đối với mỗi hệ thống hoặc mục tiêu của dự án, cần có mục tiêu kiểm thử. Bạn có thể chọn để xác định mục tiêu kiểm thử của hệ thống bằng cách chia nhỏ các chức năng hoặc vùng chức năng. Trong việc thiết lập các mục tiêu kiểm thử, xác định tất cả những điều mà kiểm thử nên hoàn thành. Trong trường hợp lý tưởng, các mục tiêu kiểm thử sẽ dựa trên chi tiết được xác định yêu cầu. Tuy nhiên, người kiểm thử thường không nhận được mức độ chi tiết trong các yêu cầu để viết mục tiêu. Thay vào đó, các mục tiêu kiểm thử có thể thu được từ:

Quy trình và nghiệp vụ

Ví dụ, bạn cần biết khách hàng sẽ đặt một số loại giao dịch hoặc yêu cầu một số dịch vụ nhất định …

Nhu cầu của khách hàng

Bạn cần biết khách hàng cần có phản hồi nhanh với các yêu cầu hoặc có thể huỷ giao dịch

3.3 Những chức năng cơ bản

Một số chức năng cơ bản cần cho phần mềm ví dụ như: tìm kiếm, các nút (buttons), controls…

Nhiệm vụ: Xác định các chức năng cần kiểm thử

Dựa trên yêu cầu Các yêu cầu của ứng dụng hoặc hệ thống thường được văn bản hoá, đó chính là nguồn tốt nhất để tìm ra các chức năng cần được kiểm thử. Tuy nhiên các yêu cầu này có thể thường xuyên được thay đổi. Do đó quy trình kiểm thử cần phải đáp ứng được với sự thay đổi yêu cầu này

Dựa trên chức năng hoạt động/ nghiệp vụ của toàn hệ thống

Các sự kiện (events) của hệ thống

Các chức năng trong hệ thống nhà cung cấp

Mục đích Thương mại

Ví dụ về tài liệu kế hoạch kiểm thử với các chức năng cần kiểm thử

Hệ thống: Hệ thống lương

4. 7 nguyên tắc cơ bản trong kiểm thử phần mềm

4.1. Kiểm thử phần mềm chứng minh sự hiện diện của lỗi

Bằng việc kiểm thử, chúng ta có thể làm giảm lượng bugs khi áp dụng nhiều phương pháp kiểm thử lên phần mềm. Tuy nhiên khi được đưa lên môi trường thật, người dùng cuối hoàn toàn có thể thấy nhiều lỗi khác không tìm thấy trong quá trình kiểm thử. Kiểm thử chứng minh được sản phẩm có lỗi nhưng không thể chứng minh rằng sản phẩm không còn lỗi. Điều này có nghĩa là, sẽ luôn có lỗi không được phát hiện trong phần mềm, ngay cả khi không tìm thấy lỗi, cũng không đồng nghĩa rằng phần mềm đúng hoàn toàn.

4.2. Kiểm thử toàn bộ là không khả thi

Đúng vậy, rất khó để kiểm tra toàn bộ các module cũng như các tính năng, kết hợp với đầu vào và đầu ra trong suốt quá trình kiểm tra. Các sản phẩm phần mềm hiện nay cực kỳ đa dạng và phức tạp, được phát triển trên nhiều nền tảng, thêm vào đó, ngày càng có nhiều công nghệ mới, khả năng kết nối dữ liệu lớn… khiến việc kiểm thử toàn bộ gần như là không thể. Thay vì cố gắng kiểm thử toàn bộ, hãy xác định mức độ quan trọng và độ ưu tiên của các module để kiểm thử những phần cần thiết hoặc gặp nhiều nguy cơ hơn.

4.3. Kiểm thử càng sớm càng tốt

Nguyên tắc kiểm thử sớm có nghĩa là việc kiểm thử cần được thực hiện càng sớm càng tốt trong vòng đời phát triển phần mềm. Vậy ở bước nào thì được coi là sớm? Nguyên tắc này cho thấy ta cần phát hiện bug ngay từ các bước đầu tiên như nghiên cứu yêu cầu (requirement) hay design. Phát hiện lỗi càng muộn, chi phí bỏ ra để xử lý càng cao. Vì vậy, việc thay đổi yêu cầu không đúng từ sớm sẽ khiến tốn ít chi phí để thay đổi tính năng hơn.

4.4. Lỗi thường được phân bố tập trung

Nguyên lý về phân bố lỗi chỉ ra rằng, chỉ một số ít module chứa phần lớn số lỗi phát hiện được. Những module này thường là những thành phần, chức năng chính của hệ thống. Điều này cũng đúng theo nguyên lý Pareto: 80 – 20: 80% số lỗi tìm thấy ở chỉ 20% module. Bằng kinh nghiệm, các QA/ Tester có thể xác định được những module có tính rủi ro và nhiều lỗi như vậy, giúp tập trung tìm kiếm lỗi nhanh và hiệu quả hơn. Tuy nhiên, cách tiếp cận này cũng ẩn chứa vấn đề: nếu thực hiện kiểm thử tương tự lặp đi lặp lại, dễ thấy rằng những test case cũ sẽ khó tìm thêm được bug mới.

4.5. Nghịch lý thuốc trừ sâu

Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, các loại sâu bệnh sẽ dần dần thích nghi và trở nên “nhờn” với loại thuốc trừ sâu đó. Tương tự với kiểm thử phần mềm, khi lặp đi lặp lại một test case, thì xác suất tìm được lỗi là rất thấp. Nguyên nhân là hệ thống hoàn thiện hơn, lỗi tìm thấy đã được sửa theo test case cũ. Để xử lý hiệu ứng “thuốc trừ sâu” này, test case cần được thường xuyên xem lại và chỉnh sửa, thêm nhiều test case mới để tìm lỗi mới (regression test).

Thêm vào đó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ thuật test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn để làm việc kiểm thử hiệu quả hơn.

4.6. Kiểm thử phụ thuộc vào ngữ cảnh

Kiểm thử phụ thuộc vào ngữ cảnh, nói một cách đơn giản, là việc kiểm thử một trang thương mại điện tử sẽ phải khác cách test một ứng dụng đọc tin tức. Tất cả các phần mềm đều được phát triển theo cách khác nhau. Và việc áp dụng chung một “cách giải” là sai lầm. Bạn cần sử dụng cách tiếp cận khác nhau, phương thức, kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/ ứng dụng/ website.

4.7. Quan niệm sai lầm về việc “hết lỗi”

Một phần mềm sạch bug 99% vẫn có thể không sử dụng được. Đây là trường hợp phần mềm được kiểm thử bằng một requirement sai. Kiểm thử không chỉ để tìm ra lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng được đúng nhu cầu hay không. Chính vì vậy, việc Không còn lỗi hay Hết lỗi là quan niệm sai lầm.

Quan điểm: “Nguyên tắc kiểm thử chỉ là để tham khảo, không có tính ứng dụng thực tế”?

Đây là quan điểm cực kỳ sai lầm. Các nguyên tắc kiểm thử giúp tạo ra một chiến lược kiểm thử rõ ràng và tạo ra những trường  hợp kiểm thử sát sao, dễ bắt được bug. Những tester dày dạn kinh nghiệm áp dụng những nguyên tắc kiểm thử nhuần nhuyễn đến độ họ không nghĩ rằng họ đang áp dụng chúng. Vì vậy, việc nguyên tắc kiểm thử không có tính ứng dụng thực tế là sai lầm.

5. Mô hình kiểm thử phần mềm là gì? Các mô hình kiểm thử phần mềm 

Có rất nhiều mô hình kiểm thử phần mềm, tuy nhiên, một số mô hình được các tester thường xuyên sử dụng gồm: mô hình thác nước, mô hình chữ V, mô hình mẫu, mô hình Agile, mô hình xoắn ốc, mô hình Scrum, mô hình tăng trưởng và mô hình

RAD.

5.1 Mô hình thác nước (Waterfall model)  

Mô hình kiểm thử phần mềm Waterfall model được sử dụng đầu tiên. Đây là mô hình áp dụng tuần tự các giai đoạn phát triển phần mềm, theo đó, đầu vào của giai đoạn sau chính là đầu ra của giai đoạn trước. 

Mô hình kiểm thử phần mềm thác nước (Waterfall model)

Kiểm thử viên chỉ có thể thực hiện giai đoạn sau khi giai đoạn trước đã kết thúc. Đặc biệt, khi muốn thay đổi, kiểm thử viên không thể quay lại giai đoạn trước để xử lý các yêu cầu. Mô hình thác nước thường được áp dụng trong các dự án nhỏ, ngắn hạn, ít thay đổi và không có yêu cầu cụ thể. 

Các giai đoạn của mô hình thác nước bao gồm: 

• Requirement gathering: Thu thập, phân tích yêu cầu được ghi lại vào tài liệu đặc tả trong giai đoạn này. 

• System Analysis: Tiến hành phân tích thiết kế và xác định kiến trúc tổng thể của phần mềm.  

• Coding: Hệ thống được phát triển theo từng Unit, đồng thời được tích hợp trong giai đoạn tiếp theo. Unit được phát triển và kiểm thử bởi lập trình viên được gọi là Unit Test. 

• Testing: Giai đoạn này, công việc chủ yếu là kiểm tra, phát hiện và sửa lỗi để phần mềm hoạt động đúng theo tài liệu đặc tả yêu cầu. 

• Implementation: Triển khai hệ thống trong môi trường khách hàng và đưa ra thị trường. 

• Operations and Maintenance: Khi có thay đổi từ khách hàng, người dùng sẽ tiến hành bảo trì hệ thống. 

Ưu điểm:

• Thân thiện, dễ tiếp cận, sử dụng và quản lý

• Các giai đoạn phát triển sản phẩm được xác định rõ ràng

• Xác nhận ở từng giai đoạn để kịp thời phát hiện và sửa lỗi

Nhược điểm:

• Ít linh hoạt, hạn chế phạm vi điều chỉnh 

• Khó để quay lại khi đã kết thúc giai đoạn  

• Gặp khó khăn khi đo lường sự phát triển trong mỗi giai đoạn

• Không phù hợp với những dự án phức tạp, đang diễn ra, có nhiều thay đổi về yêu cầu trong vòng đời phát triển  

5.2 Mô hình mẫu

Mô hình mẫu được phát triển dựa trên những yêu cầu của hệ thống. Khi đó, khách hàng sẽ có cái nhìn tổng quan về hệ thống thực tế. Đây là mô hình kiểm thử phù hợp với những dự án lớn, phức tạp, không thể xác định rõ ràng yêu cầu.

Trong mô hình mẫu, thu thập yêu cầu là việc đầu tiên với sự có mặt của khách hàng và phía phát triển phần mềm để xác định mục tiêu tổng quát của hệ thống phần mềm sau này. Thêm nữa, tất cả yêu cầu được ghi nhận và sơ lược những nhóm yêu cầu cần được làm rõ. 

Tiếp theo là thiết kế, tập trung chuyển tải những khía cạnh thông qua Prototype để khách hàng có thể hình dung và đánh giá về hệ thống phần mềm. Đây là việc giúp cho đội ngũ phát triển phần mềm có thể hiểu rõ hơn về những gì cần được phát triển, sau đó tiến hành tinh chỉnh yêu cầu sao cho phù hợp.

Các Prototype thường được làm trong thời gian ngắn cho nên không được thiết kế trên công cụ phát triển và môi trường của giai đoạn xây dựng phần mềm sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển phần mềm thực sự.  

Ưu điểm:

• Cải thiện khoảng cách giữa nhà phát triển phần mềm và người dùng 

• Người dùng có thể sớm hình dung đặc điểm và chức năng của hệ thống phần mềm

Nhược điểm:

• Mô hình mẫu vẫn chưa thể cải thiện hoàn toàn khoảng cách giữa yêu cầu và ứng dụng cuối cùng

• Prototype thường được làm vội vàng, có thể không phân tích, đánh giá kỹ lưỡng các khía cạnh liên quan đến hệ thống cuối cùng 

• Khi Prototype không chuyển tải hết các đặc điểm, chức năng của hệ thống phần mềm thì người dùng có thể “vỡ mộng” và không còn quan tâm đến hệ thống sẽ được phát triển 

5.3 Mô hình chữ V (V model)

Đây là mô hình kiểm thử phần mềm được mở rộng hơn so với mô hình thác nước. Mô hình chữ V (V model) dựa trên sự kết hợp của một giai đoạn thử nghiệm cho mỗi giai đoạn phát triển tương ứng. 

Mô hình kiểm thử phần mềm chữ V (V model)

Tức là, mỗi giai đoạn của chu kỳ phát triển phần mềm sẽ có một giai đoạn thử nghiệm liên quan trực tiếp. Mô hình kiểm thử phần mềm chữ V có tính kỷ luật cao, chỉ khi hoàn thành giai đoạn trước mới có thể bắt đầu giai đoạn tiếp theo. 

Với mô hình chữ V, việc kiểm thử xuất hiện ngay từ đầu. Từ lúc thu thập yêu cầu là có thể review tài liệu, review code, review đặc tả chi tiết các bản thiết kế, cuối cùng sẽ là test ở mức thấp nhất: từng module, màn hình, chức năng, test tích hợp và kiểm thử hệ thống.    

Mô hình chữ V và mô hình thác nước được ứng dụng gần giống nhau, bởi vì chúng đều thuộc loại tuần tự, yêu cầu rõ ràng trước khi bắt đầu dự án. Mô hình chữ V (V model) thường được ứng dụng trong phát triển Y tế. 

Ưu điểm:

• Đơn giản, dễ hiểu, dễ sử dụng và quản lý 

• Phân phối rõ từng giai đoạn, quy trình đánh giá cụ thể  

• Mô hình có tính kỷ luật cao, các giai đoạn được hoàn thành cùng lúc

• Phù hợp với những dự án nhỏ và các yêu cầu được hiểu một cách rõ ràng 

Nhược điểm:

• Khó khăn trong việc quản lý, kiểm soát rủi ro

• Khó để quay lại và thay đổi chức năng khi ứng dụng đang ở giai đoạn thử nghiệm

• Mô hình này không phù hợp với những dự án lớn, phức tạp, đang diễn ra và hướng đối tượng 

5.4 Mô hình Agile 

Mô hình kiểm thử phần mềm Agile khá linh hoạt, giúp đưa sản phẩm đến tay người dùng càng nhanh càng tốt. Mô hình này có sự cải tiến so với một số mô hình kiểm thử cũ, điển hình là mô hình thác nước (Waterfall model). 

Mô hình kiểm thử phần mềm Agile

Agile gồm hàng loạt phương thức phát triển lặp và tăng dần, trong đó, giải pháp và các yêu cầu được phát triển thông qua sự liên kết giữa các nhóm liên chức năng, nhóm tự quản. 

Mô hình Agile dựa trên mô hình Iterative and incremental. Các giải pháp phát triển và yêu cầu dựa trên sự kết hợp của các function. Bên cạnh đó, những tính năng cụ thể của bản phát hành cuối sẽ được cung cấp bởi các tác vụ chia thành các khung thời gian nhỏ. 

Ưu điểm:

• Dễ hiểu, dễ sử dụng 

• Khách hàng hài lòng vì giao nhanh chóng

• Dễ dàng thay đổi và bổ sung theo yêu cầu 

• Các chức năng được xây dựng rõ ràng, dễ quản lý

• Khơi dậy tinh thần làm việc nhóm và trao đổi công việc hiệu quả 

• Nhà phát triển, người thử nghiệm và khách hàng thường xuyên trao đổi

Nhược điểm:

• Cần một nhóm dày dặn kinh nghiệm 

• Cần sự tương tác rõ ràng của khách hàng

• Không phù hợp để xử lý các phụ thuộc phức tạp

• Xuất hiện nhiều rủi ro về tính bền vững, khả năng mở rộng và bảo trì

• Gặp khó khăn khi chuyển giao công nghệ cho các thành viên mới trong nhóm

5.5 Mô hình xoắn ốc (Spiral model) 

Xoắn ốc là mô hình kiểm thử phần mềm được phát triển dựa trên sự kết hợp giữa mô hình thác nước (Waterfall model) và mô hình mẫu (Prototype model). Thông thường, mô hình xoắn ốc được dùng cho các ứng dụng lớn hay các hệ thống được xây dựng các phân đoạn/giai đoạn nhỏ. 

5.6 Mô hình xoắn ốc (Spiral model)

Các pha trong quy trình phát triển mô hình xoắn ốc (Spiral model) bao gồm: lập kế hoạch => đánh giá, giảm thiểu rủi ro => phát triển sản phẩm => đánh giá và lên kế hoạch pha tiếp theo. 

Lập kế hoạch (Planning phase): Thu thập và phân tích yêu cầu nhận được từ khách hàng. Cần xác định rõ ràng mục tiêu và đối tượng của từng pha. 

Đánh giá, giảm thiểu rủi ro (Alternate evaluation): Xác định, đánh giá và thực hiện những hành động để giảm thiểu rủi ro. Nếu xuất hiện rủi ro trong quá trình này sẽ có các giải pháp thay thế phù hợp. 

Phát triển sản phẩm (Product development): Lựa chọn mô hình thích hợp để phát triển hệ thống phần mềm.

Đánh giá và lập kế hoạch (Next phase planning): Tiến hành đánh giá dự án và lập kế hoạch cho pha tiếp theo. 

Ưu điểm:

• Dễ dàng kiểm soát rủi ro

• Hiệu quả đối với phần mềm quy mô lớn

• Phát hiện sớm những vấn đề quan trọng 

Nhược điểm:

• Mô hình này chưa thực sự phổ biến

• Cần thay đổi thường xuyên dẫn đến lặp vô hạn 

• Phức tạp, không phù hợp với những dự án nhỏ, ít rủi ro

• Tiêu tốn nhiều thời gian và chi phí cao để hoàn thành dự án 

• Manager cần có kỹ năng tốt để đánh giá rủi ro và quản lý dự án hiệu quả

5.7 Mô hình Scrum

Mô hình kiểm thử phần mềm Scrum sử dụng các tiếp cận lặp, tăng trưởng để tối ưu hóa tính khả đoán và kiểm soát rủi ro. Những khía cạnh quan trọng của tiến trình cần được hiển thị cụ thể, rõ ràng cho những người có trách nhiệm trong tiến trình đó.

Mô hình kiểm thử phần mềm Scrum

Mô hình Scrum chia các yêu cầu thành từng giai đoạn, mỗi giai đoạn gồm một số lượng nhất định yêu cầu và thường kéo dài từ 1 – 4 tuần (không quá 1 tháng). Đầu mỗi giai đoạn sẽ làm rõ những yêu cầu được thực hiện. Việc tiếp theo là code và test. 

Cuối giai đoạn là một sản phẩm hoàn thành cả code và test, có thể demo và chạy được. Khi hoàn thành giai đoạn 1 sẽ bắt đầu giai đoạn 2, giai đoạn 3, giai đoạn 4,… cho đến khi hoàn thành hết các yêu cầu đặt ra. 

Ba nhân tố quan trọng cấu thành nên Scrum gồm: tổ chức (Organization), tài liệu (Artifacts), quy trình (Process). Trong đó: Tổ chức: Tổ chức nhóm và roles, người sở hữu sản phẩm, người điều phối, nhóm phát triển. 

Tài liệu: Danh sách chức năng cần phát triển của sản phẩm, chức năng cần phát triển cho từng giai đoạn, kết quả ước lượng của nhóm. 

Quy trình: Hoạch định, tổng kết cho mỗi giai đoạn và nhận xét theo ngày. 

Ưu điểm:

• Có khả năng phát hiện lỗi sớm 

• Một người có thể đảm nhận nhiều việc 

• Phù hợp với dự án mà khách hàng không yêu cầu rõ ràng từ đầu

Nhược điểm:

• Yêu cầu nhóm có kỹ năng nhất định 

• Nhóm phải có sự hiểu biết về mô hình Agile

• Xác định thời gian và ngân sách gặp nhiều khó khăn 

• Kéo dài thời gian vì phải thực hiện theo yêu cầu của khách hàng 

• PO có vai trò quan trọng, nếu không làm tốt sẽ ảnh hưởng đến kết quả chung

5.8 Mô hình tăng trưởng

Mô hình tăng trưởng sẽ chia chu kỳ phát triển phần mềm thành các mô-đun nhỏ để dễ dàng quản lý. Đây là mô hình kiểm thử phần mềm mà mỗi mô-đun sẽ trải qua rất nhiều giai đoạn: phân tích yêu cầu, thiết kế, thực hiện và thử nghiệm, giống như vòng đời phát triển thông thường. 

Mô hình tăng trưởng

Mô hình tăng trưởng phù hợp với những dự án mà yêu cầu đã được mô tả rõ ràng và khách hàng có nhu cầu về sản phẩm sớm. Cũng giống như những mô hình kiểm thử phần mềm khác, mô hình tăng trưởng sở hữu nhiều ưu điểm nổi bật, tuy nhiên nó vẫn tồn tại một số hạn chế nhất định. 

Ưu điểm:

• Phát triển dễ dàng, nhanh chóng

• Kiểm tra và sửa lỗi đơn giản hơn 

• Linh hoạt, ít tốn kém khi thay đổi yêu cầu, phạm vi

Nhược điểm:

• Yêu cầu cao về lập plan và thiết kế

• Tổng chi phí của mô hình này cao hơn so với mô hình thác nước 

5.9 Mô hình RAD

Mô hình kiểm thử phần mềm RAD (Rapid Application Development) sử dụng quy hoạch tối thiểu, có lợi cho việc tạo mẫu nhanh. Để tạo ra và phân phối sản phẩm nhanh hơn, các mô-đun chức năng được phát triển song song và tích hợp.

Mô hình RAD (Rapid Application Development)

Khi áp dụng mô hình RAD, dự án có thể không thành công nếu nó không được chia thành các mô-đun. Nên sử dụng mô hình RAD khi có nhu cầu tạo hệ thống mà yêu cầu của khách hàng thay đổi trong khoảng thời gian ngắn (2 – 3 tháng), chi phí cao và có sẵn designer cho model.

Ưu điểm:

• Tiết kiệm thời gian phát triển 

• Đưa ra đánh giá ban đầu nhanh chóng

• Khuyến khích khách hàng đưa ra phản hồi

• Tăng khả năng tái sử dụng của các thành phần 

Nhược điểm:

• Nhóm thực hiện cần có kỹ năng nhất định 

• Mô hình này chỉ phù hợp với những hệ thống có mô-đun

✅ Dịch vụ thành lập công ty
⭕ ACC cung cấp dịch vụ thành lập công ty/ thành lập doanh nghiệp trọn vẹn chuyên nghiệp đến quý khách hàng toàn quốc

✅ Đăng ký giấy phép kinh doanh
⭐ Thủ tục bắt buộc phải thực hiện để cá nhân, tổ chức được phép tiến hành hoạt động kinh doanh của mình

✅ Dịch vụ ly hôn
⭕ Với nhiều năm kinh nghiệm trong lĩnh vực tư vấn ly hôn, chúng tôi tin tưởng rằng có thể hỗ trợ và giúp đỡ bạn

✅ Dịch vụ kế toán
⭐ Với trình độ chuyên môn rất cao về kế toán và thuế sẽ đảm bảo thực hiện báo cáo đúng quy định pháp luật

✅ Dịch vụ kiểm toán
⭕ Đảm bảo cung cấp chất lượng dịch vụ tốt và đưa ra những giải pháp cho doanh nghiệp để tối ưu hoạt động sản xuất kinh doanh hay các hoạt động khác

✅ Dịch vụ làm hộ chiếu
⭕ Giúp bạn rút ngắn thời gian nhận hộ chiếu, hỗ trợ khách hàng các dịch vụ liên quan và cam kết bảo mật thông tin