Từ Dev chuyển sang Test có "dễ thở" hơn!? | EXPERT TALKS

Trong lĩnh vực IT có rất nhiều chuyên môn khác nhau chẳng hạn như phát triển Web, phát triển App, phát triển Game,v.v. Song dù là lập trình hay phát triển ra bất cứ sản phẩm nào thì trước khi đi vào hoạt động công khai trong cộng đồng đều phải trải qua giai đoạn Test để đánh giá chất lượng, phát hiện bug và khắc phục. Chính vì bất kỳ dự án nào cũng cần đến Test, nên Software Tester luôn có chỗ đứng giá trị ở bất cứ đâu và bất cứ thời điểm nào, tuy không phải lúc nào cũng sôi động như các công việc IT khác. Để có thêm cái nhìn thực tế về nghề này mời các bạn theo dõi bài viết Expert Talk kỳ này: "Từ DEV chuyển sang TEST có "dễ thở" hơn!?" với phần chia sẻ của anh Phan Huy Cường - Testers cho rất nhiều dự án phát triển phần mềm - Công ty One Tech Asia.

Phan Huy Cường

Phan Huy Cường

Software Tester

OneTech Asia

Giới thiệu

Anh Phan Huy Cường hiện đang là Tester của rất nhiều dự án phát triển phần mềm tại Onetech Asia, đặc biệt là các phần mềm .NET. Xuất phát điểm là một Dev sau đó chuyển sang Test, đến nay đã có 5 năm kinh nghiệm về Test các dự án. Là một tay ngang chắc hẳn có khá nhiều điều thú vị anh sẽ chia sẻ về nghề trong bài viết này!

Chủ đề EXPERTS TALK:

"Software Tester - Từ Dev chuyển sang Test có "dễ thở" hơn!​​".

 Cơ duyên nào khiến anh chọn lựa nghề Tester?

 Từ Dev anh chuyển sang Test có dễ và mất nhiều thời gian không?

 Công đoạn test thường chiếm bao nhiêu % trong tất cả công đoạn phần mềm?

Công đoạn test thường chiếm 1/3 phần trong tất cả công đoạn của dự án, nhưng cũng tùy dự án, có một vài trường hợp đặc biệt công đoạn test có thể chiếm tới 50% công đoạn của một dự án phần mềm.

 Khi nào dùng Manual Testing và khi nào dùng Automation Testing?

Nếu mình làm dự án dạng Product thì nên đầu tư thời gian để lập Script cho toàn bộ product sau giai đoạn phát triển sẽ đưa vào Automation testing, còn nếu đó là dự án Out-source thì mình nên dùng Manual Testing.

Lí do là vì quy mô của dự án phát triển Product đồ sộ hơn với nhiều màn hình và các chức năng đa dạng, mức độ test có khả năng lặp lại nhiều và đòi hỏi sự nhất quán giữa tất cả các màn hình với nhau nên mình cần lập script để automatiiong testing. Bên cạnh đó, vấn đề này cũng tùy thuộc vào bên khách hàng có yêu cầu chi ngân sách cho Automation test hay không, nếu được yêu cầu bên mình vẫn sẽ làm.

Còn các dự án Out-source nếu không được khách hàng yêu cầu cùng với tính chất và quy mô nhỏ thì mình nên dùng hẳn Manual test. Nếu ngồi lập script để Automation test cũng cần kha khá thời gian, như vậy cũng không cân xứng với quy mô và tính chất của dự án gây lãng phí công sức và thời gian mà các bạn chỉ dùng để test có một lần.

 1 Module mã vừa được sửa trong ứng dụng, kiểm tra toàn bộ ứng dụng hay chỉ kiểm tra chức năng liên quan đến Module đó

"Có cần thiết hay không còn tùy thuộc vào dự án mà bạn đang test trong quá trình phát triển và trong quá trình fix bug!"
Chẳng hạn như module đó mà bên Dev chỉ can thiệp vào một màn hình với các thay đổi chức năng không liên quan đến các màn hình khác thì chỉ cần test ở màn hình đó.

