Những điều QA, Tester nên biết về quá trình quản lý Release và Deploy

Trong cuộc họp nhóm của chúng tôi hôm nay, người quản lý đã kiểm tra với tất cả mọi người về sự “sẵn sàng đêt thực hiện test execution” của họ . Ông đã đề cập đến "code sẽ sẵn sàng cho QA vào buổi sáng ngày codei". Ông đã làm gì khi ông nói "code sẽ sẵn sàng", có nghĩa là các developers sẽ viết code trong môi trường QA tối nay?

Thực sự có nghĩa là việc triển khai dự kiến ​​sẽ được thực hiện vào ban đêm và code mới sẽ được triển khai đến môi trường QA để test.

Nhiều người trong chúng ta bây giờ có thể hỏi, triển khai là gì và họ thực sự làm gì trong nó?

Quy trình quản lý release và deploy tổng thể & tầm quan trọng cho nhóm QA:

• Tại sao chúng ta thực sự duy trì các môi trường khác nhau?
• Và Làm thế nào để code được di chuyển từ môi trường này sang môi trường khác?

Tôi sẽ đề cập đến các chủ đề sau trong bài viết này:

1. Tại sao điều quan trọng đối với tester là phải nhận thức được quá trình triển khai?
2. Các môi trường khác nhau
3. Ý nghĩa của Xây dựng và Triển khai là gì?
4. Kế hoạch với Triển khai Khẩn cấp
5. Danh sách kiểm tra QA - Trước và Sau khi Triển khai

1. Tại sao điều quan trọng đối với tester là phải nhận thức được quá trình triển khai?

Công việc chính của chúng tôi về test execution phụ thuộc vào sự thành công của việc triển khai. Nếu đội triển khai phải đối mặt với nhiều thách thức và gặp phải một số vấn đề và không thể triển khai được code đúng, điều đó sẽ chỉ ra rằng nhóm QA sẽ xác định rất nhiều lỗi có thể gắn liền với môi trường hoặc quá trình triển khai.

• Nếu tester nhận thức được quá trình triển khai, họ sẽ hiểu được tầm quan trọng của việc hoàn thành nhiệm vụ của họ trong khung thời gian dự kiến.
• Các tester sẽ nhận định được nếu vấn đề thực sự là một lỗi chức năng hoặc một cái gì đó gây ra trong quá trình triển khai. Thực tiễn: một tester được assign để test tính năng report nhưng khi họ cố gắng login vào trang web, họ thấy lỗi có nghĩa là môi trường đang không tốt, vấn đề như này không thể coi là các vấn đề chức năng code mà là vấn đề do môi trường khi triển khai. Nếu tester nhận thức được việc này, họ có thể biết đây là một vấn đề do triển khai.
• Nhiều non-issues có thể tránh được nếu tester thực sự biết danh sách đã được deploy. Đôi khi nó xảy ra bạn test và report một issue cho các khu vực code chưa được deploy.

2. Môi trường khác nhau

Trong phân loại trên, có 4 môi trường quan trọng nhất, tuy nhiên nhiều khách hàng vẫn duy trì nhiều môi trường như staging, pre-staging, vv ... Ngoài ra, quy ước đặt tên có thể khác.

• DEV - Môi trường dev là môi trường được tạo ra và duy trì bởi đội Dev để viết code. Việc truy cập cho môi trường này chỉ dành cho nhóm Dev. Thông thường đội ngũ QA không có quyền truy cập vào môi trường này. Môi trường này chủ yếu được nhóm Dev sử dụng để unit test.
• QA - QA môi trường là nơi các kiểm thử thực sự diễn ra. Môi trường này thuộc sở hữu của nhóm QA. Nhóm DEV không có quyền truy cập vào môi trường này. Sau khi thiết kế và hoàn thành code, code được chuyển đến môi trường đảm bảo chất lượng cho nhóm QA để tiến hành kiểm tra.
• UAT - User Acceptance Test là môi trường nơi người dùng doanh nghiệp tiến hành kiểm tra. Điều này được thực hiện sau khi kiểm tra hệ thống đã được hoàn thành. Mục đích chính là kiểm tra hệ thống từ điểm nhìn business. Truy cập vào môi trường này chỉ dành cho người dùng doanh nghiệp (user business). Tuy nhiên, trong một số trường hợp, họ tìm kiếm sự hỗ trợ QA, trong những trường hợp đó, đội ngũ QA được tiếp cận tạm thời với môi trường.
• PROD - Môi trường PROD là môi trường sống thực sự được tiếp xúc với người dùng thực và không có nhóm DEV và QA nào có quyền đọc / ghi vào môi trường này. Các nhóm hỗ trợ sản phẩm được duy trì để giải quyết các vấn đề liên quan đến môi trường sản xuất.

