Làm thế nào để đối phó với Tự động hóa trên mạng là tư duy Easy Easy?

Tiêu đề nói lên tất cả. Một số nhân viên trong công ty của chúng tôi tin rằng các bài kiểm tra tự động là "dễ dàng" và nó "sẽ mất một ngày" để viết các bộ kiểm tra COM và UI. Có thể làm gì để chống lại điều này?

Lưu ý: Tôi không hỏi về cách thúc đẩy tự động hóa. Đó không phải là vấn đề. Kiểm tra và quy trình tự động đang được thúc đẩy và yêu cầu mọi lúc tại đây. Vấn đề là một số cá nhân không hiểu rằng tự động hóa không "dễ dàng" cũng không phải là "nhanh".

Lần tới khi bạn nhận được yêu cầu hãy cố gắng chia nhỏ quá trình tự động hóa thành nhiều phần thời gian. Tôi nghĩ rằng khi họ nhận ra rằng phải mất 5 phút cho mỗi trường văn bản hoặc nhấn nút, họ bắt đầu nhận ra mất bao lâu.

Chẳng hạn, có lẽ tại sao phải mất nhiều thời gian đến mức họ bắt đầu đưa ra sự phụ thuộc lẫn nhau giữa các trường: vd: chỉ cho phép họ tiến hành nếu điều này được điền nhưng không phải nếu điều này không xảy ra, trừ khi ....

Cố gắng giáo dục họ về TẠI SAO mất quá nhiều thời gian, nhưng không quá nhiều khi bạn đánh mất họ thông qua quá trình "học tập".

Trong vai trò của mình, tôi đã bắt gặp nhiều người "x dễ" đặc biệt là trong các dự án phát triển. Trong tâm trí tôi có ba lý do cho việc này:

1) Họ thực sự không hiểu những gì họ đang nói nhưng rất thích nghe như họ làm.

2) Họ đã đọc một vài cuốn sách và nghĩ rằng họ biết những gì họ đang nói về

3) Cuối cùng mọi người cho rằng vì một máy tính đang thực hiện kiểm tra nhanh, vì máy tính rất nhanh.

Cách chắc chắn để chống lại điều này là thu hút người dùng một cách thường xuyên, chiến lược truyền thông cho các dự án là chìa khóa, chắc chắn giải thích các thử nghiệm tự động cho người dùng không có kỹ thuật sẽ vô ích nhưng làm cho họ biết về các quy trình liên quan có thể có lợi Bạn có thể làm điều này thông qua tài liệu, hội thảo hoặc chỉ là một cuộc trò chuyện thân thiện vào lần tới khi bạn đi qua.

Tôi thậm chí đã từng thấy một BA phát ra tiếng nói lớn nhất trong số những người "x dễ" này và chỉ cần mời họ xuống một ngày trong bộ phận, với suy nghĩ họ sẽ bỏ đi để hiểu thêm về những gì bạn làm HOẶC họ sẽ đơn giản đi ra khỏi suy nghĩ "chúa tôi thực sự không biết tôi đang nói về cái gì, tôi nghĩ rằng tôi đã sai".

Phần mềm là công việc tự động hóa mọi thứ.

Chúng tôi viết phần mềm để làm cho các công việc nhàm chán, lặp đi lặp lại và tốn nhiều công sức hơn cho chúng tôi. Chúng tôi viết phần mềm để tự động tạo báo cáo, thu thập dữ liệu, liên lạc với người khác, v.v. Viết kiểm tra tự động thực sự chỉ là viết phần mềm để đảm bảo phần mềm khác của chúng tôi hoạt động theo cách chúng tôi mong đợi.

Nếu đồng nghiệp của bạn hiểu rằng viết phần mềm là khó và mất thời gian, thì khá dễ dàng để cho họ thấy rằng viết nhiều phần mềm nên khó và mất thời gian. Sẽ thật tuyệt nếu nhận được tất cả các lợi ích của tự động hóa miễn phí, nhưng, như mọi khi, chúng ta cần đưa công việc lên phía trước để có được những lợi ích sau này.

Nếu họ không hiểu điều đó, bạn cần phải dạy họ điều đó hoặc làm việc để đánh bóng sơ yếu lý lịch của bạn.

Hầu hết các nhân viên dành thời gian của họ ở phần "phía trước" (khách hàng - ông chủ - bên liên quan) của công ty hoặc "phía sau" (nơi công việc "thực sự" được thực hiện). Hai chức năng này khác nhau, gần như trái ngược nhau. (Và rất ít người đã làm việc trong cả hai). Kết quả là, thường có sự hiểu lầm giữa hai nhóm.