Mặt khác nếu dev chỉnh sửa đến những bug hoặc thay đổi các chức năng trên toàn màn hình hoặc có liên quan đến màn hình khác thì Tester phải kiểm toàn bộ các màn hình đó, thậm chí toàn bộ ứng dụng, tùy thuộc vào phạm vi liên quan.

 Làm thế nào để test mà thiếu hoặc không có bất cứ tài liệu nào về hệ thống?

Trong khoảng thời gian anh làm tester cũng có lắm lúc gặp những trường hợp như thế này, không chỉ là những ứng dụng và hệ thống đã có sẵn từ trước, mà thậm chí là do ý tưởng hoạt động của ứng dụng và phần mềm đó quá mới, chính khách hàng cũng không có một tài liệu cụ thể gửi cho mình tìm hiểu để test.

Trước những tình huống như này thì anh phải cần bàn bạc trước với PM có kinh nghiệm để xin ý kiến,

Đồng thời cần sự phối hợp thông tin từ phía khách hàng. Ngoài ra với xuất phát điểm là Dev, thì phần này anh cũng có thể nắm nhanh hơn.

 Ngoài ra còn có tình huống khó khăn nào khi test không?

Cũng giống như nhiều vị trí công việc IT khác, Tester cũng trải qua áp lực về thời gian deadline, cụ thể là yêu cầu xác định được bug chính xác trong thời gian ngắn nhất có thể để cho bên Dev fix lại kịp gửi cho khách hàng đúng hạn. 

Càng làm nhiều thì càng thạo, khả năng ước lượng thời gian cũng chính xác hơn!

 Có điểm gì chú ý khi test trên Web và Appli không?

Khi test trên web và dev có một vài điểm khác nhau mà các bạn Tester cần lưu ý:

Về các appli thì chạy trên mobile, mà mobile hiện tại trên thị trường được phân thành nhiều loại khác nhau theo hệ điều hành cũng như dòng đời sản phẩm, chẳng hạn như hệ điều hành iOS và Android, trong đó iOS có các đời iPhone về sau này khi đưa app vào chạy cũng cho ra kết quả khác nhau. 

Nên khi test các dự án về appli các bạn cần phải test trên cả 2 hệ điều hành khác nhau nếu app của khách hàng yêu cầu trên cả 2 cửa hàng App Store và CH play, nếu khách hàng không yêu cầu thì các bạn Tester cần xác nhận lại.

Còn test trên web là các bạn cần lưu ý đến các trình duyệt phổ biến để test thử hết bằng web trên các trình duyệt đó xem có hoạt động tốt và có bug gì không! Vì tương tự như app thì khi web chạy trên các trình duyệt khác nhau cũng cho ra những kết quả khác nhau.

 Công việc của một Tester

• Nắm được yêu cầu về chất lượng của dự án từ khách hàng. Sau đó, đặt ra danh sách các câu hỏi, vấn đề mà mình còn thắc mắc về dự án cần khách hàng giải đáp. 
• Sau khi được khách hàng, sẽ tiến hành lập Plan Test, xác định kỹ thuật test, và lập các Test Case chi tiết, kèm theo thời gian thực hiện các test case
• Trong khoảng thời gian mình lên Plan Test thì các Dev đang xây dựng dự án, cho đến khi Dev hoàn thành phần của mình thì các Tester tiến hành Test

• Sau khi Test ra các bug cần được fix thì gửi cho bên Dev fix xong hết có thể báo cáo với khách hàng 
• Cuối cùng là nhận feedback rồi lại thực hiện Re-test (nếu cần) cho đến hạn chót giao thành phẩm cho khách hàng.

 Có phải tester giỏi là tester phát hiện được nhiều bug? Số lượng bug tùy thuộc vào những yếu tố nào?

Anh nghĩ ý kiến trên không đúng tí nào! Bug nhiều hay ít cũng là tùy vào quá trình phát triển dự án chứ! Nếu mà muốn so sánh giữa 2 bạn tester thì nên cho test cùng một dự án thì may ra đánh giá ai hơn ai mới đúng. 

Số lượng bug như anh nói phát sinh từ giai đoạn phát triển dự án, thậm chí có đôi lúc là ngay khâu nhận yêu cầu khách hàng, giữa mình và khách hàng bị nhiễu thông tin dẫn đến hiểu nhầm một vài chi tiết trong yêu cầu thì đó cũng là lỗi.

 Vậy để đánh giá một người Tester chuyên nghiệp dựa trên những tiêu chí nào?

