Xu hướng trong testing: CONTINUOUS DELIVERY, PRODUCTION LINE và THE DEPLOYMENT PIPELINE

Theo Michael Hackett, Tập đoàn LogiGear

Nếu bạn quan tâm đến xu hướng phát triển phần mềm - từ quan điểm của một số nhóm lớn đang làm, những bài báo và sách đang được viết ra, các chủ đề hội nghị, bạn có thể đã nhận thấy các công cụ đang được phát triển - đã có những chuyển đổi trong thập kỷ qua :

• Các bản Release càng ngày càng nhỏ
• Các công cụ xây dựng và triển khai mã nguồn thay đổi theo hướng triển khai.
• Infrastructure-as-code với các công cụ mới và việc sử dụng đám mây mang lại giá trị cho khách hàng nhanh hơn và thường xuyên hơn - giúp loại bỏ hoặc giảm thiểu các vấn đề môi trường, cài đặt, cung cấp và triển khai.

Tất cả điều này đã yêu cầu sự thay đổi về quá trình và văn hoá. Một số tư duy và nền văn hóa cũng đã phải thay đổi theo các nhóm kiểm thử.

1.Chia sẻ quyền sở hữu về chất lượng-các tác vụ được phân phối rộng rãi hơn trên toàn bộ nhóm dựa theo chất lượng 2.Sản phẩm trên đường đi phải luôn sẵn sàng để triển khai. Luôn tách chất lượng ra. Loại bỏ các vấn đề kỹ thuật. 3.Bản release nhỏ làm giảm nguy cơ, tăng tốc độ, và tạo ra phản hồi ngay lập tức.

Để hiểu đầy đủ về sự thay đổi trong tư duy phát triển, hãy xem xét đọc sách của Jez Humble và David Farley về Continuous Delivery xem xét vấn đề này, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Đây là cuốn sách cuối cùng về Continuous Delivery.

Trong khi hầu hết các nhóm phát triển phần mềm riêng lẻ không nói về tính dự đoán và lập kế hoạch-là nhu cầu kinh doanh cho nhà tài trợ. Phát triển phần mềm đã trở thành chủ đạo. Mỗi tổ chức kinh doanh hiện đại đều có đội ngũ phát triển phần mềm cũng như đội ngũ kế toán và nhân sự. Những đội dễ đoán và cung cấp một sản phẩm đã có từ trước. Họ bị ép phải làm việc theo cùng 1 khuôn mẫu. Ý tưởng là, với sự phát triển phần mềm đang trở thành chủ đạo, nó cần phải dễ đoán hơn, dễ quản lý hơn, và đáp ứng nhiều hơn cho kinh doanh. Nó được mong đợi sẽ mang lại giá trị kinh doanh và không lâu sau sẽ trở thành kho tàng.

Continuous Delivery kết hợp một số nguyên tắc về gia công của XP (eXtreme Programming) và Lean Manufacturing Principles:

1. Bản release nhỏ
2. Tích hợp liên tục
3. Sở hữu tập thể
4. Cung cấp sản phẩm nhanh nhất có thể
5. Chất lượng ở mọi bước
6. Xem toàn cảnh

Dựa theo quy trình này, nhiều người đã bắt đầu xem xét phát triển phần mềm trên khía cạnh quy trình phát triển. Mặc dù có nhiều cuộc tranh luận về chủ đề này cho các nhóm kiểm thử ở nhiều tổ chức, nó đã đến dù bạn có muốn hay không.

Những ý tưởng về Lean, XP, và quy trình phát triển đi liền với các công cụ được sử dụng ngày nay đang đẩy chúng ta phát triển sản phẩm như một quy trình phát triển. Các bộ công cụ có thể tự động truyền các đoạn mã nguồn từ môi trường này sang môi trường khác, trở nên hướng sản phẩm, dẫn đến các bản phát hành nhỏ được thử nghiệm ở mọi bước- thường xuyên và nhanh chóng được triển khai.