Cách tốt nhất để giáo dục những người "đi trước", là có một hoặc một vài người trong số họ dành một ngày ở "phía sau". Nếu họ hoàn thành "Một ngày trong cuộc sống của ...", họ sẽ có một ý tưởng thực tế hơn về những gì có thể được thực hiện trong một ngày, và tại sao phải mất nhiều thời gian và nỗ lực hơn để chạy các bài kiểm tra tự động. Tương tự như vậy, những người "quay lại" có thể được hưởng lợi từ một hoặc hai ngày ở "mặt trận".

Trong "Làm thế nào để giàu có", John Paul Getty (một ông trùm cho thời đại của mình) đã ủng hộ việc "đào tạo chéo" như vậy. Theo quan điểm của ông, một nhân viên bán hàng dành thời gian cho dây chuyền lắp ráp nơi sản phẩm được sản xuất sẽ làm việc bán hàng tốt hơn rất nhiều, và tương tự như vậy, một kỹ sư dành một ngày với khách hàng sẽ làm tốt hơn việc "gỡ lỗi".

Vấn đề là một số cá nhân không hiểu rằng tự động hóa không "dễ dàng" cũng không phải là "nhanh".

Tôi không đồng ý với tiền đề của bạn ở đây.

Tôi là một người ủng hộ thử nghiệm tự động lớn, bất kể đó là thử nghiệm đơn vị, thử nghiệm tích hợp hay thử nghiệm UI. Có rất nhiều công cụ tuyệt vời có sẵn để thực hiện các bài kiểm tra tự động.

Hãy so sánh thử nghiệm tự động với thử nghiệm thủ công dựa trên ví dụ sau:

Trong một ứng dụng web, hãy kiểm tra chức năng "Thay đổi mật khẩu" của người dùng hiện có bằng trình duyệt.

Kiểm tra thủ công :

• Bắt đầu ứng dụng web
• Mở trình duyệt
• Chết tiệt, có một lỗi. Tại sao? Ồ, tôi quên khởi động cơ sở dữ liệu!
• Được rồi, tắt ứng dụng web
• Bắt đầu cơ sở dữ liệu
• Bắt đầu ứng dụng web
• Làm mới trình duyệt
• Hmm, mật khẩu của người dùng thử của chúng tôi lại là gì?
• Nhìn vào cơ sở dữ liệu
• Ồ, bảng người dùng trống! Tôi phải tạo một người dùng mới.
• Đăng ký người dùng mới trong ứng dụng web: Nhập tên người dùng, mật khẩu, địa chỉ email
• Tại sao tôi không thể đăng nhập với người dùng mới của mình? Ồ, tôi cần nhấp vào liên kết xác nhận trong email!
• Chà, tôi đã cung cấp cho người dùng một email như "test@example.com". Hãy đi đến cơ sở dữ liệu và đặt cột "hoạt động" thành "Có".
• Đăng nhập. Lần này nó hoạt động!
• Hmm, tôi muốn kiểm tra lại điều gì ...?

Dễ dàng? Không hẳn vậy. Có rất nhiều cạm bẫy có thể xảy ra trong quá trình này.

Nhanh? Không. Công việc thủ công cần có thời gian.

Bây giờ, hãy thử viết một bài kiểm tra tự động :

• Chúng ta cần tìm các công cụ cho ngôn ngữ lập trình của mình để tự động khởi động cơ sở dữ liệu và máy chủ web. Nghiên cứu và thực hiện cần có thời gian.
• Cơ sở dữ liệu cần phải ở trạng thái sạch khi thử nghiệm bắt đầu. Tạo các kịch bản cần có thời gian.
• Chúng ta cần viết bài kiểm tra. Vì chúng tôi cần một người dùng, chúng tôi cũng cần phải đăng ký một cái mới cho thử nghiệm của chúng tôi. Tốn thời gian.
• Cuối cùng, chúng tôi có thể viết những gì chúng tôi muốn kiểm tra: Thay đổi mật khẩu của người dùng. Với công cụ kiểm tra trình duyệt của chúng tôi, việc này được thực hiện khá nhanh so với các tác vụ trước.

Dễ dàng? Không! Chúng tôi cần nghiên cứu các công cụ, thực hiện chúng, sửa một số lỗi trong các thử nghiệm của chúng tôi.

Nhanh? Không! Nó thậm chí còn lâu hơn so với làm một bài kiểm tra thủ công.

Nhưng, có một sự khác biệt lớn ở đây: Đối với các bài kiểm tra trong tương lai, bạn chỉ cần tự viết bài kiểm tra , điểm đạn cuối cùng trong danh sách - được thực hiện nhanh tương đương. Tất cả các nghiên cứu và init-script không cần phải được thực hiện cho các thử nghiệm tiếp theo.

Và sau khi bạn đã viết bài kiểm tra, bạn có thể bắt đầu nó dễ dàng. Trong vài giây (hoặc có thể là vài phút, nếu việc khởi động cơ sở dữ liệu và ứng dụng web mất nhiều thời gian), bạn sẽ thấy liệu thói quen "Thay đổi mật khẩu" có hoạt động hay không. Nếu có lỗi, hãy sửa nó và chạy thử nghiệm lại - bạn sẽ thấy ngay lỗi đó có được sửa hay không. Nhanh chóng và dễ dàng .

