Đặt hàng / Xử lý hàng nghìn lỗi ngay trước khi phát hành
Câu hỏi này đã được hỏi tôi trong một cuộc phỏng vấn với một công ty thực sự tốt, sau đây tôi sẽ cung cấp câu hỏi dưới dạng tương tác của chúng tôi (M: tôi & tôi: người phỏng vấn). Mặc dù không có câu trả lời chính xác nhưng tôi cần biết những gì ý tưởng / câu trả lời mà người phỏng vấn thực sự muốn :
I: Kịch bản là bạn và 2 người khác trong nhóm thử nghiệm. Bạn, người dẫn đầu, là người duy nhất có thể tự động hóa, những người khác chỉ có thể kiểm tra thủ công. Bạn có gần 10.000 lỗi đã được phát sinh và bạn có 4-5 tuần hoặc ít hơn trước khi sản phẩm này được giao. Bạn sẽ làm gì để đảm bảo rằng sản phẩm được giao đúng thời hạn?
M: Hãy lọc ưu tiên lỗi một cách khôn ngoan và kiểm tra lại chúng. Trong thời gian chờ đợi, hãy ghi nhật ký về những chức năng nào đang gặp phải nhiều hồi quy hơn và do đó bắt đầu tự động hóa chúng. Các lỗi tương tự hoặc có liên quan sẽ được đưa cho những người khác để kiểm tra thêm.
I: Giả sử không có lỗi nào được đánh dấu ưu tiên. Bạn sẽ làm gì?
M: Tôi sẽ lọc theo ngày tháng. Trong bất kỳ loại SDLC nào, kể cả loại nhanh, các thành phần cốt lõi được phát triển trước tiên, nếu có lỗi cốt lõi, chúng cần được sửa trước.
Tôi: (Không tán thành) Điều gì sẽ xảy ra nếu một chức năng rất quan trọng được thêm vào trong nước rút sau? Ngoài ra, bạn sẽ sử dụng đồng đội và khả năng tự động hóa của mình như thế nào.
M: Cùng với ngày tháng, với tư cách là người thử nghiệm, tôi sẽ phải biết các chức năng cốt lõi & quan trọng của sản phẩm cho đến thời điểm hiện tại. Vì vậy, hãy ghi nhớ điều đó sẽ tìm ra các lĩnh vực cốt lõi của mỗi sprint để làm việc (về nhóm đã trả lời giống nhau như trước).
I: Giả sử, các lỗi chưa được đánh dấu bằng dòng thời gian của mỗi sprint. Bạn sẽ làm gì?
M: Tôi sẽ tìm kiếm danh sách lỗi với các từ khóa đại diện cho các chức năng quan trọng mà sản phẩm không thể được phát hành. Tôi sẽ chọn lỗi từ đó.
Tôi: (Một lần nữa không tán thành) Với một từ khóa, bạn sẽ nhận được rất nhiều kết quả, bạn sẽ lướt qua từng kết quả một?
M: (dần hết hy vọng) Tôi sẽ chỉ xem qua tiêu đề và quyết định.
Tôi: Nói chung tiêu đề không có tính giải thích như vậy, bạn sẽ xử lý như thế nào?
M: Tôi sẽ bắt đầu tự mình kiểm tra sản phẩm và tìm kiếm những lỗi tương tự mà tôi gặp phải, thay vì cố gắng xử lý các lỗi vì tôi cần đưa ra quyết định cho việc phân phối sản phẩm.
I: Vì vậy, bạn sẽ bỏ qua những lỗi nhiều? Các bên liên quan có thể không đồng ý. (Sau điều này, tôi hoàn toàn mất nó và chỉ tiếp tục nói xấu và tôi không nhớ những gì khác đã được hỏi. Ngoài ra, ở mọi nơi, quản lý / công việc của 2 người kiểm tra thủ công khác đã được hỏi)
Đây là một cuộc phỏng vấn cho Sr SDET.
Trả lời
Ngoài những gì các câu trả lời khác đã nói, tôi có thể nói rằng người phỏng vấn đang tìm kiếm cách bạn, với tư cách là một bổ sung mới cho một đội, sẽ đối phó với tình huống không thắng. Thành thật mà nói, tôi nghi ngờ điều đó - ít nhất - công ty đã từng rơi vào tình huống như vậy trong quá khứ. Tệ nhất là (tôi tự do thừa nhận rằng tôi hoài nghi) một điều gì đó tương tự sẽ phải đối mặt với bất kỳ ai nhận được vị trí.
Là một người phỏng vấn, tôi muốn điều gì đó tương tự từ người mà tôi đang phỏng vấn:
Đầu tiên, tôi muốn biết những lỗi này được tổ chức như thế nào, đặc biệt là mức độ ưu tiên, mức độ nghiêm trọng và rủi ro. Tôi giả định rằng tôi đang rơi vào tình huống này chứ không phải tôi đã tham gia ngay từ đầu, bởi vì loại tình huống này cho thấy rằng mọi thứ đã đi sai chỗ nào đó.
Nếu các lỗi không được tổ chức theo cách liên quan đến mức độ ưu tiên, mức độ nghiêm trọng và rủi ro, tôi muốn nói chuyện với những người thử nghiệm, quản lý dự án và phát triển khác để xác định xem họ biết những vấn đề nào gây rủi ro lớn nhất cho việc triển khai dự kiến ngày.
Nếu có một tổ chức như vậy, tôi sẽ tìm cách nói chuyện với những người thử nghiệm, quản lý dự án và phát triển để xác nhận những lỗi có rủi ro cao nhất. Tốt nhất, tôi đang tìm cách xây dựng một danh sách các lỗi phải được sửa trước khi sản phẩm có thể được phát hành. Với 10.000 lỗi, danh sách đó sẽ mất một khoảng thời gian để tạo và giả sử không có lỗi nào mà người kiểm tra không thể tìm thấy vì các lỗi được báo cáo đang ẩn hoặc chặn chúng.
Một khi tôi có ý tưởng về tình hình tồi tệ như thế nào, tôi có thể quyết định xem - theo ý kiến của tôi - có thể phát hành ứng dụng theo kế hoạch hay không. Nếu hầu hết các lỗi có nguy cơ tương đối thấp và các lỗi rủi ro cao có vẻ dễ dàng được sửa một cách hợp lý, tôi sẽ tập trung nhóm của mình vào các lỗi có nguy cơ cao và làm việc với người quản lý dự án và bất kỳ nhóm nào khác dẫn đến rủi ro cao nhất (mức độ nghiêm trọng cao, nhiều khả năng xảy ra tại hiện trường và / hoặc chặn các khu vực của ứng dụng) đã sửa và kiểm tra các lỗi.
Nếu tôi không thể tìm ra cách phát hành sản phẩm kịp thời, tôi sẽ bắt đầu nói chuyện với người quản lý dự án và sếp của tôi để xem có cách nào để thực hiện bản phát hành beta giới hạn của chức năng vững chắc hay để trì hoãn việc phát hành. Vì tôi mới đảm nhận vị trí này, tôi không biết liệu có bất kỳ yêu cầu hợp đồng nào hoặc các yếu tố khác nằm ngoài tầm kiểm soát của tôi có thể buộc ngày ra mắt không.
Tôi cũng đảm bảo rằng sau khi phát hành, tôi đã trao đổi với các nhà lãnh đạo của tất cả các nhóm liên quan để tìm hiểu xem tình huống đó xảy ra như thế nào và chúng ta có thể thực hiện những hành động nào để ngăn nó xảy ra lần nữa, cũng như cách chúng ta có thể làm việc cùng nhau để gỡ lỗi tồn đọng.
Lưu ý rằng không có điều nào trong số này liên quan đến vai trò SDET. Rõ ràng từ câu hỏi mà người phỏng vấn mong đợi một SDET cũng đóng vai trò là người dẫn đầu thử nghiệm - tôi không nghĩ đây là một điều đặc biệt tốt, và thành thật mà nói, tôi muốn biết liệu đây có phải là điều mà công ty mong đợi từ nó SDET.
Cần nhớ rằng mặc dù các cuộc phỏng vấn là những tình huống căng thẳng cao độ, nhưng hãy cố gắng suy nghĩ nghiêng và nhìn ra hàm ý của những câu hỏi bạn được hỏi hơn là đi sâu vào. Điều này thật khó thực hiện vì bạn đang căng thẳng và cố gắng hết sức mình, nhưng nếu bạn có thể dành một chút thời gian để tự hỏi bản thân xem người phỏng vấn đang tìm kiếm điều gì với câu hỏi, bạn thường có thể đưa ra câu trả lời tốt hơn.
Điều đầu tiên xuất hiện trong tâm trí là - những thử nghiệm này đã từng hoạt động trước đây chưa? Nếu vậy, đừng hoảng sợ. Có điều gì đó đã thay đổi trong cơ sở mã hoặc khung thử nghiệm có thể khiến các nhóm trong số họ bị lỗi. Theo dõi điều đó và xem liệu bạn có thể loại bỏ vài nghìn lỗi trong một lần đi không. Bạn vẫn sẽ cần phải đọc lại những thứ đang chuyển theo cách thủ công và kiểm tra lại chúng nhưng có thể điều đó sẽ chỉ mất vài ngày.
Nếu chúng chưa bao giờ được kiểm tra trước khi tôi vẫn làm điều gì đó tương tự - hãy tìm bất kỳ điểm chung nào có thể cho phép bạn sửa các nhóm lớn cùng một lúc.
Nếu không, có quá nhiều tiếng ồn ở đó, nó có thể khiến bạn bỏ lỡ một cái gì đó quan trọng đang bị lỗi.
Sau đó, hãy chấp nhận rằng bạn có thể không đến được mọi thứ và tập trung vào con đường tạo mã tiền. Những việc phải làm hoặc công việc kinh doanh gấp. Sau đó, sau khi bạn đã xóa thêm một vài trong số đó, cứ cách một hoặc ba ngày, hãy xem xét và xem liệu có còn lỗi nhóm nào như đã đề cập trước đó hay không và thử xóa thêm một vài nhóm nữa.
Lưu ý: Trả lời câu hỏi này theo quan điểm của SDET - người có thể tự sửa chữa cơ sở mã vi phạm.
Nếu người phỏng vấn đề cập đến lỗi chứ không phải kiểm tra thất bại (nếu kiểm tra thất bại, hãy tham khảo câu trả lời của @Lewis
Trước hết, việc có 10000 lỗi đang hoạt động trong một sản phẩm thực sự là một dấu hiệu đỏ.
Và bạn không bao giờ nên phát hành một sản phẩm như vậy. Nhưng nếu quyết định quản lý vẫn là phát hành thì
Câu trả lời mà người phỏng vấn mong đợi sẽ là " mức độ nghiêm trọng "
Nhóm nên tập trung vào việc sửa các lỗi có mức độ nghiêm trọng cao trước nếu không có ưu tiên nào và giữ mức thấp một lần nữa nếu đó không phải là yêu cầu khẩn cấp và không ảnh hưởng đến logic kinh doanh thực tế.
Và tập trung vào việc tự động hóa kiểm tra khói ban đầu, sau đó bắt đầu tự động hóa tất cả các bộ hồi quy
Nhóm các lỗi và xem nơi xảy ra phân cụm lỗi và kiểm tra nghiêm ngặt mô-đun đó sau khi sửa xong.
Trước khi phát hành, hãy kiểm tra thủ công tất cả các tình huống thử nghiệm khói (logic doanh nghiệp quan trọng)
Ngoài ra, có 10000 lỗi có thể dẫn đến việc che khuyết điểm trong đó những lỗi này che một số lỗi nghiêm trọng trong sản phẩm.
Vì vậy, khi đã sửa xong, cần tiến hành kiểm tra nghiêm ngặt hơn xung quanh các mô-đun để tìm ra các lỗi nghiêm trọng hơn
vì vậy nếu tôi tham gia phỏng vấn, tôi sẽ trả lời như sau:
- 10000 lỗi trong bất kỳ dự án nào sẽ là một lá cờ đỏ lớn, nó cho thấy không có quy trình và ước tính sửa lỗi thích hợp. Tôi chắc chắn sẽ lo lắng về việc phân cụm lỗi và che khuyết điểm, có nghĩa là có khả năng hầu hết các lỗi đều tập trung vào một mô-đun duy nhất và nhiều lỗi này có thể che giấu bất kỳ lỗi quan trọng nào khác mà chỉ được xác định sau khi sửa và kiểm tra lại mô-đun một cách nghiêm ngặt . Và sẽ đề nghị đẩy ngày phát hành thêm vì lý do này.
Có nghĩa là trong khi nhóm phát triển bận rộn với việc sửa lỗi, chúng tôi sẽ bắt đầu tự động hóa các trường hợp sử dụng thử nghiệm khói và các trường hợp sử dụng lỗi. Khi bản sửa lỗi đến, chúng tôi sẽ giao nhiệm vụ kiểm tra lại cho người kiểm tra thủ công và chúng tôi tự thực hiện kiểm tra adhoc nghiêm ngặt trên mô-đun để tìm bất kỳ lỗi nghiêm trọng nào được che giấu.
- Nếu không có mức độ ưu tiên nào thì trước tiên sẽ nhàn rỗi để xem lại các lỗi nghiêm trọng hoặc mức độ nghiêm trọng cao, đồng thời cũng để điều tra thời gian tồn tại của lỗi và hiểu tại sao các lỗi không được sửa quá lâu để giúp cải thiện quy trình tổng thể trong tương lai.
Đối với các lỗi có mức độ nghiêm trọng thấp, chúng tôi cần đưa ra quyết định của nhóm về tiến trình và quyết định phát hành về việc có phát hành phiên bản đầu tiên với các lỗi này nhưng vẫn ghi lại các lỗi tương tự và cách giải quyết khi cần thiết. Đồng thời cung cấp ngày phát hành tiếp theo để có thể sửa chữa nếu có thể.
Vì vậy, là một QA cấp cao, bạn nên đưa ra quan điểm mạnh mẽ của mình là "KHÔNG" khi bạn nhìn thấy cờ đỏ. Đừng quá linh hoạt
Các câu trả lời khác ở đây là tốt nếu mục đích của câu hỏi là đưa ra một câu trả lời cụ thể.
Tuy nhiên, rất nhiều người phỏng vấn hỏi những câu hỏi mơ hồ mà không có câu trả lời cụ thể vì họ muốn biết bạn nghĩ như thế nào hoặc để hiểu liệu bạn có đang đưa ra giả định về câu hỏi hay không. Họ muốn bạn đặt câu hỏi làm rõ cho họ để biết chi tiết cụ thể. Điều này giúp định hướng câu trả lời của bạn.
Tình huống là bạn và 2 người khác bao gồm nhóm thử nghiệm. Bạn, người dẫn đầu, là người duy nhất có thể tự động hóa, những người khác chỉ có thể kiểm tra thủ công. Bạn có gần 10.000 lỗi đã được phát sinh và bạn có 4-5 tuần hoặc ít hơn trước khi sản phẩm này được giao. Bạn sẽ làm gì để đảm bảo rằng sản phẩm được giao đúng thời hạn?
Một số câu hỏi cần hỏi:
- Những người kiểm tra qa thủ công có kinh nghiệm như thế nào?
- Những người kiểm tra thủ công có kinh nghiệm trong dự án này không? Hay họ cũng là người mới tham gia dự án?
- Có cần phải sửa tất cả 10.000 trước ngày giao hàng không?
- Có phần mềm theo dõi lỗi mà nhóm sử dụng không? Nếu vậy thì sao?
- Các lỗi đã biết được theo dõi như thế nào? Chúng có mức độ ưu tiên, mức độ nghiêm trọng được liệt kê không? Chúng có được nhóm / gắn thẻ theo tính năng không?
- Có bất kỳ kiểm tra tự động nào hiện đang được sử dụng cho phần mềm không? Nếu vậy, có bao nhiêu bài kiểm tra đơn vị, bài kiểm tra tích hợp, bài kiểm tra giao diện người dùng? Hoặc, tôi có cần tạo tất cả các bài kiểm tra / khuôn khổ tự động từ đầu trong khung thời gian 4-5 tuần không?
- Các nhà phát triển chịu trách nhiệm kiểm tra bao nhiêu? Họ có đang tạo các bài kiểm tra đơn vị / tích hợp không?
- 10.000 lỗi có phải lỗi giao diện người dùng không? Hay một hỗn hợp các lỗi có thể được kiểm tra bằng các bài kiểm tra đơn vị, bài kiểm tra tích hợp, bài kiểm tra giao diện người dùng?
- Những thiết bị nào cần được sử dụng để kiểm tra?
- Mức chất lượng chúng ta cần đạt đến để làm hài lòng người dùng và các bên liên quan là gì? Làm thế nào để các bên liên quan cảm nhận về chất lượng?
- Làm thế nào để các bên liên quan xác định việc khởi động dự án thành công?
- Định nghĩa của done là gì?
- Nhóm sẽ có thời gian sau khi phát hành dự án để sửa lỗi chứ? Hay chúng ta chuyển sang dự án tiếp theo? Chúng ta sẽ có bao nhiêu thời gian nếu chúng ta có thời gian?
- Nhóm đang sử dụng Agile SDLC hay Waterfall SDLC?
Có vô số câu hỏi bạn có thể hỏi để làm rõ bạn cần đưa ra câu trả lời được suy nghĩ kỹ lưỡng.
Và, từ cuộc trò chuyện chi tiết ở trên, người phỏng vấn liên tục nhắc nhở về các chi tiết cụ thể về cách đưa người kiểm tra thủ công vào kế hoạch của bạn. Điều này cho bạn một gợi ý lớn về những gì người phỏng vấn đang tìm kiếm: họ không muốn bạn tự mình gánh vác toàn bộ gánh nặng của việc thử nghiệm dự án này; họ muốn biết với tư cách là Kỹ sư SDET / QA cấp cao cách bạn cố vấn / lãnh đạo một nhóm kiểm tra viên cấp cơ sở.
Hãy nhớ rằng, các cuộc phỏng vấn không nên là một cuộc thẩm vấn mà bạn chỉ trả lời các câu hỏi của họ. Phỏng vấn phải là một cuộc trò chuyện mà bạn có thể hỏi bất cứ điều gì giúp làm sáng tỏ câu hỏi của họ.