TESTING PROCESS (tiếp)

1.4 Thiết kế ca kiểm thử

Thiết kế ca kiểm thử là hoạt động xác định cách thức kiểm thử cho đối tượng nhất định. Nó liên quan đến việc xác định các trường hợp thử nghiệm. Xây dựng từng bước các điều kiện thử nghiệm trên cơ sở sử dụng các kỹ thuật kiểm thử trong chiến lược thử nghiệm và / hoặc kế hoạch thử nghiệm.

Tùy thuộc vào các phương pháp được sử dụng để theo dõi kiểm thử, kiểm soát kiểm thử và truy xuất nguồn gốc, các trường hợp kiểm thử có thể liên quan trực tiếp (hoặc liên quan gián tiếp thông qua các điều kiện kiểm thử ) đến cơ sở kiểm thử và xác định mục tiêu. Những mục tiêu này bao gồm mục tiêu chiến lược, mục tiêu thử nghiệm hoặc tiêu chí của các bên liên quan để dự án thành công. Thiết kế kiểm thử cho một mức kiểm thử nhất định có thể được thực hiện khi các điều kiện thử nghiệm được xác định và đủ thông tin có sẵn để cho phép sản xuất các trường hợp thử nghiệm cấp thấp hoặc cấp cao, theo sử dụng phương pháp tiếp cận để thiết kế thử nghiệm.

Đối với các cấp độ thử nghiệm cao hơn, nhiều khả năng thiết kế thử nghiệm là một hoạt động riêng biệt sau phân tích thử nghiệm trước đó. Đối với các cấp độ thử nghiệm thấp hơn, có khả năng phân tích thử nghiệm và thiết kế sẽ được tiến hành như một hoạt động tích hợp.

Cũng có khả năng một số tác vụ thường xảy ra trong quá trình thực hiện kiểm tra sẽ được tích hợp vào quy trình thiết kế thử nghiệm khi sử dụng phương pháp lặp để xây dựng các thử nghiệm cần thiết để thực hiện;

ví dụ: việc tạo dữ liệu thử nghiệm. Trong thực tế, phương pháp này có thể tối ưu hóa phạm vi điều kiện thử nghiệm, hoặc tạo ra các trường hợp thử nghiệm cấp thấp hoặc cấp cao trong quy trình.

1.5 Thực hiện kiểm thử

Thực hiện kiểm thử là hoạt động được các nhà phân tích kiểm thử tổ chức và thực hiện theo thứ tự ưu tiên. Trong bối cảnh tài liệu chính thức, thực hiện thử nghiệm là hoạt động trong đó thiết kế thử nghiệm thực hiện như các trường hợp thử nghiệm cụ thể, có quy trình thử nghiệm và dữ liệu thử nghiệm.

Một số tổ chức theo Tiêu chuẩn IEEE 829 thì cần xác định đầu vào và kết quả dự kiến liên quan của chúng trong trường hợp thử nghiệm, thông số kỹ thuật và các bước kiểm tra trong thông số kỹ thuật, thủ tục kiểm tra.

Thông thường, mỗi đầu vào thử nghiệm, kết quả mong đợi và các bước kiểm tra được ghi lại cùng nhau. Thực hiện kiểm tra cũng bao gồm tạo dữ liệu thử nghiệm được lưu trữ (ví dụ: trong các tệp phẳng hoặc bảng cơ sở dữ liệu).

Việc thực hiện kiểm tra cũng bao gồm các kiểm tra cuối cùng để đảm bảo nhóm kiểm tra đã sẵn sàng để thực hiện kiểm tra diễn ra. Kiểm tra có thể bao gồm đảm bảo cung cấp môi trường thử nghiệm cần thiết, dữ liệu thử nghiệm và mã (có thể chạy một số môi trường thử nghiệm và / hoặc thử nghiệm chấp nhận mã) và tất cả các trường hợp thử nghiệm đã được viết, xem xét và sẵn sàng để được chạy.

Nó cũng có thể bao gồm kiểm tra chống lại rõ ràng và các tiêu chí đầu vào ngầm định cho cấp độ kiểm tra được đề cập.

