Test Management

Quản lý kiểm thử

Trách nhiệm chính của người quản lý là bảo mật và sử dụng các tài nguyên (con người, phần mềm, phần cứng, v.v.) để thực hiện các quy trình gia tăng giá trị.

Đối với các nhà quản lý phần mềm và CNTT, các quy trình là một phần của dự án hoặc chương trình nhằm cung cấp phần mềm hoặc hệ thống để sử dụng nội bộ hoặc bên ngoài.

Đối với Người quản lý kiểm thử, các quy trình là những quy trình liên quan đến kiểm tra, cụ thể là các hoạt động của quy trình kiểm tra cơ bản được mô tả trong giáo trình Cấp cơ sở.

Do các quy trình kiểm tra chỉ tăng giá trị bằng cách đóng góp vào thành công chung của dự án hoặc chương trình (hoặc bằng cách ngăn chặn loại lỗi nghiêm trọng hơn), Quản lý kiểm trử phải lập kế hoạch và kiểm soát quy trình kiểm thử phù hợp.

Nói cách khác, viêc quản lý kiểm thử phải sắp xếp hợp lý các trường hợp kiểm thử các quy trình, bao gồm các hoạt động liên quan và các công việc, theo nhu cầu và hoàn cảnh của các bên liên quan khác, các hoạt động của họ (ví dụ: vòng đời phát triển phần mềm trong thử nghiệm khi xảy ra) và các sản phẩm công việc của họ (ví dụ: yêu cầu thông số kỹ thuật).

1, Hiểu biết về các bên liên quan đến kiểm thử

Các bên liên quan của quá trình kiểm thử khi họ quan tâm đến các hoạt động thử nghiệm, các sản phẩm công việc thử nghiệm hoặc chất lượng của hệ thống cuối cùng có thể giao cho khách hàng được.

Lợi ích của các bên liên quan có thể là sự tham gia trực tiếp hoặc gián tiếp vào các hoạt động thử nghiệm, nhận trực tiếp hoặc gián tiếp các sản phẩm công việc thử nghiệm hoặc ảnh hưởng trực tiếp hoặc gián tiếp đến chất lượng của sản phẩm do dự án hoặc chương trình tạo ra. Mặc dù các bên liên quan ở vị trí khác nhau, tùy thuộc vào dự án, sản phẩm, tổ chức và các yếu tố khác, họ có thể bao gồm các vai trò sau:

• Các nhà phát triển, lãnh đạo phát triển và quản lý phát triển. Các bên liên quan triển khai phần mềm đang thử nghiệm, nhận kết quả kiểm tra và thường phải hành động dựa trên các kết quả đó. (ví dụ: sửa lỗi được báo cáo).

• Kiến trúc sư cơ sở dữ liệu, kiến trúc sư hệ thống và nhà thiết kế. Các bên liên quan thiết kế phần mềm, nhận kết quả kiểm tra và thường phải hành động đối với các kết quả đó.

• Các nhà phân tích tiếp thị và kinh doanh. Các bên liên quan xác định các tính năng và mức độ chất lượng vốn có trong các tính năng đó, phải có trong phần mềm. Họ cũng thường tham gia vào việc xác định phạm vi kiểm tra cần thiết, xem xét kết quả kiểm tra và đưa ra quyết định dựa trên về kết quả kiểm tra.

• Quản lý cấp cao, quản lý sản phẩm và nhà tài trợ dự án. Các bên liên quan thường tham gia vào việc xác định phạm vi kiểm tra cần thiết, xem xét kết quả kiểm tra và đưa ra quyết định dựa trên về kết quả kiểm tra.

• Quản lý dự án. Các bên liên quan có trách nhiệm quản lý các dự án của họ để thành công, đòi hỏi phải cân bằng giữa chất lượng, tiến độ, tính năng và ưu tiên ngân sách. Họ thường mua các tài nguyên cần thiết cho các hoạt động kiểm tra và cộng tác với Trình quản lý kiểm tra trong kế hoạch kiểm soát và kiểm soát.

• Hỗ trợ kỹ thuật, hỗ trợ khách hàng và nhân viên trợ giúp. Các bên liên quan hỗ trợ người dùng và khách hàng hưởng lợi từ các tính năng và chất lượng của phần mềm được phân phối. Người dùng trực tiếp và gián tiếp. Các bên liên quan này sử dụng phần mềm trực tiếp (tức là, họ là người dùng cuối) hoặc nhận đầu ra hoặc dịch vụ do phần mềm sản xuất hoặc hỗ trợ.

