Đang load dữ liệu
Tại sao tester không được đối xử chuyên nghiệp trong một số tổ chức?
Nếu bạn đang đọc một bài viết liên quan đến QA trong thời gian rảnh theo thứ tự để nâng cao kỹ năng test, bạn thuộc vào số nhỏ (và hi vọng sẽ tăng lên) những người mong muốn trở thành Tester chuyên nghiệp.
Có thể bạn quan tâm:
Hãy thành thật bất cứ khi nào chúng tôi không được đối xử như những chuyên gia. Đó là bởi vì chúng tôi đã không ưu tiên thực hiện như những tester chuyên nghiệp.
Dựa vào kinh nghiệm hạn chế của tôi, ở khắp mọi nơi tôi đã thấy những tester thực hiện công việc của họ một cách nghiêm túc và phấn đấu để cải thiện trình độ, tôi cũng thấy cách họ được đối xử tôn trọng như thế nào, và công việc của họ được đánh giá cao như thế nào nhờ vào giá trị của nó đóng góp cho tổ chức.
Nếu bạn làm việc trong phát triển phần mềm, bạn nên hiểu ít nhất một chút về kỹ thuật phần mềm. Như một tester, bạn cần có khả năng đọc code theo thứ tự để phân tích sản phẩm của bạn, và hiểu rằng thay đổi và fix lỗi có thể gây ra ảnh hưởng đến nó và gây ra lỗi bổ sung. Bạn cũng có thể thoát ra mà không cần viết bất kỳ dòng code nào nếu như bạn không muốn, nhưng nếu như bạn không đọc mã, bạn sẽ mất rất nhiều đầu vào quan trọng cho quá trình kiểm thử tổng thể của bạn.
Theo lý thuyết, chúng tôi muốn bắt đầu trong quá trình thu thập yêu cầu và giai đoạn phân tích, cùng với phần còn lại của team. Nhưng trong thực tế, chúng tôi rất khó để cung cấp bất kỳ một đầu vào nào trước khi chúng tôi nhận được bản build đầu tiên từ developers để tìm kiếm và phản hồi về tính năng của họ.
Tại sao điều này tiếp tục xảy ra? Hầu hết tester sẽ nói rằng đó là vì “vòng luẩn quẩn” của liên kết cuối cùng trong chuỗi phát triển; Chúng tôi luôn luôn vô cùng bận kiểm thử khi “những người khác” bắt đầu lập kế hoạch.
Nhưng sự thật, nếu bạn không thể dành ra 2 giờ một ngày để tham gia cuộc họp thiết kế tính năng, nghĩa là bạn là một người quản lý thời gian tồi. Nó cũng có nghĩa rằng lý do duy nhất bạn không phải là một phần của quá trình phát triển phần mềm sớm hơn bởi vì bạn không ưu tiên nó, hoặc cách khác là bởi vì bạn không muốn!
Một phần của công việc của bạn là test sản phẩm trên môi trường thực tế và bắt các lỗi nghiêm trọng đối với người dùng khi sản phẩm được release.
Trên thực tế, công việc của bạn là trở thành người đại diện cho khách hàng của bạn trong nhóm phát triển. Để lập kế hoạch cho việc test của bạn và set up môi trường dựa trên hành vi hoạt động của họ. Bạn cũng được mong đợi cung cấp những feedback về tính năng dưạ trên nhu cầu và ràng buộc của họ.
Nếu đây là trường hợp, thì làm thế nào bạn có thể mô phỏng môi trường làm việc và đại diện cho người dùng của bạn nếu như bạn không biết về họ? Lần cuối cùng bạn gặp gỡ một người dùng để hiểu cách anh ấy/cô ấy sử dụng sản phẩm là khi nào? Bạn có thực sự liên hệ công việc họ làm với hệ thống của bạn và với những ràng buộc của môi trường làm việc của họ không? Tôi phỏng đoán câu trả lời là KHÔNG.
Hãy đi và gặp gỡ khách hàng của bạn. Cho đến khi bạn biết và hiểu về user của bạn, bạn sẽ tiếp tục làm công việc tồi tệ như là một tester.
Có một số nhỏ các sự thật đơn giản trong testing; có thể điều không đáng quan tâm nhất đó là: “không tester nào có đủ thời gian để test mọi thứ“. Đó là lúc Quản lý rủi ro cơ bản phát huy tác dụng, giúp chúng ta đánh thứ tự ưu tiên công việc của mình để biết những gì chúng ta phải test trước và những gì có thể giả định làm việc dựa trên kết quả của những phần test khác.
Mỗi tester đều biết khu vực test nào của mình chứa nhiều rủi ro; khu vực nào luôn luôn có nhiều bug và nơi công việc của team luôn bị trì hoãn do không có kế hoạch và trường hợp ngoài dự tính. Đó là một phần công việc của chúng tôi với tư cách 1 tester, để nhận định những khu vực này và remind chúng với team trong suốt quá trình phát triển dự án. Bạn nên cố gắng làm sáng tỏ các vấn đề, cho dù là hiện tại hay khả năng, ảnh hưởng đến sản phẩm của bạn. Giúp đỡ team thiết lập các mục tiêu thực tế và đạt được mục tiêu của bạn trong thời gian và ngân sách.
Nghề kiểm thử phần mềm ở nhiều khía cạnh chưa được thám hiểm. Không có cách nào để phát triển bản thân một cách chuyên nghiệp như một tester, và những cải tiến này sẽ không dễ dàng hoặc nhanh chóng. Vì vậy, trừ khi bạn quyết định bạn muốn đầu tư nghiêm túc vào việc phát triển sự nghiệp của mình, và chỉ sau khi bạn hiểu cách đạt được mục tiêu này, bạn sẽ có thể thực sự cải thiện được kỹ năng kiểm thử của bạn và giá trị mà bạn cung cấp cho tổ chức của mình hay không.
Vậy làm cách nào để đạt được điều đó?
Bắt đầu bằng lập sơ đồ về điểm mạnh và điểm yếu của bạn khi là một tester, sau đó quyết định lĩnh vực bạn muốn phát triển (điều đó cũng sẽ có giá trị với tổ chức của bạn), và cuối cùng tìm kiếm những phương tiện sẵn có để phát triển kỹ năng này.
Có một điều chắc chắn, sẽ hoàn toàn không thể cải thiện nếu như bạn từ bỏ cơ hội, hoặc để cho tester khác kéo bạn theo quá trình phát triển của họ.
Có nhiều điều hơn là chỉ chạy thử nghiệm theo kịch bản:
Giá trị công việc của bạn sẽ vượt ra ngoài việc thực hiện test-steps và thiết lập chúng là pass hay fail!
Dừng lại với lý do tại sao bạn không làm việc với tự động hóa!!
Tự động hóa không phải là một viên thuốc ma thuật hoặc sự chữa trị cho tất cả các vấn đề đối mặt với tester, nó chỉ là một lời nói dối bán hàng từ nhiều nhà cung cấp công cụ. Nhưng dù sao, nếu sử dụng scripts hoặc tool để thực hiện một phần công việc khó chịu của bạn sẽ làm nó hiệu quả hơn và tiết kiệm thời gian của bạn.
Vấn đề là có một vài tester cảm thấy không đủ kỹ thuật để thực hiện nó, và vì vậy họ chọn không sử dụng tự động hóa hoặc scriptting để cải thiện kỹ năng test của họ. Theo nghĩa nào đó, nó giống như những viên đá bật hoặc gậy cọ xát để thắp sáng ngọn lửa, và từ chối sử dụng bật lửa trong khi đó là cách dễ dàng hơn.
Một tester giỏi là một tester khiêm tốn! Chúng ta cần biết cách cung cấp feedback, và thậm chí quan trọng hơn là cách nhận feedback từ các thành viên trong team hoặc đồng nghiệp.
Nhiều tester cảm thấy bực bội khi các thành viên trong team (đặc biệt là lập trình viên) cung cấp cho họ feedback không được yêu cầu từ kiểm thử của họ, hoặc khi họ được truy vấn về một lỗi không tìm thấy hoặc một thử nghiệm không chạy. Nhiều lần có lý do chính đáng cho những lần “lỡ” này, và chúng ta chỉ cần giữ bình tĩnh, và chia sẻ thông tin này, nhưng rất nhiều tester lấy những câu hỏi này tấn công vào chuyên môn của họ, và trả lời lại to tiếng hoặc dùng những từ ngữ khắc nghiệt.
Tương tự như vậy, bạn cần biết cách báo cáo lỗi của bạn và cung cấp những feedback tích cực cho đội dự án, bạn cần biết cách nhận những sự chỉ trích mang tính xây dựng từ đồng nghiệp của bạn.
Không ai kỳ vọng bạn hoàn hảo, nhưng họ hi vọng bạn chuyên nghiệp về những lỗi lầm của bạn, và học hỏi từ họ cũng như từ những feedback bạn nhận được từ nhóm.
Một trong các quản lý giỏi nhất của tôi trong quá khi đã từng nói về “Hộp công cụ ảo” cá nhân của chúng tôi là tập hợp các kỹ năng mỗi chúng ta mang theo khi cần thiết.
Testing là một nghề thủ công không có nghi ngờ, và không có công cụ thích hợp (ảo hoặc thực tế), bạn sẽ không thể tạo ra sản phẩm theo yêu cầu.
Một số người tham gia kiểm thử bởi vì họ nghĩ rằng đây là con đường tốt nhất đến lập trình. Một số khác là bởi vì họ không biết kiểm thử là gì và cảm thấy thú vị khi “chơi” với các ứng dụng cả ngày. Sau tất cả, rất khó để thực hiện, đúng không?
Một phần trong số họ có thể trở thành tester giỏi. Nhưng hầu hết họ sẽ thất vọng, đếm từng ngày cho đến khi họ có thể dừng việc kiểm thử và bắt đầu một công việc khác họ thực sự muốn làm. Trong khi một số khác không đánh giá cao những thách thức thực sự của kiểm thử, và nghĩ rằng cách duy nhất để tiến lên là quản lý con người.
Đúng là có những thách thức và phần thưởng để quản lý một nhóm kiểm thử, nhưng cũng có vô số ngành để chinh phục mà không liên quan gì đến quản lý và điều đó có thể mang đến cho bạn nhiều thách thức và phần thưởng lớn hơn (và chấc chắn ít đau đầu hơn).
Quan điểm của tôi là, nếu tất cả thời gian bạn đang tìm kiếm một thứ khác và không tập trung vào việc làm thế nào để test tốt hơn, thì không có cách nào bạn có thể làm điều đó chuyên nghiệp hơn. Vì vậy, hãy suy nghĩ nếu bạn đang ở đúng nơi, hoặc nếu có lẽ bạn nên đơn giản suy nghĩ về một thứ khác…
Nhìn vào 10 điểm này từ 20000 feet tôi nghĩ rằng đường kết nối chúng là thay đổi cách tiếp cận chung của chúng tôi về testing.
Bước thứ nhất là hãy bắt đầu xem xét kiểm thử là một nghề.
Sau khi chúng ta hấp thụ được bước thứ nhất, bước thứ hai là xem xét những gì chúng ta đang thiếu để trở thành người kiểm thử tốt hơn. Lĩnh vực nào chúng ta cần phát triển? Chúng ta cần tiếp cận công việc và ối quan hệ với khách hàng và những thành viên trong team như thế nào? Và chúng ta cần làm gì ngay bây giờ để tăng giá trị của công việc?
Thứ ba và bước cuối (ít nhất cho cách tiếp cận ngắn này) là lên kế hoạch trước để cải thiện, và để nhận ra rằng đó là một nghề chúng ta có nhiều thứ để học trước khi tự suy nghĩ về chính mình hoặc các chuyên gia (nếu như có một điều như vậy)
Việc quan trọng nhất là để nhận ra rằng sự thay đổi cần phải đến từ bên trong!
Nguồn: Sưu tầm từ internet via Viblo
.png "Lập trình frontend với reacjs (Full)")