Thực hiện kiểm thử cũng có thể liên quan đến việc phát triển một mô tả chi tiết về môi trường thử nghiệm và dữ liệu thử nghiệm.

Mức độ chi tiết và độ phức tạp liên quan của công việc được thực hiện trong quá trình thực hiện thử nghiệm có thể là bị ảnh hưởng bởi chi tiết của các sản phẩm công việc thử nghiệm (ví dụ: các trường hợp thử nghiệm và điều kiện thử nghiệm).

Trong vài trường hợp, đặc biệt khi các bài kiểm tra được lưu trữ để sử dụng lại lâu dài trong kiểm tra hồi quy, các bài kiểm tra có thể cung cấp mô tả chi tiết các bước cần thiết để thực hiện kiểm tra, để đảm bảo đáng tin cậy, nhất quán thực hiện bất kể người kiểm tra thực hiện kiểm tra. Nếu quy tắc áp dụng, các xét nghiệm sẽ cung cấp bằng chứng về việc tuân thủ các tiêu chuẩn áp dụng (xem phần 2.9).

Trong quá trình thực hiện thử nghiệm, thứ tự chạy thử nghiệm thủ công và tự động phải là Bao gồm trong một lịch trình thực hiện thử nghiệm. Người quản lý kiểm tra cần kiểm tra cẩn thận các ràng buộc, bao gồm rủi ro và ưu tiên, có thể yêu cầu các thử nghiệm được chạy theo một thứ tự cụ thể hoặc trên thiết bị cụ thể.

Sự phụ thuộc vào môi trường thử nghiệm hoặc dữ liệu thử nghiệm phải được biết và kiểm tra. Có thể có một số nhược điểm để thực hiện thử nghiệm sớm. Ví dụ, với vòng đời Agile, mã có thể thay đổi đáng kể từ lần lặp sang lần lặp, khiến phần lớn việc thực hiện công việc lỗi thời. Ngay cả khi không có vòng đời dễ bị thay đổi như Agile, bất kỳ vòng đời lặp hoặc tăng dần nào cũng có thể dẫn đến những thay đổi đáng kể giữa các lần lặp, làm cho các bài kiểm tra theo kịch bản không đáng tin cậy hoặc có nhu cầu bảo trì cao.

Điều này cũng đúng với các vòng đời tuần tự được quản lý kém trong đó các yêu cầu thay đổi thường xuyên, thậm chí muộn vào dự án. Trước khi bắt tay vào thử nghiệm rộng rãi Nỗ lực triển khai, thật khôn ngoan khi hiểu vòng đời phát triển phần mềm và khả năng dự đoán các tính năng phần mềm sẽ có sẵn để thử nghiệm.

Có thể có một số lợi thế trong việc thực hiện thử nghiệm sớm. Ví dụ, kiểm tra cụ thể cung cấp ví dụ làm việc về cách phần mềm nên hoạt động, nếu được viết phù hợp với cơ sở thử nghiệm. Các chuyên gia trong lĩnh vực kinh doanh có thể tìm thấy xác minh các thử nghiệm cụ thể dễ dàng hơn so với xác minh quy tắc kinh doanh trừu tượng và do đó có thể xác định các điểm yếu hơn nữa trong thông số kỹ thuật phần mềm.

Như là kiểm tra xác minh có thể cung cấp minh họa rõ ràng về hành vi cần thiết cho các nhà thiết kế phần mềm và nhà phát triển.

1.6 Thực hiện kiểm tra

Thực hiện kiểm tra bắt đầu khi đối tượng kiểm tra được phân phối và các tiêu chí nhập để thực hiện kiểm tra là hợp lệ. Các thử nghiệm phải được thiết kế hoặc ít nhất là được xác định trước khi thực hiện thử nghiệm. Công cụ nên có, đặc biệt là để quản lý kiểm tra, theo dõi lỗi và tự động thực hiện kiểm tra (nếu có). Theo dõi kết quả kiểm tra, bao gồm theo dõi số liệu, sẽ hoạt động và dữ liệu được theo dõi phải được hiểu bởi tất cả các thành viên trong nhóm. Các tiêu chuẩn để ghi nhật ký kiểm tra và báo cáo lỗi phải có sẵn và được công bố. Bằng cách đảm bảo các mục này được đặt đúng chỗ trước khi thực hiện kiểm tra, việc thực thi có thể tiến hành hiệu quả.

