Thế nào là 1 Tester?

Thế nào là 1 Tester?

Tester là 1 nghề mà theo bản thân của Hòa cảm thấy thích thú và thú vị. Có người cho rằng nó thực sự nhàm chán và nhạt nhẽo. Thì các bạn nhầm rồi.

Hầu như các bạn hay than phiền phải test bằng tay hay còn gọi là manual test. Tại vì các bạn chưa khám phá hết  tất cả những tính năng liên quan. Các bạn phải trải qua nhiều dự án khác nhau và học hỏi công nghệ thì sẽ biết được làm thế nào để test cho 1 dự án đó là đạt chất lượng nhất,

Hầu như các công ty luôn biết kết hợp : giữa manual test, automation test, performance test,..

Làm như thế sẽ phát huy khả năng rà soát bug và đo lường hiệu suất của 1 project.

Vậy để trở thành 1 tester các bạn sẽ phải đi như thế nào?...

… tiếp theo phần 1(theo Hòa)

Đối với các bạn hầu như chẳng biết gì về nghề test , thì các bạn cần hỏi bật thầy google. Các bạn nên chịu khó hỏi về các khái niệm như: Whitebox, blackbox, Verification, Validation, Component test, Integration test, System test, Acceptance test, Alpha test. Beta test, Volume test, Stress test, Performance test, Test object, Test type, Test Level…

….Vì sao? Vì từ những khái niệm này các bạn sẽ bắt đầulàm quen là phân loại được project mình đang tham gia sẽ cần có những hình thức test nào?

Còn đối với những bạn đã có kinh nghiệm, các bạn nhìn vào là biết rất rõ sẽ phải dùng những loại nào là phù hợp nhất cho dự án của mình.

Quay  ngược lại vấn đề bạn luôn tự hỏi. Tại sao chúng ta cần test? Test gì cho 1 sản phẩm? Test bao nhiêu thì đủ? Mục tiêu của việc test là gì?.

 Nếu các bạn trả lời được những vấn đề tại sao đó thì các bạn đã tìm đúng con đường mình đang đi rồi đó,…

Tìm hiểu Requirement và Estimation(theo cá nhân tôi)

Tùy mỗi khách hàng, tùy mỗi dự án mà Tester tiếp cận được spec dưới những hình thức khác nhau như File mô tả, hình ảnh, usecase, sequence,.. Trước tiên chúng ta cần phân tích cẩn thận spec đó bao gồm những phần nào chính, phần nào phụ và lên plan tổng thể để ước lượng xem với khối lượng requirement đó chúng ta sẽ thực hiện cho kế hoạch test của chúng ta trong bao lâu. Chúng ta cũng có thể tạo 1 file đơn giản hơn để ước lượng hết những tính năng lớn, bé và tính xem những tính năng này sẽ chiếm bao lâu thời gian. Thường thì tester có nhiều kinh nghiệm sẽ ước đoán có vẻ ổn hơn những người chưa có kinh nghiệm. Chúng ta cũng nên tự đặc cho mình những câu hỏi như: thời gian estimate  như thế nào? Có những ràng buộc nào trong quá trình estimate?.

Trong quá trình tìm hiểu requirement chúng ta cần nên có những câu hỏi why?what?how? và hỏi lại khách hàng bằng file, hình ảnh,… để làm rõ hơn . Thường những công ty lớn khi bắt tay vào 1 dự án họ tốn nhiều thời gian họp hành face-to-face, meeting, thảo luận để giảm những vấn đề phát sinh cần phải confirm với khách hàng và đặc biệt sẽ giảm bớt bug về sauJ

Vậy chúng ta tìm hiểu phân loại về requirement nhé:

Requirement bao gồm 3 loại:

a.       User requirement: - Dành cho khách hàng với phát biểu bằng ngôn ngữ tự nhiên về 1 hệ thống.

b.      System requirement: Tài liệu có cấu trúc mô tả chi tiết các dịch vụ của hệ thống

c.       Software design specification: Mô tả chi tiết phần mềm nhằm phục vụ cho thiết kế

d. “I love deadlines. I like the whooshing sound they make as they fly by.”

                                                                                                Douglas Adams