Kiểm tra tự động: Giải thích giá trị kinh doanh của nó

Để bắt đầu, tôi không nghĩ rằng đây là sự lặp lại của các câu hỏi khác trong bài kiểm tra đơn vị . Những gì tôi đang tìm kiếm sự giúp đỡ là nói rõ giá trị của nó với một nhóm lập trình viên, nhà phân tích, nhà quản lý và người thử nghiệm. Bằng các bài kiểm tra tự động, tôi không nghĩ mình cần phân biệt giữa các bài kiểm tra đơn vị (ví dụ JUnit), BDD (ví dụ JBehave, Fitness) và UI (Selenium, Watir) vì tôi nghĩ rằng tất cả chúng đều cung cấp giá trị tương tự (nhưng cảm thấy tự do viết một câu trả lời không đồng ý :))

Sau đây là danh sách tôi đã xác định, tôi đang tìm câu trả lời giúp mở rộng hoặc tinh chỉnh:

1. Tiết kiệm thời gian / chi phí : viết bài kiểm tra tự động có thể mất nhiều thời gian hơn so với trường hợp kiểm tra bằng văn bản. Tuy nhiên, việc xem xét các bài kiểm tra được thực hiện nhiều lần, công việc cận biên (tức là chi phí / thời gian) để thực hiện các bài kiểm tra tự động ít hơn một số đơn hàng. Rằng các bài kiểm tra tự động có giá rẻ để chạy tạo điều kiện thay đổi hệ thống theo thời gian.
2. Tài liệu : không có cách xác thực nào để biết hệ thống hoạt động như thế nào so với các thử nghiệm của nó. Bất kỳ tài liệu nào khác thường hết hạn vào thời điểm nó được viết, nhưng các bài kiểm tra (ít nhất là những tài liệu đã qua) cho thấy mọi thứ thực sự hoạt động như thế nào. Điều này đúng cho cả tài liệu API và người dùng cuối.
3. Mã chất lượng : kiểm tra viết buộc bạn phải:
   • xem xét khách hàng vì các bài kiểm tra là một khách hàng
   • phá vỡ các phụ thuộc trong đó việc tạo mã có thể kiểm tra thường có nghĩa là tìm ra cách làm cho mã đó không yêu cầu một số hệ thống lớn khác có sẵn

Một vài suy nghĩ của tôi:

1. Hãy thành thật rằng viết bài kiểm tra tự động sẽ mất nhiều thời gian hơn. Nếu bạn đang thực hiện TDD cấp đơn vị (mà tôi muốn giới thiệu là điểm khởi đầu nếu bạn sẽ đầu tư vào thử nghiệm tự động), bạn có thể mong đợi thêm khoảng 30% thời gian cần thiết để mã hóa một tính năng. Chìa khóa ở đây là giải thích rằng 30% thêm này (có thể cao hơn 30% khi bắt đầu khi nhóm của bạn học cách viết bài kiểm tra tốt) là một khoản đầu tư được xây dựng để tiết kiệm chi phí theo thời gian. Ít nhất là với TDD cấp đơn vị, thiết kế hệ thống của bạn được kết nối lỏng lẻo và có tính gắn kết cao, giúp hệ thống của bạn có thể thích ứng để thay đổi theo thời gian. Yêu cầu mới và lỗi không mong muốn luôn yêu cầu thay đổi hệ thống của bạn,
2. Có rất nhiều tranh luận về giá trị của các bài kiểm tra mức độ Chấp nhận và mức độ UI được đưa ra trong khoảng thời gian để viết các bài kiểm tra này, mất bao lâu để chạy chúng và yêu cầu bảo trì bao nhiêu. Tôi khuyên bạn nên đọc bài viết này của James Shore về điều này.
3. Trong thế giới của kiểm thử tự động, có những cách tốt và cách xấu để làm điều đó. Nếu bạn đang thử nghiệm tự động cho quản lý của mình, tôi sẽ đồng ý với cách bạn dự định làm cho nhóm của mình được đào tạo để viết các bài kiểm tra tốt. Nghệ thuật kiểm tra đơn vị của Roy Osherove, Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers và Nghệ thuật phát triển nhanh nhẹn của James Shore đều là những cuốn sách tuyệt vời liên quan đến các chủ đề này trực tiếp hoặc gián tiếp. Bạn cũng nên xem xét một số loại huấn luyện viên hoặc đào tạo chính thức là tốt. Đó là một thay đổi lớn.
4. Về giá trị doanh nghiệp, # 2 và # 3 trong số các điểm của bạn ở trên thực sự phục vụ điểm đầu tiên của bạn, vì vậy tôi sẽ tập trung vào điểm số 1 và nói về cách số 2 và # 3 phục vụ điểm lớn hơn đó. Tài liệu làm cho hệ thống của bạn dễ hiểu hơn, điều này làm cho nhóm của bạn làm việc nhanh hơn. Mã chất lượng làm cho hệ thống của bạn có thể thích ứng với thay đổi, điều này làm cho nhóm của bạn làm việc nhanh hơn. Đối với những người kinh doanh, tất cả chỉ là tối đa hóa luồng giá trị từ khi một ý tưởng được đưa ra cho đến khi ý tưởng được đưa ra dưới dạng phần mềm hoạt động.

