Chào mọi người! Tên tôi là Yulia và tôi là người thử nghiệm. Năm ngoái tôi đã kể cho bạn nghe về bagodelnya - một sự kiện được tổ chức tại công ty chúng tôi để giải quyết lỗi tồn đọng. Đây là một lựa chọn hoàn toàn khả thi để giảm đáng kể (từ 10 xuống 50% ở các nhóm khác nhau) chỉ trong một ngày.

Hôm nay tôi muốn kể cho bạn nghe về thể thức Bagodelny mùa xuân của chúng tôi - BUgHunting (BUH). Lần này chúng tôi không sửa các lỗi cũ mà tìm kiếm các lỗi mới và đề xuất ý tưởng cho các tính năng. Bên dưới phần cắt có nhiều thông tin chi tiết về việc tổ chức các sự kiện như vậy, kết quả của chúng tôi và phản hồi từ những người tham gia.

Sau khi suy nghĩ kỹ và viết ra các quy định, chúng tôi đã gửi lời mời tới tất cả các kênh trong Slack của công ty, lời mời này không có bất kỳ hạn chế nào:

Kết quả là có khoảng 30 người đã đăng ký - cả nhà phát triển và chuyên gia không chuyên về kỹ thuật. Chúng tôi dành cả ngày làm việc cho sự kiện, đặt một phòng họp lớn và tổ chức bữa trưa tại căng tin văn phòng.

Tại sao?

Có vẻ như mỗi đội đều kiểm tra chức năng của mình. Người dùng báo cáo lỗi cho chúng tôi. Tại sao lại tổ chức một sự kiện như vậy?

Chúng tôi đã có một số mục tiêu.

Giới thiệu các bạn gần hơn với các dự án/sản phẩm liên quan.
Bây giờ trong công ty chúng tôi, mọi người đều làm việc theo nhóm - đơn vị riêng biệt. Đây là những nhóm dự án đang làm việc theo phần chức năng của riêng họ và không phải lúc nào cũng nhận thức đầy đủ về những gì đang xảy ra trong các dự án khác.
Chỉ cần giới thiệu đồng nghiệp của bạn với nhau.
Chúng tôi có gần 800 nhân viên tại văn phòng ở Moscow; không phải tất cả đồng nghiệp đều quen biết nhau.
Cải thiện khả năng tìm lỗi trong sản phẩm của nhà phát triển.
Chúng tôi hiện đang quảng bá Thử nghiệm Agile và đào tạo những người theo hướng này.
Không chỉ có sự tham gia của các chuyên gia kỹ thuật vào việc thử nghiệm.
Ngoài bộ phận kỹ thuật, chúng tôi còn có nhiều đồng nghiệp từ các chuyên ngành khác muốn nói nhiều hơn về thử nghiệm, về cách báo cáo lỗi chính xác để chúng tôi nhận được ít thông báo hơn như “Ahhh... không có tác dụng gì cả”.
Và tất nhiên là tìm ra những lỗi phức tạp và khó thấy.
Tôi muốn giúp các nhóm thử nghiệm các tính năng mới và cho họ cơ hội xem xét chức năng đã triển khai từ một góc độ khác.

Thực hiện

Ngày của chúng tôi bao gồm một số khối:

cuộc họp;
một bài giảng ngắn về kiểm tra, trong đó chúng tôi chỉ đề cập đến những điểm chính (mục tiêu và nguyên tắc kiểm tra, v.v.);
phần “quy tắc ứng xử tốt” khi giới thiệu lỗi (đây các nguyên tắc được mô tả rõ ràng);
bốn buổi thử nghiệm cho các dự án có kịch bản được mô tả ở cấp độ cao; trước mỗi buổi học có một bài giảng giới thiệu ngắn về dự án và chia thành các nhóm;
khảo sát ngắn về sự kiện này;
tóm tắt.

(Chúng tôi cũng không quên thời gian nghỉ giữa các buổi học và bữa trưa).

Cơ bản quy tắc

Đăng ký cho các sự kiện là cá nhân, giải quyết được vấn đề toàn đội kiệt sức do quán tính nếu một người quyết định không đi.
Người tham gia thay đổi đội mỗi phiên. Điều này cho phép người tham gia đến và đi bất cứ lúc nào và bạn cũng có thể gặp gỡ nhiều người hơn.
Đội hai người trước mỗi buổi được hình thành ngẫu nhiên, điều này làm cho nó năng động hơn và nhanh hơn.
Đối với các lỗi được giới thiệu, bạn được thưởng điểm (từ 3 đến 10) tùy theo mức độ quan trọng.
Không có điểm được trao cho các bản sao.
Các lỗi phải được thành viên trong nhóm báo cáo theo tất cả các tiêu chuẩn nội bộ.
Yêu cầu tính năng được tạo trong một nhiệm vụ riêng và tham gia vào một đề cử riêng.
Nhóm kiểm toán giám sát việc tuân thủ tất cả các quy tắc.

