Kiểm thử phần mềm: Quản lý kiểm thử (Phần 2)

Tiếp tục series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Để tiếp nối nội dung từ bài viết Kiểm thử phần mềm: Quản lý kiểm thử (Phần 1) , trong bài viết lần này, mình sẽ giới thiệu cách quản lý rủi ro, sự cố trong quá trình kiểm thử phần mềm.

3. Giám sát và kiểm soát

3.1 Giám sát tiến độ của hoạt động kiểm thử

Các kế hoạch đã được phát triển, các chiến lược và cách tiếp cận đã được xác định và ước tính các công việc phải làm, bây giờ phải giám sát công việc kiểm thử khi thực hiện dự án.
Giám sát kiểm thử có thể phục vụ các mục đích khác nhau trong suốt dự án, bao gồm:
Cung cấp cho nhóm kiểm thử và quản lý kiểm thử những phản hồi về cách kiểm thử làm việc như thế nào, chấp nhận cơ hội để hướng dẫn và cải tiến kiểm thử và dự án.
Cung cấp cho nhóm dự án tầm nhìn về kết quả kiểm thử.
Đo lường tình trạng kiểm thử, độ bao phủ của việc kiểm thử và các mục kiểm thử so sánh với các tiêu chuẩn dừng để xem xét các công việc kiểm thử đã được thực hiện hay chưa.
Thu thập dữ liệu để sử dụng trong việc ước lượng các động lực kiểm thử trong tương lai.
Đặc biệt với các dự án nhỏ, các test leader hoặc những người được ủy quyền có thể thu thập thông tin giám sát tiến độ kiểm tra bằng tay sử dụng các tài liệu, spreadsheets hoặc là các cơ sở dư liệu đơn giản.
Khi làm việc cùng các nhóm lớn, phân bổ các dự án và thời gian kiểm thử dài hạn, nên sử dụng các công cụ tự động hỗ trợ để thấy được tính hiệu quả và tính nhất quán của việc thu thập dữ liệu.

3.2 Báo cáo tình trạng kiểm thử

Báo cáo trạng thái kiểm thử giúp các bên liên quan đến dự án hiểu được kết quả của giai đoạn kiểm thử, đặc biệt nó liên quan đến các mục tiêu chính của dự án và liệu tiêu chí dừng có được đáp ứng.
Báo cáo tình trạng kiểm thử giúp là làm sáng tỏ các vấn đề đã làm và còn tồn đọng, điều này liên quan đến việc phân tích các thông tin và số liệu có sẵn để hỗ trợ việc kết luận, các khuyến nghị và các quyết định về việc làm thế nào để dẫn dắt dự án tiến triển hoặc là để thực hiện những hành động khác.
Nên lập báo cáo tình trạng kiểm thử từ trong quá trình lập kế hoạch kiểm thử và từ giai đoạn chuẩn bị, vì cần phải thu thập số liệu cụ thể từ trong và sau khi kết thúc giai đoạn kiểm thử để làm báo cáo tình trạng kiểm thử có hiệu quả.

3.3 Kiểm soát kiểm thử