Một điều có giá trị nhất định là các bài kiểm tra tự động hóa có thể được chạy liên tục; chẳng hạn như mỗi giờ trên một xây dựng lại hoặc tương tự. Việc làm này buộc bất kỳ lỗi hoặc hồi quy nào mở ra nhanh chóng trong vài giờ hoặc vài ngày kể từ khi lập trình viên làm việc với mã vi phạm, điều này làm cho việc chuyển đổi ngữ cảnh dễ dàng hơn nhiều. Lợi ích thứ hai đối với việc kiểm tra liên tục là nó buộc bạn phải kiểm tra bạn ở trạng thái hoạt động; không có gì tẻ nhạt hơn việc dành tuần đầu tiên của một chu kỳ kiểm tra sửa chữa tất cả các bài kiểm tra lỗi thời. Nếu bạn có thể tự động hóa chúng, bạn có thể chạy chúng bất cứ lúc nào và bằng cách chạy chúng thường xuyên, bạn có thể bắt lỗi trong các bài kiểm tra hoặc mã của mình một cách nhanh chóng.

Chi phí kiểm tra

Khi một bài kiểm tra tự động được viết, nó có thể được chạy bằng máy tính với chi phí của một vài joules. Bài kiểm tra thủ công tương đương yêu cầu một người trong biên chế làm việc với một danh sách các hướng dẫn.

Kiểm tra độ tin cậy

Máy tính có thể được tin cậy để thực hiện trung thực cùng một quy trình kiểm tra, mọi lúc. Con người có khả năng phạm sai lầm và lười biếng.

Các chế độ lỗi kiểm tra của máy tính cũng dễ thấy hơn nhiều - nó bị lỗi (báo cáo kiểm tra dừng xuất hiện), nó có một chút lỗi gây ra kết quả kiểm tra sai (chạy lại kiểm tra xác định và kết quả khác). Nếu một người bỏ lỡ một bước và kiểm tra "OK", làm thế nào chúng ta có thể nói?

Kiểm tra độ bền

Kiểm thử tự động phải là một tạo phẩm cụ thể (ví dụ: một đoạn mã) để chạy và được bao gồm một cách tự nhiên với các tạo phẩm phát triển phần mềm khác - kho lưu trữ nguồn. Một bài kiểm tra thủ công có thể được phát triển trên một tờ giấy ghi chú của người kiểm tra và không bao giờ được chính thức hóa. Doanh nghiệp có nhiều khả năng cần các quy trình tại chỗ để đảm bảo điều đó không xảy ra.

Bài kiểm tra giá trị

Máy tính có thể được lập trình để xuất kết quả kiểm tra dưới dạng nhất quán, dễ dàng phân tích. Người này đang thực hiện nhập dữ liệu để tạo giống nhau hoặc đang ghi lại các ghi chú dạng tự do yêu cầu nhà phân tích, nhà phát triển hoặc người quản lý để tiêu hóa.

Hầu hết (tùy thuộc vào phạm vi kiểm tra của bạn) mã không có lỗi và tôi sẽ nói rằng một trong những tranh luận lớn nhất là khi bạn nói với người quản lý của mình rằng bạn có thể viết một bài kiểm tra cho một lỗi được phát hiện, đảm bảo bạn sẽ luôn biết trong tương lai nếu lỗi đó quay trở lại :)

Ý kiến ​​của tôi là các bài kiểm tra đơn vị / tích hợp là quan trọng nhất, trong khi nếu bạn áp dụng một số mẫu UI như MVC thì nó là đủ cho hầu hết các dự án. Tôi thường kiểm tra tất cả các hành động trên bộ điều khiển / người thuyết trình của mình và để lại cơ sở dữ liệu cho Chế độ xem.

Tất nhiên, kiểm tra tự động không thay thế điểm cũ tốt và nhấp vào phiêu lưu xung quanh ứng dụng của bạn để cố gắng tìm ra những điều điên rồ nhất mà người dùng của bạn có thể làm.

Ngoài ra còn có một điểm tích hợp liên tục .

Một điều nữa - người ta phải cố gắng rằng chất lượng mã dẫn đến chất lượng sản phẩm, giá trị kinh doanh và khả năng bảo trì - nếu không thì không có lý do gì để làm điều đó.

