Thay đổi quan điểm về kiểm thử để đảm bảo chính vị trí công việc của bạn.
Trong làn sóng sa thải mạnh mẽ hiện tại, đối với ngành công nghệ, thường những người kiểm thử phần mềm là những người đầu tiên bị sa thải. Thật đau lòng nhưng có vẻ cần đối diện với sự thật này. Thường quan điểm về Tester sẽ là: “Họ không có sản phẩm cụ thể, không hề lập trình, các lỗi mà họ tìm thấy chỉ làm chậm quá trình phát triền mà thôi, vân vân và mây mây… Vậy tại sao còn phải giữ họ trong tổ chức??”
Vấn đề là, Tester thực hiện rất nhiều công việc quan trọng nhưng không được nhìn thấy hay công nhận như những vai trò khác tạo ra sản phẩm cụ thể. Có thể liên tưởng tới một quan điểm cổ hủ khi nghĩ về người vợ ở nhà nội trở đảm đang dọn dẹp vun vén cơm nước, để chồng đi làm về chỉ việc nghỉ ngơi, tái tạo sức lao động cho hôm sau, nhưng thường bị coi là ăn bám, chẳng làm ra giá trị gì cả. Nhưng rõ ràng là Tester là sự kết nối mật thiết giữa kĩ thuật và việc phát triển sản phẩm, giúp tăng tốc và cải thiện quá trình bàn giao sản phẩm đảm bảo chất lượng đến tay khách hàng.
Các Tester thường được nhìn nhận như nào?
Thường các Tester chỉ được xem là những người nhận một vài tính năng đang trong giai đoạn phát triển rồi thực hiện chạy các testcases với nó. Hoặc khi nói về kiểm thử tự động, Tester là người tạo các test script để thực hiện kiểm thử tự động và bảo trì chúng, và sau đó thì báo cáo lại các vấn đề phát hiện được, đơn giản là vậy thôi.
Khi tôi bắt đầu sự nghiệp với vai trò kĩ sư đảm bảo chất lượng 7 năm trước, sự hiểu biết của tôi về công việc này cũng hạn hẹp như vậy. Công việc hàng ngày của tôi cũng chỉ là tạo ra các testcases dựa trên yêu cầu đặc tả phần mềm được viết bởi Product Owner, và thực hiện kiểm thử khi phần mềm sẵn sàng, báo cáo lỗi và xác nhận các lỗi đã được sửa.
Tôi đã không ý thức được rằng thực ra kiểm thử còn rộng lớn hơn như vậy rất nhiều. Nhưng sau đó, khi tôi nhảy việc và tham gia vào các cộng đồng kiểm thử quốc tế, trò chuyện với nhiều người trong ngành hơn. Điều này đã thực sự giúp tôi mở mang tầm mắt: Tester đóng vai trò quan trọng hơn nhiều trong việc phát triển phần mềm so với những gì tôi đã nghĩ trước đây. Từ những điều mới mẻ đó mà tôi đã thay đổi và hình thành tầm nhìn và cách làm việc mới.
Sự thay đổi trong nhận thức về Tester… và kiểm thử
Tester luôn là các thành viên tích cực ngay từ giai đoạn đầu của chu kì phát triển.
Trong giai đoạn xác định (Definition), vai trò của Tester là sẽ giúp phân tích rủi ro sớm. Họ xem xét các yêu cầu, làm nổi bật những lỗ hổng và những điểm mâu thuẫn, chưa chắc chắn, xác định rủi ro có thể gây nguy hiểm tới sản phẩm, thúc đẩy các cuộc thảo luận với PO/BA và kĩ sư lập trình. Tester hiểu và nắm vững về sản phẩm từ cả khía cạnh kỹ thuật lẫn kinh doanh, điều này giúp họ mang đến các quan điểm mới cho cuộc thảo luận hiệu quả hơn. Chúng tôi thường đặt những câu hỏi độc đáo mà có thể chẳng ai nghĩ tới. Đôi khi, những câu hỏi như vậy sẽ gợi lên một cuộc thảo luận mang lại lợi ích cho sản phẩm và công ty.
Trong quá trình thu thập yêu cầu và thiết kế, Tester cũng đóng góp không ít công sức. Tôi nhớ có một hôm, khi Product Owner của team tôi đưa ra ý tưởng về một tính năng mới. Chúng tôi đã có một cuộc họp khởi động dự án. Các lập trình viên rất thích ý tưởng mới đó và muốn bắt đầu nhảy vào tìm giải pháp ngay. May mắn thay, nhóm Tester đã đề nghị cần xem lại trước khi làm, họ làm việc với các nhóm khác trong công ty và phát hiện ra rằng trước đây đã có một chức năng tương tự như vậy ở một sản phẩm khác. Điều này cực kì có ích trong việc rút ngắn thời gian và tăng tính hiệu quả khi tham khảo ý kiến, và tái sử dụng thiết kế đã được triển khai từ nhóm đã từng làm chức năng này.
Và đó là những gì đã xảy ra trên thực tế. Nhờ vậy chúng tôi đã giảm thiểu đáng kể chi phí cho dự án. Chức năng mới không đòi hỏi thiết kế hay code mới, và chúng tôi đã thành công trong việc duy trì tính nhất quán trong trải nghiệm người dùng sử dụng các giải pháp SaaS của chúng tôi.
Cách Testing có thể tăng tốc quá trình triển khai
Mọi người thường nghĩ rằng việc kiểm thử làm chậm tiến trình phát triển. Kiểm thử đồng nghĩa rằng có nhiều việc phải hoàn thành hơn trong quá trình triển khai. Thật sự rất khó chịu khi các developer nói: “Chúng tôi đã hoàn thành, triển khai lên Production thôi”, nhưng lại nghe được rằng vẫn còn vấn đề cần khắc phục trước khi có thể phát hành. Các Tester sẽ tìm thấy ngày càng nhiều vấn đề hơn sau khi thực hiện kiểm thử, và sẽ luôn đề xuất để khắc phục chúng. Vậy nên các developer thay vì phát hành sản phẩm ngay, thì họ lại phải dành thời gian và nỗ lực để giải quyết các vấn đề, sửa lỗi mà Tester đã tìm thấy.
Trái ngược với quan điểm phổ biển trên, thực ra kiểm thử lại giúp thúc đẩy quá trình phát triển. Khi thực hiện các hoạt động khác nhau từ kiểm thử khám phá đến kiểm thử tự động, Tester sẽ xác định được sớm các vấn đề, và lập tức thông báo cho các bên liên quan. Tester không chỉ nâng cao nhận thức về tình trạng phát triển sản phẩm, mà còn đề xuất khắc phục các vấn đề đã tìm thấy, và giúp tăng tốc quá trình phát triển ra một sản phẩm chất lượng.
Quả thực việc phát hành thêm các tính năng mới rất có giá trị. Nhưng thực tế, nếu vội vã phát hành sản phẩm nhưng lại khiến khách hàng phàn nàn về lỗi trong tính năng mới, rồi sau đó các developer vừa phải sửa lỗi trên các tính năng vừa phát hành, vừa phải tiếp tục công việc xây dựng tính năng mới khác thì sẽ làm chậm tiến độ dự án hơn rất nhiều so với việc phát hiện lỗi sớm và sửa chúng.
Phát hành sản phẩm: Kết thúc là một khởi đầu mới
Cuối cùng thì cũng tới giai đoạn phát hành. Sự phát triển và thực thi kiểm thử đã hoàn thành, và các tính năng mới cũng sẵn sàng để khách hàng trải nghiệm. Yay! Mọi người thường nói công việc của Tester tới đây là kết húc, và bây giờ chỉ cần tập trung vào nghiên cứu thêm các tính năng mới thôi. Tuy nhiên, thực tế thì lại không như vậy.
Sau khi phát hành một tính năng mới, chúng tôi cần phân tích các số liệu liên quan tới nó: tốc độ và độ tin cậy của tính năng đó, và chức năng mới ảnh hưởng đến hiệu suất và sự ổn định của tổng thể sản phẩm như thế nào. Những thông tin này đóng vai trò quan trọng trong việc xác định các thành phần cốt yếu của phần mềm và dễ sắp xếp mức độ ưu tiên công việc trong tương lai. Chúng tôi cũng quan sát tương tác, phản hồi của khách hàng với tính năng mới: họ sử dụng nó như thế nào, họ thường có câu hỏi gì khi sử dụng, và đang gặp khó khăn gì với tính năng mới này.
Năm ngoái tại một hội thảo, tôi đã chia sẻ về việc nếu chúng ta hiểu được dữ liệu sử dụng của khách hàng thì có thể giúp Tester hình thành chiến lược kiểm thử và thật sự một kiểm thử viên rất cần điều này để thực hiện công việc một cách hiệu quả. Nếu biết được khách hàng đang gặp khó khăn hoặc bị vướng mắc cụ thể ở đâu, chúng tôi sẽ truyền đạt lại cho nhóm kỹ sư để họ có thể giải quyết vấn đề đó và đề xuất độ ưu tiên cao hơn cho nó. Với một trường hợp phổ biến khác, nếu một tính năng không được khách hàng sử dụng thường xuyên và biết đến nhiều, thì việc đầu tư nhiều thời gian và công sức để sửa các lỗi nhỏ được tìm thấy có lẽ sẽ không có ý nghĩa và cấp thiết cho lắm.
Công việc của một Tester không bao giờ kết thúc
Sẽ không bao giờ có chuyện rằng các Tester chúng tôi không còn việc để làm. Chúng tôi là chất gắn kết trong việc giữ vững đội ngũ, chúng tôi luôn tích lũy kiến thức từ các Developer, Product Manager, Designer, bộ phận chăm sóc khách hàng và các bên liên quan khác, và sẽ luôn nhìn thấy bức tranh tổng thể. Tất cả những quan điểm trên về một sản phẩm đều quan trọng trong công việc của Tester, và khó có thể tìm thấy bất kỳ vai trò nào khác trong công ty có kiến thức như vậy.
Sự kết hợp kỹ năng và kiến thức độc đáo này cho phép chúng tôi trở thành những người mà mọi người tìm đến khi có bất kỳ câu hỏi nào về việc "cách tính năng nào đó hoạt động hiện tại". Chúng tôi luôn nắm rõ tình trạng hiện tại và có thể giúp thu gọn khoảng cách giữa tầm nhìn và hiện thực một cách đáng kể để giúp giảm bớt khó khăn trong quá trình phát triển.
Sau khi đọc xong bài viết này chắc bạn thực sự đã hiểu rõ sự quan trọng của một Tester, và họ giúp ích được nhiều thế nào trong một đội ngũ phát triển. Vậy nên, hãy suy nghĩ lại hai lần khi quyết định loại bỏ họ nhé.
Tác giả: Lidia Barkanova - Lead Quality Engineer
Nguồn bài viết: https://www.ministryoftesting.com/articles/4629b105
Dịch: Phương Anh