Dịch và nghiên cứu ISTQB- chương 5(phần cuối)

4.Cấu hình quản lí:

a. Việc kiểm tra là rất quan trọng, bạn biết những gì mình thử nghiệm với những vật liệu nào, trong môi trường ra sao. Mục đích của quản lí cấu hình là là thiết lập và duy trì tính toàn vẹn của sản phẩm (linh kiện, số liệu, tài liệu) của phần mềm hay hệ thống thông qua chu trình dự án và tuổi thọ sản phẩm.

• Để thử nghiệm, quản lý cấu hình có liên quan đến việc đảm bảo rằng:

• Tất cả các mục của testware được xác định, phiên bản kiểm soát, theo dõi các thay đổi liên quan đến nhau và liên quan đến các mặt hàng phát triển (đối tượng thử nghiệm) để truy xuất nguồn gốc có thể được duy trì trong suốt quá trình thử nghiệm.

• Tất cả các tài liệu xác định và các phần mềm không được tham chiếu rõ ràng trong tài liệu hướng dẫn kiểm tra.

• Đối với các máy đo, quản lý cấu hình giúp xác định duy nhất (và để tái tạo) các mục kiểm tra, tài liệu kiểm tra, thử nghiệm và khai thác thử nghiệm.

• Trong kế hoạch kiểm tra, thủ tục quản lý cấu hình và cơ sở hạ tầng (công cụ) nên được lựa chọn, ghi và thực hiện

b. Theo chuẩn IEEE có định nghĩa về cấu hình quản lí như sau:

Quản lý cấu hình thiết lập và duy trì tính toàn vẹn của sản phẩm được kiểm tra.

• Xác định và xác định các mục cấu hình trong một hệ thống và mối quan hệ của họ (tài liệu và tập tin tên, phiên bản số, cấu trúc thư viện, cơ sở / lập kế hoạch phát hành)

• Kiểm soát sự thay đổi và phát hành của các sản phẩm này trong suốt thời gian hệ thống (điều khiển phiên bản)

Ghi chép và báo cáo trạng thái các mục cấu hình và yêu cầu thay đổi (truy xuất nguồn gốc, phân tích tác động, cơ sở dữ liệu trạng thái, các truy vấn và báo cáo )

• Kiểm toán, nghĩa là xác minh tính đầy đủ và tính đúng đắn của các mục cấu hình (kiểm soát với những gì đã được xây dựng, thử nghiệm và chuyển giao)

c. Một số nguyên tắc CM( cấu hình quản lí)

• Mọi thứ được một định danh duy nhất (test cases, testware, tài liệu, hệ thống)

• Phiên bản số(Version numbering)

•Kiểm soát phiên bản(Version control)

• Truy xuất nguồn gốc

• Kiểm tra trong các phiên bản chính thức (kiểm soát, kiểm tra, kiểm tra hồi quy)

• ghi chép check-in

• Check-out khi một cái gì đó phải được thay đổi

• Sao lưu các phiên bản cũ

5.Rủi ro và kiểm tra

• Mỗi một hệ thống hay sản phẩm nào cũng đều có rủi ro của riêng nó. Rủi ro có thể được định nghĩa là sự nguy hiểm, đe dọa hoặc tình huống xảy ra và hậu quả không mong muốn của nó.
• Mức độ rủi ro sẽ được quyết định bởi khả năng của một sự kiện bất lợi xảy ra và tác động (tác hại do sự kiện đó).
• Có 2 loại chính:

• Rủi ro dự án
• Rủi ro sản phẩm

a. Rủi ro dự án( Project risks)

Sơ đồ tổng quan quy trình quản lí rủi ro:

Rủi ro dự án là những rủi ro xung quanh khả năng của dự án để cung cấp các mục tiêu của nó, gồm có:

• Rủi ro về vấn đề cung cấp:

  • Ngân sách/nguồn tài trợ cho dự án
  • Thời gian thực hiện dự án
  • Thay đổi về phạm vi và yêu cầu của dự án