Các thử nghiệm phải được thực hiện theo các trường hợp thử nghiệm, mặc dù Trình quản lý kiểm tra nên xem xét cho phép một số lượng vĩ độ để người kiểm tra có thể bao gồm các kịch bản thử nghiệm thú vị khác và các hành vi được quan sát trong quá trình thử nghiệm.

Khi theo một chiến lược thử nghiệm ít nhất là một phần phản ứng, một số thời gian nên được dành riêng cho các phiên kiểm tra sử dụng dựa trên kinh nghiệm và dựa trên khiếm khuyết kỹ thuật.

Tất nhiên, bất kỳ lỗi nào được phát hiện trong quá trình kiểm tra không được ghi như vậy phải mô tả các biến thể từ trường hợp thử nghiệm bằng văn bản cần thiết để tái tạo sự thất bại. Kiểm tra tự động sẽ làm theo hướng dẫn xác định mà không sai lệch.

Vai trò chính của Trình quản lý kiểm tra trong quá trình thực hiện kiểm tra là theo dõi tiến trình theo kiểm tra lập kế hoạch và, nếu được yêu cầu, để bắt đầu và thực hiện các hành động kiểm soát để hướng dẫn thử nghiệm hướng tới thành công kết luận về nhiệm vụ, mục tiêu và chiến lược.

Để làm như vậy, Trình quản lý kiểm tra có thể sử dụng truy xuất nguồn gốc từ kết quả kiểm tra trở lại các điều kiện kiểm tra, cơ sở kiểm tra và cuối cùng là kiểm tra mục tiêu, và cũng từ mục tiêu kiểm tra chuyển tiếp đến kết quả kiểm tra. Quá trình này được mô tả trong chi tiết trong mục 2.6

1.7 Đánh giá tiêu chí xuất cảnh và báo cáo

Tài liệu và báo cáo để theo dõi và kiểm soát tiến độ thử nghiệm được thảo luận chi tiết trong Mục 2.6. Từ quan điểm của quá trình kiểm tra, điều quan trọng là để đảm bảo rằng quá trình hiệu quả được xây đặt để cung cấp các thông tin về nguồn cần thiết cho việc đánh giá tiêu chuẩn xuất cảnh và báo cáo. Định nghĩa các yêu cầu thông tin và phương pháp thu thập là một phần của kế hoạch kiểm tra, giám sát và kiểm soát. Trong quá trình phân tích thử nghiệm, thiết kế thử nghiệm, thực hiện thử nghiệm và thực hiện thử nghiệm, Test Manager phải đảm bảo rằng các thành viên của nhóm thử nghiệm chịu trách nhiệm về những hoạt động này cung cấp các thông tin cần thiết một cách chính xác và kịp thời để tạo điều kiện hiệu quả đánh giá và báo cáo

Tần suất và mức độ chi tiết cần thiết để báo cáo phụ thuộc vào dự án và cơ quan. Điều này nên được đàm phán trong giai đoạn lập kế hoạch kiểm tra và nên bao gồm tham khảo ý kiến các bên liên quan của dự án.

1.8 Hoạt động kết thúc kiểm thử

Khi thực hiện kiểm tra được xác định là hoàn thành, các đầu ra chính sẽ được ghi lại và chuyển cho người có liên quan hoặc lưu trữ. Đây là các hoạt động kết thúc thử nghiệm. Kiểm tra kết thúc có các hoạt động rơi vào bốn nhóm chính:

1. Kiểm tra hoàn thành kiểm tra - đảm bảo rằng tất cả các công việc kiểm tra đã thực sự kết thúc.

Ví dụ,

• tất cả các bài kiểm tra theo kế hoạch nên được chạy hoặc bỏ qua một cách có chủ ý và tất cả các lỗi đã biết phải là đã được sửa chữa và xác nhận đã được thử nghiệm, hoãn lại để phát hành trong tương lai hoặc được chấp nhận là vĩnh viễn những hạn chế.

