SoftWare TestinG

Does Quality Assurance Remove Need for Quality Control?

2011-09-21T03:04:00.000-07:00

Does Quality Assurance Remove Need for Quality Control?

"If QA (Quality Assurance) is done then why do we need to perform QC (Quality Control)?", this thought may come to our mind some times and looks a valid point too. This means if we have followed all the pre-defined processes, policies and standards correctly and completely then why do we need to perform a round of QC?

In my opinion QC is required after QA is done. While in 'QA' we define the processes, policies, strategies, establish standards, developing checklists etc. to be used and followed through out the life cycle of a project. And while in QC we follow all those defined processes, standards and policies to make sure that the project has been developed with high quality and at least meets customer's expectations.

QA does not assure quality, rather it creates and ensures the processes are being followed to assure quality. QC does not control quality, rather it measures quality. QC measurement results can be utilized to correct/modify QA processes which can be successfully implemented in new projects as well.

Quality control activities are focused on the deliverable itself. Quality assurance activities are focused on the processes used to create the deliverable. QA and QC are both powerful techniques which can be used to ensure that the deliverables meet high quality expectations of customers.

E.g.: we have to use an Issue tracking system to log the bugs during testing a web application. QA would include defining the standard for adding a bug and what all details should be there in a bug, like summary of the issue, where it is observed, steps to reproduce the bugs, screenshots etc. This is a process to create deliverable 'bug–report'. When a bug is actually added in issue tracking system based on these standards then that bug report is our deliverable.

Now, suppose some time at later stage of project we realize that adding 'probable root cause' to the bug based on tester's analysis would provide some more insight to the Dev team, then we will update our pre-defined process and finally it will be reflected in our bug reports as well. This is how QC gives inputs to QA to further improve the QA.

Following is an example of a real life scenario for QA / QC:

QA Example:

Suppose our team has to work on completely new technology for upcoming project. Our team members are new to the technology. So for that we need to create a plan for training the team members in the new technology. Based on our knowledge we need to collect pre-requisites like understanding documents, design of the product along with the documents etc. and share with the team, which would be helpful while working on the new technology and even would be useful for any new comer in the team. This is QA.

QC Example:

Once the training is done how we can make sure that the training was successfully done for all the team members? For this purpose we will have to collect statistics e.g. number of marks the trainees got in each subject and minimum number of marks expected after completing the training. Also we can make sure that everybody has taken training in full by verifying the attendance record of candidates. If the number of marks of candidates are up to the expectations of the trainer/evaluators then we can say that the training is successful otherwise we will have to improve our process in order to deliver high quality training.

Hope this explains the difference between QA and QC.

How to Test Application Security – Web and Desktop Application Security Testing Techniques

2011-09-06T00:25:00.001-07:00

How to Test Application Security – Web and Desktop Application Security Testing Techniques

Need of Security Testing?

Software industry has achieved a solid recognition in this age. In the recent decade, however, cyber-world seems to be even more dominating and driving force which is shaping up the new forms of almost every business. Web based ERP systems used today are the best evidence that IT has revolutionized our beloved global village.

These days, websites are not meant only for publicity or marketing but these have been evolved into the stronger tools to cater complete business needs. Web based Payroll systems, Shopping Malls, Banking, Stock Trade application are not only being used by organizations but are also being sold as products today.

This means that online applications have gained the trust of customers and users regarding their vital feature named as SECURITY. No doubt, the security factor is of primary value for desktop applications too. However, when we talk about web, importance of security increases exponentially. If an online system cannot protect the transaction data, no one will ever think of using it. Security is neither a word in search of its definition yet, nor is it a subtle concept. However, I would like to list some complements of security.

Examples of security flaws in an application:

1) A Student Management System is insecure if 'Admission' branch can edit the data of 'Exam' branch
2) An ERP system is not secure if DEO (data entry operator) can generate 'Reports'
3) An online Shopping Mall has no security if customer's Credit Card Detail is not encrypted
4) A custom software possess inadequate security if an SQL query retrieves actual passwords of its users

Security Testing Definition:
Now, I present you a simplest definition of Security in my own words. "Security means that authorized access is granted to protected data and unauthorized access is restricted". So, it has two major aspects; first is protection of data and second one is access to that data. Moreover, whether the application is desktop or web based, security revolves around the two aforementioned aspects. Let us have an overview of security aspects for both desktop and web based software applications.

Desktop and Web Security Testing:
A desktop application should be secure not only regarding its access but also with respect to organization and storage of its data. Similarly, a web application demands even more security with respect to its access, along with data protection. Web developer should make the application immune to SQL Injections, Brute Force Attacks and XSS (cross site scripting). Similarly, if the web application facilitates remote access points then these must be secure too. Moreover, keep in mind that Brute Force Attack is not only related to web applications, desktop software is also vulnerable to this.

I hope this foreword is enough and now let me come to the point. Kindly accept my apology if you so far thought that you are reading about the subject of this article. Though I have briefly explained software Security and its major concerns, but my topic is 'Security Testing'.

I will now explain how the features of security are implemented in software application and how should these be tested. My focus will be on Whats and Hows of security testing, not of security.

Security Testing Techniques:

1) Access to Application:

Whether it is a desktop application of website, access security is implemented by 'Roles and Rights Management'. It is often done implicitly while covering functionality, e.g.in a Hospital Management System a receptionist is least concerned about the laboratory tests as his job is to just register the patients and schedule their appointments with doctors. So, all the menus, forms and screen related to lab tests will not be available to the Role of 'Receptionist'. Hence, the proper implementation of roles and rights will guarantee the security of access.

How to Test: In order to test this, thorough testing of all roles and rights should be performed. Tester should create several user accounts with different as well multiple roles. Then he should use the application with the help of these accounts and should verify that every role has access to its own modules, screens, forms and menus only. If tester finds any conflict, he should log a security issue with complete confidence.

2. Data Protection:

There are further three aspects of data security. First one is that a user can view or utilize only the data which he is supposed to use. This is also ensured by roles and rights e.g. a TSR (telesales representative) of a company can view the data of available stock, but cannot see how much raw material was purchased for production.

So, testing of this aspect is already explained above. The second aspect of data protection is related to how that data is stored in the DB. All the sensitive data must be encrypted to make it secure. Encryption should be strong especially for sensitive data like passwords of user accounts, credit card numbers or other business critical information. Third and last aspect is extension of this second aspect. Proper security measures must be adopted when flow of sensitive or business critical data occurs. Whether this data floats between different modules of same application, or is transmitted to different applications it must be encrypted to make it safe.

How to Test Data Protection: The tester should query the database for 'passwords' of user account, billing information of clients, other business critical and sensitive data and should verify that all such data is saved in encrypted form in the DB. Similarly (s)he must verify that between different forms or screens, data is transmitted after proper encryption. Moreover, tester should ensure that the encrypted data is properly decrypted at the destination. Special attention should be paid on different 'submit' actions. The tester must verify that when the information is being transmitted between client and server, it is not displayed in the address bar of web browser in understandable format. If any of these verifications fail, the application definitely has security flaw.

3. Brute-Force Attack:

Brute Force Attack is mostly done by some software tools. The concept is that using a valid user ID, software attempts to guess the associated password by trying to login again and again. A simple example of security against such attack is account suspension for a short period of time as all the mailing applications like 'Yahoo' and 'Hotmail' do. If, a specific number of consecutive attempts (mostly 3) fail to login successfully, then that account is blocked for some time (30 minutes to 24 hrs).

How to test Brute-Force Attack: The tester must verify that some mechanism of account suspension is available and is working accurately. (S)He must attempt to login with invalid user IDs and Passwords alternatively to make sure that software application blocks the accounts that continuously attempt login with invalid information. If the application is doing so, it is secure against brute-force attack. Otherwise, this security vulnerability must be reported by the tester.

The above three security aspects should be taken into account for both web and desktop applications while, the following points are related with web based applications only.

4. SQL Injection and XSS (cross site scripting):

Conceptually speaking, the theme of both these hacking attempts is similar, so these are discussed together. In this approach, malicious script is used by the hackers in order to manipulate a website. There are several ways to immune against such attempts. For all input fields of the website, field lengths should be defined small enough to restrict input of any script e.g. Last Name should have field length 30 instead of 255. There may be some input fields where large data input is necessary, for such fields proper validation of input should be performed prior to saving that data in the application. Moreover, in such fields any html tags or script tag input must be prohibited. In order to provoke XSS attacks, the application should discard script redirects from unknown or untrusted applications.

How to test SQL Injection and XSS: Tester must ensure that maximum lengths of all input fields are defined and implemented. (S)He should also ensure that defined length of input fields does not accommodate any script input as well as tag input. Both these can be easily tested e.g. if 20 is the maximum length specified for 'Name' field; and input string "<p>thequickbrownfoxjumpsoverthelazydog" can verify both these constraints. It should also be verified by the tester that application does not support anonymous access methods. In case any of these vulnerabilities exists, the application is in danger.

5. Service Access Points (Sealed and Secure Open)

Today, businesses depend and collaborate with each other, same holds good for applications especially websites. In such case, both the collaborators should define and publish some access points for each other. So far the scenario seems quite simple and straightforward but, for some web based product like stock trading, things are not so simple and easy. When there is large number of target audience, the access points should be open enough to facilitate all users, accommodating enough to fulfill all users' requests and secure enough to cope with any security-trial.

How to Test Service Access Points: Let me explain it with the example of stock trading web application; an investor (who wants to purchase the shares) should have access to current and historical data of stock prices. User should be given the facility to download this historical data. This demands that application should be open enough. By accommodating and secure, I mean that application should facilitate investors to trade freely (under the legislative regulations). They may purchase or sale 24/7 and the data of transactions must be immune to any hacking attack. Moreover, a large number of users will be interacting with application simultaneously, so the application should provide enough number access point to entertain all the users.

In some cases these access points can be sealed for unwanted applications or people. This depends upon the business domain of application and its users, e.g. a custom web based Office Management System may recognize its users on the basis of IP Addresses and denies to establish a connection with all other systems (applications) that do not lie in the range of valid IPs for that application.

Tester must ensure that all the inter-network and intra-network access to the application is from trusted applications, machines (IPs) and users. In order to verify that an open access point is secure enough, tester must try to access it from different machines having both trusted and untrusted IP addresses. Different sort of real-time transactions should be tried in a bulk to have a good confidence of application's performance. By doing so, the capacity of access points of the application will also be observed clearly.

Tester must ensure that the application entertains all the communication requests from trusted IPs and applications only while all the other request are rejected. Similarly, if the application has some open access point, then tester should ensure that it allows (if required) uploading of data by users in secure way. By this secure way I mean, the file size limit, file type restriction and scanning of uploaded file for viruses or other security threats. This is all how a tester can verify the security of an application with respect to its access points.

Vasuna.vb.testing, Win Rs. 50,000 this august!

2011-08-16T10:35:00.000-07:00

CLICK HERE TO REPORT SPAM CLICK HERE TO SAFELY UNSUBSCRIBE

Hey Vasuna.vb.testing

Join YouMint and send Privileged SMS for Free!! Anyone YOU invite also gets the same privilege!

Send Free Privileged SMS Worth Rs. 1500 monthly
- PC to Mobile SMS - FREE!
- Your Number as Sender ID!
- & No Ads!

And if you join within 48 hours of this invite, you could
- Win Rs 50,000 - Totally Tax Free!
- Get upto Rs 100 for every friend who joins 'The Legaue'!

Join Here: http://youmint.com/bigbash-nuve1284

Cheers
Team YouMint

What is difference between Performance Testing, Load Testing and Stress Testing?

2011-07-18T23:29:00.001-07:00

Q. What is difference between Performance Testing, Load Testing and Stress Testing?

1) Performance Testing:

Performance testing is the testing, which is performed, to ascertain how the components of a system are performing, given a particular situation. Resource usage, scalability and reliability of the product are also validated under this testing. This testing is the subset of performance engineering, which is focused on addressing performance issues in the design and architecture of software product.

Performance Testing Goal:

The primary goal of performance testing includes establishing the benchmark behaviour of the system. There are a number of industry-defined benchmarks, which should be met during performance testing.

Performance testing does not aim to find defects in the application, it address a little more critical task of testing the benchmark and standard set for the application. Accuracy and close monitoring of the performance and results of the test is the primary characteristic of performance testing.

Example:

For instance, you can test the application network performance on Connection Speed vs. Latency chart. Latency is the time difference between the data to reach from source to destination. Thus, a 70kb page would take not more than 15 seconds to load for a worst connection of 28.8kbps modem (latency=1000 milliseconds), while the page of same size would appear within 5 seconds, for the average connection of 256kbps DSL (latency=100 milliseconds). 1.5mbps T1 connection (latency=50 milliseconds) would have the performance benchmark set within 1 second to achieve this target.

For example, the time difference between the generation of request and acknowledgement of response should be in the range of x ms (milliseconds) and y ms, where x and y are standard digits. A successful performance testing should project most of the performance issues, which could be related to database, network, software, hardware etc…

2) Load Testing:

Load testing is meant to test the system by constantly and steadily increasing the load on the system till the time it reaches the threshold limit. It is the simplest form of testing which employs the use of automation tools such as LoadRunner or any other good tools, which are available. Load testing is also famous by the names like volume testing and endurance testing.

The sole purpose of load testing is to assign the system the largest job it could possible handle to test the endurance and monitoring the results. An interesting fact is that sometimes the system is fed with empty task to determine the behaviour of system in zero-load situation.