Các dự án không phải lúc nào cũng diễn ra như trong kế hoạch, khi rủi ro trở thành sự cố, các bên liên quan cần có tiến triển, khi kế hoạch và thực tiễn bị tách ra, cần có những hành động để đưa dự án trở lại dưới sự kiểm soát.
Trong một số trường hợp, Có sự khác nhau ẩn đằng sau các kết quả kiểm thử, ví dụ: giả sử chất lượng của các mục kiểm tra chứng tỏ việc không chấp nhận kết quả xấu và sự chậm trễ của tiến độ kiểm thử. Trong trường hợp khác, việc kiểm thử bị ảnh hưởng bởi các sự kiện bên ngoài, ví dụ: kiểm thử có thể bị trì hoãn khi các mục kiểm thử xuất hiện muộn hoặc môi trường kiểm thử không có sẵn. Kiểm soát kiểm thử là hướng dẫn và hành động khắc phục để cố gắng đạt được kết quả tốt nhất có thể cho dự án
Những hành động khắc phục hoặc hướng dẫn cụ thể phụ thuộc vào chúng ta đang cố gắng kiểm soát những gì, xem xét các giả thuyết ví dụ sau:
Một phần của phần mềm được kiểm thử sẽ bị chuyển giao muộn, sau khi kiểm tra ngày bắt đầu trong kế hoạch. Những điều kiện bắt buộc ngoài thị trường mà không thể thay đổi ngày chuyển giao sản phẩm. Việc kiểm soát kiểm thử có liên quan đến việc sắp xếp các thứ tự ưu tiên các mục kiểm thử để bắt đầu kiểm thử với những gì có sẵn ở thời điểm hiện tại.
Đối với các lý do về chi phí, kiểm thử hiệu suất thường được chạy vào những ngày cuối tuần trong giờ nghỉ trong môi trường sản xuất. Do có nhu cầu cao đối với sản phẩm mà công ty giữ môi trường làm việc 18 giờ/ ngày, 5 ngày/ tuần. Kiểm soát kiểm thử liên quan đến việc sắp xếp lại thời gian kiểm thử hiệu suất cho cuối tuần.
Trong những ví dụ này, chỉ ra các hành đông kiểm soát kiểm thử mà ảnh hưởng đến việc kiểm thử, nhóm dự án có thể cũng có những hành động khác mà ảnh hưởng đến những vấn đề khác trong dự án. Ví dụ, giả sử ngày hoàn thành kiểm thử gặp rủi ro do số lượng lớn các lỗi cần sửa chữa mà việc kiểm thử xác nhận lại thất bại trong môi trường kiểm thử. Trong trường hợp này, kiểm soát kiểm thử có thể bao gồm yêu cầu các lập trình viên thực hiện sửa lỗi một cách kỹ lưỡng để kiểm tra lại.

4. Quản lý cấu hình

Quản lý cấu hình là một phần của việc xác định rõ các mục, các thành phần nào tạo thành một phần mềm hay một hệ thống. Các mục này bao gồm: mã nguồn, kịch bản kiểm thử, phần mềm bên thứ 3, phần cứng, dữ liệu, cả tài liệu kiểm thử và phát triển. Quản lý cấu hình cũng đảm bảo rằng các mục này được quản lý cẩn thận, kỹ lưỡng trong toàn bộ dự án và vòng đời sản phẩm.
Quản lý cấu hình có một số ý nghĩa quan trọng trong kiểm thử:
Cho phép người kiểm thử quản lý các phần mềm test và các kết quả test bằng cách sử dụng các cơ chế quản lý cấu hình tương tự
Quản lý cấu hình hỗ trợ quá trình xây dựng, đó là một điều cần thiết cho việc cung cấp một bản kiểm thử trong môi trường kiểm thử
Trong các giai đoạn kiểm thử sau, cần có 1 cách thức đáng tin cậy để phân phối các mục kiểm thử làm việc hiệu quả và có phiên bản riêng biệt.
Quản lý cấu hình cho phép lập ra những biểu đồ xác định được mình đang kiểm tra những gì từ các thành phần, các tài liệu nền tảng. Ví dụ, khi báo cáo các lỗi, người kiểm thử nên báo cáo những điều bất lợi mà có thể kiểm soát các phương án, phiên bản phần mềm. Nếu không rõ ràng trong những lỗi đã tìm thấy thì các lập trình viên sẽ rất khó khăn để tìm các lỗi để sửa chữa nó.

5. Rủi ro và Thử nghiệm

5.1. Rủi ro và các mức độ rủi ro

