Trở thành Tester

Những sai lầm trong việc kiểm thử bằng tay manual - testing (Hay gọi là test tay theo tiếng việt). Đầu tiên là khái niệm: Kiểm thử trực tiếp (Manual Testing) là việc nhân viên kiểm thử thực thi việc kiểm tra hệ thống phần mềm mà không dùng qua bất cứ công cụ kiểm thử tự động nào. Dưới đây là những suy nghĩ sai lầm thường thấy của những người trong và ngoài ngành test: 1)  Ai cũng có thể thực hiện kiểm thử bằng tay. Sự thật : Testing đòi hỏi một loạt các kỹ năng khác nhau, không như tưởng tượng của một số người là ai làm cũng được. Ví dụ: kỹ năng phân tích, đọc tài liệu, trí tò mò, báo cáo... 2) Test xong nghĩa là không còn bug (defect).. Sự thật : Việc kiểm tra phần mềm chỉ mong muốn là tìm được nhiều bug nhất có thể. Nếu nghĩ testing tất cả mọi thứ là chuyện nhỏ thì là một câu chuyện hoang đường. Ví dụ: kiểm tra một trường email 50 ký tự. Ta sẽ có các trường hợp lũy thừa 50 ký tự số và chữ, và việc bỏ công test 1 trường email như thế mất hàng năm trời... 3) Test tự ...

TDD là môt kỹ thuật lập trình hướng trước cách phát triển của thiết kế phần mềm hệ thống (Hệ thống mà developer sẽ phát triển). Nó giúp các lập trình viên viết những tình huống kiểm thử trước khi việc phát triển code được thực thi và hiệu quả của việc này giúp lập trình viên sẽ hiệu quả trong khi giải quyết vấn đề của bài toán hơn là cách giải quyết bài toán. TDD sẽ giúp lập trình viên có những khía cạnh ngược. Làm được điều này sẽ tạo ra một lập trình viên: Extreme Programming. Dự đoán trước những gì mình sẽ giải quyết cho lời giải của một bài toán. Chúng ta có thể thấy rằng TDD sẽ giúp lập trình viên nâng cao kỹ năng làm việc của mình. Dev Cũ Dev - TDD

Sau đây là các mức kiểm thử theo trong quy trình phát triển phần mềm theo mô hình V model. 1. Component Testing còn gọi là Unit testing - test ở mức cơ bản (test từng hàm, từng màn hình riêng lẻ,...) 2. Integration Testing : Test ở mức tích hợp (tích hợp các hàm lại với nhau, tích hợp các màn hình lại với nhau theo từng module hay dựa theo chức năng). 3. System Testing : test ở mức hệ thống (tích hợp toàn bộ các hàm, các chức năng thành một phần mềm, module hoàn chỉnh). 4. Acceptance Testing : mức test này giống như system test nhưng thường được khách hàng thực hiện test, mục đích là xem phần mềm có đáp ứng đúng yêu cầu của khách hàng chưa. Thực ra còn một mức Integration System testing là kết hợp các hệ thống lại với nhau để xem chúng hoạt động trơn tru hay chưa. Mức này được thực hiện sau bước 3, khi System Test đã được hoàn chỉnh. Các phần trong bài viết sẽ được trình bày cụ thể sau. Nguồn: Testing Blog .

Sau khi nhận được tài liệu yêu cầu (requirement hay specification) từ khách hàng hoặc bộ phận phân tích thiết kế yêu cầu. Tiếp đó, Q.C, developer sẽ tìm hiểu, đánh giá req. này xem có lỗi hay không. Q.C sẽ viết test plan, sau đó gửi test plan cho khách hàng và project manager xem lại, sau khi duyệt test plan này Q.C sẽ tiến hành viết test case dựa vào req. đó. (Cùng lúc đó Developer sẽ dựa vào spec để phân tích ra module và bắt đầu code). Nếu công ty có bộ phận test whitebox (thường thì developer sẽ thuộc bộ phận này, nhưng trong một số tình huống dự án cần gấp thì Q.C cũng tham dự vào để hỗ trợ) thì họ sẽ dựa vào spec viết test case test whitebox và viết test script để test whitebox. (thường gọi là unit test - ở đây, "unit" là 1 hàm, 1 class hoặc 1 component,... tùy cách nhìn nhận và quản lý của mỗi công ty). Sau khi test whitebox thành công (test pass các test case whitebox) thì QC sẽ tiến hành test blackbox (test chức năng của từng màn hình - cái này cũng được x...