Quay lại khoảng thời gian gần 2 năm về trước, một ngày tháng 5 rực lửa tôi bén duyên với Deha =))). Bắt đầu với vị trí thực tập QA, lúc ấy trong đầu tôi chưa thực sự hiểu sâu về QA, chỉ đơn giản là test và test. Tôi cũng chưa biết đến Scrum là gì ? Và mình sẽ phải làm gì trong một nhóm Scrum ?
Có lẽ khái niệm về QA cũng không còn xa lạ với các công ty, đặc biệt là các công ty phần mềm. Vậy…
QA có nghĩa là gì?
Sau một thời gian thực tập, tôi dần hiểu hơn về công việc của QA, không đơn thuần chỉ là kiểm tra phần mềm, mà còn phải đảm bảo chất lượng phần mềm thông qua việc đưa ra quy trình làm việc với các bên liên quan.
Không giống như các lập trình viên , không thuộc một nhóm cố định nào đó. Ở Deha, QA hoạt động trong một nhóm chuyên biệt, đó là vì sao cái tên DEBIT ra đời. Với mục đích đảm bảo chất lượng phần mềm, giúp đỡ các thành viên trong team tham gia dự án độc lập và hỗ trợ nhau kịp thời khi gặp khó khăn.
Tại sao lại gọi là “ Biệt đội Kính lúp”?
Trong khi kiểm tra phần mềm, QA khá tỉ mẩn đến từng chi tiết, đâu đó cũng là tính cách cần có của một QA , luôn cẩn thận và kỹ càng để sản phẩm có thể làm hài lòng những vị khách khó tính nhất.
Một QA trong nhóm kiểm thử nên làm gì ?
Sau khi làm việc cùng một vài nhóm Scrum trong công ty, tôi nhận thấy rằng QA cần :
- Thảo luận mặt đối mặt : Trong quá trình Planning hay Release của Sprint, QA sẽ tham gia vào những cuộc họp này và sẽ hỏi về những đề đang được thảo luận.
- Tìm ra sự mơ hồ : Làm việc một cách hợp tác và đầy năng suất với chủ sản phẩm và đội phát triển để hình thành những tiêu chí chấp nhận của sản phẩm. Đặc biệt, phải hiểu chính xác là khách hàng muốn gì để giảm thiểu sự mơ hồ.
- Kỹ năng giao tiếp : Nên có sự giao tiếp tốt với các thành viên trong dự án và sẵn sàng đưa ra phản hồi.
- Sự minh bạch khi thực hiện kiểm thử : Thẳng thắn góp ý và đưa ra những lỗi gặp phải khi thực hiện test => Giúp cho đội phát triển tiến bộ hơn và đảm bảo chất lượng sản phẩm tới tay khách hàng.
Một QA trong nhóm DeBIT
- Nắm rõ được tình hình dự án mà mình tham gia, từ đó giúp phân tích được những rủi ro có thể gặp phải để kịp thời chỉnh sửa
- Không ngại học hỏi và trau dồi để nâng cao kỹ năng bản thân
- Nhiệt tình chia sẻ kiến thức và kinh nghiệm với đồng nghiệp
- Giúp đỡ khi đồng nghiệp gặp khó khăn trong dự án
Những thất bại đầu đời
Những bước đi chập chững đầu tiên đến với QA quả thực cũng khá gian nan. Nào là sinh viên mới ra trường, chưa có nhiều kinh nghiệm. Nào là một môi trường mới, còn nhiều lạ lẫm. Và rồi cả một núi kiến thức phải học. Sau khi được training, tôi bắt đầu được tham gia vào support một dự án. Sau đó khi một mình đảm nhiệm dự án, cụ thể là một dự án về app, mặc dù đã cố gắng test hết “máu” rồi nhưng kết quả thu lại là list bug dài ngoằng từ khách hàng trả về. Dần dần thì tôi nhận ra là:
Không phải cứ “hùng hục” test là sẽ hết bug
Điều quan trọng là bạn phải xây dựng niềm tin của team với mình , thấy được nguy cơ tiềm ẩn đúng hướng. BÀi học của tôi là các nhân viên QA nên nói chuyện và cởi mở hơn với team phát triển. Hãy cố gắng hiểu cái họ đang fix và dùng kiến thức của mình về requirement và hệ thống để quyết định case nào cần phải test hồi quy.
Requirement là kinh thánh
Đó là cách nghĩ của tôi khi mới vào nghề. Tôi nhìn vào requirement và viết TC theo từng dòng đó, mà không cần quan tâm requirement có hợp lý hay không, có hữu ích cho người dùng cuối hay không? Sau đó khi được tham gia vào các buổi phân tích và thảo luận về requirement, tôi đã chiêm nghiệm ra rằng : Requirement không phải là kinh thánh, nó có thể có nhiều chỗ chưa hợp lý. Và QA nên tích cực thảo luận với team của mình để giúp nó tốt hơn.
Developer là kẻ thù của tôi
Developer cũng giống như bạn thôi, đôi khi không thể tránh được sai lầm. Quan trọng là hãy cố gắng giúp đỡ nhau để tránh sai lầm đó. Hãy làm việc vui vẻ và cởi mở với nhau để có một mục tiêu, estimation rõ ràng hơn để giúp họ code tốt hơn.
Đổ lỗi hơn là cố gắng tìm giải pháp
Trở lại thời gian trước, khi tôi để sót một bug thì việc đầu tiên tôi làm là cố gắng tìm lý do vì sao tôi bỏ sót. Hoặc là cố gắng để tìm lý do xuất phát từ người khác. Tuy nhiên, sau đó, tôi nhận ra rằng những thứ này không phải là vấn đề chính. Dù lý do là gì thì ngay cả khi bạn đúng, vẫn sẽ có một khách hàng cảm thấy bực mình. Điều là mình nên làm trong trường hợp này là cần phải đảm bảo rằng chúng ra fix được vấn đề đó. Giải thích được với khách hàng để họ hiểu vấn đề, đồng thời cố gắng cải thiện vấn đề với tinh thần xây dựng. Bug đã xảy ra rồi, đừng làm vấn đề tệ hơn bằng cách phá vỡ các mối quan hệ.
Những chia sẻ vừa rồi có thể sẽ không phải là những quy chuẩn hoặc hoàn toàn chính xác, đó chỉ là những cảm nhận và suy nghĩ của một đứa mới theo nghề không lâu. Hy vọng sẽ giúp cho mọi người hiểu hơn về biệt đội “săm soi” =)). Để kết lại bài viết, có một câu nói luôn khiến tôi phải nỗ lực hơn nữa : “Ăn mừng thành công cũng tốt, nhưng quan trọng hơn là phải biết chú ý đến những bài học của sự thất bại. Công việc nào cũng thế không thể vì đạt được chút thắng lợi mà quên đi nhiệm vụ của mình.” – Bill Gates-