3. Ý nghĩa của Xây dựng và Triển khai là gì?

Một build chủ yếu bao gồm các gói đã biên dịch có thể bao gồm bat, exe, các thư viện như dll, lib, và archives như các file zip. Nhóm phát triển tạo việc xây dựng và cung cấp cho nhóm triển khai để cài đặt.

Việc biên soạn code nguồn chủ yếu được chăm sóc bởi nhóm phát triển và sau khi họ đã tạo ra bản build, họ đặt nó tại một số vị trí nhất định đội triển khai có thể truy cập được để triển khai đến một môi trường khác.

Khi bản build được deploy, nhóm QA được thông báo để thực hiện build verification testing (BVT) và nếu nó thành công, nhóm sẽ thực hiện phần kiểm tra chức năng còn lại

Trong một số tổ chức nơi họ không duy trì đội triển khai riêng, nhóm develop cung cấp xây dựng cho QA, và nhóm QA hoàn thành việc triển khai. Có một nguy cơ lớn liên quan, trong các trường hợp như vậy QA cần hiểu quá trình triển khai xây dựng tổng thể và cũng nên biết làm thế nào để khắc phục nếu một vấn đề xảy ra.

Các builds được duy trì bằng các số nói 1.0.01 hoặc 1.0.03. Vì vậy, có thể build 1.0.01 có thể chạy DLL v0.2 và build 1.0.03 có thể đang chạy DLL v0.5. Nó trở nên quan trọng đối với đội ngũ QA để đảm bảo rằng đúng xây dựng được triển khai trong môi trường trước khi bắt đầu test. Bạn nên theo dõi các thay đổi được cung cấp như một phần của mỗi bản build.

Duy trì một đội triển khai riêng biệt luôn là một điều tốt vì nó giúp cho chuyển code từ môi trường này sang môi trường khác được trơn tru. Triển khai là một quá trình code qua đó code / build được chuyển từ môi trường này sang môi trường khác. Hầu hết các tổ chức ngày nay theo một kênh thích hợp cho việc triển khai, và duy trì một đội riêng biệt những người chăm sóc của tất cả những.

Trước ngày triển khai, một nhóm bao gồm các developers, quản lý phát triển, kỹ sư triển khai, test lead và các bên liên quan kinh doanh khác khác. Trong cuộc họp, developers thường được yêu cầu mô tả sự thay đổi của họ. Họ thường cần phải điền vào một form cụ thể với các chi tiết về những thay đổi và kế hoạch rollback.

Trong trường hợp một số chi tiết bị bỏ qua, những thay đổi không được phê duyệt để triển khai. Nhóm sau đó sẽ quyết định xem sự thay đổi có thể là một phần của việc triển khai ngày hôm sau. Trình tự kiểm tra chất lượng được yêu cầu phê duyệt để đảm bảo rằng thay đổi sẽ không ảnh hưởng đến bất kỳ kiểm tra nào hiện có. Trong cuộc họp, các mục triển khai cuối cùng được lên kế hoạch.

Danh sách đã được phê duyệt được thực hiện bởi đội triển khai vào ngày triển khai. Nhóm chạy một loạt các chương trình như được định nghĩa trong mỗi form thay đổi (do developers cung cấp) và sau đó gửi ra thông tin liên lạc đó khi Triển khai hoàn tất.

Thông điệp Deployment Complete cung cấp một chỉ dẫn cho nhóm QA, rằng các thay đổi / code mới đã sẵn sàng để được test.

