ISTQB-Kiểm thử trong suốt vòng đời phần mềm-Mục 2.1-Phần 2/2

Vòng đời phát triển lặp

Không phải tất cả các vòng đời đều tuần tự. Ngoài ra còn có các vòng đời lặp đi lặp lại hoặc tăng dần, thay vì một dòng thời gian phát triển từ đầu đến cuối, ta chuyển qua một số giai đoạn vòng đời khép kín nhỏ hơn cho cùng một dự án. Như với V-Model, có nhiều biến thể của vòng đời lặp.

Iterative development model

Đặc điểm chung của các phương pháp tiếp cận lặp là phần chuyển giao được chia thành các phần tăng thêm hoặc các bản với mỗi phần có thêm chức năng mới.

Phần gia tăng ban đầu sẽ chứa cơ sở hạ tầng cần thiết để hỗ trợ xây dựng chức năng ban đầu. Phần gia tăng được tạo ra bởi một lần lặp có thể được kiểm thử ở một số cấp độ như một phần của quá trình phát triển. Các bước tiếp theo sẽ cần kiểm thử chức năng mới, kiểm thử hồi quy chức năng hiện có và kiểm thử tích hợp các phần mới với phần hiện có.

Kiểm thử hồi quy ngày càng quan trọng đối với tất cả các lần lặp sau lần đầu tiên. Điều này có nghĩa là sẽ cần nhiều công việc kiểm thử hơn ở mỗi giai đoạn chuyển giao tiếp theo, điều này phải được cho phép trong các kế hoạch của dự án.

Vòng đời này có thể chuyển giao các chức năng quan trọng ra thị trường sớm, có thể dễ quản lý hơn vì khối lượng công việc được chia thành nhiều phần nhỏ hơn và có thể giảm chi phí đầu tư ban đầu mặc dù có thể tốn nhiều chi phí hơn trong thời gian dài.

Ngoài ra, sự hiện diện sớm trên thị trường sẽ có nghĩa là kiểm thử xác nhận được thực hiện ở mỗi bước gia tăng, do đó đưa ra phản hồi sớm về giá trị kinh doanh và tính phù hợp để sử dụng của sản phẩm.

Ví dụ về các mô hình phát triển lặp hoặc tăng dần là nguyên mẫu (prototyping), phát triển ứng dụng nhanh (Raid Application Development – RAD), Quy trình thống nhất hợp lý (Rational Unified Process – RUP) và phát triển nhanh gọn (Agile).

Với mục đích hiểu rõ hơn về các mô hình phát triển lặp và vai trò thay đổi của kiểm thử, một giải thích ngắn gọn về cả RAD và Agile được cung cấp.

Phát triển ứng dụng nhanh RAD

Phát triển ứng dụng nhanh (RAD) chính thức là sự phát triển song song các chức năng và tích hợp sau đó. Các thành phần/chức năng được phát triển song song như thể chúng là các dự án nhỏ, các phát triển được đóng gói theo thời gian, chuyển giao và sau đó được lắp ráp thành một nguyên mẫu hoạt động.

Điều này có thể rất nhanh chóng cung cấp cho khách hàng một cái gì đó để xem và sử dụng cũng như cung cấp phản hồi về việc chuyển giao và yêu cầu của họ.

Có thể thay đổi và phát triển sản phẩm nhanh chóng bằng cách sử dụng phương pháp luận này. Tuy nhiên, đặc điểm kỹ thuật sẽ cần được phát triển vào một thời điểm nào đó, và dự án sẽ cần phải kiểm soát một cách chính thức hơn trước khi đi vào sản xuất. Phương pháp luận này cho phép xác nhận sớm các rủi ro công nghệ và đáp ứng nhanh chóng các yêu cầu thay đổi của khách hàng.

RAD Model

Phương pháp phát triển hệ thống động [Dynamic System Development Methodology – DSDM] là một quy trình RAD đã được tinh chỉnh cho phép đưa ra các biện pháp kiểm soát để ngăn quá trình vượt ra khỏi tầm kiểm soát.

Hãy nhớ rằng vẫn cần thiết có việc thực hành phát triển tốt để các phương pháp này hoạt động. Cần duy trì quản lý cấu hình chặt chẽ đối với những thay đổi nhanh chóng đang được thực hiện trong một số chu kỳ phát triển song song.