Bước tiến Infrastructure-as-code – làm sáng tỏ hạ tầng và làm cho nó có thể tái thiết kế và phù hợp hơn với tự động hóa- đã đến, và việc sử dụng các dịch vụ đám mây đang làm cho nó thậm chí nhanh hơn. Một lưu ý quan trọng ở đây là đối với nhiều nhóm, tái thiết kế kiến ​​trúc sản phẩm để phù hợp với các mô hình này thường là một vấn đề lớn và khó khăn.

Các công cụ, cơ sở hạ tầng, thực tiễn và các kỹ năng mới đang thúc đẩy phát triển sản phẩm trở thành một quy trình phát triển ổn định, lặp lại và phù hợp hơn, đồng thời đưa ra phản hồi tức thì. Quy trình phát triển chuyển từ xây dựng sang kiểm thử, sau đó được nâng cấp lên các môi trường mới với việc kiểm thử ở từng bước. Cuối cùng, các thành phần mới trên quy trình phát triển được triển khai. Tất cả điều này xảy ra với infrastructure-as-code. Nhiều người tin rằng phát triển phần mềm là một hình thức nghệ thuật, nó cần các giải pháp độc đáo và sáng tạo cho các khách hàng quan trọng với nhu cầu thay đổi liên tục trên các nền tảng và thiết bị thay đổi nhanh chóng. Nó cần sự thay đổi của DevOps / CD theo cách mọi người xem sự phát triển sản phẩm của họ. CI tập trung vào nhóm lập trình viên và kiểm thử; CD tập trung vào nhóm Ops. Khi nào CI kết thúc, CD sẽ bắt đầu xây dựng các bản chạy/phiên bản/bản triển khai, và cuối cùng triển khai trên các môi trường thực.

Bất kể niềm tin cá nhân của tôi về phát triển phần mềm là một quy trình sản xuất, ý tưởng cho rằng "dòng sản phẩm" là hình ảnh và mô tả dòng sản phẩm thông qua quá trình phát triển và chuỗi công cụ, hiện đã trở nên vững chắc. Quy trình triển khai là một biến thể của quy trình phát triển.

Rõ ràng trong Agile là chất lượng là công việc của mọi người. Tương tự như vậy, mọi người đều sở hữu một phần chất lượng. Trong CD, mọi người đều làm công việc triển khai. Mọi người đều chia sẻ một phần của việc triển khai. Nếu giúp triển khai không phải là công việc của bạn, vậy tại sao bạn lại phát triển sản phẩm?

Nhiều thứ phải thay đổi về sản phẩm để có được những ý tưởng này được thực hiện: thay đổi kiến ​​trúc, thay đổi công cụ, học các kỹ năng mới để tạo sự thuận lợi, thay đổi văn hoá, suy nghĩ lại ý tưởng về phát hành tất cả để triển khai trơn tru và dễ dàng. Cũng như tất cả các quy trình phát triển, nó sẽ gây tắc nghẽn.

Mục đích của quy trình là một dòng chảy liên tục của công việc chất lượng cao, đã hoàn thành / luôn sẵn sang triển khai. Hãy giữ quy trình luôn chạy.

Nhận được rất nhiều phản hồi tức thì và ngay lập tức cho nhóm: Nó có hiệu quả không? Khách hang có sử dụng nó? Các trường hợp sử dụng thực tế là gì?

Như Jez Humble từ Continuous Development cho biết, giải pháp là để áp dụng "một cách tiếp cận toàn diện hơn để cung cấp phần mềm."

Một phần của quy trình phát triển xuất là tìm kiếm sự tắc nghẽn và thiếu hiệu quả. Điều này được quản lý bởi các ràng buộc. Bất cứ điều gì đang chậm lại việc triển khai phải được giải quyết và sửa ngay lập tức để giữ cho quy trình chạy. Như một lời cảnh báo cho các nhóm kiểm thử: nếu quy trình bị hạn chế bởi việc kiểm thử và / hoặc do thiếu tự động kiểm thử - nhóm sẽ phải khắc phục.