Viết bài kiểm tra tự động không dễ và cũng không nhanh ngay từ đầu, nhưng thực hiện chúng là vậy.

Và đây là thời điểm mà thời gian đầu tư quay trở lại.

Kiểm tra nói chung là không dễ dàng, và cũng không nên. Nếu Boeing hoặc Mercedes không kiểm tra các sản phẩm của họ một cách nghiêm ngặt như họ thì họ sẽ bị phá sản do kiện tụng hoặc ra khỏi doanh nghiệp vì bán các mặt hàng kém chất lượng như vậy. bạn sẽ lái xe một chiếc xe hơi ở 70 dặm một giờ biết rằng vô lăng có thể hoặc không thể rơi thành từng mảnh?

Thật khó để đề xuất những cách để đối phó với suy nghĩ mà không hiểu những người đó là ai, hoặc lý do của họ. Hầu hết các nhà quản lý và giám đốc nghĩ về chi phí và được đánh giá bởi những gì được sản xuất. Sử dụng tiêu chí này khiến họ rất khó biện minh cho việc dành thời gian cho các bài kiểm tra. Nếu đây là trường hợp với bạn thì bạn sẽ cần phải tìm cách trình bày nhiệm vụ này là có lợi về lâu dài, tất nhiên là như vậy.

Chỉ vì phần mềm không hữu hình không có nghĩa là chúng ta có thể thoát khỏi mà không cần suy nghĩ về ý nghĩa của các hệ thống chúng ta xây dựng không hoạt động. Tôi cá là Amazon có các bài kiểm tra tự động và tôi cá là có những người ở đó chỉ biết quá rõ các tác động chi phí của các trang web / dịch vụ của họ không thành công.

2 +2 = 4 là một trong những đoạn mã đơn giản nhất mà mọi người đều hiểu; Và bạn có thể thấy như thế nào là dễ hiểu. Nhưng điều này không có nghĩa đó là một phương trình dễ dàng của Wikipedia. Mức độ trừu tượng cần thiết để đạt được phương trình đơn giản là khá phức tạp. Điều tương tự cũng xảy ra với các phương pháp kiểm thử phần mềm và phần mềm. Mức độ trừu tượng đòi hỏi một đoạn mã mất rất nhiều công sức.

Đúng là một thực tiễn tốt dẫn đến việc tái sử dụng các lớp và đối tượng nhưng đồng đều, để đạt đến trạng thái này là cần thiết để đầu tư thời gian và công sức .

Có hai mặt của câu hỏi này.

Về phía bạn, bạn dường như nghĩ rằng bạn đang làm tốt công việc và nhóm "Tự động hóa dễ dàng" không biết họ đang nói về điều gì.

Về phía họ, từ những gì bạn nói, họ thấy các bài kiểm tra tự động thực hiện (theo quan điểm của họ) một thời gian dài để sản xuất.

Từ khoảng cách này, với một chút chúng ta phải tiếp tục, chúng ta không biết ai là "đúng", hoặc nếu có ai "đúng".

Làm thế nào để đối phó với tự động hóa là suy nghĩ dễ dàng

Nói chuyện với họ. Thành thật hỏi ý tưởng của họ về cách nó có thể được thực hiện tốt hơn. Để họ tham gia và tham gia. Đó là cách duy nhất để tìm hiểu xem họ có thực sự có bất cứ điều gì tích cực để cung cấp không. Có lẽ họ có một số đóng góp đáng giá để thực hiện, và bạn có thể đạt được một chiến thắng / thắng.

Nếu họ không có ý tưởng thực sự về cách lập trình và kiểm thử tự động hoạt động, hoặc ý tưởng thực tế về cách cải thiện năng suất, thì việc tham gia chúng một cách tích cực, bạn có thể chỉ ra cách thức thực hiện và thời gian trôi qua. Hãy khiêm tốn và tích cực, cảm ơn họ vì ý kiến ​​/ ý kiến ​​của họ. Hãy suy nghĩ về những gì họ đã nói: có thể những gợi ý của họ sẽ kích hoạt một cách suy nghĩ khác cho bạn. Nếu vậy, cung cấp cho họ thông tin phản hồi. Bằng cách khiêm tốn và tích cực, bạn có thể biến nó thành một chiến thắng / chiến thắng.

Trước khi bạn nói chuyện với họ, hãy nghĩ về cách bạn xây dựng, chạy và quản lý các bài kiểm tra của bạn. Bạn đang sử dụng khuôn khổ nào? Có những người khác có thể tốt hơn? Bạn có nồi hơi "tiêu chuẩn" mà bạn thích nghi không? Có thể xây dựng các bài kiểm tra được tự động hơn? Cái gì đang làm bạn chùng bước vậy?