Danh sách các bên liên quan này không đầy đủ. Người quản lý kiểm tra phải xác định các bên liên quan kiểm tra cụ thể cho dự án hoặc chương trình của họ.

Người quản lý kiểm tra cũng phải hiểu bản chất chính xác của mối quan hệ giữa các bên liên quan với kiểm tra và cách nhóm kiểm tra phục vụ nhu cầu của các bên liên quan.

Ngoài việc xác định các bên liên quan kiểm tra như được mô tả ở trên, Trình quản lý kiểm tra nên xác định các hoạt động vòng đời phát triển phần mềm khác và các sản phẩm công việc ảnh hưởng đến kiểm tra và / hoặc bị ảnh hưởng bởi kiểm tra.

Không có điều này, quá trình thử nghiệm có thể không đạt được hiệu quả tối ưu

2, Các hoạt động và vòng đời phát triển phần mềm

Vì kiểm thử phần mềm là đánh giá chất lượng của một hoặc nhiều sản phẩm công việc được sản xuất bên ngoài các hoạt động kiểm thử, nên nó thường tồn tại trong bối cảnh của một vòng đời phát triển phần mềm lớn hơn các hoạt động.

Người quản lý kiểm tra phải lập kế hoạch và hướng dẫn các hoạt động kiểm tra với sự hiểu biết về cách các hoạt động khác và các sản phẩm công việc của họ ảnh hưởng đến việc kiểm tra, như đã được thảo luận trong giáo trình Foundation Foundation và cách kiểm tra ảnh hưởng đến các hoạt động khác và các sản phẩm công việc của họ.

Ví dụ: trong các tổ chức sử dụng thực tiễn phát triển Agile, nhà phát triển thường thực hiện phát triển kiểm thử, tạo thử nghiệm đơn vị tự động và liên tục tích hợp mã (cùng với các thử nghiệm chomã đó) vào hệ thống quản lý cấu hình.

Trình quản lý kiểm tra nên làm việc với người quản lý phát triển để đảm bảo rằng người kiểm tra được tích hợp và liên kết với các hoạt động này.

Người kiểm thử có thể xem xét các bài kiểm tra đơn vị để đóng góp các đề xuất để tăng độ bao phủ và hiệu quả của các bài kiểm tra này và để hiểu sâu hơn về phần mềm và việc triển khai phần mềm.

Người kiểm tra có thể đánh giá các cách để tích hợp các kiểm tra tự động của riêng họ, đặc biệt là kiểm tra hồi quy chức năng, vào hệ thống quản lý cấu hình. Mặc dù mối quan hệ cụ thể giữa các hoạt động kiểm thử và các bên liên quan kiểm thử khác, hoạt động công việc trong vòng đời phát triển phần mềm và các sản phẩm công việc khác nhau tùy thuộc vào dự án, vòng đời phát triển phần mềm kiểm thử được liên kết chặt chẽ và liên quan đến các yếu tố sau:

• Yêu cầu kỹ thuật và quản lý. Người quản lý kiểm tra cần xem xét các yêu cầu trong quá trình xác định và ước tính nỗ lực kiểm tra, cũng như nhận thức được các thay đổi đối với các yêu cầu và thực hiện các hành động kiểm soát kiểm tra để điều chỉnh theo các thay đổi đó. Chuyên viên phân tích kiểm tra kỹ thuật và phân tích kiểm tra nên tham gia đánh giá yêu cầu.
• Quản lý dự án. Người quản lý kiểm tra, làm việc với Nhà phân tích kiểm tra và Nhà phân tích kiểm tra kỹ thuật, phải cung cấp lịch trình và yêu cầu tài nguyên cho Người quản lý dự án. Quản lý kiểm tra phải làm việc với quản lý dự án để hiểu các thay đổi trong kế hoạch dự án và thực hiện các hành động kiểm soát kiểm tra để điều chỉnh theo các thay đổi đó.
• Quản lý cấu hình, quản lý phát hành và quản lý thay đổi. Quản lý kiểm tra, làm việc với nhóm thử nghiệm, phải thiết lập các quy trình và cơ chế phân phối đối tượng thử nghiệm và nắm bắt các quy trình trong kế hoạch kiểm tra. Người quản lý kiểm tra có thể yêu cầu Nhà phân tích kiểm tra và Nhà phân tích kiểm tra kỹ thuật tạo các thử nghiệm xác minh bản dựng và để đảm bảo kiểm soát phiên bản trong khi thực hiện kiểm tra.
• Phát triển và bảo trì phần mềm. Người quản lý kiểm tra nên làm việc với Người quản lý phát triển để phối hợp phân phối các đối tượng thử nghiệm, bao gồm nội dung và ngày của mỗi lần phát hành thử nghiệm, cũng như tham gia quản lý lỗi
• Hỗ trợ kỹ thuật. Người quản lý kiểm tra nên làm việc với quản lý hỗ trợ kỹ thuật để đảm bảo cung cấp kết quả kiểm tra đúng cách trong quá trình đóng kiểm tra để những người tham gia hỗ trợ sản phẩm sau khi phát hành nhận thức được các lỗi và cách giải quyết đã biết. Ngoài ra, bài kiểm tra Người quản lý nên làm việc với quản lý hỗ trợ kỹ thuật để phân tích các lỗi sản xuất để thực hiện các cải tiến quy trình thử nghiệm.
• Sản xuất tài liệu kỹ thuật. quản lý kiểm tra nên làm việc với quản lý tài liệu kỹ thuật để đảm bảo cung cấp tài liệu để kiểm tra một cách kịp thời, cũng như quản lý các lỗi được tìm thấy trong các tài liệu đó
• Ngoài việc xác định các bên liên quan kiểm tra như được mô tả ở trên, quản lý kiểm tra phải xác định các hoạt động vòng đời phát triển phần mềm khác và các sản phẩm công việc ảnh hưởng đến kiểm tra và / hoặc bị ảnh hưởng bằng cách thử nghiệm. Nếu không, quá trình thử nghiệm sẽ không đạt được hiệu quả và hiệu quả tối ưu.

3. Sắp xếp các hoạt động kiểm thử và một vài vòng đời của các mô hình tiêu biểu

Kiểm thử phải là một phần không thể thiếu của dự án, bất kể các mô hình phát triển phần mềm được sử dụng. Điêu nay bao gôm:

• Các mô hình tuần tự, như mô hình thác nước, mô hình V và mô hình W.   Trong một mô hình tuần tự, tất cả các sản phẩm và hoạt động của công việc trong một giai đoạn nhất định (ví dụ: yêu cầu, thiết kế, thực hiện, thử nghiệm đơn vị, thử nghiệm tích hợp, thử nghiệm hệ thống và thử nghiệm chấp nhận) được hoàn thành trước khi giai đoạn tiếp theo bắt đầu. Lập kế hoạch kiểm thử, phân tích thử nghiệm, thiết kế thử nghiệm và thực hiện thử nghiệm tiến hành theo kiểu chồng chéo với lập kế hoạch dự án, phân tích yêu cầu / kinh doanh, thiết kế phần mềm và cơ sở dữ liệu và lập trình, với tính chất chính xác của sự chồng chéo tùy thuộc vào mức độ thử nghiệm.

• Các mô hình lặp hoặc tăng dần, như Phát triển ứng dụng nhanh (RAD) và Quy trình hợp nhất Rational (RUP).   Trong một mô hình lặp hoặc tăng dần, các tính năng được được triển khai được nhóm lại với nhau (ví dụ: theo mức độ ưu tiên hoặc rủi ro kinh doanh) và sau đó các giai đoạn dự án khác nhau, bao gồm các sản phẩm và hoạt động công việc của chúng, xảy ra cho từng nhóm tính năng. Các giai đoạn có thể được thực hiện theo tuần tự hoặc theo kiểu chồng chéo và chính các lần lặp có thể là tuần tự hoặc chồng chéo. Trong quá trình bắt đầu dự án, lập kế hoạch kiểm tra và phân tích thử nghiệm cấp cao xảy ra song song với lập kế hoạch dự án và phân tích yêu cầu / kinh doanh.

Lập kế hoạch kiểm tra chi tiết, phân tích kiểm tra, thiết kế kiểm tra và kiểm tra thực hiện xảy ra vào đầu mỗi lần lặp, theo kiểu chồng chéo.