Trách nhiệm của nhóm triển khai là chuyển các thay đổi từ DEV sang QA. Sau khi testg hoàn thành, code được chuyển sang UAT. Việc di chuyển dữ liệu PROD là một phần quan trọng nhất và nó phải được thực hiện trong giờ nghỉ, bởi vì trong quá trình triển khai, môi trường cần được down và nó phải được thực hiện cẩn thận vì nó có thể ảnh hưởng nghiêm trọng đến hoạt động kinh doanh.

Hầu hết các triển khai Prod đều được thực hiện vào đêm khuya khi cơ hội của môi trường ảnh hưởng đến người dùng thấp hơn.

4. Kế hoạch so với Triển khai Khẩn cấp

Mỗi Tổ chức duy trì một lịch deploy. Nhiều khách hàng theo dõi triển khai một lần trong một tuần và nhiều người đến dự một tuần một lần, cho biết việc triển khai dự kiến ​​chỉ xảy ra vào thứ ba hoặc có thể xảy ra vào thứ ba và thứ sáu. Những ngày triển khai có thể thay đổi nếu ngày dự kiến ​​triển khai rơi vào kỳ nghỉ.

Trong phần trên, tôi đã đề cập đến quy trình được thực hiện cho bất kỳ triển khai dự kiến nào .

Các kế hoạch triển khai có thể có những thách thức riêng. Hãy suy nghĩ về một trường hợp, nơi code mới được triển khai đến môi trường QA và trong quá trình kiểm tra, nhóm nhận diện một blocked defect và việc kiểm tra phải được dừng lại. Nhóm test có chờ đợi một tuần cho đến khi triển khai tiếp theo không?

Để xử lý các tình huống như vậy, khẩn cấp sửa chữa và triển khai được thực hiện khi dev không cần phải đợi cho đến ngày triển khai kế hoạch. Họ cần phải tuân thủ và tìm kiếm sự chấp thuận ngay cả đối với các trường hợp khẩn cấp, tuy nhiên những sự chấp thuận này thường xảy ra nhanh chóng và những thay đổi mới có thể được triển khai vào môi trường đảm bảo chất lượng trong cùng một ngày hoặc càng sớm càng tốt.

Trước khi triển khai:

Toàn bộ giai đoạn thiết kế test diễn ra trước khi code thực sự được chuyển đến môi trường. Đó là việc thực hiện kiểm tra phụ thuộc vào sự sẵn có của code trong môi trường QA trong khi nhóm triển khai làm việc để nhận code được triển khai trong QA, nhóm QA nên đảm bảo đã hoàn thành các hoạt động dưới đây:

• Đảm bảo các trường hợp test được xem xét và chấp thuận
• Đảm bảo team test luôn available và kế hoạch resource đã hoàn thành
• Đảm bảo các nhu cầu dữ liệu test được xác định

Sau khi triển khai:

Sau khi triển khai, điều đầu tiên chúng tôi làm với đội ngũ QA là bắt đầu test. Nhưng trước khi chúng tôi bắt đầu test, chúng tôi nên đảm bảo rằng sau đây đã được chăm sóc

• Nhóm QA nên nhận được thông báo từ đội triển khai về triển khai thành công và sẵn sàng cho QA.
• Nhóm QA nên theo dõi bản build đã được deploy.
• Đảm bảo đội QA có danh sách các thay đổi được triển khai thành công và cũng không được triển khai cho các mục không được lên kế hoạch. Có thể xảy ra rằng nhóm triển khai không thể triển khai do thiếu chi tiết.. vv

Phần kết luận

Hy vọng bài viết ở trên cho bạn một ý tưởng về quá trình release tổng thể và quản lý triển khai như một phần của chu kỳ phát triển phần mềm tổng thể. Đây chỉ là một thủ tục chung chung được áp dụng ở hầu hết các tổ chức, tuy nhiên nhiều khách hàng có các giao thức khác nhau.

Bài viết được tham khảo bởi: http://www.softwaretestinghelp.com/qa-testing-release-and-deployment-management-process/