Đã đăng vào thg 8 18, 2021 2:20 CH 33 phút đọc

291

Agile software development (Phần 3)

Bài đăng này đã không được cập nhật trong 3 năm

Có một số cách tiếp cận với Agile được các tổ chức sử dụng, nhưng phổ biến trên hầu hết là cộng tác tạo user story, retrospective, tích hợp liên tục (CI), và lập kế hoạch cho mỗi vòng lặp phát triển. Phần sau đây mô tả một số Phương pháp tiếp cận Agile.

1. Các phương pháp tiếp cận phát triển phần mềm Agile

Có một số cách tiếp cận Agile, mỗi cách tiếp cận đều thực hiện các giá trị và nguyên tắc của Tuyên ngôn Agile (Agile Manifesto) theo những cách khác nhau. Trong bài này, ba đại diện của các phương pháp tiếp cận Agile được xem xét: Extreme Programming (XP), Scrum và Kanban.

1.1. Extreme Programming

Extreme Programming, ban đầu được giới thiệu bởi Kent Beck, là một cách tiếp cận Agile để phát triển phần mềm được mô tả bằng các giá trị, nguyên tắc và ví dụ trong quá trình phát triển.

XP bao hàm năm giá trị để hướng dẫn team trong quá trình phát triển phần mềm gồm: giao tiếp, đơn giản, phản hồi, can đảm và tôn trọng.

XP mô tả một tập hợp các nguyên tắc dưới dạng các chỉ dẫn bổ sung là: nhân văn, kinh tế, cùng có lợi, tương tự, cải tiến, đa dạng, phản ánh, dòng chảy, cơ hội, dư thừa, thất bại, chất lượng, bước nhỏ, và nhận trách nhiệm

XP mô tả mười ba phương pháp chính là: ngồi cùng nhau, cả team, không gian làm việc nhiều thông tin, tràn đầy năng lượng công việc, pair programming, user story, chu kỳ hàng tuần, chu kỳ hàng quý, chậm, xây dựng mười phút, liên tục tích hợp, thử nghiệm lập trình đầu tiên và thiết kế gia tăng.

Nhiều phương pháp phát triển phần mềm Agile đang được sử dụng ngày nay bị ảnh hưởng bởi XP, các giá trị và các nguyên tắc của nó. Ví dụ, các nhóm Agile theo Scrum thường kết hợp các phương pháp XP.

1.2. Scrum

Scrum là một khuôn khổ để quản lý Agile chứa các công cụ và phương pháp sau:

Sprint: Scrum chia một dự án thành các sprint (được gọi là sprint) có độ dài cố định (thường là hai đến bốn tuần).
Sản phẩm phát triển: Mỗi sprint tạo ra một sản phẩm có khả năng release hoặc có thể chuyển nhượng.
Product Backlog: Chủ sở hữu sản phẩm quản lý danh sách ưu tiên các sản phẩm đã lên kế hoạch (gọi là product backlog). Sản phẩm tồn đọng phát triển từ sprint đến sprint (được gọi là công việc sàng lọc backlog).
Sprint Backlog: Khi bắt đầu mỗi sprint, team Scrum sẽ chọn một tập hợp các ưu tiên cao nhất các product (được gọi là sprint backlog) từ product backlog. Vì team Scrum (không phải chủ sở hữu sản phẩm) chọn các mục sẽ được thực hiện trong sprint, lựa chọn được gọi là dựa trên nguyên tắc kéo hơn là nguyên tắc đẩy.
Definition of Done (DoD): Để đảm bảo rằng có một sản phẩm tiềm năng có thể release được ở mỗi cuối sprint, team Scrum thảo luận và xác định các tiêu chí thích hợp để hoàn thành sprint. Các thảo luận giúp nhóm hiểu sâu hơn về các product backlog và sản phẩm các yêu cầu.
Hộp thời gian: Chỉ những task, yêu cầu hoặc tính năng mà nhóm dự kiến sẽ hoàn thành trong sprint là một phần của sprint backlog. Nếu nhóm phát triển không thể hoàn thành nhiệm vụ trong sprint, các tính năng sản phẩm liên quan bị xóa khỏi sprint và có nhiệm vụ được chuyển trở lại product backlog. Hộp thời gian không chỉ áp dụng cho các tác vụ mà còn trong các tình huống khác (ví dụ: thực thi thời gian bắt đầu và kết thúc cuộc họp).
Tính minh bạch: Team phát triển báo cáo và cập nhật trạng thái sprint hàng ngày tại một cuộc họp được gọi là daily meeting. Điều này làm cho nội dung và tiến trình của sprint hiện tại, bao gồm kết quả test, hiển thị cho nhóm, ban quản lý và tất cả các bên quan tâm. Ví dụ, nhóm phát triển có thể hiển thị trạng thái sprint trên bảng trắng.