Load Testing Goal:

The goals of load testing are to expose the defects in application related to buffer overflow, memory leaks and mismanagement of memory. Another target of load testing is to determine the upper limit of all the components of application like database, hardware and network etc… so that it could manage the anticipated load in future. The issues that would eventually come out as the result of load testing may include load balancing problems, bandwidth issues, capacity of the existing system etc…

Example:

For example, to check the email functionality of an application, it could be flooded with 1000 users at a time. Now, 1000 users can fire the email transactions (read, send, delete, forward, reply) in many different ways. If we take one transaction per user per hour, then it would be 1000 transactions per hour. By simulating 10 transactions/user, we could load test the email server by occupying it with 10000 transactions/hour.

3) Stress testing

Under stress testing, various activities to overload the existing resources with excess jobs are carried out in an attempt to break the system down. Negative testing, which includes removal of the components from the system is also done as a part of stress testing. Also known as fatigue testing, this testing should capture the stability of the application by testing it beyond its bandwidth capacity.

The purpose behind stress testing is to ascertain the failure of system and to monitor how the system recovers back gracefully. The challenge here is to set up a controlled environment before launching the test so that you could precisely capture the behaviour of system repeatedly, under the most unpredictable scenarios.

Stress Testing Goal:

The goal of the stress testing is to analyse post-crash reports to define the behaviour of application after failure. The biggest issue is to ensure that the system does not compromise with the security of sensitive data after the failure. In a successful stress testing, the system will come back to normality along with all its components, after even the most terrible break down.

Example:

As an example, a word processor like Writer1.1.0 by OpenOffice.org is utilized in development of letters, presentations, spread sheets etc… Purpose of our stress testing is to load it with the excess of characters.

To do this, we will repeatedly paste a line of data, till it reaches its threshold limit of handling large volume of text. As soon as the character size reaches 65,535 characters, it would simply refuse to accept more data. The result of stress testing on Writer 1.1.0 produces the result that, it does not crash under the stress and that it handle the situation gracefully, which make sure that application is working correctly even under rigorous stress conditions.

Database Testing – Practical Tips and Insight on How to Test Database

2011-07-07T11:22:00.000-07:00

Database Testing – Practical Tips and Insight on How to Test Database

Database is one of the inevitable parts of a software application these days. It does not matter at all whether it is web or desktop, client server or peer to peer, enterprise or individual business, database is working at backend. Similarly, whether it is healthcare of finance, leasing or retail, mailing application or controlling spaceship, behind the scene a database is always in action.

Moreover, as the complexity of application increases the need of stronger and secure database emerges. In the same way, for the applications with high frequency of transactions (e.g. banking or finance application), necessity of fully featured DB Tool is coupled.

Currently, several database tools are available in the market e.g. MS-Access2010, MS SQL Server 2008 r2, Oracle 10g, Oracle Financial, MySQL, PostgreSQL, DB2 etc. All of these vary in cost, robustness, features and security. Each of these DBs possesses its own benefits and drawbacks. One thing is certain; a business application must be built using one of these or other DB Tools.

Before I start digging into the topic, let me comprehend the foreword. When the application is under execution, the end user mainly utilizes the 'CRUD' operations facilitated by the DB Tool.

C: Create – When user 'Save' any new transaction, 'Create' operation is performed.
R: Retrieve – When user 'Search' or 'View' any saved transaction, 'Retrieve' operation is performed.
U: Update – when user 'Edit' or 'Modify' an existing record, the 'Update' operation of DB is performed.
D: Delete – when user 'Remove' any record from the system, 'Delete' operation of DB is performed.

It does not matter at all, which DB is used and how the operation is preformed. End user has no concern if any join or sub-query, trigger or stored-procedure, query or function was used to do what he wanted. But, the interesting thing is that all DB operations performed by user, from UI of any application, is one of the above four, acronym as CRUD.

As a database tester one should be focusing on following DB testing activities:

What to test in database testing:

1) Ensure data mapping:

Make sure that the mapping between different forms or screens of AUT and the Relations of its DB is not only accurate but is also according to design documents. For all CRUD operations, verify that respective tables and records are updated when user clicks 'Save', 'Update', 'Search' or 'Delete' from GUI of the application.

2) Ensure ACID Properties of Transactions:

ACID properties of DB Transactions refer to the 'Atomicity', 'Consistency', 'Isolation' and 'Durability'. Proper testing of these four properties must be done during the DB testing activity. This area demands more rigorous, thorough and keen testing when the database is distributed.

3) Ensure Data Integrity:

Consider that different modules (i.e. screens or forms) of application use the same data in different ways and perform all the CRUD operations on the data. In that case, make it sure that the latest state of data is reflected everywhere. System must show the updated and most recent values or the status of such shared data on all the forms and screens. This is called the Data Integrity.

4) Ensure Accuracy of implemented Business Rules:

Today, databases are not meant only to store the records. In fact, DBs have been evolved into extremely powerful tools that provide ample support to the developers in order to implement the business logic at DB level. Some simple examples of powerful features of DBs are 'Referential Integrity', relational constrains, triggers and stored procedures. So, using these and many other features offered by DBs, developers implement the business logic on DB level. Tester must ensure that the implemented business logic is correct and works accurately.

Above points describe the four most important 'What Tos' of database testing. Now, I will put some light on 'How Tos' of DB Testing. But, first of all I feel it better to explicitly mention an important point. DB Testing is a business critical task, and it should never be assigned to a fresh or inexperienced resource without proper training.

How To Test Database:

1. Create your own Queries

In order to test the DB properly and accurately, first of all a tester should have very good knowledge of SQL and specially DML (Data Manipulation Language) statements. Secondly, the tester should acquire good understanding of internal DB structure of AUT. If these two pre-requisites are fulfilled, then the tester is ready to test DB with complete confidence. (S)He will perform any CRUD operation from the UI of application, and will verify the result using SQL query.

This is the best and robust way of DB testing especially for applications with small to medium level of complexity. Yet, the two pre-requisites described are necessary. Otherwise, this way of DB testing cannot be adopted by the tester.

Moreover, if the application is very complex then it may be hard or impossible for the tester to write all of the needed SQL queries himself or herself. However, for some complex queries, tester may get help from the developer too. I always recommend this method for the testers because it does not only give them the confidence on the testing they have performed but, also enhance their SQL skill.

2. Observe data table by table

If the tester is not good in SQL, then he or she may verify the result of CRUD operation, performed using GUI of the application, by viewing the tables (relations) of DB. Yet, this way may be a bit tedious and cumbersome especially when the DB and tables have large amount of data.

Similarly, this way of DB testing may be extremely difficult for tester if the data to be verified belongs to multiple tables. This way of DB testing also requires at least good knowledge of Table structure of AUT.

3. Get query from developer

This is the simplest way for the tester to test the DB. Perform any CRUD operation from GUI and verify its impacts by executing the respective SQL query obtained from the developer. It requires neither good knowledge of SQL nor good knowledge of application's DB structure.

So, this method seems easy and good choice for testing DB. But, its drawback is havoc. What if the query given by the developer is semantically wrong or does not fulfill the user's requirement correctly? In this situation, the client will report the issue and will demand its fix as the best case. While, the worst case is that client may refuse to accept the application.

Conclusion:

Database is the core and critical part of almost every software application. So DB testing of an application demands keen attention, good SQL skills, proper knowledge of DB structure of AUT and proper training.

In order to have the confident test report of this activity, this task should be assigned to a resource with all the four qualities stated above. Otherwise, shipment time surprises, bugs identification by the client, improper or unintended application's behavior or even wrong outputs of business critical tasks are more likely to be observed. Get this task done by most suitable resources and pay it the well-deserved attention.

Failover and Recovery Testing

2011-06-15T13:20:00.001-07:00

Failover and Recovery Testing testing verifies product in terms of ability to confront and successfully recover from possible failures, arising from software bugs, hardware failure or communication problems (eg network failure). The objective of this test is to check the system restore (or duplicate the main functional systems), which, in the event of failure, ensure the safety and integrity of the data product being tested.

Testing for failure and recovery is very important for systems operating on the principle of "24×7". If you create a product that will work, such as the Internet, without this kind of test you just can not do. Because Every minute of downtime or data loss in case of equipment failure can cost you money, losing customers and reputation in the market.

The technique of this test is simulating various fault conditions and subsequent study and evaluation of the reaction of protective systems. During these inspections it turns out, was it achieved the desired degree of recovery after the crash occurred.

For clarity, we consider some variants of this test, and general methods for their implementation. The object of testing in most cases are highly probable operational problems, such as:

Denial of electricity on a computer server
Denial of electricity on the client computer
Incomplete data processing cycle (interruption of data filters, interrupt synchronization).
Announcement or introduction into arrays of data are not available or erroneous elements.
Refusal data carriers.

These situations can be played as soon reached a point in development when all the system restore or duplication are ready to perform its functions. Technically, to implement the tests in the following ways:

Simulate the sudden failure of electricity on the computer (disconnect the computer).
Simulate the loss of communication with the network (turn off the power cord, disconnect the network device)
Simulate the failure of carriers (disconnect the external storage medium)
Simulate the situation in the presence of invalid data (a special test kit or a database).

Upon reaching the appropriate conditions of failure and performance-based recovery systems, we can estimate the product in terms of testing to failure. In all the cases listed above, upon completion of the recovery to be achieved some desired state of the data product:

Data loss or corruption within an acceptable range.
Report or reporting system, indicating the processes or transactions that were not completed because of errors.

It is worth noting that testing for failure and recovery - is very product-specific testing. Development of test scripts shall be subject to all the features of the system under test. Taking into account the rather harsh methods of influence, we should also evaluate the usefulness of this type of testing for a particular software product.

Design-Based Test Case Design an Effective Software Testing Technique

2011-06-15T13:18:00.001-07:00

Software design errors and faults can be discovered and software designs validated by two techniques like:

1) Requirements-based test case design being the primary technique

2) Another technique being the early design-based test case design.

In design-based test case design the information for deriving them is taken from the software design documentation.

Design-based test cases focus on the data and process paths within the software structures. Internal interfaces, complex paths or processes, worst-case scenarios, design risks and weak areas, etc. are all explored by constructing specialized test cases and analyzing how the design should handle them and whether it deals with them properly. In software testing effort, requirements-based and design-based test cases provide specific examples that can be used in design reviews or walkthroughs. Together they provide a comprehensive and rich resource for design based software testing.

Design Testing Metrics:
Increasingly, formal design reviews are adopting metrics as a means of quantifying test results and clearly defining expected results.

The metrics (measures that are presumed to predict an aspect of software quality) vary greatly. Some are developed from scored questionnaires or checklists. For example, one group of questions may relate to design integrity and system security.

Typical Integrity Questions can be like the following

Q.1: Are security features controlled from independent modules?

Q.2: Is an audit trail of accesses maintained for review or investigation?

Q.3: Are passwords and access keywords blanked out?

Q.4: Does it require changes in multiple programs to defeat the access security?

Each reviewer would answer these questions, and their answers would be graded or scored. Over time, minimum scores are established and used as pass/ fail criteria for the integrity metric. Designs that score below the minimum are reworked and subjected to additional review testing before being accepted.

Another example of a metric-based design test that can be used effectively is a test for system maintainability. An important consideration in evaluating the quality of any proposed design is the ease with which it can be maintained or changed once the system becomes operational. Maintainability is largely a function of design. Problems or deficiencies that produce poor maintainability must be discovered during design reviews; it is usually too late to do anything to correct them further along in the cycle of software testing.

To test the maintainability we develop a list of likely or plausible requirements changes (perhaps in conjunction with the requirements review). Essentially, we want to describe in advance what about the system we perceive is most apt to be changed in the future. During the design review a sample of these likely changes is selected at random and the system alterations that would be required are walked through by the reviewers to establish estimates for how many programs and files or data elements would be affected and the number of program statements that would have to be added and changed. Metric values for these estimates are again set on the basis of past experience. Passing the test might require that 80 percent of the changes be accomplished by changes to single programs and that the average predicted effort for a change be less than one man-week. Designs that score below these criteria based on the simulated changes are returned, reworked, and re-subjected to the maintainability test before being accepted. This is just one example of an entire class of metrics that can be built around what-if questions and used to test any quality attribute of interest while the system is still being designed.

Design for Testing:
In addition to the testing activities we perform to review and test the design, another important consideration is the features in the design that simplify or support testing. Part of good engineering is building something in a way that simplifies the task of verifying that it is built properly. Hardware engineers routinely provide test points or probes to permit electronic circuits to be tested at intermediate stages. In the same way, complex software must be designed with "windows" or hooks to permit the testers to "see" how it operates and verify correct behavior.

Providing such windows and reviewing designs to ensure their testability is part of the overall goal of designing for testability. With complex designs, testing is simply not effective unless the software has been designed for testing. Testers must consider how they are going to test the system and what they will require early enough in the design process so that the test requirements can be met.

Design Testing Tools and Aids:
Automated tools and aids to support design testing play an important role in a number of organizations. As in requirements testing, our major testing technique is the formal review; however there is a greater opportunity to use automated aids in support of design reviews.

