Hiển thị các bài đăng có nhãn kiem thu phan mem. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn kiem thu phan mem. Hiển thị tất cả bài đăng

Thứ Ba, 18 tháng 11, 2014

Tìm hiểu cơ chế SQL injection tester nên biết

tan-cong-sql-injection

Những lỗi sơ hở trong quá trình build ứng dụng web/ phần mềm, hacker sử dụng lỗi này để lạm dụng các câu truy vấn sql bất hợp pháp để tấn công vào web ứng dụng của chúng ta.

Sẽ hơi mơ hồ nếu như không đi từ lý thuyết thì rất khó hiểu bởi vậy ta đi từ lý thuyết kèm ví dụ minh họa nha.
Sql injection: Bạn học môn hệ quản trị cơ sở dữ liệu sql server, oracle, DB2, mongo,... biết được cú pháp, thao tác select , from, having, group by, where, inner join... thao tác các bảng dữ liệu vớinhau
Sql injection là kỹ thuật cho phép hacker lợi dụng chỗ sơ hở trong việc kiểm tra dữ liệu đầu vào ở ứng dụng web và các notification của hệ quản trị CSDL trả về để inject và thi hành các câu lệnh SQL bất hợp pháp bằng các thao tác delete, insert, update,...
chúng ta hãy để ý đến những lỗi cơ bản thường gặp dưới đây:

1. Không kiểm tra kí tự thoát truy vấn:
Sql injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu vào trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện 1 số truy vấn không mong muốn với CSDL:

statement = "SELECT * FROM users
WHERE name = '" + userName+ "' ;"

>>> Câu lệnh trên truy vấn thuôc tính name từ bảng users. Tuy nhiên, nếu biến "userName" được nhập chính xác theo 1 cách nào đó thì người dùng ác ý có thể nhập vào giá trị của biến userName như sau:

" SELECT * FROM users
WHERE name = 'a' OR 't' = 't';"

Đoạn mã trên được sử dụng trong 1 thủ tục xác thực thì VD trên có thể được sử dụng để bắt buộc lựa chọn 1 tên người dùng hợp lệ bới ' t' = 't' luôn đúng. Trong khi hầu hết các SQL server cho phép thực hiện nhiều truy vấn cùng lúc chỉ với 1 lần gọi, nhưng 1 số SQL API mysql_query của PHP lại không cho phép làm điều đó vì lý do bảo mật. Điều này chỉ ngăn cản tin tặc tấn công bằng những câu lệnh riêng rẽ mà không ngăn cản tin tặc tấn công bằng việc thay đổi cú pháp truy vấn.
Ở ví dụ trên cho thấy các giá trị của biến userName sẽ gây ra việc xóa thông tin người dùng từ bảng users cũng tương tự từ việc xóa tất cả dữ liệu từ bảng dữ liệu ( bản chất là tiết lộ thông tin người dùng) . Minh hoạ cụ thể bằng câu truy vấn dưới đây để hiểu rõ được bản chất hơn:

" DROP TABLE users;
 SELECT * FROM data
 WHERE 't' = 't'

Tổng hợp lại toàn bộ câu truy vấn như sau:

DROP TABLE users
SELECT * FROM data 
WHERE 't' = 't';

Như vậy là tin tặc lợi dụng lỗi sơ hở cú pháp truy vấn trên để chỉ việc thay đổi thêm bớt vài lệnh truy vần truyền vào là có thể xâm nhập được hệ thống của chúng ta 1 cách dễ dàng.

Điều thứ 2 liên quan tới SQL injection đó là Xử lý không đúng kiểu.