Scrum xác định ba vai trò:

Scrum Master: đảm bảo rằng các quy tắc và thực hành trong Scrum được thực hiện, tuân thủ và giải quyết mọi vi phạm, các vấn đề về tài nguyên hoặc các vấn đề khác có thể ngăn chặn bằng cách tuân theo các thông lệ và quy tắc. Thành viên này không phải là trưởng nhóm mà như là một người hướng dẫn.
Chủ sở hữu sản phẩm (PO): đại diện cho khách hàng, tạo, duy trì và ưu tiên product backlog. Người này không phải là trưởng nhóm.
Nhóm phát triển: phát triển và thử nghiệm sản phẩm. Team tự tổ chức: Không có trưởng nhóm, vì vậy nhóm đưa ra quyết định. Nhóm cũng hoạt động đa chức năng. Scrum (trái ngược với XP) không quy định các kỹ thuật phát triển phần mềm cụ thể (ví dụ: TDD). Ngoài ra, Scrum không cung cấp hướng dẫn về cách thức test phải được thực hiện trong Dự án Scrum.

1.3. Kanban

Kanban là một cách tiếp cận quản lý đôi khi được sử dụng trong các dự án Agile. Mục tiêu chung là hình dung và tối ưu hóa luồng công việc trong một chuỗi giá trị gia tăng. Kanban sử dụng ba công cụ:

Bảng Kanban: Chuỗi task được quản lý bằng bảng Kanban. Mỗi cột sẽ chứa các task, ví dụ: cột development, hoặc cột testing. Các ticket sẽ di chuyển từ trái sang phải trên bảng thông qua các cột.
Giới hạn công việc đang chạy: Số lượng task bị giới hạn nghiêm ngặt. Điều này được kiểm soát bằng số lượng ticket tối đa được phép cho một cột. Bất cứ khi nào một cột còn chỗ trống, thành viên sẽ chuyển ticket từ cột trước sang cột sau.
Thời gian làm task: Kanban được sử dụng để tối ưu hóa luồng tác vụ liên tục bằng cách giảm thiểu thời gian chờ.

Kanban có một số điểm tương đồng với Scrum. Trong cả hai phương pháp, để thấy được các tác vụ đang hoạt động (ví dụ: dùng bảng trắng) cung cấp sự minh bạch về nội dung và tiến độ của các task. Task chưa được lên lịch đang chờ tồn đọng và chuyển lên bảng Kanban ngay khi có không gian mới (sản xuất công suất) có sẵn.

Lặp lại hoặc sprint là tùy chọn trong Kanban. Quy trình Kanban cho phép release sản phẩm có thể phân phối của nó, thay vì là một phần của release. Do đó, Timeboxing như một cơ chế đồng bộ hóa tùy chọn, không giống như trong Scrum, đồng bộ hóa tất cả các nhiệm vụ trong một sprint.

2. Collaborative User Story Creation

Tài liệu kỹ thuật ít ỏi thường là lý do chính dẫn đến thất bại của dự án. Các vấn đề về tài liệu kỹ thuật có thể do sự thiếu hiểu biết của người dùng về nhu cầu thực sự của họ, thiếu tầm nhìn chung về hệ thống, dư thừa hoặc các tính năng mâu thuẫn và thông tin sai lệch khác. Trong phát triển Agile, user story được viết để nắm bắt các yêu cầu từ quan điểm của nhà phát triển, tester và đại diện doanh nghiệp. Ở trong phát triển tuần tự, hiểu biết chung về một tính năng được hoàn thành thông qua các đánh giá chính thức sau các yêu cầu được viết ra; trong phát triển Agile, hiểu biêt chung này được thực hiện thông qua đánh giá không chính thức trong khi các yêu cầu đang được viết.