Tôi nghĩ bạn nên dẫn đầu với các điểm kỳ diệu là "Chi phí thấp hơn" và "nhiều tính năng / thời gian đơn vị" / thời gian chu kỳ nhỏ hơn.

Tuy nhiên trước khi gây án, tôi khuyên bạn nên suy nghĩ về tình huống của bạn. Câu hỏi của bạn đã khiến tôi viết một bài đăng trên blog về những nhược điểm tiềm năng của kiểm tra tự động.

Dễ tái cấu trúc là một yếu tố lớn ở đây. Có phạm vi bảo hiểm tốt bằng thử nghiệm đơn vị đẹp và ĐỌC (!!!), bạn có thể cấu trúc lại hệ thống của mình mà không lo lắng về việc ảnh hưởng đến chức năng hiện có.

Bạn phải bán khái niệm - bạn cần tránh nói với họ rằng nó sẽ cải thiện mã. Nếu họ có bất kỳ khoản đầu tư nào vào mã sẽ ngay lập tức đưa họ chống lại bạn / tự động kiểm tra. Nếu họ giỏi, họ cũng sẽ hiểu về GIGO nên sẽ không hiểu tại sao bạn nghĩ nó không áp dụng.

Tôi cũng sẽ bán nó dưới dạng khía cạnh tài liệu, những thứ như Fitnesse có thể làm tốt điều đó, nhưng cho đến khi họ trải nghiệm có thể khó hình dung.

Khu vực tôi nghĩ rằng có thể có may mắn bán nó trên

1. Kiểm thử đơn vị có thể thay thế nhiều khai thác của nhà phát triển - nơi bạn tạo ứng dụng chỉ để lấy tại khu vực để gỡ lỗi / kiểm tra mà không cần thông qua tất cả các đăng nhập / menu.

2. Các thử nghiệm cho phép bạn thiết lập và dễ dàng lặp lại các tình huống sự cố - mà không mất nhiều thời gian để thiết lập dữ liệu thử nghiệm (đặc biệt là sử dụng hệ thống mô phỏng tốt)

3. Khi bạn xây dựng các bộ kiểm tra BDD & UI - bạn sẽ nhận được phản hồi nhanh hơn nhiều nếu có các khoảng nghỉ đơn giản hơn là đợi lần tới khi người kiểm tra xem xét

4. Kiểm tra BDD & UI có thể tránh bạn nhấn nút liên tục để kiểm tra tất cả các khía cạnh có thể bị ảnh hưởng bởi thay đổi của bạn và giúp bạn phải nhớ mọi khu vực.

5. Bản dựng tự động thường nổi bật khi ai đó quên kiểm tra mã

6. Các xét nghiệm giúp bạn tránh lỗi xuất hiện trở lại.

7. Kiểm tra đơn vị và mô phỏng tốt sẽ có nghĩa là mã liên kết ít hơn và sẽ dễ giải quyết hơn

Hãy nhớ rằng bạn đang cố gắng bán nó, không chuyển đổi chúng thành tôn giáo - vì vậy hãy chấp nhận các bước nhỏ và cố gắng không để họ chống lại bạn. Nó cũng sẽ mất thời gian để họ điều chỉnh và học cách viết các bài kiểm tra tốt.

Ai đó phải tin rằng có một vấn đề trước khi họ chấp nhận một giải pháp đề xuất cho vấn đề đó.

Kiểm tra tự động có thể tiết kiệm chi phí sửa lỗi, vì vậy nếu đồng nghiệp của bạn không tin rằng chi phí sửa lỗi là lớn hoặc quá mức, họ sẽ khó thuyết phục. Nếu những chi phí đó cao hoặc quá cao, nhưng mọi người không tin chúng là, trước tiên bạn có thể phải có được một số dữ liệu thuyết phục về những chi phí đó.

Những gì doanh nghiệp yêu thích là tăng giá trị và giảm chi phí. Bạn phải giải thích cách kiểm tra tự động sẽ tăng giá trị vì nó làm tăng thêm chi phí.

Nếu mã của bạn là mô-đun, nó sẽ có thể sử dụng lại nó. Điều đó có nghĩa là các bài kiểm tra không phải viết lại nhiều lần và bạn chỉ có thể làm việc trên đầu mã hiện có.

Nếu có các dự án cũ, thử nghiệm tự động làm cho việc tái cấu trúc dễ dàng hơn nhiều. Các khoản nợ kỹ thuật phải được trả xuống tại một số điểm.

Đối số tài liệu bạn cung cấp không phải là rất tốt. Sự khác biệt giữa việc giữ các bài kiểm tra cập nhật và tài liệu cập nhật chỉ là thói quen.

