[ISTQB]Chương 5: Test Management

1. Test Organization 

a, Test Organization and Independence

Hiệu quả của việc tìm kiếm các lỗi bởi kiểm thử và đánh giá có thể đc cải tiến bằng việc sửa dụng các Tester độc lập

Các lựa chọn:

- Không có Tester độc lập, Dev kiểm tra chính code của họ

- Tester độc lập bên trong Dev teams

- Group or teams kiểm tra độc lập bên trong tổ chức, báo cáo để quản lý dự án or quản lý sự thực hiện

- Testers độc lập từ tổ chức nghiệp vụ or cộng đồng người dùng

- Chuyên gia (specialists) kiểm tra độc lập cho các loại kiểm tra riêng như Usability Tester, Security Tester, Certification Tester

- Tester độc lập được thuê bên ngoài or bên trong của tổ chức

Lợi ích của sự độc lập

- Tester độc lập thấy được sự khác  biệt các lỗi và không thiên vị

- 1 Tester độc lập có thể xác thực giả thiết người làm trong đặc điểm kỹ thuật và sự thực thi của hệ thống

Hạn chế:

- Cô lập từ nhóm phát triển

- Dev mất đi cảm giác tương ứng về chất lượng

- Tester độc lập có thể như là 1 thắt nút cổ chai or đổ lỗi cho các sự chậm trễ trong khi phát hành

b, Task of the Test Leader and Tester

Test Leader còn được gọi là Test manager or Test coordinator (điều phối viên). Vai trò của Test Leader có thể được thực hiện bởi PM, Dev manager, QA manager or người quản lý của nhóm kiểm thử. Ở các dự án lớn  có thể tồn tại 2 vị trí: Test Leader or Test manager.

Leader task:

- Điều phối kế hoạch và chiến lược kiểm tra với PM or người khác

- Viết or đánh giá chiến lược kiểm thử cho dự án và chính sách kiểm thử cho tổ chức

- Đóng góp các quan điểm kiểm thử cho các hoạt động dự án khác, như là tích hợp kế hoạch

- Kế hoạch kiểm thử - xem xét bối cảnh và hiểu mục tiêu kiểm thử và rủi ro - bao gồm chọn các kiểm thử tiếp cận, ước tính thời gian, cố gắng và giá của kiểm thử, mua lại tài nguyên, định nghĩa các mức độ kiểm thử, các chu kỳ, kế hoạch quản lý biến cố.

- Bắt đầu đặc tả, chuẩn bị, thực thi và thực hiện kiểm thử, giám sát kết quả kiểm thử và kiểm tra tiêu chuẩn đầu ra

- Phỏng theo kế hoạch dựa trên kết quả kiểm thử và quy trình và lấy bất kỳ hoạt đông cần thiết để bù lại cho các vấn đề

- Thiết lập đầy đủ quản lý cấu hình của kiểm thử phần cho việc truy xuất nguồn gốc

- Giới thiệu các số liệu thích hợp cho việc đo lường quy trình kiểm thử và đánh giá chất lượng kiểm thử và sản phẩm

- Quyết định những gì nên tự động, trình độ gì và như thế nào

- Chọn các công cụ hỗ trợ kiểm thử và tổ chức đào tạo sử dụng công cụ cho Tester

- Quyết định về sự thực hiện của môi trường kiểm thử

- Viết báo cáo kiểm thử tổng quát dựa trên các thông tin tập hợp lại trong khi kiểm thử

Tester task:

- Đánh giá và góp phần cho kế hoạch kiểm thử

- Phân tích, đánh giá các yêu cầu người dùng, các đặc tả và mô hình có khả năng kiểm thử

- Tạo đặc tả kiểm thử

- Thiết lập môi trường kiểm thử

- Chuẩn bị và thu lại dữ liệu kiểm thử

- Thực thi các kiểm thử trên tất cả các mức độ, thực hiện và ghi log kiểm thử, đánh giá kết quả và ghi lại độ lệch của kết quả mong muốn

- Sử dụng các công cụ quản lý kiểm thử và giám sát như đã yêu cầu

- Automate tests

- Đo lương hiệu suất của thành phần và hệ thống

- Đánh giá các kiểm thử được phát triển bởi người khác

2. Test Planning and Estimation 

a, Test planning

Đề cương của tài liệu Test planning được bao phủ bởi "Standard for software test document" (IEEE Std 829-1998)

Test planning là 1 hoạt động liên tiếp và được thực hiện trong tất cả vòng đời quy trình và các hoạt động

Phản hồi từ các hoạt động kiểm thử đã từng sử dụng để nhìn nhận lại thay đổi của rủi ro vì vậy planning có thể được điều chỉnh.

