Software Testing and Automation

What if the software is so buggy it can not really be tested at all? The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem.   How can it be known when to stop testing? This can be difficult to determine. Most modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are: Deadlines (release deadlines, testing deadlines, etc.) Test cases completed with certain percentage passed Test budget depleted Covera...

The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available. The following are items to consider in the tracking process: Complete information such that developers can understand the bug, get an idea of its severity, and reproduce it if necessary. Bug identifier (number, ID, etc.) Current bug status (e.g., 'Released for Retest', 'New', etc.) The application name or identifier and version The function, module, feature, object, screen, etc. where the bug occurred Environment specifics, system, platform, relevant hardware specifics Test case name/number/identifier One-line bug description Full bug description Descr...

What's a 'test plan'? A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project: Title Identification of software including version/release numbers Revision history of document including authors, dates, approvals Table of Contents Purpose of document, intended audience Objective of testing effort Software product overview Relevant related document list, such as requirements, design documents, other test plans, etc....

1. The Importance of Scalability & Load Testing Some very high profile websites have suffered from serious outages and/or performance issues due to the number of people hitting their website. E-commerce sites that spent heavily on advertising but not nearly enough on ensuring the quality or reliability of their service have ended up with poor web-site performance, system downtime and/or serious errors, with the predictable result that customers are being lost. In the case of toysrus.com, its web site couldn't handle the approximately 1000 percent increase in traffic that their advertising campaign generated. Similarly, Encyclopaedia Britannica was unable to keep up with the amount of users during the immediate weeks following their promotion of free access to its online database. The truth is, these problems could probably have been prevented, had adequate load testing taken place. When creating an eCommerce portal, companies will want to know whether their infra...

Often the severity of a software defect can vary even though the software never changes.  The reason being is that a software defect's severity depends on the system in which it runs. For example, the severity of the Pentium's floating-point defect changes from system to system.  On some systems, the severity is small; whereas on other systems, the severity is high.  Another problem (which occurs regularly) is that the definitions of the severity levels (or categories) themselves change depending on the type of system.  For example, a catastrophic defect in a nuclear system means that the fault can result in death or environmental harm; a catastrophic defect in a database system means that the fault can (or did) cause the loss of valuable data.  Therefore, the system itself determines the severity of a defect based on the context for which the defect applies.  The context makes all the difference in how to classify a defect's severity.  I have attach...

User Interface Testing 1. Site · Easy to use · Instructions are simple and clear. Additionally, test that instructions are · correct (i.e. if you follow each instruction does the expected result · occur? 2. Site map or navigation bar (if provided) · Is the site map is correct? · Does each link on the map actually exist? · Are there links on the site that are not represented on the map? · Is the navigational bar present on every screen? · Is it consistent? · Does each link work on each page? · Is it organized in an intuitive manner? 3. Site Content · Correctness of wording · No overuse of bold text big fonts and blinking (user acceptance testing) · Hyperlinked references are working · Are patterns, background color and pictures distract the user? · Does all images add value to respecti...