Các user story phải giải quyết cả các đặc điểm function và non-function. Mỗi user story bao gồm acceptance criteria cho các chức năng này. Các tiêu chí này cần được xác định với sự cộng tác giữa đại diện doanh nghiệp, nhà phát triển và tester. Họ cung cấp cho các nhà phát triển và tester một tầm nhìn mở rộng về tính năng mà đại diện doanh nghiệp sẽ xác nhận. Agile team xem xét một nhiệm vụ hoàn thành khi một tập hợp các tiêu chí chấp nhận đã được thỏa mãn.

Thông thường, quan điểm độc đáo của tester sẽ cải thiện user story bằng cách xác định các chi tiết còn thiếu hoặc những yêu cầu phi lý. Tester có thể đóng góp bằng cách yêu cầu đại diện doanh nghiệp trình bày về user story, đề xuất các cách để test user story và xác nhận sự chấp nhận tiêu chuẩn.

Người tạo ra user story có thể sử dụng các kỹ thuật như brainstorming và mind map. Tester có thể sử dụng kỹ thuật INVEST:

Độc lập
Có thể thương lượng
Có ích
Có thể ước tính
Đủ nhỏ
Có thể test

Theo khái niệm 3C concept, user story là sự kết hợp của ba yếu tố:

Thẻ: Thẻ là phương tiện vật lý mô tả user story. Nó xác định yêu cầu, mức độ quan trọng, sự phát triển dự kiến và thời lượng test cũng như tiêu chí chấp nhận cho user story đó. Mô tả phải chính xác, vì nó sẽ được sử dụng trong phần product backlog
Trao đổi công việc: Cuộc trò chuyện giải thích cách phần mềm sẽ được sử dụng. Cuộc trò chuyện có thể được lập thành văn bản hoặc bằng lời nói. Tester, có quan điểm khác với nhà phát triển và đại diện doanh nghiệp, mang lại thông tin đóng góp có giá trị cho việc trao đổi, ý kiến và kinh nghiệm. Cuộc trò chuyện bắt đầu trong giai đoạn lập release planning và tiếp tục khi user story được lên lịch.
Xác nhận: Các tiêu chí chấp nhận, được thảo luận trong cuộc trò chuyện, được sử dụng để xác nhận rằng user story đã xong. Các tiêu chí chấp nhận này có thể bao gồm nhiều user story. Cả positive và negative test nên được sử dụng để bao quát các tiêu chí. Trong quá trình xác nhận, nhiều người tham gia đóng vai trò của một tester. Những người này có thể bao gồm các nhà phát triển cũng như các chuyên gia tập trung vào hiệu suất, bảo mật, khả năng tương tác và các đặc điểm chất lượng khác. Để xác nhận một user story với tư cách là được thực hiện, các tiêu chí chấp nhận đã xác định cần được test và cho thấy là thỏa mãn.

Các nhóm Agile có những cách khác nhau để họ tạo ra các user story. Bất kể cách nào để tài liệu về user story thì tài liệu phải ngắn gọn, đầy đủ và cần thiết.

3. Retrospectives

Trong phát triển Agile, retrospective là một cuộc họp được tổ chức vào cuối mỗi sprint để thảo luận về những gì đã thành công, những gì có thể được cải thiện và kết hợp các cải tiến và duy trì sự thành công trong các sprint trong tương lai. Retrospective bao gồm các chủ đề như quy trình, con người, tổ chức, các mối quan hệ và các công cụ. Thường xuyên tiến hành các cuộc họp tổng kết, khi cần theo dõi các hoạt động rất quan trọng đối với việc tự tổ chức và cải tiến liên tục quá trình phát triển và thử nghiệm.

Việc xem xét lại có thể dẫn đến các quyết định cải tiến liên quan đến test tập trung vào hiệu quả test, test năng suất, chất lượng trường hợp thử nghiệm và sự hài lòng của team. Họ cũng có thể đề cập đến khả năng test của ứng dụng, user story, tính năng hoặc giao diện hệ thống. Phân tích nguyên nhân gốc rễ của các lỗi có thể thúc đẩy cải tiến thử nghiệm và phát triển. Nói chung, các team chỉ nên triển khai một số cải tiến mỗi sprint. Điều này cho phép cải tiến liên tục với độ bền vững cao.