Do coder định nghĩa dữ liệu đầu vào không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ liệu đầu vào (ví dụ kiểm tra dữ liệu nhập vào từ user là kiểu số hay chuỗi

state = "SELECT * FROM data WHERE id = "+ a_variable +" ;"

Lệnh state trên cho chúng ta biết rằng cho người dùng nhập vào id dạng số nhưng lại không kiểm tra kiểu nhập vào nên người dùng thay vì nhập số mà nhập vào 1 chuỗi string.
Điều thứ 3 xảy ra là lỗi bảo mật bên trong máy chủ CSDL

Đôi khi lỗ hổng bảo mật nằm ngay chính máy chủ CSDL, VD hàm mysql_real_escape_string() 
hacker có thể thực hiện cuộc tấn công SQL injection thành công dựa trên những ký tự unicode không thông thường ,

lấy 1 sồ VD minh hoạ

$user ="<div> user </div>
$password = "<div> password</div>
 $query = sprintf( "SELECT * FROM users 
WHERE username ='%s' AND password = '%s'")
mysql_real_escape_string($username)
mysql_real_escape_string($password)
echo $query;

 Kết quả in ra sẽ là:
SELECT * FROM users WHERE user = ' ' AND password = ' '

Tiếp đến 1 trường hợp nữa tại form đăng nhập, người dùng nhập tên đăng nhập mà không cần đúng mật khẩu
<?php
$query = "SELECT * FROM users
WHERE username = '{$_POST['username']}' AND password = '{$_POST['password']}'";
mysql_query($query);
$_POST['username'] = ' your's name';
$_POST['password'] = " OR "=";
echo $query;
?>

Câu  lệnh truyền lên server sẽ là:

SELECT * FROM users WHERE username = 'yours name' AND password = " OR "=" 

4. Điều thứ 4 xảy ra là Blind SQL injection
Lỗi SQL injection dạng Blind SQL injection xảy ra ngay trong ứng dụng web, hậu quả của chúng  không hiển thị trực quan cho những kẻ tấn công. Nó có thể gây ra sự sai khác khi hiển thị  nội dung của 1 trang chứa lỗi bảo mật này. Hậu quả của sự tấn công SQL injection dạng Blind SQL injection này khiến cho coder phải mất nhiều time để phục hồi chính xác từng bit dữ liệu. Những kẻ tấn công còn sử dụng 1 số tool tìm dò lỗi và tấn công với những thông tin đã thiết lập sẵn
 Còn rất nhiều các dạng tấn công khác xảy ra khi mà hacker sử dụng kỹ thuật SQL injection và lỗi sơ hở trong các câu truy vấn để đột nhập lấy cắp dữ liệu

Update thêm các dạng tấn công thường gặp với ứng dụng web
1.    Dạng tấn công vượt qua kiểm tra lúc đăng nhập

Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của ứng dụng web. Thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu người dùng nhập thông tin về tên đăng nhập và mật khẩu. Sau khi người dùng nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp. Ví dụ, trong trường hợp sử dụng ASP, người ta có thể dùng 2 trang: 1 trang HTML để hiển thị Form nhập liệu và 1 trang ASP để xử lý thông tin nhập vào từ phía người dùng như sau:

- Trang nhập liệu: login.htm 
<form action="ExecLogin.asp" method="post"> 
  Username:  <input type="text" name="fUSRNAME"><br /> 
  Password:  <input type="password" name="fPASSWORD"><br /> 
  <input type="submit"> 
</form>
- Trang xử lý nhập liệu: execlogin.asp
<%
Dim vUsrName, vPassword, objRS, strSQL
vUsrName = Request.Form("fUSRNAME")
vPassword = Request.Form("fPASSWORD")
strSQL = "SELECT * FROM T_USERS " & _
"WHERE USR_NAME=' " & vUsrName & _
" ' and USR_PASSWORD=' " & vPassword & " ' "
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN=..."
If (objRS.EOF) Then
Response.Write "Invalid login."
Else
Response.Write "You are logged in as " & objRS("USR_NAME")
End If
Set objRS = Nothing %>
Chỗ sơ hở trong đoạn mã xử lý nhập liệu trên nằm ở chỗ dữ liệu nhập vào từ người dùng được dùng để xây dựng trực tiếp câu lệnh SQL. Chính điều này cho phép tin tặc có thể điều khiển câu truy vấn sẽ được thực hiện. Ví dụ, nếu người dùng nhập chuỗi trong ngoặc sau vào trong cả 2 ô nhập liệu username/password của trang login.htm là:('OR='). Lúc này, câu truy vấn sẽ được gọi thực hiện là:

SELECT * FROM T_USERS WHERE USR_NAME =''OR''='' AND USR_PASSWORD= ''OR''=''
Câu truy vấn này là hợp lệ và sẽ trả về tất cả các bản ghi của T_USERS và đoạn mã tiếp theo xử lí người dùng đăng nhập bất hợp pháp này như là người dùng đăng nhập hợp lệ.
2.    Dạng tấn công sử dụng câu lệnh SELECT

Dạng tấn công này phức tạp hơn
 Để thực hiện được kiểu tấn công này, kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công. Ví dụ, trong các trang tìm kiếm. Các trang này cho phép người dùng nhập vào các thông tin tìm kiếm như Họ, Tên, … Đoạn mã thường gặp là:

    <%
    Dim vAuthorName, objRS, strSQL
    vAuthorName = Request("fAUTHOR_NAME")
    strSQL = "SELECT * FROM T_AUTHORS WHERE AUTHOR_NAME =' " & _ vAuthorName & " ' "
    Set objRS = Server.CreateObject("ADODB.Recordset")
    objRS.Open strSQL, "DSN=..."
    …
    Set objRS = Nothing %> 
Tương tự như trên, tin tặc có thể lợi dụng sơ hở trong câu truy vấn SQL để nhập vào trường tên tác giả bằng chuỗi giá trị:

' UNION SELECT ALL SELECT OtherField FROM OtherTable WHERE ' '=' (*)
Lúc này, ngoài câu truy vấn đầu không thành công, chương trình sẽ thực hiện thêm lệnh tiếp theo sau từ khóa UNION nữa. Giả sử đoạn mã nhập vào là:

' DROP TABLE T_AUTHORS --
Câu truy vấn sẽ thực hiện việc xóa bảng.
3.    Dạng tấn công sử dụng câu lệnh INSERT
Ví dụ điển hình nhất ở thao tác đăng ký thông tin người dùng, sau khi đăng ký thành công, người dùng có thể xem thông tin của mình. Ngay lúc này SQL injection có thể được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào. Ví dụ, một câu lệnh INSERT có thể có cú pháp dạng:

    INSERT INTO TableName VALUES('Value One', 'Value Two', 'Value Three')
Nếu đoạn mã xây dựng câu lệnh SQL có dạng:

<%
    strSQL = "INSERT INTO TableName VALUES(' " & strValueOne & " ', ' " _ & strValueTwo & " ', ' " & strValueThree & " ') "
    Set objRS = Server.CreateObject("ADODB.Recordset")
    objRS.Open strSQL, "DSN=..."
    …
    Set objRS = Nothing %> 
Thì chắc chắn sẽ bị lỗi SQLi, bởi vì nếu ta nhập vào trường thứ nhất ví dụ như:

    ' + (SELECT TOP 1 FieldName FROM TableName) + '
Lúc này câu truy vấn sẽ là:

    INSERT INTO TableName VALUES(' ' + (SELECT TOP 1 FieldName FROM TableName) + ' ', 'abc', 'def')
Khi đó, lúc thực hiện lệnh xem thông tin, xem như bạn đã yêu cầu thực hiện thêm một lệnh nữa đó là:

 SELECT TOP 1 FieldName FROM TableName 

Trên đây là cơ bản về kỹ thuật SQL injection, là tester chúng ta ít nhiều nên biết về kỹ thuật này để trau dồi kinh nghiệm test cho mình J


Bài viết trên tham khảo tại wiki và 1 số trang công nghệ khác. Bạn đọc thấy thiếu sót chỗ nào phản hồi góp ý với mình nha. Thanks for reading!

Câu hỏi thường gặp khi phỏng vấn tester

Thứ Tư, 27 tháng 8, 2014

Tổng quan về kiểm thử

Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử.[1] Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khaiphần mềm.
Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm cáclỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm:
  • Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
  • Thực hiện công việc đúng như kỳ vọng.
  • Có thể triển khai được với những đặc tính tương tự.
  • Và đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗ lực kiểm thử được tiến hành
sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.
Kiểm thử không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm.[2] Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các oracle - các nguyên tắc hay cơ chế để phát hiện vấn đề. Các oracle này có thể bao gồm (nhưng không giới hạn ở) các đặc tả phần mềmhợp đồng,[3] sản phẩm tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng, quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác.
Mục đích chính của kiểm thử là phát hiện ra các lỗi phần mềm để từ đó khắc phục và sửa chữa. Việc kiểm thử không thể khẳng định được rằng các chức năng của sản phẩm đúng trong mọi điều kiện, mà chỉ có thể khẳng định rằng nó không hoạt động đúng trong những điều kiện cụ thể.[4] Phạm vi của kiểm thử phần mềm thường bao gồm việc kiểm tra mã, thực hiện các mã trong môi trường và điều kiện khác nhau, và việc kiểm thử các khía cạnh của mã: nó có làm đúng nhiệm vụ của nó hay không, và nó có làm những gì cần phải làm hay không. Trong môi trường phát triển phần mềm hiện nay, một đội kiểm thử có thể tách biệt với đội phát triển. Các thành viên trong đội kiểm thử giữ các vai trò khác nhau. Các thông tin thu được từ kiểm thử có thể được sử dụng để điều chỉnh quá trình phát triển phần mềm.[5]
Mỗi sản phẩm phần mềm có một đối tượng phục vụ riêng. Ví dụ như đối tượng của phần mềm trò chơi điện tử là hoàn toàn khác với đối tượng của phần mềm ngân hàng. Vì vậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, họ có thể đánh giá liệu các sản phẩm phần mềm có được chấp nhận bởi người dùng cuối, đối tượng phục vụ, người mua, hay những người giữ vai trò quan trọng khác hay không. Và việc kiểm thử phần mềm là một quá trình nỗ lực để đưa ra những đánh giá này.

Khiếm khuyết và thất bại[sửa | sửa mã nguồn]

Không phải tất cả các khiếm khuyết của phần mềm bị gây ra bởi lỗi lập trình mà cội nguồn chung của các khiếm khuyết đó nằm ở những thiếu sót trong yêu cầu; ví dụ, yêu cầu không được xác nhận mà gây ra lỗi là sự sơ suất của các nhà thiết kế của chương trình.[6] Những thiếu sót yêu cầu thường thấy trong những yêu cầu phi chức năng như là khả năng kiểm thử, khả năng mở rộng, bảo trì, tính khả dụng, hiệu suất, và khả năng bảo mật.
Lỗi phần mềm xảy ra thông suốt quá trình như sau: Một lập trình viên làm cho một lỗi (sai lầm), mà kết quả cho ra là một khiếm khuyết (thất bại, sai sót) trong mã nguồn phần mềm. Nếu lỗi này được thực hiện, trong những tình huống nhất định hệ thống sẽ tạo ra kết quả sai, gây ra một sự thất bại.[7] Không phải tất cả các khiếm khuyết nhất thiết sẽ dẫn đến thất bại. Ví dụ, lỗi trong mã chết sẽ không bao giờ dẫn đến thất bại. Lỗi có thể biến thành một sự thất bại khi môi trường thay đổi. Ví dụ về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một nền tảng phần cứng máy tính mới, thay đổi trong nguồn dữ liệu, hoặc tương tác với các phần mềm khác nhau. Một khiếm khuyết duy nhất có thể dẫn đến một loạt các dấu hiệu thất bại.

Kết nối đầu vào và điều kiện tiền đề[sửa | sửa mã nguồn]

Một vấn đề rất cơ bản với kiểm thử phần mềm là việc kiểm thử tất cả các kết nối đầu vào và điều kiện tiền đề (trạng thái ban đầu) là không khả thi, ngay cả với một sản phẩm đơn giản.[4][8] Điều này có nghĩa rằng số lượng các khiếm khuyết trong một sản phẩm phần mềm có thể rất lớn và có thể xảy ra thường xuyên nên rất khó để tìm thấy trong quá trình kiểm thử. Quan trọng hơn, những yêu cầu phi chức năng về chất lượng (làm nó như thế nào hơn là làm được gì?) như: tính khả dụng, khả năng mở rộng, hiệu suất, khả năng tương thích, độ tin cậy nếu xét về mặt chủ quan thì nó chưa tạo nên giá trị đủ để mọi người có thể chấp nhận được nó.
Các nhà phát triển phần mềm không thể kiểm thử được tất cả mọi thứ, nhưng họ có thể sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối thiểu của các kiểm thử cần thiết để bao quát được những điều họ muốn. Dù là kiểm thử tốc độ hay độ sâu thì họ có thể sử dụng phương pháp này để xây dựng được những cơ cấu khác nhau trong từng trường hợp kiểm thử (test case) cụ thể.[9]

Kinh tế[sửa | sửa mã nguồn]

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn.[10]
Người ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn. Bảng dưới đây cho thấy chi phí sửa chữa các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra.[11] Ví dụ, một vấn đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu. Với sự ra đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian.
theo wiki

Kiểm thử phần mềm

Gần đây tôi có đọc một bài báo nói rằng phần mềm là việc nhàm chán (ngồi cả ngày trước máy tính) và kiểm thử phần mềm là kĩ năng thấp, không được kính trọng cho nên thay vì nghiên cứu khoa học máy tính hay kĩ nghệ phần mềm, sinh viên nên nghiên cứu cái gì đó khác để làm “điều quan trọng.” Tôi không biết tác giả nghĩ gì trong đầu về những vấn đề quan trọng nhưng là một nhà chuyên môn về phần mềm trong hơn 30 năm, tôi biết rằng phần mềm KHÔNG là việc nhàm chám mà là nghề mang tính sáng tạo cao bởi vì nó yêu cầu nhiều tư duy, phân tích và canh tân. Kiểm thử phần mềm KHÔNG phải là kĩ năng thấp nhưng là một phần quan trọng của qui trình phát triển phần mềm. Nó yêu cầu người kiểm thử phần mềm phải có đầu óc logic để phân tích sự hợp lí của qui trình phần mềm, để nhận diện các lỗi và để bảo đảm sản phẩm cuối cùng đáp ứng các yêu cầu. Kiểm thử là việc rất thách thức, chẳng hạn kiểm thử trò chơi máy tính, được thiết kế để mô phỏng xúc cảm từ những người chơi, yêu cầu người kiểm thử phải có các quyết định về xúc cảm và chủ quan. Kiểm thử các phần mềm mấu chốt như hệ thống máy tính của vệ tinh hay máy bay yêu cầu người kiểm thử phải hội tụ vào mọi kịch bản có thể để khử bỏ mọi rủi ro và ngăn ngừa thảm hoạ.
Ngược với khái niệm là người làm phần mềm ngồi cả ngày trước máy tính, người làm phần mềm tốt không chỉ là người kĩ thuật mà còn là người doanh nghiệp. Họ bao giờ cũng tham gia cùng khách hàng, người dùng, người quản lí trên cơ sở hàng ngày cho nên họ có thể có hiểu biết rõ ràng về các yêu cầu doanh nghiệp. Việc của người kĩ sư phần mềm là tạo ra sản phẩm đáp ứng yêu cầu của khách hàng, người dùng và người quản lí. Bằng việc hoàn thành những yêu cầu này, họ giải quyết các vấn đề, phân tích vấn đề; tạo ra các sản phẩm canh tân mà không chỉ là những thứ được ưa chuộng nhưng còn là những thứ vui cho mọi người. Để tham gia cùng người dùng một cách có hiệu quả, người kĩ sư phần mềm chuyên nghiệp phải có quan điểm kĩ thuật và quan điểm doanh nghiệp để hiểu doanh nghiệp đang cố gắng đạt tới cái gì. Khi đối diện với thách thức họ náo nức, xúc động của họ lên cao và họ bắt đầu phân tích tình huống theo cách tiếp cận logic để tạo ra giải pháp tốt nhất có thể được. Nhiều kĩ sư phần mềm nói với tôi rằng họ tin kiến trúc, thiết kế và lập trình cho phần mềm là “nghệ thuật” và họ vừa là nhà khoa học vừa là nghệ sĩ. Họ cảm thấy giống nhà khoa học bởi vì điều đó yêu cầu tư duy logic, phân tích và tổ chức nhưng cũng giống nghệ sĩ bởi vì họ tạo ra thứ có tính trí tuệ và biến đổi chúng thành thứ vật lí – tác phẩm phần mềm, như nhạc sĩ, hoạ sĩ hay nhà văn bởi vì sản phẩm của họ là kết quả của tâm trí sáng tạo cao, dứt khoát không phải là cái gì đó nhàm chán.
Về mặt truyền thống, người kĩ sư phần mềm không nói ra lời về công việc của họ và ích lợi tích cực họ đem tới cho doanh nghiệp và xã hội. Họ để hàng giờ làm việc cũng như nhạc sĩ làm việc nhọc nhằn để tìm ra sự hài hoà hoàn hảo hay nhà thơ cố gắng đi tới những vần thơ hoàn hảo. Tuy nhiên, khác với nghệ sĩ, người làm việc chủ yếu một mình, qua việc phát triển phần mềm, người kĩ sư phần mềm thường xuyên tham gia với nhau để duy trì mối quan hệ tích cực với khách hàng của mình bằng việc trao đổi và chứng tỏ cách sản phẩm của họ sẽ đáp ứng cho yêu cầu của khách hàng. Mối nối giữa cách tiếp cận xúc cảm và vấn đề doanh nghiệp và công nghệ trong môi trường phát triển trở thành rõ ràng khi thẩm định thành công mà người làm phần mềm đạt tới trong việc chuyển giao kết quả tích cực cho doanh nghiệp.
Điều không may là tôi cũng thấy rằng nhiều người làm kiểm thử phần mềm, người được huấn luyện theo qui trình truyền thống kiểm thử mã chỉ dựa trên ngôn ngữ lập trình và thường không tham gia có hiệu quả với doanh nghiệp và do vậy đạt tới mức độ thành công và kính trọng ít hơn. Kiểm thử phần mềm là một bộ môn trong số nhiều việc huấn luyện kĩ nghệ phần mềm nhưng trong khoa học máy tính truyền thống, nó đơn thuần hội tụ vào kiểm thử lập trình, không mấy hội tụ vào kiểm thử thiết kế, kiểm thử kiến trúc, kiểm thử yêu cầu, trắc nghiệm doanh nghiệm, kiểm thử thuộc tính chất lượng và kiểm thử xúc cảm. Chẳng hạn họ có thể không hiểu tầm quan trọng của việc nắm bắt thông tin chứng tỏ giá trị mà kiểm thử đem lại cho doanh nghiệp hay sự lí thú của kiểm thử “cảm giác” của người dùng khi dùng sản phẩm, (kiểm thử tính dùng được trong công nghiệp trò chơi máy tính) mà chỉ biết cách kiểm thử mã.
Dùng cách tiếp cận xúc cảm tới kiểm thử cũng tạo khả năng cho người kĩ sư phần mềm đưa bộ môn phần mềm tới cuộc sống – dùng những ví dụ dự án cuộc sống thực mà đã bị thất bại do thiếu hụt trong kiểm thử và thủ tục đảm bảo chất lượng sẽ có hiệu quả hơn nhiều cách tiếp cận truyền thống “mã trước hỏi câu hỏi sau”. Nếu người kĩ sư phần mềm có thể tham gia với doanh nghiệp và ngành công nghiệp công nghệ ở mức độ xúc cảm, họ sẽ hiểu giá trị gia tăng và ích lợi doanh nghiệp của kiểm thử cũng như cách nó có thể là điều lí thú. Kiểm thử thực sự là cách tiếp cận “toàn trí” bởi vì nó yêu cầu cả logic và xúc cảm trong việc hướng dẫn phát triển phần mềm để khử lỗi và rủi ro qua cách tiếp cận logic và có cấu trúc. Huấn luyện truyền thống nói rằng chuẩn bị kiểm thử xảy ra sau khi lập trình được hoàn tất, điều thực sự quá muộn bởi vì nó chỉ hội tụ vào phát hiện khiếm khuyết của việc thực hiện (viết mã). Huấn luyện kĩ nghệ phần mềm hội tụ vào kiểm thử ở mọi pha của vòng đời phát triển, điều có nghĩa là kiểm thử bắt đầu khi dự án bắt đầu và trường hợp kiểm thử và kịch đoạn kiểm thử phải được chuẩn bị sớm nhất có thể được.
Tôi tin người kiểm thử phần mềm có vai trò mấu chốt trong thành công hay thất bại của dự án và họ cần tham gia vào công việc ở giai đoạn sớm, hội tụ vào mọi chi tiết một cách có hiệu quả để xác định yêu cầu từ dự án và thực sự nắm được những mức thấp nhất về điều người dùng và khách hàng muốn. Khi làm điều này, thảm hoạ có thể được ngăn ngừa, việc dùng sản phẩm có thể là vui đùa và doanh nghiệp sẽ bắt đầu nhận ra ích lợi đúng của dự án thành công. Tôi tin phần mềm là việc lí thú và người kiểm thử phần mềm cần được thừa nhận về điều họ đã đóng góp.