Những chi tiết khác

Ban đầu, tôi muốn tổ chức một sự kiện thử nghiệm “nâng cao”, nhưng... Khá nhiều người từ các nhóm phi sản phẩm đã đăng ký (SMM, luật sư, PR), chúng tôi đã phải đơn giản hóa nội dung rất nhiều và loại bỏ các trường hợp phức tạp/hồ sơ.
Do công việc của các đơn vị ở Jira trong các dự án khác nhau, theo quy trình của chúng tôi, chúng tôi đã đặc biệt tạo một dự án riêng trong đó chúng tôi thiết lập một mẫu để giới thiệu lỗi.
Để tính điểm, họ dự định sử dụng bảng xếp hạng được cập nhật qua webhooks, nhưng đã xảy ra sự cố và cuối cùng việc tính toán phải được thực hiện thủ công.

Mọi người đều gặp phải vấn đề khi tổ chức sự kiện và để giúp bạn dễ dàng hơn một chút, tôi sẽ mô tả những vấn đề của chúng tôi mà bạn có thể tránh.

Một trong những diễn giả đột nhiên đổ bệnh và phải tìm người mới.
Tôi cực kỳ may mắn khi tìm được người thay thế từ cùng một đội vào lúc 9 giờ sáng). Nhưng tốt hơn hết là đừng trông chờ vào may mắn và có một khoản dự phòng. Hoặc sẵn sàng tự mình đưa ra những báo cáo cần thiết.

Chúng tôi không có thời gian để triển khai chức năng, chúng tôi phải hoán đổi các khối.
Để tránh vứt bỏ toàn bộ khối, tốt hơn hết bạn nên có một kế hoạch dự phòng.

Một số người dùng thử nghiệm đã bỏ qua, chúng tôi phải nhanh chóng tạo lại những người dùng mới.
Kiểm tra chéo người dùng trước hoặc có thể thực hiện nhanh chóng.

Hầu như không ai trong số những người được đơn giản hóa định dạng đến.
Không cần phải kéo ai bằng vũ lực. Hạ mình.
Có một lựa chọn để quy định chặt chẽ hình thức của sự kiện: “nghiệp dư”/“nâng cao”, hoặc chuẩn bị hai phương án cùng một lúc và quyết định nên giữ phương án nào sau khi thực tế.

Điểm tổ chức hữu ích:

đặt trước một cuộc họp;
sắp xếp bàn ghế, đừng quên dây nối dài và thiết bị chống sét lan truyền (sạc máy tính xách tay/điện thoại có thể không đủ dùng cả ngày);
tự động hóa quá trình chấm điểm;
chuẩn bị bảng xếp hạng;
tạo tài liệu phát tay có thông tin đăng nhập và mật khẩu của người dùng thử nghiệm, hướng dẫn làm việc với Jira, tập lệnh;
Đừng quên gửi lời nhắc một tuần trước sự kiện, đồng thời cho biết bạn cần mang theo những gì (máy tính xách tay/thiết bị);
kể cho đồng nghiệp của bạn về sự kiện tại buổi giới thiệu, vào bữa trưa, bên tách cà phê;
đồng ý với các nhà phát triển không cập nhật hoặc triển khai bất cứ điều gì vào ngày này;
chuẩn bị loa;
đàm phán với chủ sở hữu tính năng và viết thêm kịch bản để thử nghiệm;
gọi món (bánh quy/kẹo) cho bữa ăn nhẹ;
đừng quên cho chúng tôi biết về kết quả của sự kiện.

Những phát hiện

Trong suốt cả ngày, các anh chàng đã thử nghiệm 4 dự án và tạo ra 192 lỗi (134 trong số đó là lỗi duy nhất) và 7 vấn đề liên quan đến yêu cầu tính năng. Tất nhiên, chủ dự án đã biết về một số lỗi này. Nhưng cũng có những phát hiện bất ngờ.

Tất cả những người tham gia đều nhận được giải thưởng ngọt ngào.

Và người chiến thắng là bình giữ nhiệt, huy hiệu, áo nỉ.

Điều gì trở nên thú vị:

những người tham gia nhận thấy hình thức của các buổi học khó khăn thật bất ngờ, khi thời gian có hạn và bạn không thể dành nhiều thời gian để suy nghĩ;
quản lý để kiểm tra máy tính để bàn, phiên bản di động và ứng dụng;
chúng tôi xem nhiều dự án cùng một lúc, không có thời gian để chán;
gặp gỡ các đồng nghiệp khác nhau, xem xét cách tiếp cận của họ để giới thiệu lỗi;
cảm nhận được hết nỗi đau của người thử nghiệm.

Những gì có thể được cải thiện:

thực hiện ít dự án hơn và tăng thời gian phiên lên 1,5 giờ;
chuẩn bị quà/quà lưu niệm trước rất nhiều (có khi phê duyệt/thanh toán mất cả tháng);
thư giãn và chấp nhận rằng điều gì đó sẽ không diễn ra theo đúng kế hoạch và sẽ xảy ra trường hợp bất khả kháng.

Nhận xét

Anna Bystrikova, quản trị hệ thống: “Nhà tế bần mang tính giáo dục rất lớn đối với tôi. Tôi đã tìm hiểu quy trình kiểm thử và cảm nhận được hết “nỗi đau” của người kiểm thử.
Đầu tiên, trong quá trình thử nghiệm, với tư cách là một người dùng mẫu mực, bạn sẽ kiểm tra những điểm chính: nút có nhấp vào hay không, nút có chuyển đến trang hay không, bố cục có bị di chuyển ra ngoài hay không. Nhưng sau đó bạn nhận ra rằng bạn cần phải suy nghĩ sáng tạo hơn và cố gắng “phá vỡ” ứng dụng. Người kiểm thử có một công việc khó khăn, chỉ “chọc” khắp giao diện thôi là chưa đủ, bạn cần phải cố gắng suy nghĩ sáng tạo và cực kỳ chú ý.
Ấn tượng chỉ mang tính tích cực, ngay cả bây giờ, một thời gian sau sự kiện, tôi mới thấy công việc xử lý các lỗi mà tôi tìm thấy đang được thực hiện như thế nào. Thật tuyệt khi được tham gia vào việc cải tiến sản phẩm ^_^.”

Dmitry Seleznev, nhà phát triển front-end: “Thử nghiệm ở chế độ cạnh tranh thúc đẩy chúng tôi tìm ra nhiều lỗi hơn). Đối với tôi, có vẻ như mọi người nên cố gắng tham gia Baghunting. Kiểm thử thăm dò cho phép bạn tìm ra những trường hợp không được mô tả trong kế hoạch kiểm thử. Ngoài ra, những người chưa biết về dự án có thể đưa ra phản hồi về sự tiện lợi của dịch vụ.”

Antonina Tatchuk, biên tập viên cao cấp: “Tôi thích thử sức mình với tư cách là người thử nghiệm. Đây là một phong cách làm việc hoàn toàn khác. Bạn đang cố gắng phá vỡ hệ thống chứ không phải kết bạn với nó. Chúng tôi luôn có cơ hội hỏi đồng nghiệp của mình điều gì đó về việc thử nghiệm. Tôi đã tìm hiểu thêm về cách sắp xếp thứ tự ưu tiên của các lỗi (ví dụ: tôi thường tìm kiếm các lỗi ngữ pháp trong văn bản, nhưng “trọng lượng” của một lỗi như vậy là rất nhỏ; và ngược lại, một điều dường như không quan trọng lắm đối với tôi cuối cùng lại bị loại bỏ. một lỗi nghiêm trọng đã được sửa ngay lập tức).
Tại sự kiện, các anh chàng đã trình bày tóm tắt lý thuyết trắc nghiệm. Điều này rất hữu ích cho những người không rành về kỹ thuật. Và vài ngày sau, tôi chợt nghĩ rằng mình đang viết để ủng hộ một trang web khác bằng cách sử dụng công thức “cái gì-ở đâu-khi nào” và mô tả chi tiết những mong đợi của tôi đối với trang web và thực tế.”

Kết luận

Nếu bạn muốn đa dạng hóa cuộc sống của nhóm mình, hãy có cái nhìn mới về chức năng, sắp xếp một nhóm nhỏ "Ăn thức ăn cho chó của riêng bạn", thì bạn có thể cố gắng tổ chức một sự kiện như vậy và sau đó chúng ta có thể cùng nhau thảo luận về nó.

Tất cả các lỗi tốt nhất và ít hơn!

Nguồn: www.habr.com

Bagelny: BUgSăn bắn. Cách tìm 200 lỗi trong một ngày