Kiểm tra thực hiện thường liên quan đến các cấp độ kiểm tra chồng chéo. Mỗi cấp độ thử nghiệm bắt đầu càng sớm càng tốt và có thể tiếp tục sau đó, các cấp độ thử nghiệm cao hơn đã bắt đầu.

• Agile, chẳng hạn như SCRUM và Lập trình (XP). Đây là những vòng đời lặp đi lặp lại trong đó các vòng lặp rất ngắn (thường từ hai đến bốn tuần). Các sản phẩm công việc và hoạt động cho mỗi lần lặp được kết thúc trước khi lần lặp tiếp theo bắt đầu (nghĩa là, các lần lặp là tuần tự). Thử nghiệm tiến hành tương tự như các mô hình lặp, nhưng với mức độ chồng chéo cao hơn của các hoạt động thử nghiệm khác nhau với các hoạt động phát triển, bao gồm cả sự chồng chéo đáng kể của thử nghiệm thực hiện (ở các cấp độ khác nhau) với các hoạt động phát triển.   Tất cả các hoạt động trong một lần lặp, bao gồm các hoạt động kiểm tra, phải được hoàn thành trước khi lần lặp tiếp theo bắt đầu.

Trong một Agileproject, vai trò của Trình quản lý kiểm tra thường thay đổi từ vai trò quản lý trực tiếp sang vai trò cố vấn / thẩm quyền kỹ thuật

• Xoắn ốc. Trong mô hình xoắn ốc, các nguyên mẫu được sử dụng sớm trong dự án để xác nhận tính khả thi và thử nghiệm các quyết định thiết kế và triển khai, sử dụng mức độ ưu tiên kinh doanh và rủi ro kỹ thuật để chọn thứ tự thực hiện các thí nghiệm tạo mẫu. Các nguyên mẫu này được thử nghiệm để xác định các khía cạnh của các vấn đề kỹ thuật vẫn chưa được giải quyết. Khi các vấn đề kỹ thuật chính được giải quyết, dự án tiến hành theo mô hình tuần tự hoặc lặp lại.

Để căn chỉnh chính xác các hoạt động kiểm tra trong vòng đời, quản lý kiểm tra phải có hiểu biết chi tiết về các mô hình vòng đời được sử dụng trong tổ chức của họ. Ví dụ: trong mô hình V,

Quá trình thử nghiệm cơ bản ISTQB áp dụng cho cấp độ thử nghiệm hệ thống có thể căn chỉnh như sau:

• Các hoạt động lập kế hoạch kiểm thử hệ thống xảy ra đồng thời với lập kế hoạch dự án và kiểm soát kiểm tra tiếp tục cho đến khi hoàn thành kiểm tra và đóng hệ thống kiểm tra
• Các hoạt động phân tích và thiết kế thử nghiệm hệ thống xảy ra đồng thời với đặc tả yêu cầu, đặc tả thiết kế hệ thống và kiến trúc (cấp cao) và đặc tả thiết kế thành phần (cấp thấp)
• Các hoạt động triển khai kiểm tra hệ thống có thể bắt đầu trong quá trình thiết kế hệ thống, mặc dù phần lớn các hoạt động này thường xảy ra đồng thời với kiểm thử mã hóa và thành phần, với công việc thực hiện kiểm tra hệ thống thường kéo dài cho đến vài ngày trước khi bắt đầu thực hiện kiểm tra hệ thống.
• Các hoạt động thực hiện kiểm tra hệ thống bắt đầu khi tất cả các tiêu chí nhập kiểm tra hệ thống đều được đáp ứng (hoặc từ bỏ), điều này thường có nghĩa là ít nhất kiểm thử thành phần và thường kiểm tra tích hợp thành phần cũng hoàn tất. Thực hiện kiểm tra hệ thống tiếp tục cho đến khi các tiêu chí thoát kiểm tra hệ thống được đáp ứng.
• Đánh giá các tiêu chí thoát kiểm tra hệ thống và báo cáo kết quả kiểm tra hệ thống xảy ra trong suốt quá trình thực hiện kiểm tra hệ thống, nói chung với tần suất và mức độ khẩn cấp cao hơn khi tiếp cận thời hạn dự án.
• Các hoạt động đóng kiểm tra hệ thống xảy ra sau khi các tiêu chí thoát kiểm tra hệ thống được đáp ứng và thực hiện kiểm tra hệ thống được hoàn thành, mặc dù đôi khi chúng có thể bị trì hoãn cho đến khi kết thúc kiểm thử chấp nhận và tất cả các hoạt động của dự án kết thúc.
• Trong vòng đời lặp hoặc tăng dần, các nhiệm vụ tương tự phải được thực hiện nhưng thời gian và mức độ có thể khác nhau. Ví dụ, thay vì có thể thực hiện toàn bộ môi trường thử nghiệm khi bắt đầu dự án, có thể hiệu quả hơn khi chỉ thực hiện phần cần thiết cho lần lặp hiện tại. Với bất kỳ mô hình vòng đời lặp hoặc tăng dần nào, việc lập kế hoạch càng diễn ra xa hơn, càng đi xa hơn phạm vi của quá trình thử nghiệm cơ bản có thể mở rộng.