"Điều tôi đang tìm kiếm sự giúp đỡ là nói rõ giá trị của nó với một nhóm lập trình viên, nhà phân tích, người quản lý và người kiểm tra. Bằng các bài kiểm tra tự động, tôi không nghĩ mình cần phân biệt giữa các bài kiểm tra đơn vị (ví dụ JUnit), BDD ( ví dụ JBehave, Fitness) và UI (Selenium, Watir) bởi vì tôi nghĩ rằng tất cả chúng đều cung cấp giá trị tương tự (nhưng hãy thoải mái viết một câu trả lời không đồng ý :)) "

OK tôi sẽ thực hiện thử thách đó;)

Tôi chủ yếu làm việc với các lập trình viên và QA và các công cụ của tôi là ruby, rails, testunit, rspec, jasmine và selenium.

Các công cụ BDD / TDD của rspec và testunit là một phần của lập trình. Bạn không tách chúng ra và nói về chúng một cách riêng biệt với quản lý, bạn không loại bỏ chúng do thiếu thời gian, bạn đưa chúng vào tất cả các ước tính thời gian của bạn. Nếu thực sự bị thúc đẩy, mọi người dành cho bạn bao nhiêu thời gian để giải thích về khoa học máy tính và lập trình cho họ. Tôi không sử dụng các thử nghiệm này cho mặt trước

GUI / UI / Jasmine / Selen. Đây là khác nhau. Tôi có những điều này được thực hiện bởi những người QA có nền tảng lập trình viên. Chúng tôi đảm bảo các bài kiểm tra được viết sao cho mạnh mẽ nhất có thể và dựa trên nội dung không phải bố cục. Chi phí (có thể mới) của điều này nên được giải thích là chi phí thay đổi . Thay vì thanh toán bằng phần mềm bị hỏng, mất khách hàng và sửa lỗi đắt tiền sau này, bạn trả ít hơn rất nhiều (tương đối) bây giờ với một vài thực hành đơn giản.

Tôi nghĩ rằng chìa khóa là nói về các loại thử nghiệm cụ thể mà bạn sẽ tạo, chứ không phải là "thử nghiệm tự động" nói chung. Điều thứ hai có thể là một chút mơ hồ và đáng lo ngại, và quá dễ dàng để đưa ra các ví dụ về nơi sẽ lãng phí thời gian.

Tôi luôn khuyên bạn nên chia bài kiểm tra của mình thành 4 nhóm (chi tiết hơn ở đây ). Hãy gắn bó với tôi ở đây, tôi sẽ tìm hiểu cách thức này giúp bạn bán thử nghiệm cho người khác ngay lập tức.

1. Kiểm tra chức năng cốt lõi của bạn . Tức là, đối với một công cụ giám sát trang web, đây sẽ là các thử nghiệm cảnh báo sẽ kích hoạt cho các trang web bạn đang theo dõi. Các xét nghiệm này đảm bảo công cụ này không bao giờ phá vỡ.
2. Kiểm tra khói của toàn bộ ứng dụng của bạn . Ví dụ: sử dụng Selenium để điều hướng tất cả các liên kết / nút trong ứng dụng web và đảm bảo không có lỗi từ máy chủ. Những bài kiểm tra này tránh cho bạn lãng phí thời gian của người kiểm tra với các bản dựng rõ ràng bị hỏng.
3. Các thử nghiệm của bất kỳ mã mong manh . Tức là, đối với mô-đun cũ đó, không ai muốn chạm vào, hoặc đoạn mã phức tạp dường như luôn có lỗi trong đó.
4. Các thử nghiệm mà các nhà phát triển muốn viết để hỗ trợ công việc của họ . Bởi vì đôi khi các bài kiểm tra rất hữu ích khi bạn viết một cái gì đó, nhưng không thuộc các loại trên.

Bằng cách chia các bài kiểm tra của bạn ra thành các loại này, giờ bạn có thể có một cuộc thảo luận khác. Lấy ba nhóm đầu tiên (thứ tư là tùy ý cá nhân) và hỏi xem mọi người có nghĩ rằng các thử nghiệm cho các đoạn mã đó sẽ có giá trị không? Nếu bạn không thể có được sự đồng ý, có thể bạn không bao gồm các bài kiểm tra đó ngay bây giờ. Nếu bạn có thể, tức là nếu mọi người đồng ý rằng các thử nghiệm xung quanh chức năng cốt lõi được thực thi trên mỗi cam kết là hữu ích, thì hãy bắt đầu thêm chúng.

Nhóm khác có thể hữu ích là các bài kiểm tra khó hoặc tốn thời gian để thực hiện thủ công . Cần có một lợi ích khá dễ dàng để giải thích ở đây về việc tiết kiệm thời gian kiểm tra thủ công hoặc kiểm tra những thứ bị bỏ qua vì thiếu thời gian.