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.
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?
Trùng hợp là khoảng thời gian anh gia nhập Onetech cũng là lúc công ty mới được thành lập, anh làm ở vị trí Dev được hơn nửa năm, các dự án bắt đầu tăng lên, khối lượng công việc tăng lên nhưng khi đó công ty chưa có bộ phận test, mọi sản phẩm phần mềm gửi sang khách hàng để feedback thì quá nhiều bug, nói chung bị đánh giá chất lượng không tốt.
Cùng lúc đó, bên dự án anh đảm nhận vừa hoàn thành xong cũng còn kha khá thời gian, thế là anh quyết định vào test thử, kết quả là chất lượng sau khi gửi được khách hàng đánh giá khả quan hơn rất nhiều.
Bên cạnh đó, anh cũng tự nhận thấy cũng như được mọi người đánh giá là có tố chất phù hợp, đặc biệt là tính tỉ mỉ thích hợp để làm test tốt hơn dev vì khi đó anh Dev khá chậm. Thế là từ đó anh bắt đầu dấn thân vào test cho đến giờ! Có thể nói anh là một tay ngang trong giới tester!
Từ Dev anh chuyển sang Test có dễ và mất nhiều thời gian không?
Không hề mất nhiều thời gian, đặc biệt những bạn có nền tảng IT (như là từ Dev sang), thế nên chỉ cần tìm hiểu thêm khái niệm chung và về các kỹ thuật test cùng quy trình test một dự án, rồi tập tành làm thử và cải tiến dần dần.
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.
Nói chung để chọn Manual hay Automation chúng ta tùy thuộc vào yếu tố là quy mô, tính chất dự án và sau đó là yêu cầu từ khách hàng (nếu có)
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.
Để xác định được phạm vi liên quan, trước khi test các Tester cần tìm hiểu về dự án và các yêu cầu của khách hàng. Sau đó dựa trên các thông tin này để lập Plan Test cùng các Test case giúp tester ra các quyết định test như thế nào để không thừa và cũng không bỏ sót!"
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,
Cốt yếu là ước lượng thời gian cho dự án để cả team cũng như tester có điều kiện tìm hiểu tất tần tật về hệ thống đó.
Đồ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.
Thật vậy, cái khó của nghề nó cũng nằm ở thời gian mà cả Dev và Tester dành cho dự án, không phải hết dự án này mới đến dự án khác mà phải làm nhiều dự án cùng một lúc. Tuy nhiên, khó khăn này anh nghĩ anh và các bạn trong nghề có thể lấy kinh nghiệm khắc phục và cải thiện dầ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
Có nhiều trường hợp sau khi lập test case rồi đến lúc test vẫn có phát sinh những test case mới, mà lúc đầu có thể do chủ quan và khách quan mình chưa xác định được hết, hoặc feedback của khách hàng mong muốn có thay đổi một chút trong sản phẩm thì Tester cũng phải update test case tương ứng.
- 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.
Nếu mà nhận định một Tester giỏi nhờ vào số lượng bug thôi thì cứ chẳng khác nào thừa nhận một điều phi lý và buồn cười là Tester chỉ cần làm cùng một anh Dev dở thì thành Test giỏi còn làm cạnh một anh Dev giỏi thì mình lại trở thành Test dở
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.
Thậm chí một người Tester giỏi là người nhận thấy các UI/UX của hệ thống cần được điều chỉnh điểm nào để thân thiện với người dùng liền đóng góp với khách hàng để bổ sung thêm, những khi như vậy Tester sẽ được đánh giá rất cao!
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?
Nhiều người chưa làm thì nghĩ làm Test nhẹ nhàng, và dễ thở nhưng thực tế thì không hẳn vậy! Bất kỳ công việc gì trong một nhóm dự án bạn cũng đều có áp lực chung của cả nhóm và những áp lực ở vị trí cá nhân.
Đố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ư vậy, cách thuyết phục hiệu quả nhất là đưa ra lý do cụ thể và tính nghiêm trọng của các bug nếu như không được fix. Bên cạnh đó, anh cảm thấy mối quan hệ ôn hòa trong công việc cũng bắt nguồn từ cách mình cư xử với nhau thường ngày, cứ thoải mái chân thành chia sẻ những cái khó của nhau để hiểu nhau hơn thì vào công việc sẽ rất là thuận buồm xuôi gió!
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.
Quan trọng là các bạn đừng ngại vấp ngã, bước đầu làm test có thể gặp khó khăn do thiếu kinh nghiệm không xác định được các bug cần thiết, nhưng cứ vững tinh thần rút kinh nghiệm càng nhiều càng tốt, càng làm sẽ càng thạo và hãy có tâm với sản phẩm mình test với cảm nhận của một người dùng!
Ban biên tập chân thành cảm ơn anh đã dành thời gian chia sẻ kinh nghiệm quý báu đến các đọc giả của blog GrowUpWork, chúc anh sức khỏe và thành công!
Tin tức liên quan
Chia sẻ kinh nghiệm làm việc ở vị trí Technical Lead | EXPERT TALKS
Làm sao để người hướng nội Leadership hiệu quả | EXPERT TALKS
Làm sao để thăng tiến trong công ty IT | EXPERT TALKS
Khám phá về công việc thú vị của Product Architect | EXPERT TALKS
Những lỗi sai thường gặp phải khi phỏng vấn công ty IT | EXPERT TALKS
Công việc của IT Business Analyst là gì? Bí quyết thăng tiến? |EXPERT TALKS