Thời gian và cách thức tổ chức retrospective phụ thuộc vào phương pháp Agile cụ thể được áp dụng. Đại diện doanh nghiệp và nhóm tham dự mỗi cuộc retrospective với tư cách là người tham gia trong khi người điều hành tổ chức và điều hành cuộc họp. Trong một số trường hợp, các team có thể mời những người tham gia khác vào cùng. Tester nên đóng một vai trò quan trọng trong quá trình retrospective. Tester là một phần của team và mang quan điểm riêng của họ. Kiểm tra trong mỗi sprint và góp phần quan trọng vào thành công của sprint. Tất cả các thành viên trong nhóm, tester và người không test, có thể cung cấp thông tin đầu vào cho cả hai test case và các hoạt động non-test.

Việc điều tra phải xảy ra trong mỗi môi trường chuyên nghiệp được đặc trưng bởi sự tin tưởng lẫn nhau. Các thuộc tính của một retrospective thành công cũng giống như các thuộc tính của bất kỳ cuộc họp đánh giá nào khác

4. Tích hợp liên tục (CI)

Việc phân phối sản phẩm phần mềm hoạt động được và tin cậy ở cuối mỗi sprint. Tích hợp liên tục giải quyết thách thức này bằng cách hợp nhất tất cả các thay đổi được thực hiện đối với phần mềm và tích hợp tất cả các thành phần đã thay đổi thường xuyên, ít nhất một lần một ngày. Quản lý cấu hình, biên dịch, xây dựng, triển khai và thử nghiệm phần mềm được gói gọn thành một công việc duy nhất, tự động, có thể lặp lại quá trình. Vì các nhà phát triển tích hợp công việc của họ liên tục, tích hợp liên tục và test liên tục, lỗi trong mã được phát hiện nhanh hơn.

Sau quá trình viết mã, gỡ lỗi và đăng ký mã của nhà phát triển vào mã nguồn được chia sẻ kho lưu trữ, một quá trình tích hợp liên tục bao gồm các hoạt động tự động sau:

Phân tích code tĩnh: thực hiện phân tích mã tĩnh và báo cáo kết quả
Biên dịch: biên dịch và liên kết mã, tạo các tệp thực thi
Unit test: thực hiện unit test, check code coverage và báo cáo kết quả
Triển khai: cài đặt bản dựng vào môi trường thử nghiệm
Kiểm tra tích hợp: thực hiện test tích hợp và báo cáo kết quả
Báo cáo (dashboard): đăng trạng thái của tất cả các hoạt động này lên một vị trí hiển thị công khai hoặc gửi emai cho nhóm

Quá trình xây dựng và automation test diễn ra hàng ngày và phát hiện sớm các lỗi tích hợp và nhanh lên. Tích hợp liên tục cho phép tester Agile chạy các automation test thường xuyên, trong một số các trường hợp như một phần của chính quá trình tích hợp liên tục và gửi phản hồi nhanh cho nhóm về chất lượng của mã. Các kết quả test này được hiển thị cho tất cả các thành viên trong nhóm, đặc biệt là khi tự động báo cáo được tích hợp vào quy trình. Kiểm tra hồi quy tự động có thể liên tục trong suốt sự lặp lại. Kiểm tra hồi quy tự động tốt là nhiều chức năng nhất có thể chạy, bao gồm cả người dùng những user story được phân phối trong các lần lặp trước. Mức độ phù hợp tốt trong các bài test hồi quy tự động sẽ giúp hỗ trợ xây dựng (và thử nghiệm) các hệ thống tích hợp lớn. Khi test hồi quy được tự động hóa, Tester Agile được tự do để tập trung thử nghiệm thủ công của họ vào các tính năng mới, các thay đổi đã triển khai, và test xác nhận các bản sửa lỗi.

Ngoài các automation test, các công ty sử dụng CI thường sử dụng các công cụ build để thực hiện kiểm soát chất lượng liên tục. Ngoài việc chạy các unit test và integration test, các công cụ có thể chạy các test case, đo lường và lập hồ sơ hiệu suất, trích xuất và định dạng tài liệu từ mã nguồn và tạo điều kiện cho các quy trình đảm bảo chất lượng thủ công. Liên tục kiểm soát chất lượng nhằm mục đích nâng cao chất lượng của sản phẩm cũng như giảm thời gian cần thiết để release nó bằng cách thay thế việc làm truyền thống là áp dụng kiểm soát chất lượng sau hoàn thành quá trình phát triển.