Anh nghĩ có 3 yếu tố chính để nhận định một Tester chuyên nghiệp: 

• Thứ nhất, biết nhiều kỹ thuật Test và vận dụng các kỹ thuật vào các dự án sao cho phù hợp và hiệu quả
• Thứ hai, sau khi Test nhận được feedback preview từ khách hàng tốt, tức là mình đã test ra được các bug cho dev fix lại để đạt được đúng với yêu cầu khách hàng. 

 Có ý kiến cho rằng công việc của một tester thường rất nhẹ và không áp lực như các công việc IT khác? Anh nghĩ sao về vấn đề này?

Đối với người Tester như anh cảm thấy áp lực lớn nhất đến từ trách nhiệm khi mình là khâu cuối cùng trước khi đưa sản phẩm đến tay khách hàng, luôn phải cần thận dò xét qua nhiều test case và cập nhật liên tục theo các bug được fix.

Điều này cũng gắn liền với áp lực về thời gian, vì là khâu cuối gần deadline nhất nên Tester và cả team đều phải cuống cuồng chạy, test rồi lại fix cho đến khi gửi cho khách hàng. Thế nên tester phải cố gắng test thật nhanh để cho Dev fix rồi lại re-test lần nữa.

Bên cạnh đó, áp lực khi tiếp xúc những công nghệ mới, mình phải dành nhiều thời gian và công sức để tìm hiểu, nghiên cứu nhiều.

 Có mâu thuẫn khi các tester làm việc chung với các Dev? Bí quyết để thuyết phục Dev?

Vấn đề trong công việc giữa Dev và Test thực sự là có nhưng nó được giải quyết như thế nào cũng tùy vào sự khéo léo.

Phần lớn anh và các bạn Dev làm việc với nhau trên tinh thần muốn hiệu quả công việc cũng như sản phẩm cuối cùng là tốt nhất, nên đều thảo luận mọi vấn đề một cách ôn hòa và tôn trọng lẫn nhau.

Ví dụ có những lần anh xác định ra bug này và cảm thấy nó cần được sửa, nhưng các Dev không muốn sửa vì trong yêu cầu của khách hàng không có. 

Trong tình huống này anh thường giải thích cụ thể cho các Dev dù trong yêu cầu của khách hàng không có nhưng trên thực tế sản phẩm mà để lại bug này thì sẽ ảnh hưởng đến trải nghiệm người dùng đáng kể, nên cần được sửa và với kinh nghiệm của anh, không sớm thì muộn trên feedback của khách hàng cũng sẽ yêu cầu fix bug này, chỉ là giờ họ chưa thấy sản phẩm thực tế. 

 Những tố chất quan trọng của một Tester chuyên nghiệp?

Anh nghĩ tố chất cần thiết nhất là cẩn thận, tỉ mỉ.

Tuy nhiên cũng đừng nên cầu toàn thái quá, vì nếu quá mức như vậy có thể test ra mãi không hết bug mà chỉ khiến cho trễ tiến độ và người Dev làm cùng nghĩ mình quái gỡ chẳng hạn.

Tố chất nữa anh thấy cần thiết là sự siêng năng, cần cù.

 Điều gì khiến anh gắn bó với công việc này?

Khi làm nghề này thứ nhất anh cảm thấy khả năng mình làm được và làm tốt công việc này bởi nó phù hợp với tính cách và khả năng của anh.

Càng làm Tester anh càng cảm thấy mình học được nhiều điều mới, không chỉ riêng trong kỹ thuật test mà còn nhiều lĩnh vực khác.

Đây là điều khiến anh cảm thấy gắn bó với nghề. Hơn thế nữa, khi làm Tester anh nhận ra vai trò giá trị của mình trong các dự án, thấy được những đóng góp của mình với team và các dự án được công nhận.

 Lời khuyên cho các bạn mới vào nghề tester là gì?

Khi bắt đầu làm nghề này, các bạn tuy là những người cuối cùng nhưng không hề kèm phần quan trọng. Làm Tester không chỉ luôn luôn cập nhật những kỹ thuật test mới mà còn tìm hiểu những kiến thức mới về IT, chịu khó tự học và tìm tòi.