10 thách thức tiêu biểu mà các Tester phải đối mặt ở nơi làm việc và cách để vượt qua chúng

Các thách thức vốn là chuyện bình thường. Đó là khi bạn nhìn chúng như những cơ hội thì nó sẽ giống 1 mỏ vàng và còn khi bạn nhìn chúng là các chướng ngại vật thì nó sẽ giống 1 mỏ đất mà thôi.

Dưới đây là danh sách 10 thách thức nổi bật, hãy cùng xem liệu bạn có đã và đang gặp phải cái nào không nhé!

1. Văn hóa của công ty

Đây là cái đầu tiên được liệt kê trong danh sách này bởi vì nhờ ngành công nghiệp dịch vụ IT đã cho tôi có cơ hội tiếp xúc với nhiều khách hàng, nhiều nhóm, nhiều địa điểm và nhiều công ty. Tôi thích việc trở thành 1 phần của các nhóm khác nhau, và tất nhiên, tôi sẽ không lặp lại các trải nghiệm giống nhau.

• Một nhóm mà tôi làm việc bắt đầu công việc lúc 6h sáng. Và 1 nhóm khác thì lại nhất định đòi làm việc cho tới tận 6h chiều.
• Một nhà thầu đi vào tòa nhà thông qua một cánh cửa khác và một nhà thầu khác thì thậm chí còn không tin vào quyền truy cập thẻ quẹt.
• Một công ty yêu cầu chúng tôi bỏ lại tất cả các thiết bị di động có bộ nhớ, Bluetooth hoặc bất kỳ kết nối nào khác bên ngoài trong khi một công ty khác thì mở những bản nhạc tuyệt vời tại nơi làm việc cả ngày.
• Một số công ty tuân theo một hệ thống phân cấp chặt chẽ với việc CEO của họ đạt trạng thái người nổi tiếng nhưng một công ty khác thì không theo hình khối nào cả và mọi người đều bình đẳng như nhau.

Điều tôi nhận ra theo thời gian là không có ai đúng hay sai, đó chỉ là cách mà họ vận hành mà thôi (hay nói cách là văn hóa riêng của từng công ty ý). Qua thời gian nhất định, chúng ta sẽ luôn thích nghi với mọi hoàn cảnh, nhưng nếu không được, hãy tìm lối thoát gần nhất để rút lui.

2. Sự khác biệt về múi giờ

Bạn có từng phải ở văn phòng hay ở nhà trước màn hình laptop lúc 11h tối hay 5h sáng để cố gắng bắt nhịp với các nhóm của bạn những nhóm mà được phân bố ở các vùng địa lý khác nhau không? Cái này chắc là đã quá quen đúng không nhỉ?

Thực sự là không có thuốc giải cho vấn đề này (có lẽ là cafe chăng?). Sử dụng đồng hồ để chỉ cho bạn chính xác thời gian ở các địa điểm khác nhau (hay đồng hồ thế giới trên điện thoại thông minh của bạn), sử dụng các giao thức giao tiếp hoàn hảo theo một cách nào đó để không cần phải có những buổi họp về các vấn đề, giải quyết thông qua email và lập kế hoạch cũng cần lưu ý theo múi giờ để tránh vấn đề này 1 cách đáng kể.

Ví dụ: nếu có lập kế hoạch daily meeting thì cũng nên cân nhắc tới sự chênh lệch múi giờ giữa 2 nơi để chốt ra 1 thời điểm mà tiện lợi cho cả 2 nơi có thể tham gia daily meeting được ý.

3. Sự khác biệt về văn hóa

Ví dụ: “Xin chào, bạn khỏe không?” là 1 câu chào hỏi chung ở Mỹ. Nó không nhất thiết có nghĩa là họ muốn biết chính xác bạn đang cảm thấy như thế nào ở thời điểm đó. Tuy nhiên, khi bạn mới ở Mỹ thì có thể bạn sẽ nghĩ là “Mình vừa gặp người ngày trong cuộc họp vừa nãy. Làm sao mà sức khỏe thay đổi trong 1 thời gian ngắn như vậy được mà lại hỏi câu này nhỉ? Kì cục ghê"

Vậy đó, mỗi nước có 1 văn hóa khác nhau nên đừng vội đánh giá người khác khi mình chưa thực sự hiểu rõ về văn hóa của nước họ.

Và ngoài ra, trong 1 số nền văn hóa, việc nói ít hơn thể hiện sự trầm tính trong khi ở nền văn hóa nước khác thì lại cho đó là người ta lại hiểu theo nghĩa đơn giản là điều đó thật nhàm chán hay bạn không có gì để nói. Khi bạn cố gắng hiểu những tình tiết nhỏ này, bạn có thể hiểu mọi người hơn và có thể làm việc theo cách tốt hơn.

Đúng kiểu biết người biết ta, trăm trận trăm thắng ý

4. Không có tài liệu

Ngày nay, nhiều nhóm vẫn tin tưởng vào việc giao tiếp bằng lời nói và giữ ít tài liệu tham khảo ghi chú về việc phần mềm sẽ trở thành như thế nào. Đối với phát triển phần mềm theo các chu kỳ phát triển ngắn thì chỉ càng làm cho điều này trở nên khốc liệt hơn.

Tuy nhiên, đây thực sự là một trong những trường hợp mà thách thức lại trở thành các cơ hội.

Tham gia vào các cuộc trò chuyện với các nhóm phát triển, phân tích nghiệp vụ hoặc nhóm kỹ thuật. Nghiên cứu ứng dụng, thiết lập các tài liệu tham khảo khi xem xét các ứng dụng tương tự và tiêu chuẩn của họ. Hiểu được các quan điểm của người dùng cuối. Và hãy phiêu lưu với việc kiểm thử khám phá.

Về mặt kỹ thuật thì không có bất kỳ ứng dụng nào là không có các bản yêu cầu cả. Hãy tưởng tượng 1 phần mềm không có bất kỳ cái gì cụ thể cả mà chỉ đơn giản là các dòng code tiếp nối nhau. Uh huh. Và theo trí tưởng tượng của các dev thì chúng ta chẳng thể biết được nó sẽ đi tới đâu cả.

Thế nên việc kiểm thử mà không có tài liệu thì đúng là 1 thách thứ khó nhằn không chỉ đối với QA mà còn cả với các thành viên khác trong đội dự án nữa.

5. Môi trường không ổn định

Thông thường, các nhóm QA phải chịu đựng một môi trường thiết lập kém hơn mà chúng ta phải thực sự sẵn sàng để tận dụng tối đa những gì chúng ta có.

Ví dụ: Máy chủ trở nên quá tải và cần khởi động lại vài lần trong quá trình kiểm thử, các bản log cần xóa thường xuyên để đảm bảo rằng không có 1 cái nào tràn cả, v.v.

Đưa những vấn đề này lên trước và đảm bảo rằng bạn sẽ nhận được hỗ trợ về môi trường trong quá trình kiểm thử. Đối với các trường hợp thường xảy ra, hãy truy cập vào các máy chủ bằng 1 vài bước để thực hiện một số bảo trì đơn giản, chẳng hạn như khởi động lại server, xóa hàng đợi, v.v.

Thực tế là trong dự án hiện tại của mình đôi khi việc chờ Dev khởi động server test rất là mất thời gian. Bởi lẽ múi giờ làm việc chênh nhau 2h, QA tới trước phải chờ Dev 2h sau mới tới khởi động server để test thì ôi thôi 2h ngồi chơi chăng. Chính vì thế Dev đã setup cho QA cũng có thể tự khởi động server test. OK quá tốt rồi đúng không =))

6. Các công cụ bị buộc phải sử dụng

Thi thoảng chúng ta biết rằng 1 công cụ A là không phù hợp với công việc B nào đó. Chúng ta không có lựa chọn nào khác mà vẫn phải tiếp tục sử dụng chúng bởi vì khách hàng/nhóm đã mua công cụ đó và họ không muốn mua 1 cái khác cho tới khi cái công cụ đó hết hạn.

Tôi đã phải kiểm thử 1 ứng dụng Mainframes trên HP QTP (một công cụ kiểm thử chức năng tự động) mà không có trình mô phỏng đầu cuối. Trong trường hợp này, tôi có công cụ nhưng mà nó lại không có cấu hình chính xác. Tôi hầu như không làm được gì nhiều với nó, vì thế tôi đã phải chuyển đổi qua lại giữa 2 chế độ ghi ở mức thấp và mức bình thường như 1 cách giải quyết.

Chả vui tẹo nào nhưng bạn học được sự lựa chọn thay thế. Hoặc ít nhất, bạn sẽ đạt được 1 kết luận chắc chắn như là liệu các sự lựa chọn thay thế có hoạt động hay không.

7. Một số ứng dụng chỉ không cắt bỏ nó: (nghe cái này hơi khó hiểu nhưng mà hãy kiên nhẫn đọc tiếp trình bày ở dưới nhé )

Bạn đã từng kiểm thử 1 ứng dụng và bắt đầu tự hỏi “Sao cái này được gọi là phần mềm khi mà có thể gọi nó là 1 máy sản sinh lỗi thì đúng hơn vậy?

Tôi đã từng có vinh dự đặc biệt này khi mà hầu hết 1 ngày của tôi chỉ đơn giản là việc báo cáo và báo cáo các bug mà thôi. Một số chỗ của ứng dụng đã phải cắt bỏ bớt bởi những bug này. Toàn bộ mức độ nghiêm trọng sẽ ném bạn ra khỏi trò chơi của bạn và nó trở nên áp đảo khi bạn bắt đầu suy nghĩ, “Có cái gì để tôi làm ở đây không vậy?

Làm thêm giờ, tôi đã học được cách giữ vững quyết định của mình là nếu phần mềm không sẵn sàng để kiểm thử thì tôi sẽ từ chối bản build. Không có chuyện dù phần mềm còn cả 1 rổ bug nhưng vẫn build lên và yêu cầu Tester kiểm thử, xong rồi Tester lại log cả rổ bug đó lên yêu cầu Dev fix được đâu.

Ví dụ thực tế nè: Nhớ lại hồi trước có dự án mình từng làm, có 1 quy định là một khi mà Dev thực hiện Unit test mà không pass được 80% thì sẽ không được Dev lead approve đẩy bản build lên. Nói chung việc này sẽ khiến những Dev lười Unit test không vui nhưng mà nó cũng sẽ hạn chế tối đã việc bản build bị đẩy trả lại đúng không nào.

8. Những con người kỳ quặc

Bạn đã bao giờ gặp một Dev đập vào bàn trong cuộc họp khi mà bạn đang giải thích 1 lỗi hay chưa? Vâng, điều đó đã xảy ra với tôi rồi. Sau đó tôi mới biết được đó là cách thức mà anh ta thể hiện và không hề có ý xấu.

Tôi cũng có một người trong nhóm ban đầu khá là không hợp tác và thô lỗ nhưng mà đó chỉ là do họ ngại mà thôi. Người này rất khó để nói ra vài từ hoặc giao tiếp bằng mắt khi mà hỏi về việc cập nhật trạng thái. Tôi suýt thì đã đánh giá tiêu cực về anh ta nếu như tôi không nhận ra những việc tương tự khi làm việc với anh ta qua email thì lại trở nên dễ dàng hơn. Lý do ở đây là vì anh ta cảm thấy không thoải mái với những cuộc trao đổi 1 đối 1. Trường hợp này quả Kỳ cục hết sức nhỉ? >"<

Mỗi người đều có những tính cách khác nhau tuy nhiên đừng quá thô lỗ và nên tôn trọng các ranh giới.

9. Thiếu vòng lặp phản hồi

Đôi khi bạn làm việc remote từ một vị trí không cùng với nhóm của bạn mà bạn cảm thấy bị cô lập và không có ai đáp lại ý tưởng của bạn đưa ra cả.

Hoặc các phản hồi mà bạn nhận được chẳng hữu ích gì cả. Họ nói bạn tạo 1 tài liệu quy trình làm việc và kêu là nó OK rồi. Thế nhưng bạn không thấy tài liệu quy trình làm việc nào được xuất bản ra hoặc đưa vào sử dụng và bạn sẽ tự hỏi điều gì đã xảy ra với nó nhỉ. Vì vậy, có thông tin phản hồi là việc “tốt” nhưng lại không có tác dụng gì cả thì cũng là số 0 thôi và đôi lúc là gần như không có phản hồi gì hết.

Tìm kiếm những phản hồi chân thật và tạo 1 ra một cộng đồng để thảo luận về các ý tưởng của bạn. Điều này thường không dễ để làm nhất, nhưng mà nếu như không có những viện trợ tích cực khác thì đôi khi bước này sẽ làm cho bạn mất đi phần nào động lực làm việc đó.

10. Những định kiến

Uh huh, chúng ta biết rằng có nhiều định kiến ở nơi làm việc quay quanh các vấn đề giới tính, quốc tịch, vv. Tôi sẽ không đi vào chi tiết cụ thể ở đây nhưng trừ khi chúng ta bắt đầu coi thế giới như một ngôi làng toàn cầu và mọi người đều bình đẳng như nhau, cả thế giới và nơi làm việc đều trở nên độc hại.

Kết luận

Trên là những thách nổi bật mà ít nhiều trong số các Tester có thể đã và đang gặp. Theo quan điểm và phụ thuộc vào nơi làm việc của mỗi người, cũng có thể có những thách thức khác nữa.

Hãy cùng chia sẻ những thách thức mà bạn gặp phải và cách bạn đã vượt qua nó như thế nào với mình nhé!

Bài viết được dịch từ link: https://www.softwaretestinghelp.com/challenges-testers-face-at-workplace/