Các công cụ build có thể được liên kết với các công cụ triển khai tự động, có thể tìm nạp bản dựng thích hợp từ tích hợp liên tục hoặc xây dựng máy chủ và triển khai nó thành một hoặc nhiều phát triển, thử nghiệm, dàn dựng hoặc ngay cả các môi trường phát triển. Điều này làm giảm các lỗi và sự chậm trễ liên quan đến việc dựa vào thành viên hoặc lập trình viên chuyên biệt để cài đặt các release trong các môi trường này.

Tích hợp liên tục có thể mang lại những lợi ích sau:

Cho phép phát hiện sớm hơn và dễ dàng phân tích nguyên nhân gốc rễ của các vấn đề tích hợp và xung đột thay đổi
Cung cấp cho nhóm phát triển phản hồi thường xuyên về việc mã có hoạt động hay không
Giữ phiên bản của phần mềm đang được thử nghiệm trong vòng một ngày kể từ ngày phiên bản được phát triển
Giảm rủi ro hồi quy liên quan đến việc tái cấu trúc mã của nhà phát triển do thử nghiệm lại nhanh chóng cơ sở mã sau mỗi tập hợp thay đổi nhỏ
Cung cấp niềm tin rằng công việc phát triển mỗi ngày dựa trên một nền tảng vững chắc
Làm cho tiến trình hoàn thành sản phẩm tăng lên trông thấy, đáng khích lệ nhà phát triển và tester
Loại bỏ rủi ro lịch trình liên quan đến tích hợp big-bang
Cung cấp tính khả dụng liên tục của phần mềm thực thi trong suốt sprint để thử nghiệm, mục đích trình diễn hoặc giáo dục
Giảm các hoạt động test thủ công lặp đi lặp lại
Cung cấp phản hồi nhanh chóng về các quyết định được đưa ra để cải thiện chất lượng và thử nghiệm

Tuy nhiên, tích hợp liên tục không phải là không có rủi ro và thách thức:

Các công cụ tích hợp liên tục phải được nâng cấp và bảo trì
Quá trình tích hợp liên tục phải được thiết lập
Tự động hóa test yêu cầu thêm tài nguyên hệ thống và có thể rất phức tạp để thiết lập
Phạm vi test là điều cần thiết để có được lợi thế khi test tự động
Các team đôi khi phụ thuộc quá mức vào các unit test và thực hiện quá ít test hệ thống và acceptance test

Tích hợp liên tục yêu cầu sử dụng các công cụ, bao gồm các công cụ để test, các công cụ để tự động hóa xây dựng quy trình và các công cụ để kiểm soát phiên bản.

5. Release planning và vòng lặp

Như đã đề cập, lập kế hoạch là một hoạt động đang diễn ra và đây cũng là việc làm trong các vòng đời Agile. Đối với các vòng đời Agile, có hai loại lập kế hoạch xảy ra, release planning và sprint planning.

Release planning xem xét trước khi phát hành một sản phẩm, thường là một vài tháng trước khi bắt đầu dự án. Release planning xác định và xác định lại sản phẩm tồn đọng và có thể liên quan đến việc tinh chỉnh lớn hơn user story thành một bộ sưu tập các user story nhỏ hơn. Release planning cung cấp cơ sở cho một phương pháp test tiếp cận và kế hoạch kiểm tra cho tất cả các sprint. Các release planning là cấp cao.

Trong khi lập release planning, đại diện doanh nghiệp thiết lập và ưu tiên các user story cho release, phối hợp với team. Dựa trên những user story, dự án và chất lượng rủi ro được xác định và ước tính nỗ lực cấp cao được thực hiện.

Tester tham gia vào việc lập release planning và đặc biệt là gia tăng giá trị trong các hoạt động sau:

Xác định user story có thể kiểm tra, bao gồm tiêu chí chấp nhận
Tham gia vào các phân tích rủi ro chất lượng và dự án
Ước tính nỗ lực thử nghiệm liên quan đến user story
Xác định các cấp độ kiểm tra cần thiết
Lập kế hoạch thử nghiệm cho release

Sau khi lập release planning được thực hiện, lập sprint planning cho lần đầu tiên được bắt đầu. Lập sprint planning có vẻ trước khi kết thúc một lần lặp và quan tâm đến tồn đọng của lần lặp.