Rủi ro là khả năng của một kết quả tiêu cực hoặc không mong muốn, trong tương lai rủi ro có khả năng xảy ra là 0% đến 100%, đó là một khả năng không phải là điều chắc chắn
Khả năng rủi ro là một trong những yếu tố cần xem xét khi nghĩ đến mức độ rủi ro liên quan đến những hậu quả tiêu cực có thể có, khả năng xảy ra kết quả càng lớn thì rủi ro càng tệ.
Chúng ta có thể phân loại rủi ro thành hai loại sau:
Rủi ro sản phẩm (các yếu tố liên quan đến sản phẩm do công việc sản xuất, ví dụ những điều chúng ta đang thử nghiệm).
Rủi ro của dự án (các yếu tố liên quan đến cách công việc được thực hiện, ví dụ dự án thử nghiệm).

5.2 Rủi ro sản phẩm

Rủi ro sản phẩm là khả năng hệ thống hoặc phần mềm có thể không đáp ứng hoặc chỉ đáp ứng được một số kỳ vọng mong muốn của khách hàng, người sử dụng hoặc các bên liên quan. (Một số người còn gọi “Rủi ro sản phẩm” là “Rủi ro về chất lượng” vì chúng là những rủi ro đối với chất lượng của sản phẩm.)
Các rủi ro về sản phẩm mà có thể khiến sản phẩm hoặc phần mềm gặp nguy hiểm là:
Phần mềm bỏ qua một số chức năng quan trọng mà khách hàng chỉ định, người sử dụng yêu cầu hoặc các bên liên quan đã thống nhất.
Phần mềm không đáng tin cậy và thường xuyên hoạt động bị lỗi.
Phần mềm hỏng gây ra thiệt hại về tài chính hoặc thiệt hại khác cho người sử dụng hoặc công ty mà người sử dụng đang làm việc.
Phần mềm có vấn đề liên quan đến một đặc tính chất lượng cụ thể, có thể không phải là tính năng, mà là an ninh, độ tin cậy, khả năng sử dụng, tính bảo trì hoặc hiệu suất.
Các nhanh nhất để phân tích rủi ro sản phẩm:
Thứ nhất, bạn nên nhớ cân nhắc cả khả năng xảy ra rủi ro và tác động của rủi ro. Trong khi bạn có thể cảm thấy tự hào bằng cách tìm kiếm được nhiều khuyết điểm nhưng thử nghiệm cũng là về xây dựng sự tự tin trong các chức năng chính. Chúng ta cần phải kiểm tra cả những điều có thể sẽ không phá vỡ nhưng sẽ rất xấu nếu chúng đã thực hiện.
Thứ hai, phân tích rủi ro sớm, thường là các cuộc phỏng đoán đã được huấn luyện. Tại các mốc quan trọng của dự án, điều quan trọng là phải đảm bảo rằng bạn xem lại và theo dõi phân tích rủi ro.

5.3 Rủi ro dự án

Thử nghiệm (Đưa dự án vào chạy ở môi trường tương tự môi trường thật) là một hoạt động quan trọng,là phần của dự án và do đó nó tiềm ẩn rủi ro gây nguy hiểm cho dự án.
Những rủi ro dự án gây nguy hiểm cho dự án:
Truyền tải các đề mục thử nghiệm muộn cho nhóm thử nghiệm hoặc các vấn đề có sẵn với môi trường thử nghiệm.
Sự chậm trễ quá mức trong việc sửa chữa các khiếm khuyết được tìm thấy trong quá trình kiểm thử hoặc các vấn đề với việc hỗ trợ quản lý hệ thống chuyên nghiệp cho môi trường thử nghiệm.
Để phát hiện được những rủi ro này , hãy tự hỏi bản thân, những người tham gia dự án và các bên liên quan “ những vấn đề gì có thể xảy ra trong dự án làm trì hoãn hoặc vô hiệu các kế hoạch kiểm thử, chiến lược kiểm thử và ước tính cho việc kiểm thử?”, “ những kết quả không chấp nhận được của kiểm thử và trong quá trình kiểm thử là gì ?”, “những khả năng xảy ra và tác động của mỗi rủi ro là gì?"
Đối với bất kỳ rủi ro nào, rủi ro dự án hoặc rủi ro sản phẩm nào, chúng ta có 4 hành động tiêu biểu mà có thể thực hiện được là:
Giảm thiểu: Thực hiện các bước nâng cao để giảm khả năng và tác động của rủi ro.
Dự phòng: Có kế hoạch để giảm thiểu khả năng rủi ro trở thành kết quả.
Chuyển tiếp: thuyết phục một số thành viên khác của nhóm hoặc các bên liên quan dự án để giảm xác suất hoặc chấp nhận tác động của rủi ro.
Bỏ qua: Bỏ qua rủi ro, thường là lựa chọn tốt chỉ khi có rất ít phương pháp mà có thể được thực hiện hoặc khi khả năng và tác động của rủi ro đó là thấp trong dự án.

