Với thế giới ngày càng được liên nối bởi internet, phần mềm đã đạt tới nhiều người hơn và nhiều doanh nghiệp hơn bao giờ hết. Với điều đó, lỗi phần mềm cũng đã tăng lên đáng kể. Trong khi một số lỗi có thể làm ngắt công việc, các lỗi khác có thể tạo ra hư hỏng làm tổn thất hàng triệu đô la. (Vài tuần trước, một lỗi phần mềm đã làm đổi vài số không trong chỉ số thị trường chứng khoán châu Âu, tạo ra sự hoảng hốt trong gần mười phút cho tới khi nó được sửa. Hư hỏng được ước lượng quãng vài triệu mặc dầu họ dừng thương mại ngay lập tức). Để đảm bảo chất lượng của sản phẩm, kiểm thử phần mềm là bản chất trong lúc mọi thứ xảy ra với tốc độ nhanh chóng với nhiều tự động hơn và ít can thiệp của con người hơn.
Theo một nghiên cứu mới của chính phủ Mĩ, có nhu cầu đang tăng lên về nhiều người kiểm thử phần mềm, đặc biệt trong công nghiệp tài chính (ngân hàng, thị trường chứng khoán, thể chế tài chính và công ti bảo hiểm). Đây cũng là tin mừng cho các nhà cung cấp khoán ngoài vì có thiếu hụt trầm trọng người phần mềm trên toàn cầu. Ngày nay, ngành công nghiệp tài chính đang dùng nhiều hệ thông tin hơn bao giờ để tăng tốc kinh doanh của họ. Phần lớn các công ti vận hành 7 ngày và 24 giờ (7/24) cho nên hệ thống phần mềm của họ phải tin cậy cao. Với toàn cầu hoá, ngành công nghiệp tài chính đang thấy sự tăng trưởng chưa từng có trước đây, và với điều này có cả trách nhiệm đảm bảo liên tục kinh doanh. Với công nghệ thay đổi nhanh chóng, ngành công nghiệp tài chính (ngân hàng, thị trường chứng khoán, thể chế tài chính và công ti bảo hiểm) phải thường xuyên nâng cấp hệ thông tin lớn của họ hay cải tiến các ứng dụng hỗ trợ then chốt của họ và họ cần nhiều người kiểm thử phần mềm. Theo nghiên cứu mới nhất, thị trường kiểm thử phần mềm toàn cầu được ước lượng đạt tới US$56 tỉ đô là trước năm 2013, và tăng trưởng nhanh chóng này sẽ yêu cầu gần 300,000 người kiểm thử chuyên nghiệp trong năm năm tới.
Nghiên cứu này cũng để lộ rằng viết mã là nguồn sinh lỗi và kiểm thử vẫn là phương pháp tốt nhất để tìm ra lỗi. Tuy nhiên, nhiều đào tạo phần mềm vẫn còn dựa trên vòng đời thác đổ nơi người phát triển viết mã, người kiểm thử kiểm thử, và việc kiểm thử xảy ra sau khi viết mã được thực hiện. Điều này là KHÔNG hiệu quả và thường là quá muộn. Nó cho phép người kiểm thử ném “mã viết kém” cho người kiểm thử và để người kiểm thử tìm lỗi. Cách nhìn này cũng đặt người kiểm thử ở dưới người phát triển dưới dạng trạng thái, địa vị và đó là lí do tại sao nhiều người không muốn làm việc như người kiểm thử.
Qui trình kĩ nghệ phần mềm yêu cầu rằng người kiểm thử được đưa vào ngày lúc đầu của dự án và người phát triển phải là một phần của giải pháp chất lượng. Qui trình này nói rằng khi một sản phẩm được thiết kế, trường hợp kiểm thử cũng phải được thiết kế cùng với nó, không sau đó. Vì người phát triển tạo ra mã, không có ai khác tốt hơn người phát triển để kiểm thử mã này bởi vì người đó hiểu mã riêng của mình. Khi người phát triển viết mã, người đó cũng phải viết các trường hợp kiểm thử. Mọi dòng mã đều phải được viết có tính kiểm thử được trong tâm trí và sản phẩm phần mềm phải được thiết kế để nó là kiểm thử được lúc cuối. Vấn đề là ai phải làm kiểm thử? Câu trả lời là người phát triển phải kiểm thử mã riêng của mình (kiểm thử đơn vị) và viết trường hợp kiểm thử cho kiểm thử chức năng trên mã này chính là điều được họ viết ra. Bằng việc làm điều đó, mọi lỗi trong mã có thể được nhận diện, sửa chữa và xoá bỏ vào pha phát triển.
Người kiểm thử phải được tham gia từ đầu của dự án để chắc chắn rằng người phát triển tuân theo các nguyên lí kiểm thử và thiết kế sản phẩm phần mềm rơi vào trong phạm vi của công cụ kiểm thử. Về căn bản, khi người phát triển viết mã và trường hợp kiểm thử, đồng thời, người kiểm thử cũng viết trường hợp kiểm thử tương ứng riêng của họ. Cùng nhau họ làm việc để đảm bảo chất lượng của sản phẩm cuối cùng. Trong khi người phát triển hội tụ vào kiểm thử đơn vị của họ và kiểm thử chức năng, người kiểm thử hội tụ nhiều vào kiểm thử hệ thống và kiểm thử tích hợp nơi nhiều đơn vị và chức năng được tổ hợp tạo nên sản phẩm cuối cùng. Tất nhiên, làm việc cùng nhau là không dễ và có vấn đề mà người kiểm thử phải vượt qua. Bên cạnh xung đột cá nhân hay vấn đề tổ, có vấn đề kĩ thuật khác nữa. Với công cụ lập trình tiên tiến, người phát triển có thể cải tiến năng suất của họ một cách có ý nghĩa. Chẳng hạn, với môi trường phát triển tích hợp (IDE) một công cụ phần mềm tổ hợp trình biên soạn mã nguồn, trình biên dịch, tự động dựng và gỡ lỗi, người phát triển có thể viết mã, kiểm thử, và cũng làm kiểm thử chức năng trên mã họ viết nhanh hơn nhiều. Một số IDE như “IntelliJ” và “Eclipse” giúp người phát triển với những phản hồi về mã của họ mà họ đã viết ra. Điều này đặt nhiều sức ép lên người kiểm thử bởi vì người phát triển có thể viết mã nhanh hơn, nhưng người kiểm thử vẫn phải tổ hợp mọi phương pháp kiểm thử để đảm bảo phần mềm không có lỗi. Đây là lí do tại sao đôi khi người phát triển phàn nàn rằng người kiểm thử quá chậm và ngăn cản việc đưa ra phần mềm.
Today, many things are controlled by software and software quality is becoming the number one issue. With the world more interconnected by the internet, software has reached more people and more businesses than ever. With that, software defects have also increased significantly. While some defects can disrupt work, others can create damages with millions dollars in losses. (Few weeks ago, a software defect changed a few zeros in a European stock market index, created a panic for almost ten minutes until it was correct. The damage was estimated at few millions although they stop trading immediately). To ensure quality of the product, software testing is essential in a time where everything happens at rapid rate with more automation and fewer human intervention.
According to a new U.S Government study, there is a growing demand for more software testers, especially in the financial industry (Banks, Stock market, Trading institutions, and Insurance companies). This is also a good news to outsourcing providers since there is a critical shortage of software people globally. Today, the financial industry is using more information systems than ever to speed up their business. Most companies are operating seven days and 24 hours (7/24) so their software system must be highly reliable. With globalization, the financial industry is seeing unprecedented growth, and with this comes the responsibility of ensuring business continuity. With technology change rapidly, the financial industry (Banks, financial institutions, stock market, and insurance companies) must constantly upgrades their large information systems or improve their key support applications and they need a lot of software testers. According to the latest study, the global software testing market is estimated to reach US$56 billion by 2013, and this rapid growth will require nearly 300,000 professional testers globally in the next five year.
The study also reveals that coding is error-prone and testing is still the best method to find defects. However, many software trainings are still based on the waterfall lifecycle where developer codes, tester tests, and testing happened after coding is done, This is NOT efficient and usually it is too late. It allows developer to throw “Poorly written codes” to tester and let tester find defects. This view also places tester below the developer in term of status, position and that is why many people do not want to work as testers.
The software engineering process requires that testers be involved in the beginning of the project and developers have to be part of the quality solution. This process stated that when a product is being designed, the test case should also be designed along with it, not afterwards. Since the developer creates the code, there is nobody else better to test the code than the developer because he understands his own code. When developer writes codes, he must also write the test cases. Every line of code must be written with testability in mind and the software product has to be designed that it is testable in the end. The question is who has to do the testing? The answer is developer has to test his own code (Unit test) and write test cases for the functional testing on the code which they are written. By doing that, all defects in code can be identifies, fixed, and eliminated at the development phase.
Testers should be involved in the beginning of the project to make sure that developers are following testing principles and design the software product that falls within the scope of testing tools. Basically, when the developer writes code and test cases, at the same time, the tester also write their own correspondent test cases. Together they work to ensure the quality of the final product. While developer focuses on their unit test and functional test, tester focuses more towards system test and integration test where many units and functions are combined to form the final product. Of course, working together is not easy and there are issues that tester must overcome. Beside the personal conflict or teaming issue, there is another technical issue too. With advanced programming tools, developers can improve their productivity significantly. For example, with Integrated Development Environment (IDE) a software tool that combines source code editor, compiler, build automation and debugger, developers can code, test, and also do the functional testing on the code which they have written much faster. Some IDEs such as “IntelliJ” and “Eclipse” help developers with feedbacks on their code they have written too. This put more pressure on testers since developers can write code faster, but testers still have to incorporate all the testing methods to ensure the software has no defect. This is why sometime developers complain that testers are too slow and prevent the release of software.