Sự tắc nghẽn trong quy trình kìm hãm lại toàn bộ nhóm. Việc xây dựng, thúc đẩy, ảo hóa hoặc tựu động hóa các tác vụ của cơ sở hạ tầng đám mây và tốc độ nhanh của những cú đẩy nhỏ có thể nhanh chóng cho thấy rằng thiếu kiểm thử tự động gây tắc nghẽn quá trình sản xuất. Làm tất cả những gì bạn có thể để ngăn chặn nỗ lực kiểm thử khỏi bị tắc nghẽn! Không làm đủ việc kiểm thử tự động sẽ gây ra tắc nghẽn.

Điều này không có nghĩa là bạn nên làm sản phẩm chất lượng kém. Điều đó có nghĩa là bạn nên xác định sản phẩm chất lượng kém với việc kiểm thử tự động tự động và nhận phản hồi về chất lượng kém cho nhóm ngay khi có thể.

Những gì tôi muốn tập trung vào các nhóm kiểm thử, trong chủ đề của quy trình phát triển, là hai ý tưởng từ lean: 1.Chất lượng ở mọi bước. 2.Xác định các nút cổ chai và sửa chữa / gỡ bỏ chúng.

Với công việc của tôi trong các nhóm kiểm thử, tôi muốn tập trung vào chất lượng ở mọi bước và tại các điểm có thể kiểm thử trong quy trình phát triển. Lý do tại sao các nhóm kiểm thử, và cụ thể là kiểm thử tự động, không thể trở thành nút cổ chai, là nút cổ chai sẽ được sửa. Và bạn có thể không biết về cách nó được cố định.

Thực tế ngày nay là ở Thung lũng Silicon và những nơi khác, nhiều công ty đã làm việc với các phòng QA và kiểm thử được thực hiện bởi các lập trình viên ở cấp đơn vị nhỏ, và với việc sử dụng Microservices và các vật chứa. Kiểm thử được thực hiện với các API ở cấp API / services và có rất ít hoặc không có việc kiểm thử nào được thực hiện ở cấp UI.

Điều này sẽ ảnh hưởng đến chất lượng sản phẩm, nhưng ở mức độ thấp hơn nhiều so với trước đây, khi kiểm thử các đơn vị nhỏ là bí ẩn, nếu nó được thực hiện. Trong các tổ chức này, kiểm thử các đơn vị nhỏ là một tác vụ chính thức, có thể lặp lại, có ý nghĩa và là lối vào cho bất kỳ bước nào trong tiến trình triển khai. Đối với các nhóm kiểm thử ngày nay, mức độ kiểm thử tự động cần phải tăng lên.

Đối với các quy trình phát triển, để tiếp tục di chuyển với việc phản hồi ngay lập tức không có nghĩa là lấy một bộ hồi quy tự động và làm nó chạy nhiều lần và lặp đi lặp lại. Điều đó không đảm bảo chất lượng hoặc sự đảm bảo. Có những thời điểm nhất định, đặc biệt với mã nguồn mới, rằng việc kiểm thử đợn vị nhỏ có hiệu quả nhất để phản hồi ngay lập tức. Có những thời điểm khác mà kiểm thử API hoặc dịch vụ là cách tốt nhất và vẫn còn những chỗ khác có thể kiểm thử giao diện trong quy trình phát triển. Về việc kiểm thử đơn vị nhỏ nhiều hơn và lặp lại, xem hình ảnh trên. Hầu hết mọi người sẽ nhận ra tam giác tự động đảo ngược hoặc lật lại. Nó không phải là mới đối với hầu hết mọi người, nhưng các nhóm cần phải nhận ra rằng sự thay đổi này đã xảy ra và sẽ chỉ tiếp tục phát triển.

Điều này có nghĩa là việc giữ quy trình tiếp tục chạy này là để tự động hóa tất cả mọi thứ bạn có thể. Chúng tôi biết rằng trong quá trình chạy nước rút, có một nhu cầu tuyệt đối cho việc kiểm thử bằng tay. Sự cần thiết phải kiểm thử bằng tay sẽ không bao giờ biến mất. Nhưng, nó đang trở nên nhỏ hơn.