5.4 Kết hợp để quản lý rủi ro

Chúng ta có thể giải quyết các rủi ro liên quan đến việc kiểm thử của dự án và sản phẩm bằng cách áp dụng một số biện pháp đơn giản, kỹ thuật quản lý rủi ro có cấu trúc. Bước đầu tiên là đánh giá hoặc phân tích rủi ro sớm trong dự án. Bằng cách sử dụng mẫu lập kế hoạch test ..., với mẫu này sẽ giúp người kiểm thử xem xét và quản lý rủi ro trong giai đoạn lập kế hoạch. Các phân tích rủi ro nhờ trình độ phỏng đoán cũng có thể sẽ mắc sai lầm. Do vậy, cần đảm bảo rằng có kế hoạch đánh giá lại và điều chỉnh rủi ro một cách thường xuyên trong dự án, điều chỉnh phương hướng thích hợp đối với việc kiểm thử hoặc bản thân dự án.
Một vấn đề phổ biến mà mọi người gặp phải khi tổ chức kiểm thử lần đầu mà áp dụng kiểm thử dựa vào rủi ro có xu hướng báo động quá mức bởi một vài rủi ro chúng kết nối với nhau một cách rõ ràng. Không nên nhầm lẫn giữa tác động và khả năng xảy ra và ngược lại, nên quản lý rủi ro một cách thích hợp dựa trên khả năng xảy ra và mức độ tác động. Việc sàng lọc rủi ro bằng cách hiểu được mất bao nhiêu nỗ lực, cố gắng phải bỏ ra để giải quyết rủi ro. Điều quan trọng phải duy trì quan điểm theo từng bối cảnh, tập trung vào các điểm quan trọng. Mục tiêu của kiểm thử dựa trên rủi ro là phải thực tế, một dự án không thể không có rủi ro. Vậy chúng ta đạt được những gì khi thực hiện kiểm thử dựa trên rủi ro là kết hợp kiểm thử với các phương pháp tối ưu nhất trong quản lý rủi ro để đạt được kết quả của dự án cân bằng rủi ro với chất lượng, tính năng, ngân sách và tiến độ.

6. Quản lý sự cố

6.1 Báo cáo sự cố và cách viết báo cáo sự cố