Trong lập sprint planning, team sẽ chọn các user story từ tồn đọng release được ưu tiên, xây dựng user story, thực hiện phân tích rủi ro cho user story và ước tính công việc cần thiết cho mỗi người dùng user story. Nếu một user story quá mơ hồ và nỗ lực làm rõ nó không thành công, nhóm có thể từ chối chấp nhận nó và sử dụng user story tiếp theo dựa trên mức độ ưu tiên. Các đại diện doanh nghiệp phải trả lời các câu hỏi về mỗi user story để nhóm có thể hiểu những gì họ nên triển khai và cách kiểm tra mỗi user story.

Số lượng user story được chọn dựa trên tốc độ nhóm đã thiết lập và quy mô ước tính của những user story đã chọn. Sau khi nội dung của mỗi sprint được hoàn thiện, các user story được chia thành các nhiệm vụ sẽ được thực hiện bởi các thành viên trong nhóm thích hợp.

Tester tham gia vào việc lập sprint planning và đặc biệt là gia tăng giá trị trong các hoạt động sau:

Tham gia vào quá trình phân tích rủi ro chi tiết về các user story
Xác định khả năng kiểm tra của các user story
Tạo các acceptance test cho các user story
Chia nhỏ user story thành các tác vụ (đặc biệt là các tác vụ thử nghiệm)
Ước tính nỗ lực thử nghiệm cho tất cả các nhiệm vụ thử nghiệm
Xác định các khía cạnh function và non-function của hệ thống được kiểm tra
Hỗ trợ và tham gia tự động hóa thử nghiệm ở nhiều cấp độ thử nghiệm

Các release planning có thể thay đổi khi dự án tiếp tục, bao gồm các thay đổi đối với từng user story trong tồn đọng sản phẩm. Những thay đổi này có thể được kích hoạt bởi các yếu tố bên trong hoặc bên ngoài. Các yếu tố nội bộ bao gồm khả năng phân phối, tốc độ và các vấn đề kỹ thuật. Các yếu tố bên ngoài bao gồm việc phát hiện ra thị trường và cơ hội mới, đối thủ cạnh tranh mới hoặc các mối đe dọa kinh doanh có thể thay đổi việc phát hành mục tiêu và / hoặc ngày mục tiêu. Ngoài ra, planning lặp lại có thể thay đổi trong một sprint. Vì ví dụ, một user story cụ thể được coi là tương đối đơn giản trong quá trình ước tính có thể chứng minh phức tạp hơn mong đợi.

Những thay đổi này có thể gây khó khăn cho tester. Tester phải hiểu được bức tranh toàn cảnh về việc phát hành cho mục đích lập kế hoạch thử nghiệm và họ phải có cơ sở thử nghiệm đầy đủ và lời tiên tri kiểm tra trong mỗi sprint cho các mục đích phát triển test case. Thông tin bắt buộc phải có sẵn sàng cho tester từ sớm, nhưng phải thay đổi được chấp nhận theo các nguyên tắc Agile. Tình huống tiến thoái lưỡng nan này đòi hỏi những quyết định cẩn thận về các chiến lược kiểm tra và tài liệu test.

Release planning và sprint cần giải quyết việc lập kế hoạch kiểm tra cũng như lập kế hoạch phát triển các hoạt động. Các vấn đề liên quan đến thử nghiệm cụ thể cần giải quyết bao gồm:

Phạm vi thử nghiệm, mức độ thử nghiệm cho các lĩnh vực đó trong phạm vi, các mục tiêu thử nghiệm và lý do cho những quyết định này.
Các thành viên trong nhóm sẽ thực hiện các hoạt động thử nghiệm.
Môi trường thử nghiệm và dữ liệu thử nghiệm cần thiết, khi nào chúng cần thiết và có bất kỳ bổ sung nào không hoặc các thay đổi đối với môi trường thử nghiệm và dữ liệu sẽ xảy ra trước hoặc trong dự án.
Thời gian, trình tự, phụ thuộc và điều kiện tiên quyết cho function và non-function hoạt động kiểm tra (ví dụ: tần suất chạy kiểm tra hồi quy, tính năng nào phụ thuộc vào các tính năng hoặc dữ liệu thử nghiệm, v.v.), bao gồm cách các hoạt động thử nghiệm liên quan và phụ thuộc vào hoạt động phát triển.
Các rủi ro về chất lượng và dự án cần giải quyết.

Ngoài ra, nỗ lực ước tính của nhóm lớn hơn nên bao gồm việc xem xét thời gian và nỗ lực cần thiết để hoàn thành các hoạt động thử nghiệm được yêu cầu.

Tham khảo