Software testing tools in common use include design simulators (such as the data base and response time simulators; system charters that diagram or represent system logic; consistency checkers that analyze decision tables representing design logic and determine if they are complete and consistent; and data base dictionaries and analyzers that record data element definitions and analyze each usage of data and report on where it is used and whether the routine inputs, uses, modifies, or outputs the data element.

None of these software testing tools performs direct testing. Instead, they serve to organize and index information about the system being designed so that it may be reviewed more thoroughly and effectively. In the case of the simulators, they permit simplified models to be represented and experimentation to take place, which may be especially helpful in answering the question of whether the design solution is the right choice. All the tools assist in determining that the design is complete and will fulfill the stated requirements.

Documentation Errors

2011-06-15T13:07:00.000-07:00

The purpose of error reporting is fixing it. About how to describe the error, what it consists of a description of the error and how it might look like the example tells this story.

So you found a bug. Not shelving them to start to write a bug report (not to procrastinate, then you can forget to write a report, to forget in what place was a mistake to miss part or even misquote the situation).

The first step is desirable to calm down and not make any sudden movements, not to press extra buttons, etc. We must remember the sequence of actions that have been made and try to reproduce the situation. Better to do it in a new browser window (if it is a web-application). Come and write data input / command buttons are pressed, in any menu jump to, what kind of reaction system to these actions, what error message is displayed.

Now we need to write their own actions. Record should be brief, but clear and understandable. Find a middle ground. If you write a memoir, the programmer will not read them or think that the error is very difficult and would defer until later, and ultrashort report no one will understand. As a consequence, error correction (bug) will hang in the air and sent back to you marked "not play" or ask clarifications, thereby simply and your spending and your time. Also, do not enter into one report more than one error. Motive is the same.

The report is written not only for ourselves but for others. So, it should be written so as to understand everything, but had no idea that you would like to say, do not ask again. Ask yourself a question: whether to repeat your actions the person who first sees the product?

If possible, try different options to express exactly the problem.

It is also desirable to avoid jargon or expressions which may be difficult to understand others.

In no case does not need to pass an oral report bugs, write an e-mail, icq, etc.! In most cases, forget about them, not treat them seriously and, if not corrected, especially in this case will blame you. You need this? All errors must be observed and described and have its own unique number. Then, for uncorrected errors will be the responsibility on the programmer.

These records will need another bug testers to work with you, the managers for them to see that you work and work productively, testers, who will come for you, as well as for writing reports.

Error Description

We now turn to the description of the error. Depending on what the company bagtrekingovaya system (accounting system errors), there will be different input fields.

At the beginning of opening a new bug report. It is possible that you will see a lot of lines for the filling, but it is possible that they do not all have to fill. It is better to consult with other testers, a manager or head of the group testing. But most likely have to fill out the following fields:

Priority (as a serious mistake and a speed of execution requires. Must be corrected quickly or you can wait)
Designate (who will deal with an error)
Class (this is what kind of error-serious, minor, typo …)

Header Error

The headline should concisely and fully describe the problem. We spend a lot of time leafing through the bugs database and browsing the headlines errors. Much time can be saved if the headlines are clear and not have to open the error description to understand what was meant.

Problem Description

Describe the problem better by using "arrows". With them, the text of the report is discarded many unnecessary words that interfere with understanding the essence.

Example: I opened www.aaa.ru -> introduced in the word bbb ccc -> clicked ddd -> get errors: ddd

An example from the life

Title: The problem with the menu "forgot password"

Problem Description: Go to the login page -> click "Forgot Password" - "in the" Personal Account "enter 2389 -> in the« e-mail »enter test@test.com -> System says:" Error sending message . (# 1) "

If necessary, the data in the operating environment, configuration, logs. Is there a dependence on the configuration, installation, condition, options, settings, version, etc.

Attachments

To make the report more detailed and vivid can and must resort to:

links
screenshot
video recording

Link

Well here everything is clear. Popped up an error - is taken link to this page, and inserted into the report. It is desirable also with screenshots. (Assuming that the tested Web application - approx. Editor)

Screenshots

A very useful thing to visualize the problem. Make a screenshot of the problematic area. (The simplest thing - it's on the keyboard to find the button Print Screen, then press it to open the program from Paint (if we are in the operating system of family Windows - approx. Editor), which is automatically installed in Windows and in her press Ctrl-V, then cut out unnecessary , store (preferably in the format JPG))

Although there is a more professional program that are more adapted to this kind of action and have a lot of very useful features, such as SnagIt, HyperSnap, HardCopy, RoboScreenCapture, FullShot 9, HyperSnap-DX 5, TNT 2. Screenshot want to attach to the bug report.

Videos

If the error difficult to describe, it is the most appropriate method. Program: SnagIt, CamStudio.

Top 10 negative test cases

2011-06-15T13:05:00.001-07:00

Negative test cases used for testing the application, subject to receipt on his entry "incorrect" data. Such test cases should always be used during testing. Below are the ten most popular negative test scenarios:

Embedded Single Quote - Most SQL databases, there are problems in the presence of single quotes in the query (eg, Jones's car).
Use single quotes when checking each input field working with the database.

Required Data Entry - In the specification of your application should be clearly defined fields requiring mandatory data entry.
Check that the forms that have fields defined as mandatory for entry, can not be maintained in the absence of data in them.

Field Type Test - In the specification of your application should be clearly defined data types for each of the fields (fields date / time, numeric fields, fields for entering a telephone number or postal code, etc.)
Check that each of the fields allows you to enter or store data only certain specification of the type (for example, the application should not allow you to enter or maintain letters or special characters in numeric fields).

Field Size Test - In the specification of your application should be clearly defined maximum number of characters in each of the fields (for example, the number of characters in a field with a user name should not exceed 50).

To check that your application can not adopt or maintain more characters than specified. Do not forget that these fields should not only function correctly, but also to warn the user about the limitations, for example, with explanatory text boxes or error messages.

Numeric Bounds Test - Numeric field of your application may be limited allowable numeric values. These constraints can be specified in the specification of your application or arising from the logic of the program (for example, if you test the functionality associated with the accrual of interest on the account, it is logical to assume that the accrued interest can not take a negative value).

Check that the application displays an error message if the values fall outside the acceptable range (for example, the error message should appear when you enter a value of 9 or 51 in a field with valid values range from 10 to 50, or when you enter a negative value in the field whose values must be positive).

Numeric Limits Test - Most databases and programming languages define the numerical values of the variables with a certain type (eg, integer or long integer), which, in turn, have limited allowable numeric values (eg, integer values must be in the range -32768 32767, a long integer from -2147483648 to 2147483647).
Check the boundary values of the variables used for numeric fields, the boundary values which are not clearly defined specification.

Date Bounds Test - Very often in applications, there are logical limits to the fields containing the date and time. For example, if you check the box containing the user's date of birth, it is only logical to ban entry not yet due date (ie the date in the future), or restriction on the entry date is different from that of today more than 150 years.

Date Validity - Date fields should always be checking the validity of the entered values (eg, 10/31/2009 - not valid date). Also, do not forget about checking dates in leap years (years divisible by 4 m and multiples of 100 and 400 at the same time - a leap).

Web Session Testing - Many web applications use a browser session to track user logged into the system, application-specific application settings for a particular user, etc. At the same time, many of the features of the system can not or should not work without login. Check that the functionality or pages that are behind a password, not user is not authenticated.

Performance Changes - For each new product release is conducting a series of performance tests (for example, the rate of additions, deletions or changes of various elements on the page). Compare the results with tests of performance of previous versions. This practice will allow you to advance to identify potential performance problems due to code changes in new versions of the product.

localization testing tips and tricks

2011-06-15T13:04:00.001-07:00

If you have already encountered with the testing locations, it is certainly one of the first questions you asked yourself starting to work, sounded something like this: "What should I test? Because I do not know the language / languages. "And the truth is that?

In fact, the correctness of the translation - not the only thing that you should pay attention when testing sites. Yes, of course, very important that the text was the grammatically, syntactically and logically correct. But that's not enough for a good location. That is why this kind of work and attract testers.

So, a few words about what needs to know and that should draw the attention of the tester in the test sites.

1. Prepare a suitable test environment for testing applications

Depending on the implementation, the choice of language for web applications can be carried out both manually and on the basis of language and regional settings on your browser or operating system, and even on your geographic location. And if a manual selection of a language more or less clear, in other cases, you will have to show a little ingenuity, and is likely to have multiple test environments. The ideal option would be virtual machines with installed OS and other software related sites. When configuring these machines, try to keep most settings to their original state, because very few users are using a configuration different from the CDS. When you create a virtual machine, is guided by the average statistical portrait of your end user, in order to imagine what software can be installed on its PCs. Why do it? The fact that some programs could seriously affect the final result of testing, and, accordingly, to get you to make false conclusions. For example, PC with MS Office 2003 and MS Office 2007 will behave differently in terms of working with a localized product, since the installation of MS Office 2007 includes the font Arial Unicode, which includes the inscription of characters overwhelming majority of world languages ??(in including Chinese and Japanese characters), but in the MS Office 2003 is not such a font.

2. Follow the correct translation

In my opinion, validation of the translation should always carry a person who is a native speaker or professional translator, or at least, people familiar with the language. All the rest of the evil one. But still, it is believed that such tests should exercise and a tester, even if he has no idea about the language. In such cases the Board to use electronic translators and dictionaries, not one but several at once, which will compare the results of translation and can make correct conclusions about its correctness.

In general, even if you have decided on such an adventure, try not too hold to, in fact, most likely, a professional translation interface, which, believe me, makes it more adequate translation than electronic translators.

3. Be the application "for you"

Before embarking on testing web applications in an unknown language to you, try to learn it so that you can move on it almost blindly. Read the basic functionality in the version of localization, the language you understand. This will save a lot of time, because you do not have to guess which may cause one or another link, or what the consequences will be pressing some buttons.

4. Begin testing with static elements

First of all, try to check the label on the static elements of the site: the block header explaining the inscriptions, etc., on them the user will pay attention at first.

By checking these items, do not forget that the length of one and the same text in different languages ??may differ materially. This is especially true if you checked the localization of the product for which the "native" language is English, because, as you know, when translating from English into any other text length increases by about 30%. Accordingly, try to make sure that all required inscriptions found a place in the markup of your site.

5. Pay attention to the controls, and error messages

Once the static elements will be finished, proceed to the rest of the control of your site: buttons, menus, etc. Remember that depending on the implementation, localization controls can be defined in the code, and may depend on your browser settings or OS.

Do not forget about error messages. Plan testing and compose test cases so that the maximum number of test error messages. Programmers are somehow paying very little attention to such things, because of which a significant part of the error messages may never entered into a localized version or be translated into appropriate language, or be totally unreadable because of problems with the encoding.

6. Ensure that data entry can be done in terms of localization

If the tested Web application involves the implementation of any data the user, be sure that users can enter data in terms of localization and all extended characters entered by the user and process the application correctly.

7. Do not forget the national and regional particularities

Another important point to which attention should be paid for testing - regional and national characteristics of the country, which is designed for localization. These features include the direction of the text, date formats, addresses, decimals, currency symbols, units of different quantities, etc. Always remember that good localization should be not only well-translated text, but an exact match cultural characteristics of people who speak the appropriate language.

I hope these simple tips will help you make your application more accessible and understandable for users of multi-lingual and multi-national World Wide Web.

Requirements Testing

2011-06-15T13:03:00.001-07:00

Requirements Testing

Testing software is an integral part of building a system. However, if the software is based on inaccurate requirements, then despite well written code, the software will be unsatisfactory. Most of the defects in a system can be traced back to wrong, missing, vague or incomplete requirements.

Requirements seem to be ephemeral. They flit in and out of projects, they are capricious, intractable, unpredictable and sometimes invisible. When gathering requirements we are searching for all of the criteria for a system's success. We throw out a net and try to capture all these criteria.

The Quality Gateway

As soon as we have a single requirement in our net we can start testing. The aim is to trap requirements-related defects as early as they can be identified. We prevent incorrect requirements from being incorporated in the design and implementation where they will be more difficult and expensive to find and correct.

To pass through the quality gateway and be included in the requirements specification, a requirement must pass a number of tests. These tests are concerned with ensuring that the requirements are accurate, and do not cause problems by being unsuitable for the design and implementation stages later in the project.

Make The Requirement Measurable

In his work on specifying the requirements for buildings, Christopher Alexander describes setting up a quality measure for each requirement.

"The idea is for each requirement to have a quality measure that makes it possible to divide all solutions to the requirement into two classes: those for which we agree that they fit the requirement and those for which we agree that they do not fit the requirement."

In other words, if we specify a quality measure for a requirement, we mean that any solution that meets this measure will be acceptable. Of course it is also true to say that any solution that does not meet the measure will not be acceptable.

The quality measures will be used to test the new system against the requirements. The remainder of this paper describes how to arrive at a quality measure that is acceptable to all the stakeholders.

Quantifiable Requirements

Consider a requirement that says "The system must respond quickly to customer enquiries". First we need to find a property of this requirement that provides us with a scale for measurement within the context. Let's say that we agree that we will measure the response using minutes. To find the quality measure we ask: "under what circumstances would the system fail to meet this requirement?" The stakeholders review the context of the system and decide that they would consider it a failure if a customer has to wait longer than three minutes for a response to his enquiry. Thus "three minutes" becomes the quality measure for this requirement.

Any solution to the requirement is tested against the quality measure. If the solution makes a customer wait for longer than three minutes then it does not fit the requirement. So far so good: we have defined a quantifiable quality measure. But specifying the quality measure is not always so straightforward. What about requirements that do not have an obvious scale?

Non-quantifiable Requirements

Suppose a requirement is "The automated interfaces of the system must be easy to learn". There is no obvious measurement scale for "easy to learn". However if we investigate the meaning of the requirement within the particular context, we can set communicable limits for measuring the requirement.

Again we can make use of the question: "What is considered a failure to meet this requirement?" Perhaps the stakeholders agree that there will often be novice users, and the stakeholders want novices to be productive within half an hour. We can define the quality measure to say "a novice user must be able to learn to successfully complete a customer order transaction within 30 minutes of first using the system". This becomes a quality measure provided a group of experts within this context is able to test whether the solution does or does not meet the requirement.

An attempt to define the quality measure for a requirement helps to rationalise fuzzy requirements. Something like "the system must provide good value" is an example of a requirement that everyone would agree with, but each person has his own meaning. By investigating the scale that must be used to measure "good value" we identify the diverse meanings.

Sometimes by causing the stakeholders to think about the requirement we can define an agreed quality measure. In other cases we discover that there is no agreement on a quality measure. Then we substitute this vague requirement with several requirements, each with its own quality measure.

Requirements Test 1

Does each requirement have a quality measure that can be used to test whether any solution meets the requirement?

By adding a quality measure to each requirement we have made the requirement visible. This is the first step to defining all the criteria for measuring the goodness of the solution. Now let's look at other aspects of the requirement that we can test before deciding to include it in the requirements specification.

Requirements Test 2

Does the specification contain a definition of the meaning of every essential subject matter term within the specification?

When the allowable values for each of the attributes are defined it provides data that can be used to test the implementation.

Requirements Test 3

Is every reference to a defined term consistent with its definition?

Requirements Test 4

Is the context of the requirements wide enough to cover everything we need to understand?

Requirements Test 5

Have we asked the stakeholders about conscious, unconscious and undreamed of requirements?

Requirements Test 5 (enlarged)

Have we asked the stakeholders about conscious, unconscious and undreamed of requirements? Can you show that a modelling effort has taken place to discover the unconscious requirements? Can you demonstrate that brainstorming or similar efforts taken place to find the undreamed of requirements?

Requirements Test 6

Is every requirement in the specification relevant to this system?

Requirements Test 7

Does the specification contain solutions posturing as requirements?

Requirements Test 8

Is the stakeholder value defined for each requirement?

Requirements Test 9

Is each requirement uniquely identifiable?

Requirements Test 10

Is each requirement tagged to all parts of the system where it is used? For any change to requirements, can you identify all parts of the system where this change has an effect?

Conclusions

The requirements specification must contain all the requirements that are to be solved by our system. The specification should objectively specify everything our system must do and the conditions under which it must perform. Management of the number and complexity of the requirements is one part of the task.

The most challenging aspect of requirements gathering is communicating with the people who are supplying the requirements. If we have a consistent way of recording requirements we make it possible for the stakeholders to participate in the requirements process. As soon as we make a requirement visible we can start testing it. and asking the stakeholders detailed questions. We can apply a variety of tests to ensure that each requirement is relevant, and that everyone has the same understanding of its meaning. We can ask the stakeholders to define the relative value of requirements. We can define a quality measure for each requirement, and we can use that quality measure to test the eventual solutions.

Testing starts at the beginning of the project, not at the end of the coding. We apply tests to assure the quality of the requirements. Then the later stages of the project can concentrate on testing for good design and good code. The advantages of this approach are that we minimise expensive rework by minimising requirements-related defects that could have been discovered, or prevented, early in the project's life.

References:

An Early Start to Testing: How to Test Requirements
Suzanne Robertson

The Importance of “Hands-On” Mobile App Testing

2011-05-26T04:44:00.001-07:00

On a simulator, you still use a mouse to 'touch' the screen and simulate gestures. You also have a full-sized keyboard for data entry. Of course, this is very different from using a mobile device, wouldn't you say?

First, a mobile device sits in your hand. Each of us likely has slightly different ways of holding and operating the device. For some, it's done with one-hand using your thumb or a finger. For others, it might be two hands using both thumbs.

Second, there's the act of touching various screen elements like buttons and controls. This is much easier to do with a mouse pointer than a pudgy finger.

Based on the prior experience of many mobile testers, this difference is a critical one, and the biggest, for testing application design and function. Using a mouse with the simulator, you do not get the full effect of having to scroll through a large list view of items or having to play 'whack-a-mole' on the screen with your thumb because button placement for navigating multiple screens is inconsistent.

Mobile developers are strongly encouraged to ensure that application testing begins early, and happens often, on the mobile device itself rather than on a simulator. The same holds true for tablet devices.

From Web Trends, Mobile Analytics: "Even on the same mobile platform, screen sizes and resolutions can vary based on device type. For instance, the screen size and resolution on the HTC Incredible is different than that on the HTC EVO 4G. Consequently, for an application to have a consistent look and feel across both devices and across a variety of other devices, user interface elements and graphics need to be scalable."

Top 10 Reasons to Become a Mobile App Tester

2011-05-26T04:43:00.001-07:00

There are lots of reasons to become a mobile app tester, which you would know if you read our posts every day. Here are ten of those reasons, in no particular order:

1. High income potential

2. You want to work in the "wild west" of new technology

3. No fancy degrees or certifications needed to get started

4. You want to say "I tested that app!" to your friends and family

5. You're bored with testing the same old web and desktop apps

6. You want to see the latest, greatest apps before everyone else

7. You want to be one of the early experts in a fast-growing field

8. You're curious, with a knack for problem-solving

9. You want to get paid to play with the latest apps and devices

10. You want your wireless bill to be tax deductible

Mobile Functional Testing: Manual or Automated?

2011-05-26T04:40:00.001-07:00

Mobile Functional Testing: Manual or Automated?

Okay, so you know what aspects of your mobile application are in need of functional testing. But before you start crafting test cases or user journeys, you must answer another important question: manual testing or automation?

For established companies, the answer to that question would be a resounding "both". But for startups with limited testing budgets and rapidly-evolving applications, manual testing – although slightly more costly – is the preferred option. Although there are several open-source automated solutions many of them are exclusively made for one operating system (iOS). Preferred

Other advantages of manual testing include:

Find real bugs: Automation suites will highlight some errors, but most bugs within mobile apps – especially usability and layout issues – are only discovered under true real-world scenarios.

Adaptability: Manual testing can be altered much more quickly and effectively than an elaborate automated test. Chances are, if you're working within a startup environment, your testing requirements are likely to change as new features are added.

Real feedback: Unfortunately, automated tests can't give you an honest (human) opinion about your app's performance, usability and functionality. We'll let you know when this changes. In the meantime, you need to see results from real users with real devices.

Variable Control: As we've alluded to earlier, there's simply too many outside variables to rely on automation for all of your testing objectives. Until you've isolated and addressed all of these variables, manual testing should be your preferred methodology.

Mobile testing for start-ups is all about discovering new areas of concern. So, to rehash an old quote from mobile testing expert Karen N. Johnson:

Software Cost Estimation

2011-05-17T02:33:00.001-07:00

Software Cost Estimation

This article aims to study the process of Software Cost Estimation and its impact on the Software Development Process. We also highlight the various challenges involved in Software Cost Estimation and common solutions to navigate through these challenges.

Background:
Software Cost Estimation is widely considered to be a weak link in software project management. It requires a significant amount of effort to perform it correctly. Errors in Software Cost Estimation can be attributed to a variety of factors. Various studies in the last decade indicated that 3 out of 4 Software projects are not finished on time or within budget or both

Who is responsible for Software Cost Estimation?
The group of people responsible for creating a software cost estimate can vary with each organization. However the following is possible in most scenarios -

- People who are directly involved with the implementation are involved in the
..estimate.
- Project Manager is responsible for producing realistic cost estimates.
- Project Managers may perform this task on their own or consult with
..programmers responsible.
- Various studies indicate that if the programmers responsible for development
..are involved in the estimation it was more accurate. The programmers have
..more motivation to meet the targets if they were involved in the estimation
..process.

Following scenarios are also possible

- An independent cost estimation team creates an Estimate
- Independent Experts are given the Software specification and they create a
..Software Cost estimate. The Estimation team reviews this and group
..consensus arrives at a final figure.

Factors contributing to inaccurate estimation

· Scope Creeps, imprecise and drifting requirements
· New software projects pose new challenges, which may be very different from
..the past projects.
· Many teams fail to document metrics and lessons learned from past projects
· Many a times the estimates are forced to match the available time and
..resources by aggressive leaders
· Unrealistic estimates may be created by various 'political under currents'

Impact of Under-estimating:
Under-Estimating a project can be vary damaging

- It leads to improper Project Planning
- It can also result in under-staffing and may result in an over worked and
..burnt out team
- Above all the quality of deliverables may be directly affected due insufficient
..testing and QA
- Missed Dead lines cause loss of Credibility and goodwill

The Estimation Process:
Generally the Software Cost estimation process comprises of 4 main steps:

1) Estimate the size of the development product.
This comprises of various sub-steps or sub tasks. These tasks may have been done already during Requirement Analysis phase. If not then they should be done as a part of the estimation Process. Important thing is that they should be done to ensure the success of the Estimation Process and the Software Project as a whole

a) Create a detailed Work Break Down Structure. This directly impacts the accuracy of the estimate. This is one of the most important steps. The Work Break down structure should include any and all tasks that are within the scope of the Project, which is being estimated. The most serious handicap is the inability to clearly visualize the steps involved in the Project. Executing a Software Project is not just coding.

b) The work Break down structure will include the size and complexity of each software module that can be expressed as number of Lines of Code, Function Points, or any other unit of measure

c) The Work Break down structure should include tasks other than coding such as Software Configuration Management, various levels and types of Testing, Documentation, Communication, User Interaction, Implementation, Knowledge Transition, Support tasks(if any) and so on

