Mình làm test manual đến nay đã gần 2 năm, dạo gần đây mình cảm thấy khá là stress trong công việc , từ nói chuyện với bên khách hàng, đến test các dự án hiện tại chủ yếu là nâng cấp từ các hệ thống đã triển khai. Mình cảm thấy tay nghề của mình dạo này không phát triển lên được và cảm thấy mất phương hướng.
Mình làm cho cty outsource, test chủ yếu dựa trên tài liệu của BA,nhưng đội ngũ BA không được chuyên nghiệp cho lắm, hầu như không phải dân cntt chính thống, tài liệu làm xong thì lại sửa đổi rồi mình lại test lại 1 đống. Testcase thì không có thời gian để viết trước, các dự án dồn dập, dự án này xong thi nhảy sang test dự án khác luôn, đến khi test xong rồi mới quay ra update or làm mới testcase.
Mình đang cảm thấy chán nản khi phải làm việc như này. Mình đang định hướng sang auto test, ad cho mình xin lời khuyên hiện tại mình cần làm gì để vứt bỏ cái mớ bòng bong này trong đầu với ạ. Thanks!
Mất phương hướng trong công việc manual tester
-
- Hoc Tester
- Posts: 7
- Joined: Mon 26 Nov, 2018 5:19 pm
- Contact:
-
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Mất phương hướng trong công việc manual tester
Hi hoantt25195
Mình hiểu sự mất phương hướng của bạn. Mình đã từng rơi vào trường hợp tương tự như vậy. Nhưng nó không phải là về việc bảo trì các hệ thống cũ. Mà dựa trên 1 sản phẩm, sao chép và chỉnh sửa theo yêu cầu mới cho khách hàng khác (mới).
Vấn đề cẩn phải giải quyết ở đây là Hoa quá nhiều việc. Và sự thay đổi yêu cầu quá nhanh, quá gấp, cao hơn mức (khả năng) Hoa và nhóm có thể xử lý được. Nó tạo ra cảm giác luôn dồn dập và "ngợp." Và làm cho Hoa có suy nghĩ rằng công việc mà Hoa đã làm rồi (test case mà Hoa đã viết, các chức năng mà Hoa đã kiểm thử), giờ phải ngồi làm lại => phí công sức và tốn nhiều công sức vô ích. Vô tình nó không tạo động lực cho Hoa làm việc, mà lại làm Hoa có cảm giác là người gây ra sự chậm trễ, và đuối vì test không kịp,... trong khi khách hàng và PM thì hối và luôn hỏi tại sao chất lượng phần mềm lại không cao? tại sao bugs nhiều? User thì hỏi tại sao hệ thống/sản phẩm lại không sử dụng được, v.v...
Liệu giờ Hoa chuyển sang hướng Automation tester thì có giải quyết được vấn đề này không? Mình không nghĩ Hoa cần chuyển sang hướng khác. Vì nó không giúp Hoa thoát ra khỏi mớ bồng bông, vòng luẩn quẩn này. Chỉ khi nào Hoa nghỉ làm ở đó thì may ra Hoa có thể thoát được nó thôi. Nhưng Hoa không muốn nghỉ, và Hoa muốn ưu tiên một cách/giải pháp/lựa chọn khác để thử trước khi nghĩ đến lựa chọn cuối cùng đó.
Tại sao Hoa muốn chuyển hướng sang làm auto? Giả sử Hoa học xong 1 khóa auto đâu đó, rồi Hoa sẽ làm gì tiếp? Áp dụng vào các dự án hiện tại đó hay tìm công ty khác? Test automation có giúp ích gì nhiều cho các dự án gấp gấp và tài liệu thì chuối (như em mô tả - luôn thay đổi xoành xoạch vì không giống với ý khách hàng) hay không?
Hoa suy nghĩ một số câu hỏi trên và có thể comment (reply) ở đây và mình sẽ trao đổi tiếp chủ đề này nha. Nó cũng là câu chuyện tương tự của rất rất nhiều bạn khác nữa áh. Không riêng Hoa đâu nha. Nên cũng đáng để mọi người suy ngẫm và chia sẻ ý kiến cá nhân cũng như cách mà họ đã vượt qua "khủng hoảng" này.
Mình hiểu sự mất phương hướng của bạn. Mình đã từng rơi vào trường hợp tương tự như vậy. Nhưng nó không phải là về việc bảo trì các hệ thống cũ. Mà dựa trên 1 sản phẩm, sao chép và chỉnh sửa theo yêu cầu mới cho khách hàng khác (mới).
Vấn đề cẩn phải giải quyết ở đây là Hoa quá nhiều việc. Và sự thay đổi yêu cầu quá nhanh, quá gấp, cao hơn mức (khả năng) Hoa và nhóm có thể xử lý được. Nó tạo ra cảm giác luôn dồn dập và "ngợp." Và làm cho Hoa có suy nghĩ rằng công việc mà Hoa đã làm rồi (test case mà Hoa đã viết, các chức năng mà Hoa đã kiểm thử), giờ phải ngồi làm lại => phí công sức và tốn nhiều công sức vô ích. Vô tình nó không tạo động lực cho Hoa làm việc, mà lại làm Hoa có cảm giác là người gây ra sự chậm trễ, và đuối vì test không kịp,... trong khi khách hàng và PM thì hối và luôn hỏi tại sao chất lượng phần mềm lại không cao? tại sao bugs nhiều? User thì hỏi tại sao hệ thống/sản phẩm lại không sử dụng được, v.v...
Liệu giờ Hoa chuyển sang hướng Automation tester thì có giải quyết được vấn đề này không? Mình không nghĩ Hoa cần chuyển sang hướng khác. Vì nó không giúp Hoa thoát ra khỏi mớ bồng bông, vòng luẩn quẩn này. Chỉ khi nào Hoa nghỉ làm ở đó thì may ra Hoa có thể thoát được nó thôi. Nhưng Hoa không muốn nghỉ, và Hoa muốn ưu tiên một cách/giải pháp/lựa chọn khác để thử trước khi nghĩ đến lựa chọn cuối cùng đó.
Tại sao Hoa muốn chuyển hướng sang làm auto? Giả sử Hoa học xong 1 khóa auto đâu đó, rồi Hoa sẽ làm gì tiếp? Áp dụng vào các dự án hiện tại đó hay tìm công ty khác? Test automation có giúp ích gì nhiều cho các dự án gấp gấp và tài liệu thì chuối (như em mô tả - luôn thay đổi xoành xoạch vì không giống với ý khách hàng) hay không?
Hoa suy nghĩ một số câu hỏi trên và có thể comment (reply) ở đây và mình sẽ trao đổi tiếp chủ đề này nha. Nó cũng là câu chuyện tương tự của rất rất nhiều bạn khác nữa áh. Không riêng Hoa đâu nha. Nên cũng đáng để mọi người suy ngẫm và chia sẻ ý kiến cá nhân cũng như cách mà họ đã vượt qua "khủng hoảng" này.
-
- Hoc Tester
- Posts: 8
- Joined: Wed 05 Sep, 2012 12:10 pm
- Contact:
Re: Mất phương hướng trong công việc manual tester
Chào bạn hoantt25195,
Bên cạnh comments của tvn ở trên, mình cũng chia sẻ một chút.
Công việc nào cũng có những khó khăn riêng, công việc càng có khăn thì nó lại là cơ hội để phát huy khả năng của mình, để biết được sức mình có khả năng "bơi" được bao xa.
Trong trường hợp của bạn, trước khi test application thì bạn đã xem tài liệu của BA và có phát hiện điều gì bất hợp lý hay không? BA cũng có thể tạo ra lỗi trong tài liệu hoặc tài liệu không được rõ ràng. Bạn có thể "test" tài liệu trước khi test application để phát hiện bug sớm.
Với những dự án thay đổi liên tục, thì checklist sẽ hiệu quả hơn test case, tiết kiệm được thời gian để làm việc khác.
Một điểm nữa là liệu bạn có đang thực hiện việc test đúng cách hay chưa? có thích nghi với sự thay đổi của dự án chưa? có nâng cấp kỹ năng của mình lên chưa...? Bạn nói cụ thể hơn những điều bạn đang gặp khó khăn thì mình nghĩ mọi người sẽ giúp được bạn.
Hoặc bạn có thể tới những buổi offline hoặc group skype của TVN để gặp các anh chị có kinh nghiệm tư vấn cho mình thêm.
Còn nếu vấn đề nằm ở kỹ năng testing thì bạn có thể học thêm những khóa học về testing sẽ áp dụng rất nhiều trong công việc.
Chúc bạn sớm thoát khỏi mớ bòng bong này.
Bên cạnh comments của tvn ở trên, mình cũng chia sẻ một chút.
Công việc nào cũng có những khó khăn riêng, công việc càng có khăn thì nó lại là cơ hội để phát huy khả năng của mình, để biết được sức mình có khả năng "bơi" được bao xa.
Trong trường hợp của bạn, trước khi test application thì bạn đã xem tài liệu của BA và có phát hiện điều gì bất hợp lý hay không? BA cũng có thể tạo ra lỗi trong tài liệu hoặc tài liệu không được rõ ràng. Bạn có thể "test" tài liệu trước khi test application để phát hiện bug sớm.
Với những dự án thay đổi liên tục, thì checklist sẽ hiệu quả hơn test case, tiết kiệm được thời gian để làm việc khác.
Một điểm nữa là liệu bạn có đang thực hiện việc test đúng cách hay chưa? có thích nghi với sự thay đổi của dự án chưa? có nâng cấp kỹ năng của mình lên chưa...? Bạn nói cụ thể hơn những điều bạn đang gặp khó khăn thì mình nghĩ mọi người sẽ giúp được bạn.
Hoặc bạn có thể tới những buổi offline hoặc group skype của TVN để gặp các anh chị có kinh nghiệm tư vấn cho mình thêm.
Còn nếu vấn đề nằm ở kỹ năng testing thì bạn có thể học thêm những khóa học về testing sẽ áp dụng rất nhiều trong công việc.
Chúc bạn sớm thoát khỏi mớ bòng bong này.
-
- Hoc Tester
- Posts: 7
- Joined: Mon 26 Nov, 2018 5:19 pm
- Contact:
Re: Mất phương hướng trong công việc manual tester
Mình cũng xác định được là ở đâu cũng có áp.lực. Lượng công việc nhiều hay ít cũng 1 phần phụ thuoc vào năng lực của mình. Dù mik có nghỉ nơi mik đang làm.hay không thì sang bên khác cũng có thể gặp trường hợp tương tự.
+ Trường hợp mình đang gặp phải: hiện mình đang làm 2 dự án song song, thực tế là 1 dự án xây dựng mới, 1 dự án nâng cấp tiếp. Dự án 1 mik làm xong và chỉ đợi bên K.hang test thôi, tuy nhiên mỗi lần họ test là 1 lần hỏi rất nhiều, trong khi lần check trước mik đã tl rất rõ, lần sau lại hỏi y nguyên như vậy, minh vẫn tl nhưng quỹ thời gian còn dành cho dự án khac, họ cứ muốn mình kè kè bên cạnh, hỏi là phải rep ngay lập tức và họ không đọc tài liệu luôn, dẫn đến mik có rất ít thời gian để test con khác nên mình sợ lọt bug dẫn đến có thể fail.
+ Dự án nâng cấp mik đọc tài liệu 1 lượt xem phải làm j. Check ý chính, ý sửa đổi trước sau đó mới check đến validate đảm bảo phần nâng cấp k bị lỗi j. Sau đó mik check đến phần ảnh hưởng.
Yêu cầu thay đổi liên tục mik có thể xử lý nhưng quỹ thời gian hạn hẹp làm mik stress, mặc dù biết lỗi có thể xảy ra ở đâu nhưng deadline không cho phép mình test thêm nữa
Hơn nữa còn chưa kể thời gian mình phải tìm hiểu hệ thống này chạy luồng như nào nữa
Dev làm mik khổ sở vì ảnh hưởng luồng rất nhiều, có thể do lỗi từ phase trc mà giờ mới phát hiện ra
Đó là thứ tự test của mình.
+ Kỹ năng sau mỗi dự án thì mik có thể phán đoán đc case có thể gặp phải và hỗ trợ dev xử lý được tốt hơn
Tuy nhiên nếu cứ phải test lại luồng khi hay bị thay đổi thì có hướng nào check nhanh nhất mà vẫn đảm bảo được không ạ
Mọi người có cách xử lý nào tốt hơn hay hợp lý hơn khi quỹ thời gian ít không ạ, cho mình xin lời khuyên với
+ Trường hợp mình đang gặp phải: hiện mình đang làm 2 dự án song song, thực tế là 1 dự án xây dựng mới, 1 dự án nâng cấp tiếp. Dự án 1 mik làm xong và chỉ đợi bên K.hang test thôi, tuy nhiên mỗi lần họ test là 1 lần hỏi rất nhiều, trong khi lần check trước mik đã tl rất rõ, lần sau lại hỏi y nguyên như vậy, minh vẫn tl nhưng quỹ thời gian còn dành cho dự án khac, họ cứ muốn mình kè kè bên cạnh, hỏi là phải rep ngay lập tức và họ không đọc tài liệu luôn, dẫn đến mik có rất ít thời gian để test con khác nên mình sợ lọt bug dẫn đến có thể fail.
+ Dự án nâng cấp mik đọc tài liệu 1 lượt xem phải làm j. Check ý chính, ý sửa đổi trước sau đó mới check đến validate đảm bảo phần nâng cấp k bị lỗi j. Sau đó mik check đến phần ảnh hưởng.
Yêu cầu thay đổi liên tục mik có thể xử lý nhưng quỹ thời gian hạn hẹp làm mik stress, mặc dù biết lỗi có thể xảy ra ở đâu nhưng deadline không cho phép mình test thêm nữa
Hơn nữa còn chưa kể thời gian mình phải tìm hiểu hệ thống này chạy luồng như nào nữa
Dev làm mik khổ sở vì ảnh hưởng luồng rất nhiều, có thể do lỗi từ phase trc mà giờ mới phát hiện ra
Đó là thứ tự test của mình.
+ Kỹ năng sau mỗi dự án thì mik có thể phán đoán đc case có thể gặp phải và hỗ trợ dev xử lý được tốt hơn
Tuy nhiên nếu cứ phải test lại luồng khi hay bị thay đổi thì có hướng nào check nhanh nhất mà vẫn đảm bảo được không ạ
Mọi người có cách xử lý nào tốt hơn hay hợp lý hơn khi quỹ thời gian ít không ạ, cho mình xin lời khuyên với
-
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Mất phương hướng trong công việc manual tester
Mình thấy dự án của bạn đang làm, gặp vấn đề "thay đổi yêu cầu liên tục" và bạn không có đủ thời gian để đối phó. Và song song là sự "làm phiền" từ phía khách hàng kia. Mình nghĩ bạn có thể thử theo một trong những cách sau:
1. Bạn yêu cầu khách hàng kia test xong 1 lượt và báo cáo cho bạn case nào passed, failed rồi sau đó bạn sẽ kiểm tra, đối chiếu và trả lời họ MỘT lần
2. Bạn có thể viết ra 1 check list cơ bản, giao nó cho DEV và yêu cầu nhóm dev phải tự test cái check list đó (cho màn hình/cụm chức năng tương ứng) trước khi gửi sang yêu cầu bạn test.
1. Bạn yêu cầu khách hàng kia test xong 1 lượt và báo cáo cho bạn case nào passed, failed rồi sau đó bạn sẽ kiểm tra, đối chiếu và trả lời họ MỘT lần
2. Bạn có thể viết ra 1 check list cơ bản, giao nó cho DEV và yêu cầu nhóm dev phải tự test cái check list đó (cho màn hình/cụm chức năng tương ứng) trước khi gửi sang yêu cầu bạn test.
-
- Hoc Tester
- Posts: 7
- Joined: Mon 26 Nov, 2018 5:19 pm
- Contact:
Re: Mất phương hướng trong công việc manual tester
Mình thấy việc để dev check lại trước khi bàn giao sang cho mình test khá là ổn, số lượng bug giảm đi khá nhiều. Thanks ad nhé
-
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Mất phương hướng trong công việc manual tester
Không có gì. Chúc bạn thành công và thấy yêu đời trở lại trên con đường tester.hoantt25195 wrote: ↑Sun 07 Apr, 2019 10:52 pmMình thấy việc để dev check lại trước khi bàn giao sang cho mình test khá là ổn, số lượng bug giảm đi khá nhiều. Thanks ad nhé