Từ góc độ thử nghiệm, cần lập kế hoạch rất cẩn thận và cập nhật kế hoạch thường xuyên vì mọi thứ sẽ thay đổi rất nhanh (xem Chương 5 để biết thêm về kế hoạch kiểm thử).

Quy trình RAD khuyến khích phản hồi tích cực của khách hàng. Khách hàng có thể nhìn thấy sản phẩm sớm, có thể cung cấp phản hồi về thiết kế và có thể quyết định, dựa trên chức năng hiện có, có nên tiếp tục phát triển hay không, chức năng nào sẽ bao gồm trong phần chuyển giao tiếp theo hoặc thậm chí dừng dự án nếu không mang lại giá trị mong đợi.

Một giải pháp tập trung vào kinh doanh sớm trên thị trường mang lại lợi tức đầu tư (ROI) sớm và có thể cung cấp thông tin tiếp thị có giá trị cho doanh nghiệp. Do đó, xác nhận với quá trình phát triển RAD là một hoạt động sớm và chính.

Phát triển nhanh gọn (Agile)

Extreme Programming (XP) hiện là một trong những mô hình vòng đời phát triển nhanh nổi tiếng nhất. Phương pháp này được cho là thân thiện với con người hơn các phương pháp phát triển truyền thống.

Một số đặc điểm của XP là:

  • Nó thúc đẩy việc tạo ra các câu chuyện kinh doanh để xác định chức năng.
  • Nó yêu cầu một khách hàng trực tiếp để có phản hồi liên tục, xác định và thực hiện kiểm thử chấp nhận chức năng.
  • Nó thúc đẩy lập trình cặp (pair programming) và quyền sở hữu chia sẻ code giữa các nhà phát triển.
  • Nó tuyên bố rằng các kịch bản kiểm thử thành phần sẽ được viết trước khi lập trình và những bài kiểm thử đó phải được tự động hóa.
  • Nó nói rằng việc tích hợp và kiểm thử code sẽ diễn ra nhiều lần trong ngày.
  • Nó nói rằng luôn thực hiện giải pháp đơn giản nhất để đáp ứng các vấn đề ngày nay.

Với XP, có rất nhiều lần lặp yêu cầu kiểm thử. Các nhà phát triển XP viết mọi trường hợp kiểm thử mà họ có thể nghĩ ra và tự động hóa chúng.

Mỗi khi code thay đổi, nó sẽ được kiểm thử thành phần và sau đó được tích hợp với code hiện có, sau đó được kiểm thử tích hợp hoàn toàn bằng cách sử dụng toàn bộ các trường hợp kiểm thử.

Điều này cho phép tích hợp liên tục, theo đó có nghĩa là các thay đổi được kết hợp liên tục vào bản phần mềm được xây dựng. Đồng thời, tất cả các trường hợp kiểm thử phải chạy ở 100% nghĩa là tất cả các trường hợp kiểm thử đã được xác định và tự động hóa đều được thực thi và vượt qua.

XP không phải là việc thực hiện các hoạt động cực đoan trong quá trình phát triển, mà là thực hiện các hoạt động bổ sung giá trị gia tăng đã biết một cách cực đoan

Kiểm thử trong một mô hình vòng đời

Tóm lại, bất kỳ mô hình vòng đời nào đang được sử dụng, có một số đặc điểm của kiểm thử tốt:

  • Đối với mỗi hoạt động phát triển có một hoạt động kiểm thử tương ứng;
  • Mỗi cấp độ kiểm thử có các mục tiêu kiểm thử cụ thể cho cấp độ đó;
  • Việc phân tích và thiết kế các bài kiểm thử cho một mức độ kiểm thử nhất định nên bắt đầu trong quá trình phát triển hoạt động tương ứng;
  • Người kiểm thử nên tham gia vào việc xem xét tài liệu ngay khi có bản nháp trong quy trình phát triển.

Ở phần tiếp theo, chúng ta sẽ tìm hiểu về Các cấp độ kiểm thử.

Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.

Syllabus tải về Tại đây

Ezami

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *