NHỮNG SỰ THẬT CHỈ TESTER MỚI HIỂU

22/10/2020

NHỮNG SỰ THẬT CHỈ TESTER MỚI HIỂU 

 

Việc kiểm thử phần mềm có thể rất stress. Nguyên nhân gây ra có thể đến từ việc chạy deadline, thiếu giao tiếp hay các áp lực từ bên trong nội bộ. Đây là bản chất hiển nhiên của công việc này - là điều các tester sẽ phải trải qua khi làm việc. Sau đây là một vài khó khăn mà chỉ tester mới hiểu:

1. Bị đánh giá thấp

“Dev có thể tự check code của họ” – Đây là lí do mà nhiều công ty đưa ra để giải thích cho vấn đề không cần tester. Điều này hay xảy ra với những công ty có kinh phí thấp.

Lúc nào cũng cần phải có tester. Cắt giảm chi phí dành cho việc kiểm thử không phải là cách. Trong quá trình phát triển, một team kiểm thử tận tụy sẽ tiết kiệm giúp công ty rất nhiều thời gian và công sức. Nếu release một sản phẩm đầy bug, các công ty sẽ mất luôn cả khách hàng của mình, các lập trình viên sẽ mất nhiều thời gian để fix – điều này chắc chắn sẽ làm tăng chi phí.

Các lập trình viên có thể viết các chương trình không có lỗi, có thể viết các dòng code rất tinh tế chỉ trong nháy mắt… nhưng vậy vẫn chưa đủ. Bạn vẫn cần một team kiểm thử tốt.

Tester không phải là người chỉ tìm kiếm bug. Họ còn cải thiện các tính năng của sản phẩm cho các mục đích kinh doanh trên từng yêu cầu. Một sản phẩm hoàn thiện là chưa đủ mà còn phải chuyển giao sản phẩm tốt khiến người sử dụng yêu thích.

Nhiều người nói rằng “Tester không giỏi bằng các developer”- Hoàn toàn sai – một dev tốt chưa hẳn là một test tốt, một tester tốt cũng chẳng cần phải là một dev tốt. Một tester yêu cầu phải có những kĩ năng đặc biêt bao gồm các kiến thức tổng quát về hệ thống, database và giao tiếp hiệu quả. Việc duy trì giao tiếp lúc nào cũng là một thách thức khó khăn.

2. Hạn chế về thời gian

Việc testing lúc nào cũng được đặt tại giai đoạn cuối của một project, và điều này có thể trở nên rất tệ: “Chúng ta sẽ launch sản phẩm này tuần sau, tester có thể nhanh tay lên một chút không?”- PM “của năm” hỏi 
Sau đó tester sẽ cố hoàn thành task của mình nhưng không thể giảm thiểu rủi ro nhiều như bình thường.

Thông thường, chúng ta sẽ tập trung vào việc tìm các lỗi nhỏ hơn là thực sự hiểu về phần mềm đó. Chúng ta sẽ bỏ qua các lỗi tinh vi trong hệ thống, bỏ qua khả năng bảo trì và chất lượng code. Đó là điều tốt nhất chúng ta có thể làm trong hoàn cảnh này. Cho dù có cố gắng nhiều như thế nào đi chăng nữa, việc đảm bảo chất lượng testing với deadline áp lực là bất khả thi

Hãy xem xét việc để tester và developer hợp tác với nhau ngay từ đầu dự án. Chúng ta có thể sớm phát hiện các lỗi tiềm năng và không bị dí deadline. Điều này sẽ làm mọi người hạnh phúc, đặc biệt là người sử dụng sản phẩm

3. Là người không bao giờ được báo về các thay đổi của tính năng

Đây là ác mộng tệ nhất của tester. Hãy tưởng tượng bạn dành cả ngày để đọc code và viết scripts, sau đó trên tay với bản report với 32 bugs được tìm thấy thì nghe bảo:

- Đây đâu phải là bug, đó là tính năng mới được update. Không ai nói cho tester biết sao?
- Không…

Giờ bạn lại phải quay lại bàn làm việc, viết lại tất cả các test case và lặp lại tất cả quá trình một lần nữa. Việc không giao tiếp được với team có thể gây ra việc làm đi làm lại không cần thiết à tốn thời gian và tiền bạc

4. Người phải chịu tiếng xấu

Không ai thích bị nói là “ Con bạn xấu quá”. Một vài dev không thích “con” của họ cần được sửa chữa nhưng công việc của tester là report lỗi và chắc chắn đó không phải là một việc làm được lòng người khác cho lắm J)

- Tester: “Có bug tại dòng X kìa”

- Dev/Manager: “Chắc chưa? Tôi sẽ chứng minh là cậu hoàn toàn sai!”

Đây là lúc tester cần biết để chứng minh tại sao lại có bug.

Nhưng nếu chúng ta sai thì sao?

Ý kiến của chúng ta sẽ không được lắng nghe vào lần tiếp theo. Tester không được phát biểu quá nhiều trong toàn bộ quá trình vì đó không phải là sản phẩm của họ.

Tuy nhiên, tester có quyền dừng một sản phẩm nếu họ thấy nó kém chất lượng. Chúng ta giữ trách nhiệm quyết định khi nào dừng test, chúng ta đánh giá một sản phẩm đã sẵn sàng launching chưa. Điều này sẽ gây nên rất nhiều xung đột giữa tester và PM, nhiều khi tester còn bị buộc lỗi vì làm chậm quá trình launching sản phẩm.

5. Không phải lúc nào cũng thú vị

Đừng hiểu nhầm, chắc chắn rằng các tester đều rất yêu công việc của mình. Đây chỉ là một điều hiển nhiên mỗi người phải trải qua trong công việc, cho dù bạn có là nhân viên văn phòng hay một công nhân.

Hàng ngày, các tester phải viết những bản report giống nhau, thực thi các tets case giống nhau lặp đi lặp lại thì không thể nào không chán được. Cho dù chúng ta có sáng tạo, tâm huyết đến đâu thì vẫn sẽ có việc lặp đi lặp lại. Sự hồi hộp khi tìm bug ban đầu sẽ dần dần phai nhạt.

“Thế việc tự động hóa các quy trình thì sao?”

Đó là một giải pháp. Tuy nhiên, chúng ta, những tester phải thật cẩn thận. Chúng ta phải đảm bảo rằng việc test tự động được thực hiện đầy đủ. Chỉ một lỗi nhỏ thôi cũng có thể đẩy cả team xuống. Tự động hóa là một con dao hai lưỡi đặc biệt là khi sứ mệnh của tester là để đảm bảo chất lượng

Nhưng này, chúng ta ngủ, đánh răng, tắm rửa và làm việc mỗi ngày. Chúng ta lặp lại các công việc hàng ngày để đáp ứng các nhu cầu cơ bản để chúng ta có thể làm những điều mình muốn. Tester cũng thế. Sau khi đã làm những việc cơ bản, tester bắt tay vào việc kiểm thử. Việc kiểm thử cho phép bạn vi phạm mọi thứ (break things), điều này trở nên khá thú vị. Chúng ta sẽ khám phá các phần mềm và tìm kiếm những mẫu ẩn cùng những thông tin giá trị. Việc kiểm thử trở nên vui vẻ hơn bao giờ hết.

6. Một công việc không được tôn trọng

 

Là một tester cũng giống như là một team hậu trường, chúng ta phải đảm bảo mọi thứ chạy mượt mà. Tuy nhiên, chỉ có công ty, người quản lí và đội dev giành được spotlight. Không ai nhớ công của Tester sau khi mọi thứ đã xong. Cuối cùng đó cũng chỉ là “việc phải làm”

Vậy nếu khi công ty release sản phẩm và có bug xuất hiện thì sao? Tất nhiên đó là lỗi của tester. Testing là công đoạn cuối cùng trước khi một sản phẩm được đến tay khách hàng vậy nên việc đổ lỗi cho tester là dễ hiểu và hiển nhiên nhất. Mọi thứ lúc nào cũng cần phải hoàn hảo, thậm chí khi phải trải qua deadline gấp và vòng làm việc lặp lại không bao giờ kết thúc. Giờ thì chúng ta lại trở lại với số 2.

Mạnh mẽ lên, tester!

Nếu bạn là tester và đang gặp phải những vấn đề như vậy? Bạn có nghĩ càng một tester tốt cần được công nhận thường xuyên hơn? Dù bạn có đồng tình hay không, chúng tôi cũng rất sẵn lòng nghe câu chuyện, ý kiến và kinh nghiệm của bạn!

 

XEM THÊM CÁC KHÓA HỌC
DOANH NGHIỆP LIÊN KẾT
CƠ SỞ VẬT CHẤT

Copyright © 2019 ietech.vn, All Rights Reserved