Chúng tôi đảm bảo việc tự động kiểm thử của chúng tôi hiệu quả nhất có thể. Điều này không nhất thiết có nghĩa là chúng tôi tự động kiểm thử nhiều hơn. Thay vào đó, chúng tôi tự động hoá các bài kiểm thử có ý nghĩa và đáng ghi nhận nhất.

Chúng tôi tự động hóa nhiều như chúng ta cần để cung cấp cho các phản hồi ngay lập tức cho nhóm: tự động hóa một cách thông minh hơn.

Con số đó có thể là hàng trăm hoặc hàng ngàn hoặc hàng chục nghìn - nó phụ thuộc vào hệ thống. Nhưng tự động kiểm thử nhiều hơn không phải lúc nào cũng có nghĩa là chất lượng cao hơn. Chúng ta đều biết điều này, nhưng nó vẫn lặp đi lặp lại.

Những gì chúng tôi đang hướng tới hiện tại cho việc kiểm thử trong CD là một chiến lược tự động hoá; Những bài kiểm thử để chạy và khi nào làm chúng – khi sản phẩm sẵn sàng? Tại giao diện nào? Tại môi trường nào? Với những dữ liệu nào? Khi nào? Đó mới là một chiến lược tự động hóa.

Hãy nhớ rằng khi bạn xây dựng các kế hoạch cho quy trình CD, tự động kiểm thử không có nghĩa là thiếu lỗi. Kiểm thử tự động cho thấy sự nhất quán tại lần lặp cuối cùng. Nó cho thấy sự ổn định và khả năng dự đoán. Không tìm thấy lỗi không có nghĩa rằng không có lỗi - nó cho thấy rằng các lỗi vẫn chưa được tìm thấy.

Các loại kiểm thử khác, bằng tay hoặc tự động, vẫn cần được làm. Chúng tôi vẫn cần tập trung vào việc tìm kiếm lỗi trước khi mã nguồn đi vào quy trình chính.

Nhận được phản hồi ngay lập tức thường bị bỏ qua trong việc vội vàng thực hiện tự động hóa. Kiểm thử tự động cần chạy để hiển thị mã nguồn hoặc sản phẩm đó đã sẵn sàng để chuyển sang bước tiếp theo trong quy trình. Chú ý đến thông tin mà bạn đang phản hồi lại nhóm.

Thông tin này có ý nghĩa gì? Có phải chỉ là một số bài kiểm thử đã thành công hay không? Tỷ lệ phần trăm các bài kiểm thử thành công? Nó có ý nghĩa toàn cục không? Làm thế nào để bạn nói với đội sản phẩm đã sẵn sàng để đi đến bước tiếp theo của quy trình?

Ngoài ra, phải biết bao lâu bạn phải nói cho họ biết điều này. Nếu việc kiểm thử hồi quy tự của bạn mất 5 ngày để chạy xong – nó sẽ không thể áp dụng trong CD. Đây sẽ là nút cổ chai. Hãy nhớ rằng mục tiêu tự động hoá là hiệu quả, không chậm và cồng kềnh.

Phát triển sản phẩm đã trở thành một quy trình sản xuất. Triển khai quy trình là một dòng chảy được hỗ trợ bởi các chuỗi công cụ để hỗ trợ môi trường Ops / IT, cung cấp, quản lý cấu hình, triển khai, vv. Tìm kiếm sự thiếu hiệu quả và ngăn chặn sự chậm trễ trong tiến trình.

Hãy chắc chắn rằng thử nghiệm không phải là nút cổ chai. Tự động hoá phải thông minh hơn. Mục tiêu của sự hồi quy là hiệu quả hơn và hơn nữa. Khi tự động hoá thông minh hơn và hiệu quả hơn, các nhóm có phản hồi tức thì và có ý nghĩa.

Bài viết được dịch lại từ blog: http://www.logigear.com/magazine/exploratory-testing/mega-trends-in-testing-continuous-delivery-production-line-and-the-deployment-pipeline/