b, Test planning activities 

Hoạt động cho 1 phần or toàn bộ hệ thống có thể bao gồm:

- Xác đinh phạm vi và các rủi ro và nhận định các mục tiêu của kiểm thử

- Định nghĩa các tiếp cận của kiểm thử, bao gồm định nghĩa các mức độ kiểm thử, tiêu chuẩn đầu vào và đầu ra

- Tích hợp và điều phối các hoạt động kiểm thử đến các hoạt động của vòng đời phần mềm

- Tạo các quyết định về những gì để kiểm thử, những vai trò gì sẽ thực hiện các hoạt động kiểm thử, các hoạt động kiểm thử như thế nào nên hoàn thành, kết quả kiểm thử như thế nào sẽ được đánh giá

- Lên lich phân tích kiểm thử và hoạt đông thiết kế

- Lên lịch thực hiện , đánh giá kiểm thử

- Phân công tài nguyên (resources) cho các hoạt động khác đươc định nghĩa

- Định nghĩa chi tiết số tiền, mức độ, cấu trúc và bản mẫu cho tài liệu kiểm thử

- Chọn số liệu cho giám sát và điều khiển chuẩn bị kiểm thử, thực hiện, vấn đề rủi ro và độ phân giải lỗi

- Thiết lập chi tiết các mức độ cho thủ tục kiểm thử trong thứ tự cung cấp đủ thông tin để hỗ trợ tái sản xuất sự chuẩn bị và thực hiện kiểm thử

c, Entry criteria

- Môi trường kiểm thử khả dụng và sẵn sàng

- Công cụ kiểm thử sẵn sàng trong môi trường kiểm thử

- Code khả dụng có thể kiểm thử

- Dữ liệu kiểm thử sẵn sàng

d, Exit criteria

- Các biện pháp triệt để như là bao phủ code, chức năng or rủi ro

- Giá

- Ước tính được mật độ lỗi or biện pháp tin cậy

- Rủi ro dư như các lỗi chưa fix or thiếu độ bao phủ kiểm thử trong 1 vùng nhất định

- Sắp xếp như những người dựa trên thời gian để thị trường

e, Test estimation 

Có 2 tiếp cận cho ước tính nỗ lực thử nghiệm:

- Cách tiếp cận dựa trên số liệu:

- Cách tiếp cận dựa trên chuyên gia: ước tính tasks dựa trên ước tính được làm bởi chủ các task đó or bởi chuyên gia

Nỗ lực thử nghiệm tùy theo số các yếu tố, bao gồm:

- Đặc điểm của sản phẩm: Chất lượng của đặc tả và thông tin khác được sử dụng để kiểm thử các mô hình, kích thước của sản phẩm, độ phức tạp của problem domain, các yêu cầu cho độ tin cậy và bảo mật và các yêu cầu cho tài liệu

- Đặc điểm của quá trình phát triển: Sự ổn định của tổ chức, tools test, test process, skills của người tham gia, áp lực thời gian

- Kết quả của thử nghiệm: Số lỗi và số tiền yêu cầu làm việc lại

f, Test strategy and test approach 

Test approach là sự thực hiện của Test strategy cho 1 dự án riêng

Test approach được định nghĩa và lọc trong test plan và test design 

Test approach là điểm bắt đầu cho kế hoạch test process, cho sự lựa chọn test design techniques và test type để ứng dụng và cho định nghĩ tiêu chuẩn đầu vào và đầu ra.

Lựa chọn tiếp cận tùy theo bối cảnh và có thể xem xét rủi ro, nguy hiểm và an toàn, tài nguyên sẵn sàng, skills, technology, bản chất của hệ thống, các mục tiêu và quy định thử nghiệm.

Approaches bao gồm:

- Analytical approaches (Phân tích tiếp cận), như là thử nghiệm dựa trên rủi ro

- Model-based approaches (Tiếp cận dựa trên mô hình)

- Methodical approaches (Phương pháp tiếp cận), như: failure-based, experience-based, checklist-based và chất lương characteristic-based 

- Process or standard-compliant approaches

- Dynamic and Heuristic approaches

- Consultative approaches  (Tư vấn tiếp cận,)

- Regression-averse approaches (Tiếp cận hồi tưởng ngược)

3. Test Progress Monitoring and Control 

a, Test Progress Monitoring 

