Bốn trong số năm ứng viên QA muốn học cách làm việc với các bài kiểm tra tự động. Không phải công ty nào cũng có thể đáp ứng được mong muốn như vậy của người kiểm thử thủ công trong giờ làm việc. Wrike đã tổ chức một trường dạy tự động hóa cho nhân viên và nhận ra mong muốn này của nhiều người. Tôi đã tham gia vào trường này chính xác với tư cách là một sinh viên QA.
Tôi đã học cách làm việc với Selenium và hiện đang hỗ trợ một cách độc lập một số lượng thử nghiệm tự động nhất định mà hầu như không cần sự trợ giúp từ bên ngoài. Và, dựa trên kết quả kinh nghiệm chung của chúng tôi và kết luận cá nhân của tôi, tôi sẽ cố gắng rút ra chính công thức cho trường phái tự động hóa lý tưởng nhất.
Kinh nghiệm của Wrike trong việc tổ chức trường học
Khi nhu cầu về một trường dạy tự động hóa trở nên rõ ràng, tổ chức của trường được giao cho Stas Davydov, trưởng nhóm kỹ thuật về tự động hóa. Ai khác ngoài anh ấy có thể giải thích tại sao họ lại đưa ra sáng kiến này, liệu họ có đạt được kết quả hay không và liệu họ có hối tiếc về thời gian đã bỏ ra không? Hãy cho anh ta lên sàn:
— Vào năm 2016, chúng tôi đã viết một khuôn khổ mới cho các bài kiểm tra tự động và làm cho nó trở nên dễ dàng để viết bài kiểm tra: các bước bình thường xuất hiện, cấu trúc trở nên dễ hiểu hơn nhiều. Chúng tôi nảy ra một ý tưởng: chúng tôi cần thu hút sự tham gia của tất cả những người muốn viết bài kiểm tra mới và để dễ hiểu hơn, chúng tôi đã tạo ra một loạt bài giảng. Chúng tôi cùng nhau đưa ra một kế hoạch về các chủ đề, mỗi giảng viên tương lai lấy cho mình một chủ đề và chuẩn bị một báo cáo về nó.
- Học sinh gặp khó khăn gì?
- Tất nhiên, chủ yếu là kiến trúc. Có rất nhiều câu hỏi về cấu trúc bài kiểm tra của chúng tôi. Trong phản hồi, có rất nhiều bài viết về chủ đề này và chúng tôi phải tổ chức các bài giảng bổ sung để giải thích chi tiết hơn.
- Trường có trả hết tiền không?
- Vâng chắc chắn. Nhờ cô ấy, rất nhiều người đã tham gia viết bài kiểm tra, và trung bình, trong bệnh viện, mọi người bắt đầu hiểu rõ hơn về bài kiểm tra tự động là gì, cách viết và cách chúng được triển khai. Tải trọng cho các kỹ sư tự động hóa cũng đã giảm: giờ đây chúng tôi nhận được ít yêu cầu trợ giúp phân tích các bài kiểm tra hơn nhiều lần, vì những người thử nghiệm và nhà phát triển đã bắt đầu tự mình giải quyết vấn đề này trong hầu hết các tình huống. Chà, bộ phận có một số lợi thế nội bộ: chúng tôi đã có được kinh nghiệm thuyết trình và bài giảng, nhờ đó một số kỹ sư tự động hóa đã có thể thuyết trình tại các hội nghị, đồng thời nhận được một bộ video và bài thuyết trình mạnh mẽ dành cho những người mới tham gia.
Thay mặt tôi, tôi sẽ nói thêm rằng việc liên lạc giữa các phòng ban của chúng ta đã được đơn giản hóa đến mức cực kỳ dễ dàng. Ví dụ, bây giờ tôi thực tế không cần phải suy nghĩ về những trường hợp nào và ở mức độ nguyên tử nào để tự động hóa. Do đó, tất cả các bên quan tâm đều quan tâm đầy đủ đến phạm vi thử nghiệm không ngừng tăng lên. Không ai đòi hỏi điều không thể từ người khác.
Nhìn chung, tác động đến công việc của các nhóm chắc chắn là tích cực. Có lẽ đồng nghiệp đọc bài viết này cũng đang nghĩ đến việc làm điều gì đó tương tự? Khi đó, lời khuyên sẽ rất đơn giản: thật đáng giá nếu bạn ưu tiên kiểm tra tự động. Tiếp theo, chúng ta sẽ nói về một câu hỏi phức tạp hơn: làm thế nào để tổ chức tất cả những điều này một cách chính xác nhất có thể, sao cho chi phí của tất cả các bên là tối thiểu và sản lượng là tối đa.
Mẹo tổ chức
Trường học rất hữu ích, nhưng, như Stas thừa nhận, có một số khó khăn, do đó cần phải sắp xếp các bài giảng bổ sung. Và chính khi là một sinh viên gần đây so sánh bản thân mình lúc này và bản thân mình lúc này, tôi đã xây dựng các bước sau để tạo ra, theo quan điểm của tôi, cách lý tưởng để dạy người kiểm tra hiểu các bài kiểm tra tự động.
Bước 0. Tạo từ điển
Tất nhiên, bước này không chỉ cần thiết đối với QA. Tuy nhiên, tôi muốn làm rõ: cơ sở mã tự động hóa phải được giữ ở dạng có thể đọc được. Ngôn ngữ lập trình - không kém phần quan trọng ngôn ngữ, và từ đó bạn có thể bắt đầu chuyến lặn của mình.
Đây là ảnh chụp màn hình của chế độ xem tác vụ với tên của các thành phần. Hãy tưởng tượng rằng bạn đang thử nghiệm taskview như một hộp đen và chưa bao giờ nhìn thấy Selenium trong đời. Mã này làm gì?
(Spoiler - tác vụ sẽ bị xóa thông qua phần còn lại thay mặt quản trị viên và sau đó chúng tôi thấy rằng có một bản ghi về điều này trong luồng.)
Chỉ riêng bước này đã đưa ngôn ngữ QAA và QA lại gần nhau hơn. Các nhóm tự động hóa sẽ dễ dàng giải thích kết quả của quá trình chạy hơn; những người thử nghiệm thủ công phải tốn ít công sức hơn vào việc tạo ra các trường hợp: chúng có thể được thực hiện ít chi tiết hơn. Tuy nhiên, mọi người đều hiểu nhau. Chúng tôi đã nhận được tiền thắng ngay cả trước khi khóa đào tạo thực sự bắt đầu.
Bước 1. Lặp lại các cụm từ
Hãy tiếp tục song song với ngôn ngữ. Khi chúng ta học nói khi còn nhỏ, chúng ta không bắt đầu từ từ nguyên và ngữ nghĩa. Chúng ta lặp lại “mẹ”, “mua đồ chơi”, nhưng không đi sâu vào nguồn gốc Ấn-Âu nguyên thủy của những từ này. Vì vậy, nó ở đây: không có ích gì khi đi sâu vào các tính năng kỹ thuật của bài kiểm tra tự động mà không cố gắng viết thứ gì đó hoạt động.
Nghe có vẻ hơi phản trực giác, nhưng nó có tác dụng.
Trong bài học đầu tiên, cần đưa ra cơ sở về cách viết trực tiếp các bài kiểm tra tự động. Chúng tôi giúp thiết lập môi trường phát triển (trong trường hợp của tôi là Intellij IDEA), giải thích các quy tắc ngôn ngữ tối thiểu cần thiết để viết một phương thức khác trong một lớp hiện có bằng cách sử dụng các bước hiện có. Chúng tôi viết một hoặc hai bài kiểm tra với họ và giao cho họ bài tập về nhà, tôi sẽ định dạng như thế này: một nhánh tách ra khỏi nhánh chính, nhưng một số bài kiểm tra đã bị xóa khỏi nó. Chỉ còn lại mô tả của họ. Chúng tôi yêu cầu người thử nghiệm khôi phục các thử nghiệm này (tất nhiên không phải thông qua show diff).
Kết quả là, người lắng nghe và làm mọi thứ sẽ có thể:
- học cách làm việc với giao diện môi trường phát triển: tạo các nhánh, phím nóng, cam kết và đẩy;
- nắm vững những kiến thức cơ bản về cấu trúc của ngôn ngữ và các lớp: nơi chèn nội dung và nơi cần nhập, tại sao cần chú thích và loại ký hiệu nào được tìm thấy ở đó, ngoài các bước;
- hiểu sự khác biệt giữa hành động, chờ đợi và kiểm tra, sử dụng cái gì ở đâu;
- Hãy chú ý sự khác biệt giữa kiểm tra tự động và kiểm tra thủ công: trong kiểm tra tự động, bạn có thể kéo trình xử lý này hoặc trình xử lý khác thay vì thực hiện các hành động thông qua giao diện. Ví dụ: gửi nhận xét trực tiếp đến phần phụ trợ thay vì mở chế độ xem tác vụ, chọn đầu vào, nhập văn bản và nhấp vào nút Gửi;
- hình thành các câu hỏi sẽ được trả lời ở bước tiếp theo.
Điểm cuối cùng là rất quan trọng. Những câu trả lời này có thể dễ dàng được đưa ra trước, nhưng nguyên tắc giảng dạy quan trọng là những câu trả lời không có câu hỏi được xây dựng sẵn sẽ không được ghi nhớ và không được sử dụng khi cần thiết.
Sẽ thật lý tưởng nếu vào thời điểm này, một kỹ sư tự động hóa từ nhóm QA đã giao cho anh ta nhiệm vụ viết một vài bài kiểm tra trong trận chiến và cho phép anh ta gửi đến chi nhánh của mình.
Những gì không nên cho:
- kiến thức chuyên sâu hơn về chức năng của môi trường phát triển và chính ngôn ngữ lập trình, điều này sẽ chỉ cần thiết khi làm việc với các nhánh một cách độc lập. Nó sẽ không được ghi nhớ, bạn sẽ phải giải thích hai hoặc ba lần, nhưng chúng tôi quý trọng thời gian của các kỹ sư tự động hóa, phải không? Ví dụ: giải quyết xung đột, thêm tệp vào git, tạo lớp từ đầu, làm việc với các phần phụ thuộc;
- mọi thứ liên quan đến xpath. Nghiêm túc. Bạn cần nói về nó một cách riêng biệt, một lần và rất tập trung.
Bước 2. Xem xét kỹ hơn về ngữ pháp
Hãy nhớ ảnh chụp màn hình taskview từ bước #0. Chúng tôi có một bước gọi là checkCommentWithTextExists. Người thử nghiệm của chúng tôi đã hiểu bước này làm gì và chúng tôi có thể xem xét bên trong bước này và phân tích nó một chút.
Và bên trong chúng ta có những thứ sau:
onCommentBlock(userName).comment(expectedText).should(displayed());OnCommentBlock ở đâu
onCommonStreamPanel().commentBlock(userName);Bây giờ chúng ta học cách nói không phải “mua đồ chơi” mà là “mua đồ chơi từ cửa hàng Detsky Mir, nằm trong chiếc tủ màu xanh trên kệ thứ ba từ trên xuống”. Cần phải giải thích rằng chúng ta trỏ đến một phần tử một cách tuần tự, từ các phần tử lớn hơn (luồng -> khối có nhận xét từ một người nào đó -> phần đó của khối này chứa văn bản được chỉ định).
Không, vẫn chưa phải lúc nói về xpath. Chỉ cần đề cập ngắn gọn rằng tất cả các hướng dẫn này đều được họ mô tả và sự kế thừa đều thông qua chúng. Nhưng chúng ta cần nói về tất cả những người mai mối và người phục vụ này; họ liên quan cụ thể đến bước này và cần thiết để hiểu điều gì đang xảy ra. Nhưng đừng quá tải: học sinh của bạn có thể tự mình nghiên cứu các khẳng định phức tạp hơn sau này. Rất có thể, nên, WaitUntil,display();, tồn tại();, not(); là đủ.
Bài tập về nhà rất rõ ràng: một nhánh trong đó nội dung của một số bước cần thiết cho một số bài kiểm tra nhất định đã bị loại bỏ. Hãy để những người thử nghiệm khôi phục chúng và làm cho đường chạy trở lại xanh tươi.
Ngoài ra, nếu nhóm kiểm thử không chỉ có các tính năng mới trong công việc của mình mà còn có một số bản sửa lỗi, bạn có thể yêu cầu anh ấy viết ngay các bài kiểm tra về những lỗi này và phát hành chúng. Rất có thể, tất cả các yếu tố đã được mô tả, chỉ có thể thiếu một vài bước. Đây sẽ là buổi tập luyện hoàn hảo.
Bước 3. Ngâm hoàn toàn
Đầy đủ nhất có thể đối với một người thử nghiệm sẽ tiếp tục thực hiện nhiệm vụ trực tiếp của mình. Cuối cùng, chúng ta cần nói về xpath.
Trước tiên, chúng ta hãy làm rõ rằng tất cả những onCommentBlock và comment này đều do chúng mô tả.
Tổng số:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Thứ tự của câu chuyện rất quan trọng. Đầu tiên, chúng tôi lấy bất kỳ xpath hiện có nào và hiển thị cách tab phần tử chứa một và chỉ một phần tử. Tiếp theo, chúng ta sẽ nói về cấu trúc: khi nào bạn cần sử dụng WebElement và khi nào bạn cần tạo một tệp riêng cho một phần tử mới. Điều này sẽ cho phép bạn hiểu rõ hơn về thừa kế.
Phải nói rõ rằng một phần tử duy nhất là toàn bộ taskview, nó chứa phần tử con - toàn bộ luồng, chứa phần tử con - một nhận xét riêng, v.v. Các phần tử con nằm bên trong các phần tử cha cả trên trang và trong cấu trúc của khung kiểm tra tự động.
Tại thời điểm này, khán giả chắc hẳn đã hiểu rõ cách chúng được kế thừa và những gì có thể được nhập sau dấu chấm tại onCommentBlock. Tại thời điểm này, chúng tôi giải thích tất cả các toán tử: /, //, ., [], v.v. Chúng tôi thêm kiến thức về việc sử dụng vào tải @class và những thứ cần thiết khác.
Học sinh nên hiểu cách dịch xpath theo cách này. Để củng cố - đúng vậy, bài tập về nhà. Chúng tôi xóa mô tả của các phần tử, để chúng khôi phục công việc kiểm tra.
Tại sao con đường đặc biệt này?
Chúng ta không nên làm quá tải một người với những kiến thức phức tạp, nhưng chúng ta phải giải thích mọi thứ cùng một lúc, và đây là một tình huống khó xử. Con đường này trước tiên sẽ cho phép chúng ta khiến người nghe đặt câu hỏi nhưng không hiểu điều gì đó và trả lời chúng ngay sau đó. Nếu bạn nói về toàn bộ kiến trúc, thì vào thời điểm phân tích chủ đề về các bước hoặc xpath, những phần quan trọng nhất của nó sẽ bị lãng quên do tính khó hiểu của chúng.
Tuy nhiên, một số bạn có thể chia sẻ kinh nghiệm của mình về cách có thể tối ưu hóa quy trình hơn nữa. Tôi sẽ rất vui khi đọc được những gợi ý tương tự trong phần bình luận!
Nguồn: www.habr.com