d) Clearly indicate or eliminate any gray areas (vague/unclear specifications etc.)

e) Also take into account the various Risk Factors and down times. There are many different Risk Factors involved – Technical aspects such as availability of the Environment, Server/Machine uptime, 3rd party Software Hardware failures or Human aspects – Employee Attrition, Sick time, etc. Some of them may seem to be 'overkill' but real world experience shows that these factors affect the time lines of a project. If ignored they may adversely impact the Project timelines and estimates.

2) Estimate the effort in person-hours.
The Result of various tasks involved in step 1 is an effort estimate in person hours. The effort of various Project tasks expressed in person-hours is also influenced by various factors such as:

a) Experience/Capability of the Team members
b) Technical resources
c) Familiarity with the Development Tools and Technology Platform

3) Estimate the schedule in calendar months
The Project Planners work closely with the Technical Leads, Project Manager and other stakeholders and create a Project schedule. Tight Schedules may impact the Cost needed to develop the Application.

4) Estimate the project cost in dollars (or other currency)
Based on the above information the project effort is expressed in dollars or any other currency.

Measuring the Size/Complexity of the Software Program:
This is one of the most elusive aspects in the Software Cost Estimation Process.
There are different methodologies for arriving at and expressing the size/complexity of the Software Program. Some of the popular ones are

1) Function Points
2) Lines of Code
3) Feature Points
4) Mk II function points
5) 3D Function Points
6) Benchmarking

We briefly explain each of the above methods in the next few pages

Function Points
The Function Point methodology was developed by Allan Albrecht at IBM. This methodology is based on the belief that the size of a software project can be estimated during the requirements analysis. It takes into account the inputs and outputs of the system. Five classes of items are counted:

1. External Inputs
2. External Outputs
3. Logical Internal Files
4. External Interface Files
5. External Inquiries

The Total Function Point count is calculated based on the

a) Counts for each of these items
b) The weighting factors and adjustment factors in this methodology

What are function points and why count them?
"Function points are a measure of the size of Software applications and the projects that build them. The size is measured from a functional, or user, point of view. It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application."

Function points are not a perfect measure of effort to develop an application or of its business value, although the size in function points is typically an important factor in measuring each. Since the function point count for an application is independent of the technology used to develop the application it can be used for almost all types of applications such as GUI, OOP, Client Server, etc.
Since function points are based on screens, reports and other external objects, this measure takes the users' view. In these days of outsourcing and other confusion regarding the role of IT in an organization, understanding the users' view is of critical importance!

Lines of code:
Counting lines of code measures software from the developers' point of view The number of lines of code is the traditional way of measuring the application size. Many people consider this method as irrelevant now. There are technical problems with the lines of code measure. It is difficult to compare lines of code when a mix of technologies is used. There is no standard definition of what a line of code is. A Program may have blank lines, comments, data declarations, and multi-line statements.

Feature points Methodology:
It was developed by Software Productivity Research (SPR) in 1986. This technique takes into account the number of algorithms used in the application. It is compatible with the Function Points Methodology. The size calculated by the two methods for an ordinary transactional program would be the same. Feature Points Methodology is generally more useful for estimation in real-time process control, mathematical optimization and various embedded systems. The estimates are higher and considered more accurate in these cases.

Mk II function points Methodology:
This was developed Charles Symons in 1984 at Nolan, Norton & Co., part of KPMG Management Consulting. The Original Function Point approach suffers from the following weaknesses:

· It is often difficult to identify the components of an application.
· The original Function Point Methodology assigned weights to function point
..components based on "debate and trial."
· The original Function Point Methodology did not provide a means of accounting
..for internal complexity. 'Feature points' technique addresses these issues.
· When small systems are combined into larger applications. Function
..Points Methodology makes the total function point count less than the sum
..of the components.