Mục đích của Test monitoring là để cung cấp các phản hồi và khả thi về các hoạt động kiểm thử. Thông tin được giám sát có thể được thu thập tự động or thủ công và có thể sử dụng để đo tiêu chuẩn đầu ra như dộ bao phủ.
Common test metrics:
- Phần trăm công việc hoàn thành trong sự chuẩn bị test case
- Phần trăm công việc hoàn thành trong sự chuẩn bị môi trường test
- Thực thi test case
- Thông tin lối
- Thử nghiệm bao phủ các yêu cầu, rủi ro or code
- Niềm tin chủ quan của Tester trong sản phẩm
- Ngày tháng của các mốc kiểm thử
- Giá kiểm thử

b, Test Reporting

Test reporting liên quan với việc tóm tắt thông tin về nỗ lực kiểm thử, bao gồm:- Những gì đã xảy ra trong gia đoạn kiểm thử

- Phân tích thông tin và số liệu để hỗ trợ sự giới thiệu và quyết định về hoạt động tương lai, như đánh giá các lỗi còn lại, các rủi ro nổi bật, mức độ tự tin của phần mềm đã kiểm thử.

Dùng chuẩn "Standard for software test documentation" (IEEE std 829-1998)

Số liệu nên được thu thập trong khi và kết thúc 1 mức độ kiểm thử theo thứ tự để đánh giá:

- Đầy đủ các mục tiêu kiểm thử cho mức độ kiểm thử đó

- Đầy đủ kiểm thử tiếp cận 

- Hiệu quả của việc kiểm thử với sự tôn trọng các mục tiêu

c, Test Control

Ví dụ các hoạt động Test control, bao gồm:
- Tạo ra các quyết định dựa trên thông tin từ thử nghiệm giám sát
- Tái ưu tiên các thử nghiệm khi được nhận định rủi ro xảy ra

4. Configuration Management 

Mục đích là để thiết lập và bảo trì toàn vẹn sản phẩm, phần mềm, hệ thống qua vòng đời của dự án và sản phẩm
For testing:
- Tất cả các mục của phần mềm được nhận định, version controlled, theo dõi sự thay đổi, liên quan đến nhau và liên quan tới các mục phát triển vì vậy truy xuất nguồn gốc có thể được bảo trì khắp qui trình kiểm thử
- Tất cả các tài liệu được nhận định và các mục phần mềm được tham khảo rõ ràng trong tài liệu kiểm thử
For Tester:
- Giúp nhận định duy nhất Test items, test document

5. Risk and Testing

a, Project risk 

Organizational factors: (Yếu tố tổ chức)
- Skill, training và thiếu nhân viên
- Các vấn đề nhân viên
- Các vấn đề chính trị
- Thái độ không đúng cách or sự mong đợi  của testing
Technical issues: (Vấn đề kỹ thuật)
- Vấn đề trong việc định nghĩa đúng các yêu cầu
- Phạm vi các yêu cầu đó không thể đáp ứng được các hạn chế đang tồn tại
- Môi trường thử nghiệm không sẵn sàng đúng thời hạn
- Late data conversion, migration planing and development and testing data conversion/migration tools
- Design, code, cấu hình dữ liệu, test data chất lượng thấp
Supplier issues: (vấn đề nhà cung cấp)
- Failure of third party: Thất bại của bên thứ 3
- Contractual issues: Vấn đề về hợp đồng

b, Product risk 

Bao gồm:

- Phần mềm thất bại được đưa ra

- Tiềm năng mà phần mềm, phần cứng có thể là nguyên nhân làm hại đến cá nhân hay công ty

- Đặc điểm phần mềm kém

- Sự toàn vẹn và chất lượng dữ liệu kém

- Phần mềm không thể thực hiện được các chức năng dự định của nó.

Các rủi ro được sử dụng để quyết định bắt đầu testing ở đâu và test nhiều hơn ở đâu; 

6. Incident Management 

Mục tiêu của Incident report :

- Cung cấp người phát triển và các bên khác với phần hồi về vấn đề để cho phép nhận biết, cô lập và chỉnh sửa khi cần thiết

- Cung cấp Test leader để theo dõi chất lượng hệ thống và tiến độ của testing

- Cung cấp các ý tưởng để cải tiến qui trình test

Detail of incident report:

- Ngày phát hành, tổ chức phát hành và tác giả

- Kết quả thực tế và mong muốn

- Nhận biết các mục và môi trường kiểm thử

- Qui trình vòng đời của phần mềm or hệ thống, trong đó các sự cố đã được quan sát

- Miêu tả sự cố để cho phép tái sản xuất và độ phân giải, bao gồm logs

- Phạm vi or trình độ của các tác động người liên quan

- Tác động nghiêm trọng trên hệ thống

- Ưu tiên để sửa chữa

- Trạng thái của sự cố

- Kết luận, giới thiệu và phê duyệt

- Global issues (vấn đề toàn cầu)

- Change history

- References