Sự cố (Incidents) là bất kỳ tình huống nào mà hệ thống thực hiện đều có vấn đề, có một sự gián đoạn không được lên kế hoạch trước hoặc sự sụt giảm chất lượng của dịch vụ. Các nguyên nhân gây ra sự cố bao gồm cấu hình sai hoặc lỗi của môi trường thử nghiệm, dữ liệu kiểm thử không đúng, kết quả dự kiến không hợp lệ hoặc lỗi của người kiểm thử.
Tại sao cần phải viết báo cáo sự cố:
Trong một số dự án, có rất nhiều lỗi được tìm thấy. Ngay cả đối với các dự án nhỏ hơn có 100 lỗi hoặc ít lỗi được tìm thấy, rất khó để theo dõi tất cả chúng trừ khi bạn có một quy trình báo cáo, phân loại, gán và quản lý các lỗi từ khi phát hiện ra đến lúc giải quyết cuối cùng.
Một bản báo cáo sự cố có chứa mô tả về sự cố đã được quan sát và phân loại sự cố đó. Báo cáo sự số nhằm cung cấp cho các lập trình viên, người quản lý và những người khác thông tin chi tiết sự cố.
Báo cáo sự cố giúp hỗ trợ phân tích các xu hướng trong dữ liệu lỗi tổng hợp hoặc kiểm tra cụ thể hoặc để hiểu và báo cáo mức độ tổng thể của chất lượng hệ thống.
Báo cáo sự cố, khi được phân tích trên một dự án và thậm chí trên các dự án, cung cấp thông tin có thể dẫn đến các cải tiến về phát triển và thử nghiệm.
Các lập trình viên cần thông tin trong báo cáo để tìm và sửa lỗi. Tuy nhiên, trước khi điều đó xảy ra, các nhà quản lý nên xem xét và ưu tiên các sự cố để kiểm tra, sửa chữa và xác nhận kiểm thử các sự cố quan trọng nhất. Mặc dù nhiều sự cố trong số này sẽ là lỗi người dùng hoặc một số hành vi khác không liên quan đến lỗi, một số phần trăm lỗi bị bỏ xót khỏi hoạt động kiểm thử và đảm bảo chất lượng.
Phần trăm phát hiện sự cố, so sánh các sự cố của trường với các lỗi kiểm tra, là một thước đo quan trọng về hiệu quả của quá trình thử nghiệm.
Cách viết báo cáo sự cố tốt:
Đầu tiên, sử dụng một cách tiếp cận cẩn thận, chu đáo để thực hiện các bài kiểm thử. Bạn không bao giờ biết khi nào bạn sẽ tìm thấy một vấn đề.
Bạn cũng nên cố gắng tái hiện lại lỗi, nó sẽ giúp hướng dẫn lập trình viên khi giải quyết các vấn đề của hệ thống.
Nên cố gắng cô lập các khiếm khuyết bằng cách thực hiện các thay đổi được lựa chọn cẩn thận cho các bước được sử dụng để tái hiện nó.
Nên tăng cường hiểu biết của mình về cách thức làm việc của hệ thống và hệ thống làm việc lỗi như nào.
Nên tìm kiếm các điều kiện tổng quát hơn để khiếm khuyết có thể xảy ra, thay vì chỉ dựa vào test case. Điều này giúp ngăn chặn báo cáo sự cố xấu với lời ngụy biện “không chắc người dùng có thể thực hiện hành động này”. Nó cũng giảm được số lượng các báo cáo nộp lên bị lặp.
So sánh một vấn đề quan sát được với các kết quả test tìm được và tìm ra các khiếm khuyết
Sự ảnh hưởng của người dùng, khách hàng và các bên liên quan rất quan trọng.
sự ảnh hưởng của người dùng, khách hàng và các bên liên quan cũng rất quan trọng.
phải giữ thái độ trung lập, tập trung vào thực tế và không thiên vị, hãy nhớ những vấn đề liên quan đến kiểm thử được thảo luận
Phải giữ thái độ trung lập, tập trung vào thực tế và không thiên vị, hãy nhớ những vấn đề liên quan đến kiểm thử được thảo luận

6.2 Những gì xảy ra trong một báo cáo sự cố?