Ngoài các giai đoạn lập kế hoạch xảy ra cho từng dự án, việc thực hiện kiểm tra và báo cáo cũng có thể bị ảnh hưởng bởi vòng đời đang được sử dụng bởi nhóm.

Ví dụ, trong vòng đời lặp, có thể có hiệu quả để tạo báo cáo hoàn chỉnh và thực hiện các phiên đánh giá sau lặp trước khi bắt đầu lần lặp tiếp theo.

Bằng cách coi mỗi lần lặp là một dự án nhỏ, nhóm sẽ có cơ hội sửa và điều chỉnh dựa trên những gì xảy ra trong lần lặp trước.

Bởi vì các lần lặp có thể ngắn và thời gian bị hạn chế, nên có thể viết tắt thời gian và công sức dành cho báo cáo này và đánh giá, nhưng các nhiệm vụ nên được tiến hành như một cách để theo dõi tiến trình thử nghiệm tổng thể và xác định bất kỳ vấn đề nào càng nhanh càng tốt.

Các vấn đề về quy trình có kinh nghiệm trong một lần lặp có thể dễ dàng ảnh hưởng và thậm chí tái diễn trong lần lặp tiếp theo nếu không áp dụng các biện pháp khắc phục

Tùy thuộc vào nhu cầu của tổ chức, dự án và sản phẩm, các mức kiểm tra bổ sung ngoài các mức được xác định trong giáo trình Cấp cơ sở có thể được yêu cầu, chẳng hạn như:

• Kiểm thử tích hợp phần mềm-phần mềm
• Kiểm thử tích hợp hệ thống
• Kiểm tra tương tác tính năng
• Kiểm tra tích hợp sản phẩm của khách hàng

Mỗi cấp độ kiểm tra cần có các yếu tố sau được xác định rõ ràng:

• Mục tiêu thử nghiệm, với các mục tiêu có thể đạt được
• Phạm vi kiểm tra và các mục kiểm tra
• Cơ sở thử nghiệm, cùng với một phương tiện đo lường mức độ bao phủ của cơ sở đó (tức là, truy xuất nguồn gốc
• Tiêu chí xuất nhập cảnh Các sản phẩm tốt nhất, bao gồm báo cáo kết quả
• Các kỹ thuật kiểm tra áp dụng, cùng với cách đảm bảo mức độ bao phủ phù hợp bằng cách sử dụng các kỹ thuật đó
• Các phép đo và số liệu liên quan đến mục tiêu kiểm tra, tiêu chí xuất nhập cảnh và báo cáo kết quả (bao gồm các phép đo bảo hiểm)
• Các công cụ kiểm tra sẽ được áp dụng cho các nhiệm vụ kiểm tra cụ thể (nếu và nếu có)
• Tài nguyên (ví dụ: môi trường thử nghiệm)
• Các cá nhân và nhóm chịu trách nhiệm, cả trong và ngoài nhóm thử nghiệm
• Tuân thủ các tiêu chuẩn tổ chức, quy định hoặc các tiêu chuẩn khác (nếu và nếu có)

Như được thảo luận sau trong chương này, cách thực hành tốt nhất là xác định các yếu tố này một cách mạch lạc trong tất cả các cấp độ thử nghiệm để tránh các lỗ hổng lãng phí và nguy hiểm trên các cấp độ thử nghiệm tương tự khác nhau.

tài liệu tham khảo: (Advanced Level Syllabus Test Manager -version 2012)