• Rủi ro về yếu tố tổ chức:

  • Kỹ năng và thiếu nhân lực:

    ・tester non trẻ, thiếu kinh nghiệm, chưa có độ nhạy bén trong công việc

    ・Thiếu nhân lực ngay từ đầu dự án hoặc trong quá trình thử nghiệm dự án( nhiều dự án chay song song không điều động được người kịp thơi,nghỉ đột xuất...)

  • Vấn đề cá nhân và đào tạo

  • Các vấn đề chính trị, pháp luật

• Rủi ro về các vấn đề kỹ thuật:

  • Vấn đề trong việc xác định các yêu cầu đúng
  • Mức độ mà các yêu cầu có thể được gặp gỡ cho những hạn chế hiện tại
  • Chất lượng của sản phẩm

b. Rủi ro về sản phẩm:

Thất bại tiềm năng trong phần mềm hay hệ thông được gọi là rủi ro sản phẩm, gồm có:

• Phần mềm dễ bị lỗi chuyển giao
• Đặc điểm phần mềm nghèo nàn( ví dụ chức năng, độ bảo mật, độ tin cậy... không cao)
• Phần mềm không thực hiện chức năng dự định của mình
• Tiềm năng mà các phần mềm có thể gây ảnh hưởng xấu đến cá nhân hoặc công ty

Chính vì vậy mà quá trình thử nghiệm làm giảm tối đa ảnh hưởng xấu xảy ra. Các cách tiếp cận rủi ro để thử nghiệm nhằm giảm mức độ rủi ro, các rủi ro được xác định có thể được sử dụng:

• Xác định các kỹ thuật kiểm tra được thực hiện
• Xác định mức độ thử nghiệm được tiến hành
• Ưu tiên thử nghiệm để tìm ra lỗi quan trọng càng sớm càng tốt

Để đảm bảo rằng các lỗi của sản phẩm được giảm thiểu, các hoạt động quản lý rủi ro phải có phương pháp chặt chẽ, tuân theo các mục:

• Đánh giá một các thường xuyên những rủi ro có thể xảy ra
• Xác định những rủi ro nào là quan trọng cần giải quyết
• Thực hiện các hành động để giải quyết những rủi ro đó

6.Vấn đề / Xử lý sự cố

• Có thể dễ dàng hình dung tiến trình của vấn đề qua mô hình:

Khi phát sinh vấn đề thì đầu tiên sẽ là việc nhận thức vấn đề đó-> giải quyết vấn đề-> thực hiện sửa chữa vấn đề-> Tiến hành thử nghiệm, theo dõi trong quá trình hệ thống hoạt động xem vẫn đề đã được giải quyết triệt để hay chưa.

• Quy trịnh trạng thái sử lí vấn đề:

Khi có vấn đề mới phát sinh thì sẽ xem xét kiểm tra vấn đề đó:

• Nếu thực chất k phải là vấn đề thì sẽ reject
• Nếu là vấn đề thì sẽ vừa theo dõi vừa phân tích vấn đề => Sau khi phân tích vấn đề đề ra hướng giải quyết thì sẽ điều chỉnh rồi tiến hành thử nghiệm lại-> nếu k có vấn đề gì phát sinh thì vấn đề được giải quyết, nếu vẫn xảy ra lỗi thì lại quay vòng lại quá trình phân tích lại.

• Mục đích của việc báo cáo sự cố:

  • Cung cấp cho các nhà phát triển với các thông tin phản hồi về vấn đề để có phương hướng điều chỉnh cần thiết
  • Cung cấp cho bộ phận kiểm tra một phương tiện để theo dõi chất lượng của hệ thống
  • Cung cấp những ý tưởng để cải thiện quá trình thử nghiệm.

• Một thử nghiệm hoặc người nhận xét thường ghi lại các thông tin iên quan đến một sự cố:

  • Ngày phát hành, phát hành tổ chức, tác giả, phê duyệt và tình trạng.
  • Phạm vi, mức độ nghiêm trọng và ưu tiên của vụ việc.