Như đã đề cập ở trên, chúng ta thường ghi lại các thông tin như là tóm tắt, các bước tiến hành, cố gắng tách biệt các bước và ảnh hưởng của các vấn đề. Các trường này nên đề cập đến các đầu vào và đầu ra được quan sát. Sự trái ngược hoặc là sự khác nhau so với mong đợi, những cách bạn nên làm và không nên làm có thể làm các vấn đề quay trở lại và gây ảnh hưởng. Phân loại thông tin mà tester cung cấp bao gồm ngày, giờ của sự cố, những giai đoạn nào của dự án thất bại mà đã được tìm thấy, các testcase gây ra sự cố, sự tương quan giữa các thông số kỹ thuật hoặc các tài liệu khác cung cấp các thông tin về các hành vi đúng, tên của tester( hoặc là người đánh giá), môi trường test và một số thông tin về cấu hình của phần mềm, hệ thống hoặc môi trường. Thỉnh thoảng tester phân loại phạm vi, mức độ nghiêm trọng và độ ưu tiên của các vấn đề ( bình thường đây là quyền của nhà quản lý hoặc là ban phân loại lỗi).
Các sự cố này được quản lý để giải quyết, quản lý có thể chỉ định mức độ ưu tiên cho báo cáo. Bảng kiểm soát việc thay đổi hoặc ban quản trị lỗi ghi lại các rủi ro, các chi phí, các cơ hội và lợi ích liên quan đến các lỗi đã sửa chữa hoặc chưa sửa được. Các lập trình viên khi sửa lỗi có thể nắm bắt được nguyên nhân gốc rễ, các giai đoạn. Sau khi các vấn đề được giải quyết, các quản lý, lập trình viên hoặc là những người liên quan khác muốn nắm bắt tóm lược được các kết luận và các kiến nghị. Trong suốt vòng đời của báo cáo sự cố, từ khám phá đến lúc giải quyết, hệ thống theo dõi lỗi nên cho phép mỗi người làm việc trên báo cáo sự cố nhập được trạng thái và thông tin lịch sử .

6.3. Điều gì sẽ xảy ra với các báo cáo sự cố sau khi nộp chúng?

Báo cáo sự cố được quản lý theo vòng đời từ khi lúc tìm thấy đến lúc giải quyết. Các vòng đời của báo cáo sự cố thường được hiển thị như là một sơ đồ chuyển trạng thái. Trong khi hệ thống theo dõi lỗi có thể sử dụng một vòng đời khác
Ví dụ này sẽ cho chúng ta thấy vòng đời của sự cố hoạt động như thế nào, vòng đời của báo cáo sự cố được hiển thị như hình dưới.

Tất cả các báo cáo sự cố sẽ di chuyển qua một loạt các trạng thái được xác định rõ ràng sau khi được báo cáo. Một số chuyển đổi trạng thái xảy ra khi một thành viên của nhóm dự án hoàn thành một số task được phân công liên quan đến việc close một báo cáo sự cố. Một số thay đổi trạng thái xảy ra khi nhóm dự án quyết định không sửa lỗi này trong dự án do đó dẫn đến hoãn báo cáo sự cố và một số chuyển đổi trạng thái xảy ra khi báo cáo sự cố được viết kém hoặc mô tả hành vi có thực sự đúng dẫn đến việc báo cáo sự cố bị từ chối.
Nên tập trung vào bản báo cáo sự cố cuối cùng, khi báo cáo được nộp thì sẽ được đánh giá bởi tester ngang hàng khác hoặc quản lý test. Nếu đánh giá thành công thì báo cáo sẽ được mở công khai, vì vậy, nhóm dự án phải quyết định có sửa hay không sửa lỗi, nếu sửa lỗi thì sẽ phân công cho một lập trình viên sửa nó. Khi lập trình viên đã sửa xong thì báo cáo sẽ trả về cho tester để kiểm tra xác nhận. Nếu kiểm tra fail thì báo cáo sẽ được mở lại và phân công lại, nếu kiểm tra tốt thì báo cáo sẽ được đóng. Trong mỗi trạng thái báo cáo sự cố xác định rõ ràng người chịu trách nhiệm. Người sở hữu có trách nhiệm chuyển đổi sự cố sang một trạng thái cho phép. Các mũi tên trong sơ đồ hiển thị các trạng thái được phép chuyển đổi sang.
Link bài viết tiếp theo Các công cụ hỗ trợ cho việc kiểm thử. (Phần 1)