MKII decomposes the application being counted into a collection of logical transactions. Each transaction consists of an input, a process and an output. For each transaction, Unadjusted Function Points (UFP) become a function of the number of input data element-types, entity-types referenced and output data element-types. The UFPs for the entire system are then summed. Mk II is widely used in the UK, India, Singapore, Hong Kong and Europe. Users include governmental organizations, finance, insurance, retail and manufacturing.

3D function points:
This methodology was developed by Boeing Company and published in 1992. The new technique was designed to address two classic problems associated with the Albrecht approach( the original Functional Point Methodology)

a) The original Functional Point Methodology is not user friendly
b) It is inaccurate when measuring complex scientific and real-time systems.

The 3D function points takes into account the following Dimensions - data, function and control. The data dimension is similar to the original Function Point Methodology. The function dimension accounts for the transformations or algorithms. The control dimension accounts for transitions or changes in application state.

Benchmarking:
Over the years many Organizations with significant development experience and mature processes have collected metrics on the various software development projects. These include the time, effort required to develop applications on various platforms and in various Business Domains. Based on this data benchmarks are created.

Each new software module to be developed can be categorized using the

a) Number of inputs
b) Number of outputs
c) Number of transactions
d) Algorithms
e) Features of the module

Based on the above factors the module can be categorized for example as Simple, Medium or Complex. If it is too Complex you could express it in multiples of the above three categories. The baseline effort in terms of person-hours it takes for each category is predefined based on historical data/metrics for a similar platform. This figure can be improvised/refined over a period of time This can be correlated to an algorithm for calculating Car Insurance Premium. This is used to estimate the size and the effort needed for Software Development.

Risk Analysis in Software Testing

2011-05-17T02:32:00.001-07:00

Risk Analysis

In this tutorial you will learn about Risk Analysis, Technical Definitions, Risk Analysis, Risk Assessment, Business Impact Analysis, Product Size Risks, Business Impact Risks, Customer-Related Risks, Process Risks, Technical Issues, Technology Risk, Development Environment Risks, Risks Associated with Staff Size and Experience.

Risk Analysis is one of the important concepts in Software Product/Project Life Cycle. Risk analysis is broadly defined to include risk assessment, risk characterization, risk communication, risk management, and policy relating to risk. Risk Assessment is also called as Security risk analysis.

Technical Definitions:

Risk Analysis: A risk analysis involves identifying the most probable threats to an organization and analyzing the related vulnerabilities of the organization to these threats.

Risk Assessment: A risk assessment involves evaluating existing physical and environmental security and controls, and assessing their adequacy relative to the potential threats of the organization.

Business Impact Analysis: A business impact analysis involves identifying the critical business functions within the organization and determining the impact of not performing the business function beyond the maximum acceptable outage. Types of criteria that can be used to evaluate the impact include: customer service, internal operations, legal/statutory and financial.

Risks for a software product can be categorized into various types. Some of them are:

Product Size Risks:

The following risk item issues identify some generic risks associated with product size:

Estimated size of the product and confidence in estimated size?
Estimated size of product?
Size of database created or used by the product?
Number of users of the product?
Number of projected changes to the requirements for the product?

Risk will be high, when a large deviation occurs between expected values and the previous experience. All the expected information must be compared to previous experience for analysis of risk.

Business Impact Risks:

The following risk item issues identify some generic risks associated with business impact:

Affect of this product on company revenue?
Reasonableness of delivery deadline?
Number of customers who will use this product and the consistency of their needs relative to the product?
Number of other products/systems with which this product must be interoperable?
Amount and quality of product documentation that must be produced and delivered to the customer?
Costs associated with late delivery or a defective product?

Customer-Related Risks:

Different Customers have different needs. Customers have different personalities. Some customers accept what is delivered and some others complain about the quality of the product. In some other cases, customers may have very good association with the product and the producer and some other customers may not know. A bad customer represents a significant threat to the project plan and a substantial risk for the project manager.

The following risk item checklist identifies generic risks associated with different customers:

Have you worked with the customer in the past?
Does the customer have a solid idea of what is required?
Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?
Is the customer willing to participate in reviews?
Is the customer technically sophisticated in the product area?
Does the customer understand the software engineering process?

Process Risks:

If the software engineering process is ill-defined or if analysis, design and testing are not conducted in a planned fashion, then risks are high for the product.

Has your organization developed a written description of the software process to be used on this project?
Are the team members following the software process as it is documented?
Are the third party coders following a specific software process and is there any procedure for tracking the performance of them?
Are formal technical reviews are done regularly at both development and testing teams?
Are the results of each formal technical review documented, including defects found and resources used?
Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases?
Is a mechanism used for controlling changes to customer requirements that impact the software?

Technical Issues:

Are specific methods used for software analysis?
Are specific conventions for code documentation defined and used?
Are any specific methods used for test case design?
Are software tools used to support planning and tracking activities?
Are configuration management software tools used to control and track change activity throughout the software process?
Are tools used to create software prototypes?
Are software tools used to support the testing process?
Are software tools used to support the production and management of documentation?
Are quality metrics collected for all software projects?
Are productivity metrics collected for all software projects?

Technology Risk:

Is the technology to be built new to your organization?
Does the software interface with new hardware configurations?
Does the software to be built interface with a database system whose function and performance have not been proven in this application area?
Is a specialized user interface demanded by product requirements?
Do requirements demand the use of new analysis, design or testing methods?
Do requirements put excessive performance constraints on the product?

Development Environment Risks:

Is a software project and process management tool available?
Are tools for analysis and design available?
Do analysis and design tools deliver methods that are appropriate for the product to be built?
Are compilers or code generators available and appropriate for the product to be built?
Are testing tools available and appropriate for the product to be built?
Are software configuration management tools available?
Does the environment make use of a database or repository?
Are all software tools integrated with one another?
Have members of the project team received training in each of the tools?

Risks Associated with Staff Size and Experience:

Are the best people available and are they enough for the project?
Do the people have the right combination of skills?
Are staffs committed for entire duration of the project?

Metrics Used In Software Testing

2011-05-17T02:27:00.001-07:00

Metrics Used In Testing

In this tutorial you will learn about metrics used in testing, The Product Quality Measures - 1. Customer satisfaction index, 2. Delivered defect quantities, 3. Responsiveness (turnaround time) to users, 4. Product volatility, 5. Defect ratios, 6. Defect removal efficiency, 7. Complexity of delivered product, 8. Test coverage, 9. Cost of defects, 10. Costs of quality activities, 11. Re-work, 12. Reliability and Metrics for Evaluating Application System Testing.
The Product Quality Measures:

1. Customer satisfaction index

This index is surveyed before product delivery and after product delivery
(and on-going on a periodic basis, using standard questionnaires).The following are analyzed:

Number of system enhancement requests per year

Number of maintenance fix requests per year

User friendliness: call volume to customer service hotline

User friendliness: training time per new user

Number of product recalls or fix releases (software vendors)

Number of production re-runs (in-house information systems groups)

2. Delivered defect quantities

They are normalized per function point (or per LOC) at product delivery (first 3 months or first year of operation) or Ongoing (per year of operation) by level of severity, by category or cause, e.g.: requirements defect, design defect, code defect, documentation/on-line help defect, defect introduced by fixes, etc.

3. Responsiveness (turnaround time) to users

Turnaround time for defect fixes, by level of severity

Time for minor vs. major enhancements; actual vs. planned elapsed time

4. Product volatility

Ratio of maintenance fixes (to repair the system & bring it into compliance with specifications), vs. enhancement requests (requests by users to enhance or change functionality)

5. Defect ratios

Defects found after product delivery per function point.

Defects found after product delivery per LOC

Pre-delivery defects: annual post-delivery defects

Defects per function point of the system modifications

6. Defect removal efficiency

Number of post-release defects (found by clients in field operation), categorized by level of severity

Ratio of defects found internally prior to release (via inspections and testing), as a percentage of all defects

All defects include defects found internally plus externally (by customers) in the first year after product delivery

7. Complexity of delivered product

McCabe's cyclomatic complexity counts across the system

Halstead's measure

Card's design complexity measures

Predicted defects and maintenance costs, based on complexity measures

8. Test coverage

Breadth of functional coverage

Percentage of paths, branches or conditions that were actually tested

Percentage by criticality level: perceived level of risk of paths

The ratio of the number of detected faults to the number of predicted faults.

9. Cost of defects

Business losses per defect that occurs during operation

Business interruption costs; costs of work-arounds

Lost sales and lost goodwill

Litigation costs resulting from defects

Annual maintenance cost (per function point)

Annual operating cost (per function point)

Measurable damage to your boss's career

10. Costs of quality activities

Costs of reviews, inspections and preventive measures

Costs of test planning and preparation

Costs of test execution, defect tracking, version and change control

Costs of diagnostics, debugging and fixing

Costs of tools and tool support

Costs of test case library maintenance

Costs of testing & QA education associated with the product

Costs of monitoring and oversight by the QA organization (if separate from the development and test organizations)

11. Re-work

Re-work effort (hours, as a percentage of the original coding hours)

Re-worked LOC (source lines of code, as a percentage of the total delivered LOC)

Re-worked software components (as a percentage of the total delivered components)

12. Reliability

Availability (percentage of time a system is available, versus the time the system is needed to be available)

Mean time between failure (MTBF).

Man time to repair (MTTR)

Reliability ratio (MTBF / MTTR)

Number of product recalls or fix releases

Number of production re-runs as a ratio of production runs

Metrics for Evaluating Application System Testing:

Metric = Formula

Test Coverage = Number of units (KLOC/FP) tested / total size of the system. (LOC represents Lines of Code)

Number of tests per unit size = Number of test cases per KLOC/FP (LOC represents Lines of Code).

Acceptance criteria tested = Acceptance criteria tested / total acceptance criteria

Defects per size = Defects detected / system size

Test cost (in %) = Cost of testing / total cost *100

Cost to locate defect = Cost of testing / the number of defects located

Achieving Budget = Actual cost of testing / Budgeted cost of testing

Defects detected in testing = Defects detected in testing / total system defects

Defects detected in production = Defects detected in production/system size

Quality of Testing = No of defects found during Testing/(No of defects found during testing + No of acceptance defects found after delivery) *100

Effectiveness of testing to business = Loss due to problems / total resources processed by the system.

System complaints = Number of third party complaints / number of transactions processed

Scale of Ten = Assessment of testing by giving rating in scale of 1 to 10

Source Code Analysis = Number of source code statements changed / total number of tests.

Effort Productivity = Test Planning Productivity = No of Test cases designed / Actual Effort for Design and Documentation

Test Execution Productivity = No of Test cycles executed / Actual Effort for testing

Internationalization Testing

2011-04-24T14:56:00.001-07:00

Internationalization Testing

Introduction

World is flat. If you are reading this page, chances are that you are experiencing this as well. It is very difficult to survive in the current world if you are selling your product in only one country or geological region. Even if you are selling in all over the world, but your product is not available in the regional languages, you might not be in a comfortable situation.

Products developed in one location are used all over the world with different languages and regional standards. This arises the need to test product in different languages and different regional standards. Multilingual and localization testing can increase your products usability and acceptability worldwide.

Definition

Internationalization is the process of designing and coding a product so it can perform properly when it is modified for use in different languages and locales.

Localization (also known as L10N) refers to the process, on a properly internationalized base product, of translating messages and documentation as well as modifying other locale specific files.

Assuming that there is not a separate base product for the locale, the localized files are installed at their proper location in the base product. This product is then released as a localized version of the product.

Localizing a properly internationalized product in most cases should require no changes to the source code.

Internationalization testing is the process, which ensures that product's functionality is not broken and all the messages are properly externalized when used in different languages and locale. Internationalization testing is also called I18N testing, because there are 18 characters between I and N in Internationalization.

Internationalization

In I18N testing, first step is to identify all the textual information in the system. This includes all the text present on the application's GUI, any text/messages that application is producing including error message/warning and help/documentation etc.

Main focus of the I18N testing is not to find functional defects, but to make sure that product is ready for the global market. As in other non functional testing it is assumed that functional testing has been completed and all the functionality related defects are identified and removed.

I18N testing can be divided in to two parts. First, to make sure that application's GUI or functionality will not be broken with the translated text. Second to make sure that translation of all the strings have happened properly. This activity is called Translation Verification Testing and is normally conducted by person who knows the language very well.

To make sure that application's functionality or GUI will not be broken after the translation a popular technique known as pseudo-translation is used. In pseudo-translation instead of translating it completely, it is translated in a pseudo manner. For example an externalized string "Bad Command" can be translated in Japanese as [JA XXXXX Bad Command XXXXXX JA]. Now if the product is launched with locale as Japanese it should show the externalized string as given above instead of "Bad Command". There are utilities to do this job for you, to do pseudo-translation of all the externalized strings of your application. During pseudo-translation you need to make sure that you are doing it roughly according to the rule. For example, width is normally expanded up to forty percent for the pseudo-translated strings as compare to the English.

As stated above, In I18N testing focus is not on the functionality but on the translation and locale related issues. Once all the externalized strings are pseudo-translated, you need to make sure that you have test case for every message or text element present in the system. Once it is done, same set of test cases can be executed on the properly translated build to make sure that translation is proper.

Pseudo-localization

A convenient approach to internationalization testing is to use the technique of pseudo-localization. This technique simulates the process of localizing products, involving many things a localization center does when localizing a product. To pseudo-localize a product:

Pseudo-translate message files by inserting a specific prefix and suffix into every message. You can also modify localizable non-message resources, such as font names and colors. Localizable non-message resources should not be translated.
Also, other files that may be localized should be modified in some way, such as help, text, html and graphics files.

