Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects). A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members.
Keywords: Software, bugs, application, condition, organization
Cite this article
Kirti Sharma,Girish Mehta, Himanshu Saini, Software Testing. Journal of Software Engineering Tools & Technology Trends.2015; 2(2): 32–35p.
Basili Victor R.. The experimental paradigm in software engineering. In Experimental Software Engineering Issues: Critical Assessment and Future Directives. Proc of Dagstuhl-Workshop, H. Dieter Rhombic, Victor R. Basili, and Richard Selby (eds), published as Lecture Notes in Computer Science #706, Springer-Vela. 1993.
Geoffrey Bowker and Susan Leigh Star: Sorting Things Out: Classification and Its Consequences. MIT Press. 1999.
Brooks Frederick P. Jr. Grasping Reality Through Illusion—Interactive Graphics Serving Science. Proc 1988 ACM SIGCHI Human Factors in Computer Systems Conf (CHI '88). 1988: 1–11p.
Rebecca Burnett. Technical Communi-cation. Thomson Heine. 2001.
Guerin Thomas F. Cultural Boundaries of Science: Credibility on the line. Unit of Chicago Press. 1999.
ICSE 2002 Program Committee. Types of ICSE papers. http://icse-conferences. org/2002/info/paperTypes.html
Impact Project. Determining the impact of software engineering research upon practice. Panel summary, Proc. 23rd International Conference on Software Engineering (ICSE 2001). 2001.
Ellen Isaacs and John Tang. Why don't more non-North American papers get accepted to CHI? http://acm.org/ sigchi/bulletin/1996.1/isaacs.html
Ralph E. Johnson & panel. How to Get a Paper Accepted at OOPSLA. Proc OOPSLA'93, pp. 429-436, http://acm. org/sigplan/oopsla/oopsla96/how93.html
Jim Kajiya. How to Get Your SIGGRAPH Paper Rejected. Mirrored at http://www.cc.gatech.edu/student.services/phd/phd-advice/kajiya
Levin Roy and Redell David D.. How (and How Not) to Write a Good Systems Paper. ACM SIGOPS Operating Systems Review. 1983; 17(3): 35–40p. http://ftp. digital.com/pub/DEC/SRC/other/SOSPadvice.txt
Newman William. A preliminary analysis of the products of HCI research, using pro forma abstracts. Proc 1994 ACM SIGCHI Human Factors in Computer Systems Conf (CHI '94). 1994: 278–284p.
Newman William et al. Guide to Successful Papers Submission at CHI. 2001. http://acm.org/sigs/sigchi/ chi2001/ call/submissions/guide-papers.html
OOPSLA '91 Program Committee. How to get your paper accepted at OOPSLA. Proc OOPSLA'91. 59–363p. http://acm.org/ sigplan/oopsla/oopsla96/how91.html
Partridge Craig. How to Increase the Chances your Paper is Accepted at ACM SIGCOMM. http://www sop.inria.fr/members/Arnaud.Legout/Documents/ccr-9807-partridge.pdf
- There are currently no refbacks.
This site has been shifted to https://stmcomputers.stmjournals.com/