1. Thử nghiệm tạo tác bàn giao - cung cấp các sản phẩm công việc có giá trị cho những người cần chúng.

• ví dụ, các khuyết tật đã biết hoãn lại hoặc được chấp nhận nên được truyền đạt tới những người sẽ sử dụng và hỗ trợ việc sử dụng hệ thống. Các thử nghiệm và môi trường thử nghiệm nên được cung cấp cho những người chịu trách nhiệm kiểm tra bảo trì. Bộ kiểm tra hồi quy (tự động hoặc thủ công) cần được ghi lại và giao cho đội bảo trì.

1. Bài học kinh nghiệm

• thực hiện hoặc tham gia các cuộc họp hồi cứu khi quan trọng bài học (cả từ trong dự án thử nghiệm và trên toàn bộ quá trình phát triển phần mềm vòng đời) có thể được ghi lại. Trong các cuộc họp này, các kế hoạch được thiết lập để đảm bảo rằng tốt thực tiễn có thể được lặp đi lặp lại và thực tiễn kém không được lặp lại hoặc, trong đó các vấn đề không thể được giải quyết, chúng được cung cấp trong kế hoạch dự án.

Các khu vực được xem xét bao gồm tiếp theo:

a. Là đại diện người dùng trong các phiên phân tích rủi ro chất lượng có một mặt cắt đủ rộng? Ví dụ, do phát hiện muộn các cụm khiếm khuyết không dự đoán được, nhóm nghiên cứu có thể đã phát hiện ra rằng một mặt cắt ngang rộng hơn của đại diện người dùng nên tham gia vào các phiên phân tích rủi ro chất lượng về các dự án trong tương lai.

b. Các ước tính có chính xác không? Ví dụ, ước tính có thể đã được đáng kể đánh giá sai và do đó các hoạt động ước tính trong tương lai sẽ cần phải giải thích cho việc này cùng nhau với các lý do cơ bản, ví dụ, đã thử nghiệm không hiệu quả hoặc ước tính thực sự thấp hơn hơn nó nên có

c. Các xu hướng và kết quả phân tích nguyên nhân và kết quả của các khiếm khuyết là gì? Dành cho ví dụ, đánh giá nếu các yêu cầu thay đổi muộn ảnh hưởng đến chất lượng phân tích và phát triển, tìm kiếm các xu hướng chỉ ra các thực tiễn xấu, ví dụ: bỏ qua cấp độ thử nghiệm sẽ tìm thấy khuyết điểm sớm hơn và theo cách hiệu quả hơn về chi phí, đối với nhận thức tiết kiệm thời gian Kiểm tra xem xu hướng lỗi có thể liên quan đến các lĩnh vực như mới không công nghệ, thay đổi nhân sự, hoặc thiếu kỹ năng. Cười mở miệng. Có cơ hội cải tiến quy trình tiềm năng?

e. Có bất kỳ phương sai không lường trước được từ kế hoạch nên được cung cấp trong kế hoạch tương lai?

4.Lưu trữ kết quả, nhật ký, báo cáo và các tài liệu và sản phẩm công việc khác trong cấu hình hệ thống quản lý. Ví dụ, cả kế hoạch kiểm tra và kế hoạch dự án nên được lưu trữ trong một lập kế hoạch lưu trữ, với một liên kết rõ ràng với hệ thống và phiên bản mà chúng được sử dụng trên.

Các nhiệm vụ này rất quan trọng, thường bị bỏ lỡ và cần được đưa vào một cách rõ ràng như là một phần của kế hoạch kiểm tra.

Thông thường, một hoặc nhiều trong số các nhiệm vụ này bị bỏ qua, thường là do phân công lại sớm hoặc sa thải các thành viên nhóm dự án, áp lực tài nguyên hoặc lịch trình đối với các dự án tiếp theo hoặc nhóm kiệt sức.

Trên các dự án được thực hiện theo hợp đồng, chẳng hạn như phát triển tùy chỉnh, hợp đồng nên chỉ định các nhiệm vụ cần thiết.

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