Install the pseudo-translated message files, as well as all other pseudo translated or modified files, in the locale of your choice, at the proper location in the product. In certain cases, such as for Java resource bundles, you must name the files with a locale-specific suffix and install them in the same location as other locale-specific message files.
Run the product from this locale. The messages and GUI labels should display the prefixes and suffixes you added, and not the English default messages. You should also see the behavior of the modified, localizable non-messages, and other files that were modified, like help, text, html and graphics files, will show the modified versions of these files, when run in this locale.

This approach allows you to use the product, including its menus and other GUI objects, without needing to know another language or fully translate the message files.

Many of the sections that follow take this approach.

Localization Testing

2011-04-24T14:46:00.001-07:00

Definition of Localization Testing

Localization is the process of adapting a globalized application to a particular culture/locale. Localizing an application requires a basic understanding of the character sets typically used in modern software development and an understanding of the issues associated with them. Localization includes the translation of the application user interface and adapting graphics for a specific culture/locale. The localization process can also include translating any help content associated with the application.

Localization of business solutions requires that you implement the correct business processes and practices for a culture/locale. Differences in how cultures/locales conduct business are heavily shaped by governmental and regulatory requirements. Therefore, localization of business logic can be a massive task.

Localization testing checks how well the build has been translated into a particular target language. This test is based on the results of globalized testing where the functional support for that particular locale has already been verified. If the product is not globalized enough to support a given language, you probably will not try to localize it into that language in the first place!

What we need to consider in Localization Testing?

What we need to consider in Localization Testing ?

Things that are often altered during localization, such as the UserInterface and content files.

Operating System

Keyboards

Text Filters

Hot keys

Spelling Rules

Sorting Rules

Upper and Lower case conversions

Printers

Size of Papers

Mouse

Date formats

Rulers and Measurements

Memory Availability

Voice User Interface language/accent

Video Content

Localization Testing Features

Object based Recording: Does not record based on coordinates and hence Localization testing is not affected by position change due to shorter or longer localized strings.

Centralized Object Repository: Localization testing will not be affected by textual changes as only logical name are placed in the scripts.

Unicode Support: Full Unicode support allows you to record in any language.

Automatic Resource Generator: Extracts all the string, literals and stores them in a resource file.

I18N Editor: Allows you to assign localized terms for the contents of the resource.

Powerful Library: Provides powerful libraries to get and set locales at runtime. Allows you to change the date format to suite the locale to be tested.

Purpose of Localization Testing

Products that are localized to international markets often face domestic competition, which makes it critical for the localized product to blend seamlessly into the native language and cultural landscape. The cost of a localization effort can be significant. Once you have the strings translated and the GUI updated, localization testing should be used to help ensure that the product is successfully migrated to the target market.

In addition to verifying successful translation, basic functional testing should be performed. Functional issues often arise as a result of localizing software. Don't risk the time and effort spent localizing by not performing adequate Quality Assurance.

General Areas of Focus in Localization Testing

Localization testing should focus on several general areas. The first involves things that are often altered during localization, such as the UI and content files. The second consists of culture-specific, language-specific, and country-specific areas. Examples include configurable components-such as region defaults and the default language-as well as language-specific and region-specific functionality-such as default spelling checkers, speech engines, and so on. You should also test the availability of drivers for local hardware and look for the encryption algorithms incorporated into the application. The rules and regulations for distribution of cryptographic software differ from country to country.

Pay specific attention to the customization that could not be automated through the globalization services infrastructure (Win32 NLS APIs and the .NET Framework). For example, check that formatting of mailing addresses is locale-specific and that parts of the user's name are ordered correctly. (The order in which surname and first name appear varies according to country. For instance, some Muslim countries and certain regions in India use a different name order than that used in the English language.) Functionality of this kind is often implemented by an application-testing must verify its correctness.

Other areas of localization testing should include basic functionality tests; setup, upgrade, and uninstall tests that are run in the localized environment; and, finally, application and hardware compatibility tests that are planned according to the product's target market.

Platform in Localization Testing

Any language version of Windows XP or Windows 2000 can be selected as a platform for the test if the product is properly globalized. Of course, in the case of localization testing, the localized version of the operating system can be a wise choice, since that's the most likely environment for your application in the real world. However, a globalized and localizable application, even after it undergoes localization, must be able to run on any language version of the operating system and with MUI installed.

You should run the application with MUI installed when your application implements an MUI behavior, through pluggable UI, satellite dynamic-link libraries (DLLs), or some other technique that adjusts the UI language to the user's preferences. MUI allows the user to switch the UI language of the operating system and thus you must make sure your application matches the operating-system settings. You should verify the behavior of the application when the user's default language of the UI differs from the other locale settings. By doing so, you'll immediately see any problems in the way resources are loaded and processed.

Localization Testing of the UI

Also keep an eye on the behavior of applications that run processes in a system-such as operating-system services-rather than in a user's context. When a system process queries its user default UI language settings, it might get a result different from what a user's process running at the same time will get. This can cause localization problems, inconsistency in the UI that the user sees (if parts of it are generated by the system services), or even problems in functionality. In order to avoid those problems, always check an application's behavior with different default user and system UI languages. The settings for UI languages should also be different from those used in the development environment.

For example, assume you have a machine with MUI installed and a user whose default UI language is different from that of the system. Suppose a fax service waiting for incoming calls is running continuously and that, when a fax arrives, the service displays a notification message to the currently logged user (if there is one). You must ensure that the message be in the user's language, which might not necessarily be the same as the one returned to the fax service when it queries its default UI language.

In particular, localization testing of the UI and linguistics should cover items such as:

Validation of all application resources.

Verification of linguistic accuracy and resource attributes.

Checking for typographical errors.

Checking that printed documentation, online Help, messages, interface resources, and command-key sequences are consistent with each other. If you have shipped localized versions of your product before, make sure that the translation is consistent with the earlier released versions.

Confirmation of adherence to system, input, and display environment standards.

Checking usability of the UI.

Assessment of cultural appropriateness.

Checking for politically sensitive content.

Making sure the market-specific information about your company, such as contact information or local product-support phone numbers, is updated.

Overview of Localization Testing

2011-04-24T14:40:00.000-07:00

Overview of Localization Testing

Although localization and, by extension, localization testing are not strictly a part of the development of world-ready software, localization becomes possible once you have developed world-ready software. If you do decide to localize, you should be familiar with the scope and purpose of localization testing. Localizers translate the product UI and sometimes change some initial settings to adapt the product to a particular local market.

This definitely reduces the "world-readiness" of the application. That is, a globalized application whose UI and documentation are translated into a language spoken in one country will retain its functionality. However, the application will become less usable in the countries where that language is not spoken.

Localization testing checks how well the build has been translated into a particular target language. This test is based on the results of globalized testing where the functional support for that particular locale has already been verified. If the product is not globalized enough to support a given language, you probably will not try to localize it into that language in the first place!

You should be aware that pseudo-localization, which was discussed earlier, does not completely eliminate the need for functionality testing of a localized application. When you test for localizability before you localize, the chances of having serious functional problems due to localization are slim. However, you still have to check that the application you're shipping to a particular market really works. Now you can do it in less time and with fewer resources.

Localization Testing

2011-04-24T14:39:00.000-07:00

Localization Testing

Introduction

Localization (L10N) is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. This process involves translating all native language strings to the target language and customizing the GUI so that it is appropriate for the target market. Depending on the size and complexity of the software, localization can range from a simple process involving a small team of translators, linguists, desktop publishers and engineers to a complex process requiring a Localization Project Manager directing a team of a hundred specialists. Localization is usually done using some combination of in-house resources, independent contractors and full-scope services of a localization company.

Contents:

Overview of Localization Testing

Definition of Localization Testing

Things to be consider in Localization Testing

Localization Testing Features

Purpose of Localization Testing

General Areas of Focus in Localization Testing

Platform in Localization Testing

Localization Testing of the UI

Security Testing Tutorial

2011-04-24T14:30:00.001-07:00

Security Testing Tutorial

A video on Security Testing

RDBMS Testing Concepts

2011-04-24T14:28:00.001-07:00

RDBMS Testing Concepts

Database Testing Concepts

Testing Mobile Applications - Tutorial

2011-04-24T14:25:00.001-07:00

Testing Mobile Applications - Tutorial: Mobile Application Testing Tutorial, Mobile Device Testing, Mobile Simulator Testing, Mobile Testing Tutorial, Telecom Testing

Excellent Tutorial on Mobile Application Testing. Must read.

http://www.automatedqa.com/techpapers/testcomplete/testing-pda-applications-with-testcomplete/

Mobile and hand held usability testing - why it matters

2011-04-24T14:03:00.001-07:00

Mobile phone and PDA usability testing is critical to your business. In fact, mobile and handheld usability testing could be even more important than computer-based usability testing. The main reasons for this are:

The number of people accessing the Internet from mobile and handheld devices is increasing at a massive rate - in 2008 alone there'll be an estimated 58 million PDAs sold worldwide
People generally have a lot less experience of using their mobile to go online than they do of using their computer. This means that computer-based users can be assumed to have a higher level of existing expertise than mobile and handheld users
The platform through which users access your site is far less predictable when using mobile phones. Computer-based site visitors generally only differ from one another in their browser and operating system (i.e. most people will use a screen, mouse and keyboard), whereas the different types of mobile phones and PDAs differ can drastically.

Which mobile phones and PDAs do you need to consider?

Mobile phones and PDAs can differ from one another dramatically, and this will radically change how people experience and use websites. Some of the ways in which handheld devices can differ include:

Screen size (small vs. large)
Screen layout (portrait vs. landscape)
Input device (stylus, numeric keypad, dial-wheel, QWERTY keypad)

Because the mobile phone / PDA that someone is using will have such a profound effect on their experience of your site, you should try to test with as many mobile phones and PDAs as possible.

Of course, testing with every mobile phone and PDA is impossible. Here are some ideas to help narrow down the number of devices you'll need to test with:

Your mobile site visitors may belong to a specific audience. Certain audiences tend to prefer particular types of phones (e.g. phones with big screens that are designed to support online access vs. small-screen models that aren't).
There are 'phone families' that offer a very similar user experience (and will not need to be tested individually).
You may only want to test with the most popular mobile phones in Europe² or the most popular models that are being used to access your site (you can check your site statistics to find out this information).

Where should mobile usability testing sessions be conducted?

Mobile phones and PDAs are used in the real world so usability testing of handheld devices should therefore not only take place in a usability laboratory.

Where, when and how a mobile phone is used is critical to a person's experience of the site they are accessing. Any of the following circumstances could influence this experience and therefore considerations of the site's usability:

Lighting
Background noise
Distractions
Concurrent tasks (i.e. anything the person is doing at the same time)
Physical movement

As such, we'd recommend, if possible, that any mobile phone and PDA usability testing is conducted both in a laboratory and also in the 'outside world'.

How you plan and run mobile phone usability sessions will be based on your business and its audience, but the most popular methods of mobile usability testing include:

Lab-based (using a camera to record the session)
Diary-studies (asking people to keep a diary of how they have used their mobile phone and any problems they encounter)
Paper prototypes (running usability testing on a paper-based version of the site, using mobile phone screen-sized pieces of paper)

What is Mobile Device Testing??

2011-04-24T13:55:00.001-07:00

Mobile Device Testing is the process to assure the quality of mobile devices, like mobile phones, PDAs, etc. The testing will be conducted on both hardware and software. And from the view of different procedures, the testing comprises R&D Testing, Factory Testing and Certificate Testing.

R&D Testing

R&D test is the main test phase for mobile device, and it happens during the developing phase of the mobile devices. It contains hardware testing, software testing, and mechanical testing.

Factory Testing

Factory Testing is a kind of sanity check on mobile devices. It's conducted automatically to verify that there are no defects brought by the manufacturing or assembling.

Mobile Testing contains

Mobile application testing Hardware testing

 Battery(Charging) Testing
 Signal receiving 
 Network Testing

Protocol testing mobile games Testing Mobile software compatibility Testing.

Certification Testing

Certification Testing is the check before a mobile device goes to market. Many institutes or governments require mobile devices to conform with their stated specifications and protocols to make sure the mobile device will not harm users' health and are compatible with devices from other manufacturers. Once the mobile device passes all checks, a certification will be issued for it.

Source: Wekipedia

Top 10 myths about job interviews

2011-04-19T05:26:00.000-07:00

Here is his list of the top 10 job interview myths, and how to deal with them:

Myth #10: The interviewer is prepared.

"The person you're meeting with is probably overworked and stressed about having to hire someone," Couper says. "So make it easy for him or her. Answer that catchall request, 'Tell me about yourself", by talking about why you're a great fit for this job. If it's obvious they haven't read your resume, recap it briefly, and then tie it to the job you want." Tell them what they really need to know, so they don't have to come up with more questions.

Myth #9: Most interviewers have been trained to conduct thorough job interviews.

While human resources professionals do get extensive training in job interviewing techniques, the average line manager is winging it. "To make up for vague questions, be specific even if they don't ask," Couper suggests. "Be ready with two or three examples of particular skills and experiences that highlight why they should hire you."

Myth #8: It's only polite to accept an interviewer's offer of refreshment.

"They usually try to be courteous and offer you a drink, but they don't really want to bother with it," says Couper. "Unless the beverage in question is right there and won't take more than a second to get, just say, no, thank you."

Couper once interviewed a job candidate who said she would love a cup of tea, which, he recalls, "meant I spent half the allotted interview time looking for a tea bag, heating water, and so on. It was irritating."

Another good reason, Couper says, to decline caffeine is that "if the interview is a lengthy one, you don't want to need a restroom halfway through the conversation."

Myth #7: Interviewers expect you to hand over references' contact information right away.

Hold off until you're specifically asked, Couper advises, and even then, you can delay a bit by offering to send the information in an email in a day or two. There are at least two good reasons for not rushing it, Couper says. First, "you sometimes don't know until the end of the interview who would be the best references for this particular job," he notes. "If you get a sense that the interviewer cares most about, for instance, teamwork, you want to choose someone who can attest to your skills in that area. A reference who can only talk about some other aspect of your work is not going to help."

Second, and no less important, "you want a little time to prep your references, by gently coaching them on what you'd like them to say, before the employer calls them."

Myth #6: There's a right answer to every question an interviewer asks.

"Sometimes how you approach your answer is far more important than the answer itself," Couper says. If you're presented with a hypothetical problem and asked how you would resolve it, try to think of a comparable situation from the past and tell what you did about it.

Talkback: Has anything surprised you during a job interview? Leave a comment at the bottom of this story.

Myth #5: You should always keep your answers short.

Here's where doing lots of research before an interview really pays off. "The more you've learned about the company and the job beforehand, the better able you are to tell why you are the right hire," Couper says.

Don't be afraid to talk at length about it, partly because it will spare the interviewer having to come up with another question for you (see Myth #1 above) and partly because "in a good interview, you should be talking about two-thirds of the time."

Myth #4: If you've got great qualifications, your appearance doesn't matter.

Reams of research on this topic have proven that physical attractiveness plays a big part in hiring decisions. "Anyone who says otherwise is lying," Couper says. "People care about your looks, so make the absolute most of what you've got." Even if you're not drop-dead gorgeous, it's impossible to overestimate the importance of looking "healthy, energetic, and confident."

Myth #3: When asked where you see yourself in five years, you should show tremendous ambition.

The five-year question is a common one, and it's uncommonly tricky. "Interviewers want you to be a go-getter, but they also worry that you'll get restless if you don't move up fast enough. So you want to say something that covers all bases, like, 'I'd be happy to stay in this job as long as I'm still learning things and making a valuable contribution,'" says Couper.

You might also consider turning the question around and asking, "Where do you see me in five years?" Says Couper, "Sometimes the answer to that -- like, 'Well, we'd expect you to keep doing the same thing we hired you to do' -- is a good way to spot a dead-end job."

Myth #2: If the company invites you to an interview, that means the job is still open.

Alas, no. In fact, the job may never have existed in the first place: "Some companies use 'interviews' to do market research on the cheap. They ask you about your current or recent duties, your pay scale, and so on, to get information for comparison purposes." Another possibility, Couper says, is that "they may already have a strong internal candidate in mind for the job but just want to see if they come across someone better."

If you get an interview through a networking contact, he adds, "an employer may interview you simply as a courtesy to the person who referred you, if that is someone they don't want to disappoint."

Even if the job opening is phony, it's still worth going, he says: "Sometimes they discover you're a good fit for a different opening that really does exist. You never know where an interview might lead."

And the #1 myth about job interviewing: The most qualified person gets the job.

In at least one crucial respect, a job interview is like a date: Chemistry counts.

"A candidate who is less qualified, but has the right personality for the organization and hits it off with the interviewer, will almost always get hired over a candidate who merely looks good on paper," Couper says.

What can you do if you suspect you're not knocking an interviewer's socks off?

"At the end of the discussion, you'll probably be asked if you have any questions," Couper says. "If you sense the person has reservations about your style, ask what the ideal candidate for this job would be like." Then think fast. Can you talk a bit about how you fit that profile? "Addressing any concerns the interviewer might have, beyond your formal qualifications, is your chance to seal the deal," Couper says.

Interviews – Stop thinking aloud. Start thinking, Channelize your thoughts and Reply…

2011-04-13T07:08:00.001-07:00

Some of the questions that were asked in Testing interviews are:-

"How do you test a pen?", "How do you test a mobile?", "How do you test a remote controller?", "How do you test a random number generator?", "How do you test an application that generates the fibonacci series?" etc.

When I asked them "How do you plan your testing for a website selling mobile phones, interacting with 3 suppliers?", none of them paused to think. The answer came immediately like below.

"I'd plan for sanity testing. Will plan for testing the site against XYZ interfaces. L&P Testing needs to be a part of the test plan. I'll have daily stand-ups. I will talk about cost and variances to think about estimation. I'll have a risk plan for managing risks proactively. I will do a requirements-traceability-matrix..."... and he'd go on and on and on.

After talking to many candidates, it struck me that most of them, when answering the above questions, did not pause to think; or ask for time to think. Though it seemed that they were answering the question, they were only "thinking out their thoughts aloud".

Thinking a bit more, I guess the best way to answer such questions, in an interview would be in the following 4 steps:

STEP 1:- Think.
Ponder about the question for a minute and think about the answers and various possibilities for the next couple of mins and speak up when you are prepared to answer. If you want more time, please ask the interviewer for time.

STEP 2:- Channelize your thoughts.
Think about the solution and channelize your thoughts to ensure that your answer is structured correctly, or how you want it to be structured. A structured answer, will definitely earn you a lot of brownie points with your future employer. If you want, write down short points on paper before you start talking about the answer

STEP 3:- Prioritize the reply and speak it out accordingly.
Go ahead and speak up and start answering the question. If required, refer to the short points while you answer. If you need more time to think, please ask for more time.

STEP 4:- Invite him for discussion on your reply
Ask if the interviewer has any questions or invite him to discuss the finer points of your answer. Try to give logical reasons for your decisions for prioritizing.

--------------------------------------------------------

visit www.nuve.info

--------------------------------------------------------

Are You a Fresher or Freelancer ? Try Beta Testing !

2011-04-13T06:23:00.001-07:00

Are You a Fresher or Freelancer ? Try Beta Testing !

What is a beta testing?

A Beta test is a testing done for a piece of computer product prior to commercial release in the market. Beta testing can be considered the last stage of testing, and normally can involve sending the product to beta test sites outside the company for real-world exposure. Normally, a free trial version of the product is allowed to be downloaded over the Internet. Beta test versions of software are distributed to a wide range of users to get the software tested in different combination of hardware and associated software.

What is in for a fresher or freelancer?

So what should we do as a fresher or a freelance software tester? Beta testing provides a platform for us to test some real world software. There are many companies which release beta version of their software before they ship it to the market for commercial selling.

By signing up as a beta tester and downloading a test version of the software, you can get a first hand preview of the software. It is an exciting experience to get the software free of cost before the world gets to see the product. If you can find few bugs or write some reviews (positive or negative) about the beta version of the software, most of the companies give a free licensed version of the product when they release in the market.

Benefits of beta testing to a fresher?

Also as a fresher, you can show this experience of testing a beta product. You can list down what all defects or bugs you have submitted to the company. There are few companies which I know who pay for finding bugs in there products. Your resume will shine if you can prove that you earned few dollars by finding bugs for this and that company.

uTest.com

Sign Up with uTest.com and get paid for finding bugs. I am sure there are lots of other companies which pay for pointing out their defects.

Beta products from Microsoft

Microsoft also provides wide range of Beta software for testing. Sign up with them and start testing a free beta product today.

Here are some tips for running a Beta Test

Take back up of your PC before you install a Beta version software. You never know when the software crashes.
Read the terms and conditions carefully. Find out which bugs have already been reported. You don't want to waste time finding bugs which someone has already reported.
Get the specification or requirement document first. How do you test a product if you don't know what it is supposed to do?
Create a network of Beta Testers. This will help you get informed of latest happenings around the world.

***Happy Testing***

www.nuve.info

Testing Glossary - 100 Most Popular Software Testing Terms

2011-04-13T06:19:00.001-07:00

Are you confused of testing terms and acronyms? Here are few glossaries that might help you. Here are 100 most popular testing terms compiled from International Software Testing Qualifications Board's website. A complete and exhaustive list of terms is available for download at that site.

100 Most Popular Software Testing Terms
Acceptance testing	Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.
Ad hoc testing	Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity.
Agile testing	Testing practice for a project using agile methodologies, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm.
Alpha testing	Simulated or actual operational testing by potential users/customers or an independent test team at the developers' site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing.
Back-to-back testing	Testing in which two or more variants of a component or system are executed with the same inputs, the outputs compared, and analyzed in cases of discrepancies.
Beta testing	Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire feedback from the market.
Big-bang testing	A type of integration testing in which software elements, hardware elements, or both are combined all at once into a component or an overall system, rather than in stages.
Black-box testing	Testing, either functional or non-functional, without reference to the internal structure of the component or system.
Black-box test design technique	Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.
Blocked test case	A test case that cannot be executed because the preconditions for its execution are not fulfilled.
Bottom-up testing	An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested.
Boundary value	An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or maximum value of a range.
Boundary value analysis	A black box test design technique in which test cases are designed based on boundary values.
Branch testing	A white box test design technique in which test cases are designed to execute branches.
Business process-based testing	An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes.
Capture/playback tool	A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.
Certification	The process of confirming that a component, system or person complies with its specified requirements, e.g. by passing an exam.
Code coverage	An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage.
Compliance testing	The process of testing to determine the compliance of the component or system.
Component integration testing	Testing performed to expose defects in the interfaces and interaction between integrated components.
Condition testing	A white box test design technique in which test cases are designed to execute condition outcomes.
Conversion testing	Testing of software used to convert data from existing systems for use in replacement systems.
Data driven testing	A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution tools such as capture/playback tools.
Database integrity testing	Testing the methods and processes used to access and manage the data(base), to ensure access methods, processes and data rules function as expected and that during access to the database, data is not corrupted or unexpectedly deleted, updated or created.
Defect	A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.
Defect masking	An occurrence in which one defect prevents the detection of another.
Defect report	A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function.
Development testing	Formal or informal testing conducted during the implementation of a component or system, usually in the development environment by developers.
Driver	A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system.
Equivalence partitioning	A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.
Error	A human action that produces an incorrect result.
Error guessing	A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them.
Exhaustive testing	A test approach in which the test suite comprises all combinations of input values and preconditions.
Exploratory testing	An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.
Failure	Deviation of the component or system from its expected delivery, service or result.
Functional test design technique	Procedure to derive and/or select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure.
Functional testing	Testing based on an analysis of the specification of the functionality of a component or system.
Functionality testing	The process of testing to determine the functionality of a software product.
Heuristic evaluation	A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called "heuristics").
High level test case	A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available.
ISTQB	International Software Testing Qualification Board. Click here for more details.
Incident management tool	A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of incidents and provide reporting facilities.
Installability testing	The process of testing the installability of a software product.
Integration testing	Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
Isolation testing	Testing of individual components in isolation from surrounding components, with surrounding components being simulated by stubs and drivers, if needed.
Keyword driven testing	A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control script for the test.
Load testing	A test type concerned with measuring the behavior of a component or system with increasing load, e.g. number of parallel users and/or numbers of transactions to determine what load can be handled by the component or system.
Low level test case	A test case with concrete (implementation level) values for input data and expected results. Logical operators from high level test cases are replaced by actual values that correspond to the objectives of the logical operators.
Maintenance testing	Testing the changes to an operational system or the impact of a changed environment to an operational system.
Monkey testing	Testing by means of a random selection from a large range of inputs and by randomly pushing buttons, ignorant on how the product is being used.
Negative testing	Tests aimed at showing that a component or system does not work. Negative testing is related to the testers' attitude rather than a specific test approach or test design technique, e.g. testing with invalid input values or exceptions.
Non-functional testing	Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability.
Operational testing	Testing conducted to evaluate a component or system in its operational environment.
Pair testing	Two persons, e.g. two testers, a developer and a tester, or an end-user and a tester, working together to find defects. Typically, they share one computer and trade control of it while testing.
Peer review	A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical review and walkthrough.
Performance testing	The process of testing to determine the performance of a software product.
Portability testing	The process of testing to determine the portability of a software product.
Post-execution comparison	Comparison of actual and expected results, performed after the software has finished running.
Priority	The level of (business) importance assigned to an item, e.g. defect.
Quality assurance	Part of quality management focused on providing confidence that quality requirements will be fulfilled.
Random testing	A black box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performance.
Recoverability testing	The process of testing to determine the recoverability of a software product.
Regression testing	Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
Requirements-based testing	An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.
Re-testing	Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
Risk-based testing	An approach to testing to reduce the level of product risks and inform stakeholders on their status, starting in the initial stages of a project. It involves the identification of product risks and their use in guiding the test process.
Severity	The degree of impact that a defect has on the development or operation of a component or system.
Site acceptance testing	Acceptance testing by users/customers at their site, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes, normally including hardware as well as software.
Smoke test	A subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. A daily build and smoke test is among industry best practices.
Statistical testing	A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases.
Stress testing	Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.
Stub	A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component.
Syntax testing	A black box test design technique in which test cases are designed based upon the definition of the input domain and/or output domain.
System integration testing	Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet).
System testing	The process of testing an integrated system to verify that it meets specified requirements.
Test automation	The use of software to perform or support test activities, e.g. test management, test design, test execution and results checking.
Test case specification	A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item.
Test design specification	A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases.
Test environment	An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test.
Test harness	A test environment comprised of stubs and drivers needed to execute a test.
Test log	A chronological record of relevant details about the execution of tests.
Test management tool	A tool that provides support to the test management and control part of a test process. It often has several capabilities, such as testware management, scheduling of tests, and the logging of results, progress tracking, incident management and test reporting.
Test oracle	A source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark), a user manual, or an individual's specialized knowledge, but should not be the code.
Test plan	A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.
Test strategy	A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).
Test suite	A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.
Testware	Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing.
Thread testing	A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy.
Top-down testing	An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.
Traceability	The ability to identify related items in documentation and software, such as requirements with associated tests. See also horizontal traceability, vertical traceability.
Usability testing	Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions.
Use case	A sequence of transactions in a dialogue between a user and the system with a tangible result.
Use case testing	A black box test design technique in which test cases are designed to execute user scenarios.
Unit test framework	A tool that provides an environment for unit or component testing in which a component can be tested in isolation or with suitable stubs and drivers. It also provides other support for the developer, such as debugging capabilities.
Validation	Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.
Verification	Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.
Vertical traceability	The tracing of requirements through the layers of development documentation to components.
Volume testing	Testing where the system is subjected to large volumes of data.
Walkthrough	A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content.
White-box testing	Testing based on an analysis of the internal structure of the component or system.

Software Testing Jokes/Humour - The case of poor Boundary Value Analysis

2011-04-13T06:08:00.001-07:00

The case of poor Boundary Value Analysis

In September 2005, a man living in Gurgaon near New Delhi, India, received a bill for his as yet unused credit card stating that he owed Rs.0/-. He ignored it and threw it away.

In April, he received another and threw that one away too.

The following month, the credit card company sent him a very nasty note stating they were going to cancel his card if he didn't send them Rs.0/- by return of post. He called them and talked to them; they said it was a computer error and told him they'd take care of it.

The following month, our hero decided that it was about time that he tried out the troublesome credit card figuring that if there were purchases on his account it would put an end to his ridiculous mess. However, in the first store that he produced his credit card in payment for his purchases, he found that his card had been cancelled.

He called the credit card company who apologized for the computer error once again and said that they would take care of it. The next day he got a bill for Rs.0/- stating that payment was now overdue. Assuming that, having spoken to the credit card company only the previous day, the latest bill was yet another mistake, he ignored it, trusting that the company would be as good as their word and sort the problem out.

The next month, he got a bill for Rs.0/- stating that he had 10 days to pay his account or the company would have to take steps to recover the debt.

Finally giving in, he thought he would play the company at their own game and mailed them a cheque for Rs.0/-. The computer duly processed his account and returned a statement to the effect that he now owed the credit card company nothing at all.

A week later, the man's bank called him asking him what he was doing writing a cheque for Rs.0/-. After a lengthy explanation, the bank replied that the Rs.0/- cheque had caused their cheque processing software to fail.

The bank could now not process ANY cheques from ANY of their customers that day because the cheque for Rs.0/- was causing the bank's computer to crash.

The following month, the man received a letter from the credit card company claiming that his cheque had bounced and that he now owed them Rs.0/- and unless he sent a cheque by return of post, they would be taking steps to recover the debt.

The man, who had been considering buying his wife a computer for her birthday, bought her a typewriter instead.

Software Testing Jokes/Humor - Who Is Who?

2011-04-13T06:06:00.001-07:00

Who Is Who?

A Project Manager is the one who thinks 9 women can deliver a baby in 1 month.
An Onsite Coordinator is the one who thinks 1 woman can deliver 9 babies in 1 month.
A Developer is the one who thinks it will take 18 months to deliver 1 baby.
A Marketing Manager is the one who thinks he can deliver a baby even if no man and woman are available.
A Client is the one who doesn't know why he wants a baby.
A Tester is the one who always tells his wife that this is not the right baby.

Software Testing Jokes/Humor -The ‘Height’ Of A Flagpole

2011-04-13T06:04:00.000-07:00

The 'Height' Of A Flagpole

A group of managers were given the assignment of measuring the height of a flagpole. So they go out to the flagpole with ladders and tape measures and they're struggling to get the correct measurement; dropping the tape measures and falling off the ladders.

A tester comes along and sees what they're trying to do, walks over, pulls down the flagpole, lays it flat, measures it from end to end, gives the measurement to one of the managers and walks away.

After the tester is gone, one manager turns to another and laughs, "Isn't that just like a tester? We're looking for the height and he gives us the length."

Funny Testing Definition

2011-04-13T00:12:00.000-07:00

Testing Definition

To tell somebody that he is wrong is called criticism. To do so officially is called testing.

he Glass

To an optimist, the glass is half full.
To a pessimist, the glass is half empty.
To a good tester, the glass is twice as big as it needs to be.

Signs That You're Dating A Tester

Your love letters get returned to you marked up with red ink, highlighting your grammar and spelling mistakes.
When you tell him that you won't change something he has asked you to change, he'll offer to allow you two other flaws in exchange for correcting this one.
When you ask him how you look in a dress, he'll actually tell you.
When you give him the "It's not you, it's me" breakup line, he'll agree with you and give the specifics.
He won't help you change a broken light bulb because his job is simply to report and not to fix.
He'll keep bringing up old problems that you've since resolved just to make sure that they're truly gone.

Alpha and Beta Testing

2011-04-12T08:00:00.001-07:00

Alpha and Beta Testing

ALPHA - Software undergoes alpha testing as a first step in getting user feedback. Alpha is Latin for "doesn't work."
BETA - Software undergoes beta testing shortly before it's released. Beta is Latin for "still doesn't work."

General Interview Questions

2011-04-12T07:54:00.000-07:00

General Interview Questions

1. Tell me something about yourself.
2. Why did you leave your last job? Why do you want to change your job?
3. What experience do you have in this field?
4. Do you consider yourself successful?
5. What do co-workers say about you?
6. What do you know about this organization?
7. What have you done to improve your knowledge in the last year?
8. Are you applying for other jobs?
9. Why do you want to work for this organization?
10. Do you know anyone who works for us?

11. What kind of salary do you expect?
12. Are you a team player?
13. How long would you expect to work for us if hired?
14. Have you ever had to fire anyone? How did you feel about that?
15. What is your philosophy towards work?
16. If you had enough money to retire right now, would you?
17. Have you ever been asked to leave a position?
18. Explain how you would be an asset to this organization.
19. Why should we hire you?
20. Tell me about a suggestion you have ma

21. What irritates you about co-workers?
22. What is your greatest strength?
23. Tell me about your dream job.
24. Why do you think you would do well at this job?
25. What are you looking for in a job?
26. What kind of person would you refuse to work with?
27. What is more important to you: the money or the work?
28. What would your previous supervisor say your strongest point is?
29. Tell me about a problem you had with a supervisor.
30. What has disappointed you about a job?

31. Tell me about your ability to work under pressure.
32. Do your skills match this job or another job more closely?
33. What motivates you to do your best on the job?
34. Are you willing to work beyond normal work hours, and on weekends?
35. How would you know you were successful on this job?
36. Would you be willing to relocate if required?
37. Are you willing to put the interests of the organization ahead of your own?
38. Describe your management style.
39. What have you learned from mistakes on the job?
40. Do you have any blind spots?

41. If you were hiring a person for this job, what would you look for?
42. Do you think you are overqualified for this position?
43. How do you propose to compensate for your lack of experience?
44. What qualities do you look for in a boss?
45. Tell me about a time when you helped resolve a dispute between others.
46. What position do you prefer on a team working on a project?
47. Describe your work ethic.
48. What has been your biggest professional disappointment?
49. Tell me about the most fun you have had on the job.
50. Do you have any questions for me?

Software Testing Interview Questions

2011-04-12T07:51:00.000-07:00

Software Testing Interview Questions

A software tester should be able explain the questions by applying what he learnt in his organization. These are frequently asked questions that you may likely to face if you attempt to sit for a job change interview.

1. Tell me something about yourself?
2. Tell me about your current project?
3. What is your primary role in your project?
4. What is your daily routine in your office?
5. What is the end to end process that is followed in your project?
6. What is a test plan and who prepares it?
7. How do you make sure that you have understood the entire requirement given by the client?
8. What do you do when you find something wrong in the requirement?
9. What is a traceability matrix, and what is the purpose of it?
10. What do you do when you received a build?
11. What is the difference between retesting and regression?
12. Why do you do sanity and regression and what is the difference?
13. How do you write test cases?
14. How can we test without requirements?
15. How do we know all scenarios are covered in test cases?
16. What is role of a tester in the requirement phase?
17. If the release date is only one day left, how you will test the product in one day?
18. What is the review process that is followed in your project/organisation?
19. What is the test environment and sets in up in your project?
20. How do you report a bug?
21. What is a bug life cycle?
22. What are severity and priority?
23. Who decides severity and priority?
24. How do you know something is a bug?
25. Which is the most important bug you have reported so far?
26. Tell me an example of high severity but low priority bug?
27. Tell me an example of low severity but high priority bug?
28. What are the test case design techniques that you know?
29. Tell me about boundary value analysis with an example
30. What is equivalence partitioning?
31. How do you reduce the number of test cases?
32. When do you say your product ready for release?
33. What is suspension and resumption criteria in test plan?
34. Which all major fields/information are required when reporting a defect?
35. What is difference between static and dynamic testing?
36. What is the difference between system testing and functional testing?
37. What are Alpha and Beta testing?
38. What are verification and validation?
39. What is monkey testing and why it is necessary?
40. What is pesticide paradox?
41. If you report a bug, and developer says that this is not a bug, how would you handle such situation?
42. What is performance testing?
43. What is the difference between load and stress testing?
44. What is gorilla testing?
45. How many types of integration testing strategies are there?
46. What are stubs and drivers in integration testing?
47. When can we go for automation testing?
48. What is parameterization in automation testing?
49. What is correlation in performance testing?
50. How do you perform installation testing?
51. What is usability testing?
52. What are virtual users in performance testing?
53. How does system testing differ from integration testing?
54. What are CMMI levels?
55. What is the difference between inspection and walkthrough?
56. What are the code coverage tools?
57. What are Testing Effectiveness (TE) and Defect Removal Efficiency (DRE)?
58. Who are PQA, DPA and CC in a project?
59. Can automation replace manual testing and manual testing replace automation testing?
60. What is defect masking?
61. Which Estimation Model is used for your project work?
62. Who assigns work in your project and how?
63. Why do you want to change your job?
64. Do you have any problem in working late nights or on weekends?

65. Do you have any experience in managing a software testing project?

Vasuna.vb.testing, Win Rs. 50,000 this march!

2011-04-11T09:14:00.000-07:00

CLICK HERE TO REPORT SPAM CLICK HERE TO SAFELY UNSUBSCRIBE

Get Free Mobile Recharge!

and others

Hey Vasuna.vb.testing,

Venu Naik has invited you to join YouMint, where you can get Free mobile recharge instantly!

50 Lakh members already trust and love YouMint!
- Get Free Mobile Recharge on ALL operators in India!
- Send Free SMS worth Rs 900 monthly!

And if you join within 48 hours of this invite, you could
- Win Rs 50,000 - Totally Tax Free!
- Get upto Rs 100 for every friend who joins 'The Legaue'!

Join Here: http://youmint.com/bigbash-nuve1284

Cheers
Venu Naik

SoftWare TestinG

Does Quality Assurance Remove Need for Quality Control?

How to Test Application Security – Web and Desktop Application Security Testing Techniques

Examples of security flaws in an application:

Security Testing Techniques:

1) Access to Application:

2. Data Protection:

3. Brute-Force Attack:

4. SQL Injection and XSS (cross site scripting):

5. Service Access Points (Sealed and Secure Open)

Vasuna.vb.testing, Win Rs. 50,000 this august!

What is difference between Performance Testing, Load Testing and Stress Testing?

Q. What is difference between Performance Testing, Load Testing and Stress Testing?

1) Performance Testing:

2) Load Testing:

3) Stress testing

Database Testing – Practical Tips and Insight on How to Test Database

What to test in database testing:

1) Ensure data mapping:

2) Ensure ACID Properties of Transactions:

3) Ensure Data Integrity:

4) Ensure Accuracy of implemented Business Rules:

How To Test Database:

1. Create your own Queries

2. Observe data table by table

3. Get query from developer

Conclusion:

Failover and Recovery Testing

Design-Based Test Case Design an Effective Software Testing Technique

Documentation Errors

Error Description

Header Error

Problem Description

An example from the life

Attachments

Link

Screenshots

Videos

See Also

Top 10 negative test cases

localization testing tips and tricks

Requirements Testing

Requirements Testing

The Importance of “Hands-On” Mobile App Testing

Top 10 Reasons to Become a Mobile App Tester

Mobile Functional Testing: Manual or Automated?

Mobile Functional Testing: Manual or Automated?

Software Cost Estimation

Software Cost Estimation

Risk Analysis in Software Testing

Risk Analysis

Technical Definitions:

Product Size Risks:

Business Impact Risks:

Customer-Related Risks:

Process Risks:

Technical Issues:

Technology Risk:

Development Environment Risks:

Risks Associated with Staff Size and Experience:

Metrics Used In Software Testing

Metrics Used In Testing

The Product Quality Measures:

Metrics for Evaluating Application System Testing:

Internationalization Testing

Introduction

Contents:

Definition

Internationalization

Pseudo-localization

Localization Testing

Definition of Localization Testing

What we need to consider in Localization Testing?

Localization Testing Features

Purpose of Localization Testing

General Areas of Focus in Localization Testing

Platform in Localization Testing

Localization Testing of the UI

Overview of Localization Testing

Overview of Localization Testing