Pure Test - Software Testing Tutorial

2009-11-10T01:44:00.000-08:00

Software Testing

Testing is a process to find bugs, find them as early as possible, and make sure they get fixed.

Testing Types
1. White box testing (Also known as Clear Box Testing, Glass Box Testing, Open Box Testing and Structural Testing): Used to test internal based application.

2. Black box testing (Also known as Skin Box Testing, Closed Box Testing and Behavioral Testing): Used to test functional based or requirement based application.

3. Gray box testing: Used to test web applications. It is a combination of both White box & Black box testing.

Testing Techniques (Testing approach)

The most popular Black box testing techniques are:
1. Equivalence Partitioning
2. Boundary Value Analysis
3. Cause-Effect Graphing
4. Error-Guessing

The White-Box testing techniques are:
1. Statement coverage
2. Decision coverage
3. Condition coverage
4. Decision-condition coverage
5. Multiple condition coverage
6. Basis Path Testing
7. Loop testing
8. Data flow testing

Software Testing Check List

Sometimes testers confused when they have assigned any testing task for any product. They dont know from where they should start the testing. To keep this in mind, I have collected information from many websites. Also I have put my inputs and updated the information in simple form. I have created a Checklist for website testing as well as Checklist for Desktop application Testing.

Checklist covers the following points:
Step 1 - User Interface Testing (GUI Testing)
Step 2 - Functionality Testing
Step 3 - Interface Testing
Step 4 - Compatibility Testing
Step 5 - Security Testing
Step 6 - Performance testing

Responsibilities of a Tester

a. Understand project requirements.
b. Develops and implements Test Plans that will address the testing needs of functional, regression, integration and system testing.
c. Update Test Case document.
d. Conduct Testing including Smoke, Sanity, and Execute the Test cases.
e. Update the Test Result document.
f. Attend the Regular client calls.
g. Log / File the defects in Defect tracking tool / Bug Report.
h. Verify defects.
i. Discuss doubts/queries with Development Team / Client.
j. Implements software quality assurance standards and processes.
k. Participates in design reviews/walkthroughs for projects.
l. Other duties that are within education and experience or the incumbent may be assigned for the betterment of the company.

Related Testing Topics
a. Agile Testing
b. Black Box testing
c. Testing for Biginners
d. Smartphone Testing

2009-11-10T00:02:00.001-08:00

QA, QC & Testing

Testing is often confused with the processes of quality control and quality assurance. Testing is the process of creating, implementing and evaluating tests. If you are shopping for a new television, you can call that process "testing for the best TV for you"... it's kind of pretentious, but that is what you're doing as you compare prices and features to find what will work best for you. Testing usually has a limited scope and duration – you're just looking at TVs, and only in your town, you're not going to spend a year shopping, are you?

Quality control is a refinement of testing, involving the formal and systematic use of testing and a precise definition of what quality means for the purposes of the test. You aren't just testing; you are testing and then doing something with the results. Quality control is used for testing a product or output of a process, with the test measuring the subject's ability to meet a certain benchmark or threshold of quality. The tests usually take the form of "does this product meet requirement X?", and are often pass-fail. Testing -- and by extension quality control -- is reactive; that is, you test to find deviations from a standard. If you systematically employ a formal battery of tests on a consistent schedule, you will be able to pass a product with fairly stable quality. The shortcoming here is that this kind of testing does nothing to improve the quality of output; as far as user-experience is concerned, you're just running in place. Testing and quality control does nothing to raise the level of quality beyond perhaps tweaking the standard to "raise the bar".

Quality assurance goes beyond quality control to examine the processes that create and shape the product: quality assurance looks at the quality of output, as well as at the quality of the inputs.

QA Vs Testing

QA is traditionally responsible for the measurement and auditing of the processes used to make a product. Not only is a Quality Assurance "team" not the same as a test team, they shouldn't even exist in the same organization. Quality Assurance evaluates or establishes processes, sets up measurement programs to evaluate processes, and identifies weaknesses in those processes so that the errors do not happen again. This includes analyzing the tools, metrics, and processes used by Program Management (including specification processes), Development, and Testing.

The industry has created laughable titles like SQA Tester which make no sense to me. I looked at monster.com recently for QA positions (I'm happy here, but I like to know what's out there), and virtually every "QA" position is really a testing position.

Related Testing Topic
a. Black Box testing

Software Testing Techniques

2009-11-10T00:01:00.001-08:00

Black box testing techniques
a. Equivalence Partitioning.
b. Boundary Value Analysis.
c. Cause-Effect Graphing.
d. Error-Guessing.

Equivalence Partitioning

Equivalence partitioning is a software testing related technique with the goal:
1. To reduce the number of test cases to a necessary minimum.
2. To select the right test cases to cover all possible scenarios.
Following example of a function has the pass parameter "month" of a date. The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.

........ -2 -1 0 1 ....................... 12 13 14 15 ...............
------------------------------------------------------
invalid partition 1 valid partition invalid partition 2

It is sufficient to select one test case out of each partition to check the behavior of the program. The values within one partition are considered to be "equivalent". Thus the number of test cases can be reduced considerably. Equivalence partitioning is no stand alone method to determine test cases. It has to be supplemented by boundary value analysis.

Boundary Value Analysis
Boundary value analysis is a software testing related technique to determine test cases covering known areas of frequent problems at the boundaries of software component input ranges.

To set up boundary value analysis test cases you first have to determine which boundaries you have at the interface of a software component. This has to be done by applying the equivalence partitioning technique. Boundary value analysis and equivalence partitioning are inevitably linked together. For the example of the month in a date you would have the following partitions:

......... -2 -1 0 1 ...................... 12 13 14 15 .....
-------------- ---------------------------------------
invalid partition 1 valid partition invalid partition 2

Applying boundary value analysis you have to select now a test case at each side of the boundary between two partitions. The boundary value analysis can have 6 text cases: n,n-1,n+1 for the upper limit and n,n-1,n+1 for the lower limit.

White-Box testing techniques
a. Statement coverage
b. Decision coverage
c. Condition coverage
d. Decision-condition coverage
e. Multiple condition coverage
f. Basis Path Testing
g. Loop testing
h. Data flow testing

Related Testing Topic
a. Black Box testing

2009-11-10T00:00:00.007-08:00

Negative Testing

1) Testing the application for fail conditions, negative testing is testing the tool with improper inputs.for example entering the special characters for phone number.

2) Testing aimed at showing software does not work. Also known as "test to fail".

3) Negative testing is testing that is directed to showing that something will -not- work. It's such a natural part of regular testing that I doubt that most people know that there is both a "positive" and "negative" testing.

4) Negative Testing is simply testing the application beyond and below of its limits. For example:
A) We want to enter a name for that negative test can be first we enter numbers.
B) We enter some ASCII characters and we will check
C) First numbers and characters we will check
D) Name should have some minimum length below that we will check

5) Negative testing is testing the tool with improper inputs. For example entering the special characters for phone number.

6) Negative testing is kind of testing doing with the Boundary values, may be max val and min val or with some other kind of data type input etc.

7) Testing the application for fail conditions.

8) here we test if system is doing something which it is not supposed to do ex in password field we try to enter only alphabets were as in requirement it is specified password should have at least 1 no, if it accepts only alphabets then test case is fail otherwise it's pass.

9) Negative testing is testing an application giving invalid data, for example entering wrong user id or wrong password to make the test unacceptable.

10) Negative testing is testing the application with negative assumptions and navigations to get a negative result which leads to positive one.

11) This is a type of testing which is done by tester's to make sure that the system works fine for the Inputs which the code dosen't designed for.

12) Negative testing is a testing which ensures that the application should not do what it is not supposed to do.

13) Negative testing is performed to check how the application works if an unexpected input is given which is out of requirements, to check the stability of the application. "For a error to be thrown it doesn’t throw error and error shouldn’t thrown it throws an error".

14) Testing the application for fail conditions, negative testing is testing the tool with improper inputs.for example entering the special characters for phone number.

15) Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.

16) In negative testing, we check whether the application or system handles the exception properly or not. It is nothing but "Test to Break" testing.

Related Testing Topic
a. Black Box testing

2009-11-10T00:00:00.005-08:00

Software Testing Quotes

1. To find the bugs that customers see - that are important to customers - you need to write tests that cross functional areas by mimicking typical user tasks. This type of testing is called scenario testing, task-based testing, or use-case testing.

2. Testing a product is a learning process.

3. If the date is missed, the schedule was wrong. It doesn't matter why the date was missed. The purpose of the schedule was planning, not goal-setting.

4. Exploratory testing can be described as a martial art of the mind. It's how you deal with a product that jumps out from the bushes and challenges you to a duel of testing. Well, you don't become a black belt by reading books. You have to work on it. Happy practising.

5. The only person who likes change is a wet baby.

6. A fool with a tool is still a fool.

7. Quality is free, but only to those who are willing to pay heavily for it.

8. Ever Tried. Ever failed. No matter. Try again. Fail again. Fail better.

9. A day lost at the beginning of a project hurts just as much as a day lost at the end. ... There are infinitely many ways to loose a day ..but not even one way to get one back.

10. Winners never talk about glorious victories. That's because they are the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories.

Related Testing Topics
a. Black Box testing

Black Box testing

2009-11-10T00:00:00.001-08:00

Black Box testing refers to the technique of testing a system with no knowledge of the internals of the system. Black Box testers do not have access to the source code and are oblivious of the system architecture. A Black Box tester typically interacts with a system through a user interface by providing inputs and examining outputs without knowing where and how the inputs were operated upon. In Black Box testing, target software is exercised over a range of inputs and the outputs are observed for correctness.

Advantages

a. Efficient Testing — Well suited and efficient for large code segments or units.

b. Unbiased Testing — clearly separates user's perspective from developer's perspective through separation of QA and Development responsibilities.

c. Non intrusive — code access not required.

d. Easy to execute — can be scaled to large number of moderately skilled testers with no knowledge of implementation, programming language, operating systems or networks.

Disadvantages

a. Localized Testing — Limited code path coverage since only a limited number of test inputs are actually tested.

b. Inefficient Test Authoring — without implementation information, exhaustive input coverage would take forever and would require tremendous resources.

c. Blind Coverage — cannot control targeting code segments or paths which may be more error prone than others.

White Box Testing refers to the technique of testing a system with knowledge of the internals of the system. White Box testers have access to the source code and are aware of the system architecture. A White Box tester typically analyzes source code, derives test cases from knowledge about the source code, and finally targets specific code paths to achieve a certain level of code coverage. A White Box tester with access to details about both operations can readily craft efficient test cases that exercise boundary conditions.

Advantages

a. Increased Effectiveness — Crosschecking design decisions and assumptions against source code may outline a robust design, but the implementation may not align with the design intent.

b. Full Code Pathway Capable — all the possible code pathways can be tested including error handling, resource dependencies, and additional internal code logic/flow.

c. Early Defect Identification — Analyzing source code and developing tests based on the implementation details enables testers to find programming errors quickly.

d. Reveal Hidden Code Flaws — access to source code improves understanding and uncovering unintended hidden behavior of program modules.

Disadvantages

a. Difficult To Scale — requires intimate knowledge of target system, testing tools and coding languages, and modeling. It suffers for scalability of skilled and expert testers.

b. Difficult to Maintain — requires specialized tools such as source code analyzers, debuggers, and fault injectors.

c. Cultural Stress — the demarcation between developer and testers starts to blur which may become a cultural stress.

d. Highly Intrusive — requires code modification has been done using interactive debuggers, or by actually changing the source code. This may be adequate for small programs; however, it does not scale well to larger applications. Not useful for networked or distributed systems.

Difference between Black Box and White Box Testing

1. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box.

2. Synonyms for white-box include: structural, glass-box and clear-box.

3. Generally black box testing will begin early in the software development i.e. in requirement gathering phase itself. But for white box testing approach one has to wait for the designing has to complete.

4. We can use black testing strategy almost any size either it may be small or large. But white box testing will be effective only for small lines of codes or piece of codes.

5. In white box testing we can not test Performance of the application. But in Black box testing we can do it.

Gray Box Testing refers to the technique of testing a system with limited knowledge of the internals of the system. Gray Box testers have access to detailed design documents with information beyond requirement documents. Gray Box tests are generated based on information such as state-based models or architecture diagrams of the target system.

Advantages

a. Offers Combined Benefits — Leverage strengths of both Black Box and White Box testing wherever possible.

b. Non Intrusive — Gray Box does not rely on access to source code or binaries. Instead, based on interface definition, functional specifications, and application architecture.

c. Intelligent Test Authoring — Based on the limited information available, a Gray Box tester can author intelligent test scenarios, especially around data type handling, communication protocols and exception handling.

d. Unbiased Testing — The demarcation between testers and developer is still maintained. The handoff is only around interface definitions and documentation without access to source code or binaries.

Disadvantages

a. Partial Code Coverage — Since the source code or binaries are not available, the ability to traverse code paths is still limited by the tests deduced through available information. The coverage depends on the tester authoring skills.

b. Defect Identification — Inherent to distributed application is the difficulty associated in defect identification. Gray Box testing is still at the mercy of how well systems throw exceptions and how well are these exceptions propagated with a distributed Web Services environment.

Related Testing Topics

a. Testing Concepts

b. Error, Bug & Defect

c. Testing Models

d. Testing Techniques

e. Load testing

f. Usability Testing

g. Localization Testing

h. GUI Testing

i. QA, QC & Testing

j. Negative Testing

k. Severity vs Priority

l. Test Cases

m. Testing Tools

n. RTM, VV, Static and Dynamic Testing

Error and Bug

2009-11-09T23:59:00.003-08:00

1. Error/bug/defect/mistake are human intraction which produce an incorrect result.

Fault: Fault is a stage of software which is caused by an error/bug/defect/mistake.

Failure: It is a deviation of software from its expected delivery or service.

For eg.

you are driving a car and you are on road while on driving now there is two way on the road

a) left: mumbai

b) right: delhi

now you have to go to delhi it means you have to turn the stearing to the right, but by mistake you turn the stearing to the left, from that position that is called as "Error" because human intraction is there. and now Fault is there till you will not reach the mumbai, but when you reach mumbai that is a final stage which is called "Failure" becoz you had to reach delhi but now you are in Mumbai.

2. Differences in terms
a. Error: the mistakes made by developer in coding.

b. Bug: Found problem in application By Tester


c. Defect: Found problem in application By Customer after release

Difference Between Bug, Error, Defect and Issue

a. Bug: A software bug is an error, flaw, mistake, failure, or fault in a program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code.

b. Error: The mistake made by developer in coding.

c. Defect: Defect is something which is in the requirement document and it is not implemented or it is implemented in a wrong way.

d. Issue: Issue is something which is not all above, Some issues are there like site is slow, session related problems, security problems etc.

Related Testing Topic
a. Black Box testing

2009-11-09T23:59:00.001-08:00

1. Performance Testing

In white box testing testers, developers, system administrators and DBAs work together in order to instrument the application code and the database queries (via specialized profilers for example), and the hardware/operating system of the server(s) running the application and the database (via monitoring tools such as vmstat, iostat, top or Windows PerfMon). All these activities belong to performance testing.

The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.

These bottlenecks can exist at multiple levels:

a. at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)

b. at the database level, developers and DBAs can use database-specific profilers and query optimizers

c. at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used

d. at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool.

From a testing point of view, the activities described above all take a white-box approach, where the system is inspected and monitored "from the inside out" and from a variety of angles.

2. Load Testing

Are you actively profiling your application code and/or monitoring the server(s) running your application? If the answer is yes, then you're engaged in performance testing. If the answer is no, then what you're doing is load testing.
In the testing literature, the term "load testing" is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing.

Examples of volume testing

a. testing a word processor by editing a very large document

b. testing a printer by sending it a very large job

c. testing a mail server with thousands of users mailboxes

d. a specific case of volume testing is zero-volume testing, where the system is fed empty tasks

Examples of longevity/endurance testing

a. testing a client-server application by running the client in a loop against the server over an extended period of time

Goals of load testing

a. expose bugs that do not surface in cursory testing, such as memory management bugs, memory leaks, buffer overflows, etc.

b. ensure that the application meets the performance baseline established during performance testing. This is done by running regression tests against the application at a specified maximum load.

Although performance testing and load testing can seem similar, their goals are different. On one hand, performance testing uses load testing techniques and tools for measurement and benchmarking purposes and uses various load levels. On the other hand, load testing operates at a predefined load level, usually the highest load that the system can accept while still functioning properly. Note that load testing does not aim to break the system by overwhelming it, but instead tries to keep the system constantly humming like a well-oiled machine.

3. Stress Testing

If you want to actually discover bugs and to see if your application fails and recovers gracefully, you need to do stress testing. Blast your Web server with double the number of users for example. Unplug network cables randomly (or shut down/restart switch ports via SNMP). Take out a disk from a RAID array.

The main purpose behind this madness is to make sure that the system fails and recovers gracefully.

Here are some ways in which stress can be applied to the system:

a. double the baseline number for concurrent users/HTTP connections

b. randomly shut down and restart ports on the network switches/routers that connect the servers (via SNMP commands for example)

c. take the database offline, then restart it

d. rebuild a RAID array while the system is running

e. run processes that consume resources (CPU, memory, disk, network) on the web and database servers

If chair is designed for 100 kg weight, and my weight is 70 kg then that testing is called as normal testing. If my weight is 100 kg then that testing is called as load testing. If my wt is 120 kg then that testing called as stress testing.

Differences
a. Performance test: To determine or validate speed, scalability, and/or stability.
b. Load test: To verify application behavior under normal and peak load conditions
c. Stress test: To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.
d. Capacity test: To determine how many users and/or transactions a given system will support and still meet performance goals.

Related Testing Topic

a. Black Box testing

Testing Models

2009-11-09T23:58:00.002-08:00

Scrum Development Process

Scrum is an agile method for project management. Scrum is a method for managing work and achieving very high productivity. A popular agile method for project management, Scrum is noted for its simplicity, its high level of transparency, and a team based approach to work.

Characteristics of Scrum

a. A product backlog of prioritized work to be done;

b. Completion of a fixed set of backlog items in a series of short iterations or sprints;

c. A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.

d. A brief sprint planning session in which the backlog items for the sprint will be defined.

e. A brief sprint retrospective, at which all team members reflect about the past sprint.

Following are some practices for the Scrum:

a. Customers become a part of the development team. (i.e., Customer must be genuinely interested in the output.)

b. Frequent intermediate deliveries with working functionality.

c. Frequent risk and mitigation plans developed by the development team itself. Make it live, and continuous activity.

d. Daily status discussion with the team. – Standup meetings.

e. A daily discussion asking each team member:

1. What have you done since yesterday?

2. What are you planning to do by tomorrow?

3. Do you have any problems preventing you from accomplishing your goal?

f. Transparency in planning and module development – Let everyone know, who is accountable for what and by when.

g. Workplaces and working hours must be energized. – "Working more hours" does not necessarily mean "producing more output."

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.

Requirement (Diagram)

a. Design

b. Implementation & Unit Testing

c. Integration & System Testing

d. Operation

Advantages

a. Simple and easy to use.

b. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

c. Phases are processed and completed one at a time.

d. Works well for smaller projects where requirements are very well understood.

Disadvantages

a. Adjusting scope during the life cycle can kill a project

b. Poor model for complex and object-oriented projects.

c. Poor model for long and ongoing projects.

d. Poor model where requirements are at a moderate to high risk of changing.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Advantages

a. Simple and easy to use.

b. Each phase has specific deliverables.

c. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.

d. Works well for small projects where requirements are easily understood.

Disadvantages

a. Very rigid, like the waterfall model.

b. Software is developed during the implementation phase, so no early prototypes of the software are produced.

c. Model doesn’t provide a clear path for problems found during testing phases.

Spiral Model

The spiral model gives more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Advantages

a. High amount of risk analysis.

b. Good for large and mission-critical projects.

c. Software is produced early in the software life cycle.

Disadvantages

a. Can be a costly model to use.

b. Risk analysis requires highly specific expertise.

c. Project’s success is highly dependent on the risk analysis phase.

d. Doesn’t work well for smaller projects.

Related Testing Topic
a. Black Box testing

Severity vs Priority

2009-11-09T23:58:00.000-08:00

Severity: Severity determines the defect's effect on the application. Severity is given by Testers

Priority: Determines the defect urgency of repair. Priority is given by Test lead or project manager

1. High Severity and Low Priority : For example an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

2. High Severity and High Priority : In the above example if there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed urgently.

3. Low Severity and High Priority : If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.

4. Low Severity and Low Priority : If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Priority is used to organize the work. The field only takes meaning when owner of the bug
P1 Fix in next build
P2 Fix as soon as possible
P3 Fix before next release
P4 Fix it time allow
P5 Unlikely to be fixed
Default priority for new defects is set at P3

Related Testing Topic

a. Black Box testing

GUI Testing

2009-11-09T23:49:00.001-08:00

GUI testing is a process to test application's user interface and to make sure that it confirms the design requirements.

1. Text Box
a. Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar.
b. If it doesn't then the text in the box should be grey or non-updateable.
c. Try to overflow the text by typing to many characters.
d. Enter invalid characters - Letters in amount fields, try strange characters like + , - * etc. in All fields.
e. SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.

2. Radio Button:
Left and Right arrows should move ON Selection. So should Up and Down. Select with mouse by clicking.
Check Boxes: Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same.

3. Command Buttons
a. If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots.
b. All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.
c. Click each button once with the mouse - This should activate
Tab to each button - Press SPACE - This should activate
Tab to each button - Press RETURN - This should activate
d. If there is a Cancel Button on the screen , then pressing should activate it.

4. Aesthetic Conditions:
a. Is the general screen background the correct colour?
b. Are the field prompts the correct colour?
c. Are the field backgrounds the correct colour?
d. In read-only mode, are the field prompts the correct colour?
e. In read-only mode, are the field backgrounds the correct colour?
f. Are all the screen prompts specified in the correct screen font?
g. Is the text in all fields specified in the correct screen font?
h. Are all the field prompts aligned perfectly on the screen?
i. Are all the field edit boxes aligned perfectly on the screen?
j. Should the screen be resizable?
k. Should the screen be minimisable?
l. Is all user input captured in UPPER case or lower case consistently?

5. Validation Conditions:
a. Does a failure of validation on every field cause a sensible user error message?
b. Is the user required to fix entries which have failed validation tests?
c. Have any fields got multiple validation rules and if so are all rules being applied?
d. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.?
e. Is validation consistently applied at screen level unless specifically required at field level?
f. For all numeric fields check whether negative numbers can and should be able to be entered.
g. For all numeric fields check the minimum and maximum values and also some mid-range values allowable?
h. For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
i. Do all mandatory fields require user input?
j. If any of the database columns don't allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)

6. Usability Conditions:
a. Is all date entry required in the correct format?
b. When an error message occurs does the focus return to the field in error when the user cancels it?
c. Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer

7. Data Integrity Conditions:
a. Check the maximum field lengths to ensure that there are no truncated characters?
b. Check maximum and minimum field values for numeric fields?
c. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?

8. Date Field Checks
a. Assure that leap years are validated correctly & do not cause errors/miscalculations
b. Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
c. Assure that 00 and 13 are reported as errors
d. Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
e. Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
f. Assure that Feb. 30 is reported as an error
g. Assure that century change is validated correctly & does not cause errors/ miscalculations

9. Alpha Field Checks
a. Use blank and non-blank data
b. Include lowest and highest values
c. Include invalid characters & symbols
d. Include valid characters
e. Include data items with first position blank
f. Include data items with last position blank

Related Testing Topic:
a. Black Box testing

Free Tools used for Software Testing

2009-11-09T23:48:00.000-08:00

1. Add-on Pinger to find broken links:
Firefox Add-on Pinger 1.0.2

Pinger Description - Looks for broken links on page, links that are not working anymore - returning 404 code. You can select to check whole page, or just links in selection.

2. Tool to find broken links online:

Summary of the features:

- Checks your websites for dead links

- Can scans 3000 web-pages

- Validates both internal and external URLs

- Shows problematic link's location is your HTML code !!!

- For bad URLs reports HTTP response code: 404 etc

- Can be used on Mac, iPad, Linux, UNIX, Windows

3. Fireshot to save screenshots:

Fireshot: Screenshots can be saved to disk (PNG, GIF, JPEG, BMP), printed (NEW), copied to clipboard, e-mailed and sent to external editor for further processing.

4. Firebug to monitor HTML:

Firebug: Integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

5. Selenium used for regression testing:
Selenium: Used for functional testing

What are the components of selenium ?
Selenium IDE - Plugin to Firefox to record and play test in firefox
and also export tests in different languages. The most appealing
format is the html test case which seems to based on fit html .
Selenium RC- Allows playing of exported test in different platform/OS
Selenium Grid - Allows to control lots of selenium machines.

6. Tool used for performance testing:

Web page performance (speed) - Page Speed generates its results based on the state of the page at the time you run the tool. To ensure the most accurate results, you should wait until the page finishes loading before running Page Speed. Otherwise, Page Speed may not be able to fully analyze resources that haven't finished downloading.

7. Tool used to create video (steps to reproduce bug):
Screencast-O-Matic is the original free and easy way to create a video recording of your screen (aka screencast) and upload it for free hosting all from your browser with no install!

8. Compatibility testing of browser:
Adobe BrowserLab [Provide screen shots]:

Adobe BrowserLab is an online hosted service that lets you test the pages of your web site across a variety of web browsers and operating systems. The service works by taking screen shots of your web pages in different browsers, and then displaying them in the BrowserLab application window.

You can use BrowserLab as a standalone service, or integrated with Dreamweaver CS4. The standalone service lets you test pages that you've posted to a server within the context of a web browser. If you use BrowserLab as an integrated service with Dreamweaver, you can test your pages from within Dreamweaver without publishing your pages to a server.

BrowserLab supports the following browsers:

• Firefox 2.0 - Windows XP
• Firefox 3.0 - Windows XP
• Firefox 3.5 - Windows XP
• Chrome 3.0 - Windows XP
• Internet Explorer 6.0 - Windows XP
• Internet Explorer 7.0 - Windows XP
• Internet Explorer 8.0 - Windows XP
• Safari 3.0 - Macintosh OS X
• Safari 4.0 - Macintosh OS X
• Firefox 2.0 - Macintosh OS X
• Firefox 3.0 - Macintosh OS X
• Firefox 3.5 - Macintosh OS X

9. Compatibility testing of browser:
Browser Sandbox [Run any browser from the web]

• Microsoft Internet Explorer 8
• Internet Explorer 7
• Internet Explorer 6
• Mozilla Firefox 3.5
• Firefox 3
• Firefox 2
• Apple Safari 4
• Safari 3
• Google Chrome
• Opera 10
• Opera 9

My Comments as a Tester:
a. Adobe BrowserLab will be helpful to compare the designs of multiple Browsers.
b. Browser Sandbox will be helpful to test the functionality and design on multiple Browsers.

10. powercfg /energy:
Generate "Power Efficiency Diagnostics Report" by running the command powercfg /energy

11. Summary:
1. Bug Tracking Tool: Bugzilla
2. Recording the bug in video format: Screencast-o-matic
3. Tool for taking Screen-shots for reporting the bug: Fireshot
4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab
5. Tool to Monitor CSS and HTML: Firebug
6. Tool to ensure valid HTML: HTML Validator
7. Performance Testing tool: Page Speed by Google
8. To find Broken Links: Pinger Ad-on and brokenlinkcheck
9. For checking the spelling of content: Spell Check
10. powercfg command

Related Testing Topic:
a. Black Box testing

Creativity of Software Testers

2009-11-09T23:47:00.000-08:00

Re: CreativityThe comparison with the harvester and the hunter seems quite good!

However, the developer/designer should also fulfill the position of a “sower” as well. If they take care to “sow” the right stuff, there will be less to “de-weed” and as a result a better crop for all!!!

The harvest will of course be good too :)
After all, you reap what you sow!!

- C

Creativity of Testers:

As in many different professions, opportunities for creativity exist, but they are not all available at all levels. Comparin the tester's goals to the developper's goal, you can say that the developer looks for _one_ solution that fits the specifications, while the tester has to (should) find _all_ the defects that were introduced in the development process (from specificaiton to code). As such the challenge is much more interesting, just as the challenge for the "hunter" is greater than for the "harvester".

You will enjoy creativity in coming up with different attacks (methods for finding defects) to show presence (or absence) of defects. However, it is most likely that you will first have to execute tests created by others (less creativity here). Then you will have enough understanding of the different types of possible defects, and conceive new tests that others will execute (more creativity).

In the end you may come up with completely new paradigms on testing, and that is the greatest creativity possible.

The creativity is not based on company, nor on the team where you will work. It is based only on how you look at your work: if you limit yourself to executing again and again the same activity (without learning new things) then it will not be creative. If you limit the scope of your thoughts you will not find creativity. On the other hand, if you challenge your own knowledge and try to expand it always, then you will have the opportunity to be both creative and recognized by your peers.

Venkat has asked following simple question:

"I have a question. I am new to testing field.
Developers can not test there code while developing there code and save time? Sorry if my question sounds silly."

Then I gave him following answer:

1. Every director likes his own movie no matter movie is good or bad. Only audience can tell whether the movie is good or bad.

2. Mother of ugly child can not admit that her child is ugly. For her, her child is the most beautiful child in the world.

Similarly how can developer tell you that project has bug or not. A person who create anything can not find any bad thing in it.

If any one has other examples then please add below.

Related Testing Topic:
a. Testing Experiences
b. Having Other People Test....
c. Black Box testing

Realities of QA

2009-11-09T23:44:00.000-08:00

1. I have seen in my experience till now that position of QA is least in most of the organizations.
2. No body is aware about QA. Nobody knows the value of QA. But they can take decisions on QA tasks/plans easily.
3. Everyone thinks that any person can perform QA tasks on any project.
4. QA always dances on the fingers of Developers.
5. Developers decides who will be the QA of their project.
6. Developers decides which bug should be address to the client because it can harm their positions.
7. When new comers come to any organization they do not want to become QA because of above points.
8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.

Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final drop before 1-2 hours of product delivery.
And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.

Please forgive QAs and try to understand their feelings afterall they are also human beings.

Here are the valuable comments on invaluable article written above:

Yes! Rajiv,
you are very true!! Now a days nobody was have QA scene!
-Krish

Yes rajiv, it's really true
-Vaneeta

Yes..
That is 100 % correct
I am also agreeing with Rajeev
-Sarath

Totally agree, for a real QA there must be an active compromise from management leaders making sure that everyone is aware of QA, and protecting the space of QA within a company or project environment.
-Antonio

HI Rajiv & Guys!
I really appreciate your effort & feelings about QA position in the present industry.
Exactly I am in a same situation where u have explained the points. In my current project, DEV team did not fixed the bugs and repeatedly client reported bugs. My manager thinks that everybody can test an application to catch bugs.
But in my view, Testing of the application is not that much easy as people thinking.
Let me give one example: One developer will write the code to fulfill one requirement and not to break by a tester with maximum number of scenarios. But a tester has to think technically & realistically (as a end user) to break the application with more number of scenarios as a developer thinks and finally breaks the system.
Let me know if I wrote anything wrong.
Thanks
-Arif

Sad, but true :/
-LadyRoot

I've seen a lot of agreement with Rajiv's observations, but I must say that it's not true in every company. In my experience it's been more true in the larger corporate environments, but I'm currently working with a small company where the QA department is greatly appreciated, the developers are eager to fix bugs, and they actually want the input from QA.
I would also like to point out that even in the large corporate environments I achieved a high level of success with the developers (managers were a completely different story). I used the principles from Cem Kaner's Defect Advocacy course and taught it to my entire team. While convincing management of our true value was never achieved, we had most of the developers wanting our testing and responding to our defects. A lot of how they react to our bug reports is dependent on how we approach them with the defects. Continuing to hold an attitude of "us vs. them" tends to make them put up defensive walls whereas an approach of helping them produce better code produces more of a teamwork atmosphere.
I'd highly recommend going through Cem's course (http://www.testingeducation.org/BBST/BBSTbugAdvocacy.htm) and applying what you learned to your environment. You can often change the environment by changing your approach.
-Thad Butterworth

me too in the same situation
-Venkatesalu

1. I have seen in my experience till now that position of QA is least in most of the organizations.
Ravi: Its not in my Organization. I feel you have not seen much in your life.

2. No body is aware about QA. Nobody knows the value of QA. But they can take decisons on QA tasks/plans easily.
Ravi:
> No one will be aware of anything, unless its been proven.
> Prove yourself, test & expose the s/w in all ways.
> For all this you must be aware of the system like anyone else developing it, desinging it.
> If you look at all projects like a user then you will be treated as common.

3. Everyone thinks that any person can perform QA tasks on any project.
5. Developers decides who will be the QA of their project.

Ravi:
> It may happen initially, but once your QA team gain some expertise then you can assing some person.
> If all of the team members are doing user level / black box testing then its obvious that anyone can do the job.

4. QA always dances on the fingers of Developers.
Ravi:
> Whomesoever doesn't have knowledge on system dance on other person fingers.
> Its applicable for another developer too, so learn about the system in much more details and expose s/w by all means.

6. Developers decides which bug should be address to the client. because it can harm their positions.

Ravi:
> If its might be a business decision.
> But keep a record of all the issues through mail and get their reply in specified time and
> save them so that at adverse time you can expose with details.

7. When new joinies come to any organization thay do not want to become QA because of above points.
Ravi:
> You must be proud of yourself being a tester first, are you ??

8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.
Ravi:
> I feel you must be aware of system / OS to be a better tester.

9. Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final drop before 1-2 hours of product delivery. And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.
Ravi:
> This might be applicable for development team too by giving small time for development.
> You must have good managerial skill to tackle these kind of issues.
> Give your report specifying basic testing alone executed and details testing is not done due to lack of timing constrains.

10. Please forgive QAs and try to understand their feelings afterall they are also human beings.
Ravi:
> Don't plead for QA's, QA is in good position only. You need to improve your knowledge & other soft skills.

I aggree with Rajiv's points. Its true man!
Although it is not true in my current company but in my previous
company this was so very true.
-Mugen

A debate should remain healthy but I see points that can turn this into something else.
I am also working as a tester & I believe some of the points both you gentlemen (Ravi & Rajiv) are correct, Though I feel Ravi has better points.
At some point everyone remain unsatisfied whether he is developer or tester. And Rajiv, you would be agree that there are few companies where developer feel same as you wrote about testers. Tester is not any pitiful animal, he has his points & if management decides to disagree with his point of view it does not mean that he is worthless.
I refuse to accept my job on the points you wrote however some of them might be correct in your context.
People will feel pity for you only if you represent yourself as one helpless creature.
All in all, its up to me how I take & value my job & it does not need any debate to change my point of view. I value it, I know its worth & hence I am here.
Instead of writing this stuff lets concentrate on the queries on testing, problems & the solutions. We are not here to create any minority group but we re professionals.
-Vikas

First of all, let's clarify what you are talking about. I've got a
feeling that you speak of testing rather than QA role.
It can be that testers are undervalued in some organization but it
isn't true for all organizations. As they say a fish starts getting
spoiled from the head. If top management sees testers like monkey,
like under qualified working force then others in organization are
most likely to share this vision.
Also, a lot is in hands of a test manager. His or her primary goal is
to provide quality working conditions to the performers. Treating like
pigeons by management or developers will hardly make team moral
better. Test team manager should keep defining comfortable working
atmosphere by loosing strain between testers and developers. I did it
many times in my career. The best way is to explain tester that this
is natural for developers to express their bad feeling about discovery
of an issue, so we need to learn how to politely ignore the first
expression and keep the voice of discussion down. On another hand I
kept preaching to developers that we are all in same boat, that
testers are just like them but simply doing another work, that this is
much better that we have found earlier than later.
So, this is frustrating to be undervalued, but you can do something
about it.
-Vladimir Trushkin

Hi Vikas,
Thanks for the beautiful reply. I know Ravi's points are better. I am also not facing these problems in my current organization.
But I have written this article on behalf of my friends who are working in different organizations. Also I have taken survey on this and found that more than 70 % people are facing these problems. I have written just the problems of those people who are working in different organizations and facing similar problems.
My motive is not to tell just the problem. I wanted to discuss the proper solution on these points.
We can do this only if we *all* agree on the points which I have written. We have to admit that many testers are facing these problems. If we will not going to admit this then we can not help them.
I am not satisfy with your comment i.e.
"Instead of writing this stuff lets concentrate on the queries on testing, problems & the solutions. We are not here to create any minority group but we re professionals."
I think this Google group is not created for just to discuss theory part. We should also discuss these types of real time challenges which we face practically. And I do not want to create any minority group but I want to help people who belongs to my profession. Because..
I am proud of my testing profession.
So I request you all, first of all please agree with my points then provide your solutions. Otherwise this debate will be endless.
I am sorry in advance if anyone of you think that I am wrong.
-Rajiv

Hi all,
appart of my initial agreement with the initial message by Rajiv I would like to add the following as a paradigm in perharps many of these organisations where testing tasks are compromised and QA not managed as a whole. Let me know how many of you agree:
1 - Selling is the real constraint, no matters what is going to be sold.
2 - The product is not completelly specified normally so that the whole project is opened to any customer's request.
3 - Eventually any request may arrive for development without any analysis work done about feasibility or impact in the project's current state.
4 - If new requests impact is not taken into acount, milestones' deadlines may not be postponed accordingly.
5 - The project goes into a state in which there are more tasks to do than planned and there is less time for them than planned.
6 - Since development happens before than testing (obvious, I know), development takes integration and verification time.
7 - Hopefully testers just perform some sanity tests of a recently integrated product version before releasing the product.
My conclusion after all these comments: it is a must that management believes in QA and works for it, giving enough flexibility for selling but always allowing time for analysing, developping and verifying what is being done as a product.
All the best,
-Antonio

Related Testing Topics:
a. Black Box testing
b. Testing Experiences

Software Testing in Agile

2009-11-09T23:42:00.001-08:00

Agile means being able to quickly change direction. Agile software development is a group of software development methodologies.

Agile software development methods:
1. Agile Modeling
2. Agile Unified Process (AUP)
3. Dynamic Systems Development Method (DSDM)
4. Essential Unified Process (EssUP)
5. Extreme Programming (XP)
6. Feature Driven Development (FDD)
7. Open Unified Process (OpenUP)
8. Scrum
9. Velocity tracking

Agile method: Scrum (development)
Scrum is an iterative incremental process of software development commonly used with agile software development.

Software developed during one unit of time is referred to as an iteration, which typically lasts from two to four weeks. Each iteration passes through a full software development cycle, including planning, requirements analysis, design, writing unit tests, then coding until the unit tests pass and a working product is finally demonstrated to stakeholders.

The Product Backlog is the master list of all functionality desired in the product. A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Sprint Backlog: The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner.

Daily SCRUM meeting rules:
1. Hold the daily scrum in the same place at the same time every work day.
2. All team members are required to attend.
3. The scrum master begins the meeting by starting with the person to his or her left and proceeding counter clockwise around the room until everyone has reported.
4. Each team member should respond to three questions only:
a) What have you done since the last daily scrum regarding this project?
b) What will you do between now and the next daily scrum meeting regarding this project?

QC Process followed in small companies

1) If there is small project then we opt for Ad-hoc testing. Ad-hoc testing is done without test cases. But for this, software tester should have enough knowledge about the project. And it is done by experienced QA engineer.

2) If software tester don't know anything about the project then we perform exploratory testing on that project. We explore all the features and then create and execute test cases.

3) In general, following Testing process is followed by small companies:

a) Requirement Stage: Analyze requirement document, discuss with team internally, ask doubts from client if required.

b) Test Plan: Create test plan which defines the type of testing should be done, who will test this, duration for which we have to test, availability of test resources, types of Testing performed, features to be tested, features not to be tested etc.

4) Test Cases: Test cases (sequence of steps to test the correct behavior of a functionality) are prepared by reviewing the functional requirements in use cases or by
exploring the application.

5) Execution of Test Cases: Each test case is executed by more than one QC engineer and on different configuration PCs to ensure that its working 100% fine.

6) Instant Bug reporting: If we find number of bugs then initially we report the bugs in excel sheet and send it to developers so that they can make a proper plan and start work on it.

7) Bug reporting in bug tracking tool: Then we post each bug with more details in to bug tracking tool.

8) Explain the required bug to developer with exact scenario

9) Re test the issue fixed by developer

10) Mark the status in bug tracking tool.

Related Testing Topics:
a. Black Box testing
b. Testing for Beginners
c. Smartphone Testing

Usability Testing

2009-11-09T23:41:00.005-08:00

Usability testing is a technique used to evaluate a product by testing it with representative users.

Elements of Usability Testing:
a. Participation of QA and designers.
b. Participation of sample end users (Non Team Members).
c. Observation by test moderator.
d. Development of research questions.
e. Recomendation of improvements to the design of the product.

Limitation:

a. Testing is always an artificial situation.
b. Test results do not prove that product works.
c. Participants are rarely fully representatives of the target population.

Types of tests:

a. Exploratory or formative study: is conducted quite early in the development cycle.

b. Assessment or Summative Test: are conducted after fundamental or high-level design or organization of the product has been established.

c. Verification or Validation Test: To confirm that problems discovered earlier have been remedied and that new ones have not been introduced. This test takes place much closer to the release of the product.

Usability testing VS GUI testing:

GUI testing is a process to test application's user interface and to make sure that it confirms the design requirements. e.g are the colors, fonts and control placements done according to the specs?

Usability testing goes much more into human factoring. Examples of Usability issues:

1. Long Scrolling Pages

2. Non-Standard Link Colors

3. Complex Website Addresses (URLs)

Related Testing Topic:
a. Black Box testing

Localization Testing

2009-11-09T23:41:00.003-08:00

In order to perform Localization testing, test engineer should follow following levels:

Globalization Testing (Internationalization Testing): The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

Localizability Testing: Localizability testing verifies that you can easily translate the user interface of the program to any target language without re-engineering or modifying code. Localizability testing catches bugs normally found during product localization, so localization of the program is required to complete this test. Successful completion of localizability testing indicates that the product is ready for localization. You can use pseudo-localization to avoid the time and expense of true localization.

The most effective way to perform pseudo-localization is to modify the program's resources automatically. For example, here is what English-speaking localizers do when they translate a program's UI:

a. Replace English text with text containing non-English characters. For example: For a, use à or å For c, use ĉ or ç For n, use ń or ñ.

b. Add extra characters to your resource strings. In many cases translated text is longer than the English original ("some string" becomes "+++some string+++").

c. Stretch your dialog boxes. Localizers usually do this when the string length grows due to localization.

Localization Testing: Localization translates the product UI and occasionally changes some initial settings to make it suitable for another region. Localization testing checks the quality of a product's localization for a particular target culture/locale. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product.

Related Testing Topic:
a. Black Box testing

Checklist for Website Testing

2009-11-09T23:40:00.001-08:00

Here you can find the checklist for web testing. By using the checklist for web application testing, user can create test cases for any web based application:

Step 1 - User Interface Testing (GUI Testing):

a. Content wording used in the web pages should be correct.

b. Wrap-around should occur properly.

c. Instructions used in web pages should be correct (i.e. if you follow each instruction does the expected result occur?)

d. Check image size specifications: Check that at least the text of the page appears quickly.

e. View in text browser: Test each web page in text-only browser, or text-browser emulator. It will help you pick up on badly-chosen or missing ALT texts.

f. Switch images off: Check that sensible ALT texts have been provided for images.

g. Check sensible page titles.

h. Resolution change effect on web pages.

i. Image spacing – To verify that images are displaying properly with text.

j. Print – Pinting should be proper.

For more information about GUI testing, kindly refer to http://puretest.blogspot.com/2009/11/gui-testing.html

Step 2 - Functional Testing

a. Check for broken links (Broken link refers to a hyperlink which does not work): Manually its very difficult to find broken links. There are various tools available to find these, such as:

- Broken Link Check

- Firefox Add-on Pinger 1.0.2

b. Validate the HTML: Make sure that you have valid HTML (or XHTML). This can be done with a W3C validator

c. Disable the cookies from your browser settings. If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. See if appropriate messages are displayed.

(A cookie is a small piece of information stored as a text file on your computer that a web server uses when you browse certain web sites that you've visited before).

d. Switch JavaScript off: It is important to check that your site still functions with Javascript disabled or provide proper Javascript error message:
e.g. “enable Javascript to see animation of Intelligaia Technologies”.

e. Warning messages: Error/warning messages should be flash to user for incorrect inputs.

Step 3 - Interface Testing

a. Data display on browser should match with data available on server: To test browser and server interface, run queries on the database to make sure the transaction data is being retrieve and store properly.

b. Error Handling: Make sure system can handle application errors.

Step 4 - Compatibility Testing

a. Test on different Operating systems: Test your web application on different operating systems like Windows (XP, Vista, Win7 etc), Unix, MAC, Linux, Solaris with different OS flavors.

b. Test on different Browsers: Test web application on different browsers like:

- Firefox, as that has the best standards compliance and is the second most-used browser.

- Internet Explorer for Windows – currently the most widely used browser (IE6, IE7, IE8).

- Opera – growing in popularity due to its speed and pretty good standards compliance.

c. Mobile browsing: This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.

Step 5 - Security Testing

a. Limit should be defined for the number of tries: Is there a maximum number of failed logins allowed before the server locks out the current user?

b. Verify rules for password selection.

c. Is there a timeout limit?

d. Test by pasting internal url directly into browser address bar without login. Internal pages should not open.

e. Test the CAPTCHA for automates scripts logins.

f. Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.

g. All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

h. Clear your Cache: Be sure to clear the browser cache, including cookies, before each test.

i. SQL injection: To test for SQL injection bugs, find places where users can enter text, such as where the text is used to perform a lookup function, according to Breach. Then type a single quote character and some text. If the application shows an error message from your database, then you're likely housing an SQL injection bug.

(SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution.)

j. Cross-site scripting (XSS): Find areas in your application that accept user input, such as a page where users can send in their feedback or reviews of a product, for example. Try submitting following:
1. >"'><script>alert(‘XSS')</script>
2. >%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
4. AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
5. %22%2Balert(%27XSS%27)%2B%22
6. <table background="javascript:alert(([code])"></table>
7. <object type=text/html data="javascript:alert(([code]);"></object>
8. <body onload="javascript:alert(([code])"></body>

If that text displays where you reload the page, then your site has an XSS vulnerability.

(Cross-site scripting attacks occur when a malicious person, the attacker, can force an unknowing user, the victim, to run client-side script of the attacker’s choice. The term cross-site scripting is sort of a misnomer, because it’s not just about scripting and it doesn’t even have to be cross-site. It’s a name that was branded upon its discovery and it has just stuck.)

k. Session hijacking: If your application has a session identifier number in the URL decrease that number by one and reload the page. The app has a session hijacking vulnerability if the app then "sees" you as a different user.

(Session hijacking, also known as TCP session hijacking, is a method of taking over a Web user session by surreptitiously obtaining the session ID and masquerading as the authorized user. Once the user's session ID has been accessed (through session prediction), the attacker can masquerade as that user and do anything the user is authorized to do on the network.)

Step 6 - Performance testing

a. Can your site handle a large amount of users requesting a certain page.

b. Long period of continuous use: Is site able to run for long period, without downtime.

For more information about Load testing, kindly refer to: http://puretest.blogspot.com/2009/11/performance-testing-1.html

c. Web page performance (speed) - Page Speed generates its results based on the state of the page at the time you run the tool. To ensure the most accurate results, you should wait until the page finishes loading before running Page Speed. Otherwise, Page Speed may not be able to fully analyze resources that haven't finished downloading.

Free Tools which plays very important role in web site testing:
1. Bug Tracking Tool: Bugzilla

2. Recording the bug in video format: Screencast-o-matic
3. Tool for taking Screen-shots for reporting the bug: Fireshot
4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab
5. Tool to Monitor CSS and HTML: Firebug
6. Tool to ensure valid HTML: HTML Validator
7. Performance Testing tool: Page Speed by Google
8. To find Broken Links: Pinger Ad-on and brokenlinkcheck
9. For checking the spelling of content: Spell Check

Related Testing Topics:
a. Desktop App Testing Checklist
b. Test Cases
c. Testing Tools

Checklist for Desktop Application Testing

2009-11-09T23:39:00.003-08:00

Level 1 - User Interface Testing (GUI Testing):
a. Content wording used in the web pages should be correct.

b. Wrap-around should occur properly.

c. Instructions used in the application should be correct (i.e. if you follow each instruction does the expected result occur?)

d. Image spacing – To verify that images are displaying properly with text.

Level 2 - Functional Testing
a. Check for broken links (Broken link refers to a hyperlink which does not work).

b. Warning messages: User input should get verified at system level according to business rules and error/warning messages should be flash to user for incorrect inputs.

c. Resolution change effect on the application: Ensure that application's functionality and design is compatible with the different resolutions.

d. Print: Following points must be verified

- Test the print functionality of the application when no printer connected - application should behave correctly if printer is not available.

- Test the print functionality of the application when printer is connected

- Ensure that application queues prints in printer if papers are not available in printer.

- To ensure that lengthy description of an event is not truncating on print layout in selected event printing.

e. Theme change: Ensure the successful launch of application after theme change.

f. Installation Testing (Upgrade/Downgrade): Verify application is included in Programs and Features list after installation. Also Verify application is removed from Programs and Features list after un installation. Keep in mind that older version of application should not be install on latest version.

g. Testing with multi user accounts: Open Control Panel, User Accounts, and add 2 user accounts (Standard and admin) to the system. With the application running, press Start, the Switch User to the user account just created.
Verify application launches and runs correctly on the newly created user account. Switch back and forth between user accounts and use the application in both. Watch for any performance decreases and check functionality.

h. Sleep: While the application is running, put the system to sleep (S3). Wake the system up after two minutes.
a) Verify the application is still running.
b) Verify there is no distortion or error.

i. Cache:
- Delete the application's cache, launch the application and verify that application should work properly.
- Delete the application's cache while application is running and verify that application should work properly.

Level 3 - Compatibility Testing
a. Test on different Operating systems: Some functionality in your web application may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API’s may not be available in all Operating Systems.
Test your web application on different operating systems like Windows (XP, Vista, Win7 etc), Unix, MAC, Linux, Solaris with different OS flavors.

Level 4 - Performance testing
a. Long period of continuous use: Is site able to run for long period, without downtime.

b. Memory: Note down the average memory usage in Comments column.

c. Generate "Power Efficiency Diagnostics Report" by running the command powercfg /energy

Related Testing Topics:
a. Web Testing Checklist
b. Test Cases
c. Testing Tools
d. Power Efficiency Diagnostics Report

Regression Testing Tool - Selenium

2009-11-09T23:39:00.001-08:00

Components of Selenium: a. Selenium IDE - Plugin to Firefox to record and play test in firefox and also export tests in different languages. The most appealing format is the html test case which seems to based on fit html.
b. Selenium RC- Allows playing of exported test in different platform/OS.
c. Selenium Grid - Allows to control lots of selenium machines.

Selenium RC Tutorial: Selenium RC is a Java based command line server that starts browsers and runs commands you pass from your tests.

Steps to set up the Selenium tool and execute the test case:

1. Install Selenium IDE

2. Record a test case using Selenium IDE in firefox and Export file as “PHP selanium RC” with filename Example.php

3. Open PHP file in notepad and verify that following code should be displayed:

Last line Complexity in the code - ‘$this->getText…’. The function ‘getText’ returns the text found at the element specified in the expression. The complex looking line is an xpath expression.

An easy way is to use the XPather Firefox addon to get the xpath of any element on a page. After you download and install the addon, restart Firefox, right-click on any element and from the context menu select ‘Show in XPather’. XPather retrieves the xpath to the specified element, which you can than use in your test code.

4. Download and Install Java Runtime

5. Downloaded Selenium RC

6. Start the Selenium RC server by typing “java -jar selenium-server.jar” command in command prompt.

7. Now the server is ready to accept test commands from your PHP script. Make sure you keep this server running till you finish testing.

8. Download and Install WAMP and PHPUnit on Windows.

a. Once you have installed and setup WAMP, open up the command prompt and go to your php directory in WAMP [C:\>cd wamp\bin\php\php5.2.5]

b. From here you must run the go-pear.bat file to install PEAR and all the files needed for it [C:\wamp\bin\php\php5.2.5>go-pear.bat]

c. When executed PEAR will ask you a series of question to set itself up correctly, if you don’t know what your doing then just accept the defaults.

d. Once installed you must run the PEAR_ENV.reg which will create the environment variables for the user, so that PEAR can be called in any directory on the command line [C:\wamp\bin\php\php5.2.5>PEAR_ENV.reg].

e. It should work but if you cannot call PEAR from the command prompt, then you must manually add the directory to the path in the Environment Variables list, found in System Properties -> Advanced-> Environment Variables, then add the directory [C:\wamp\bin\php\php5.2.5 to the PATH variable].

f. Once you have PEAR setup, then you must register the PHPUnit channel with PEAR [C:\wamp\bin\php\php5.2.5>pear channel-discover pear.phpunit.de].

g. Now you can use the PEAR to install packages from the PHPUnit channel [C:\wamp\bin\php\php5.2.5>pear install phpunit/PHPUnit]

9. Copy and paste the “Example.php” file in php folder [C:\wamp\bin\php\php5.2.8]

10. Open another command window and write [cd C:\wamp\bin\php\php5.2.8]

11. Run command [phpunit Example]

Enjoy the tool :)

Source: Selenium: Code Diesel, PHP: Jsdoodnauth Wordpress

Related Testing Topics:
a. Testing Tools

2009-11-09T23:37:00.000-08:00

Test Case

1. What is a test case?

“A set of test data and their expected results.

2. Why we write test cases?

To validate the testing coverage of the application.

3. How to write test cases (Example of test case or Sample of Test Case)?

There is no particular formula for writing the test case. Basic elements used in the test case are:

a. Test case number: 1 OR 1.1

b. Test Case Name: Login Verification

c. Test case Inputs or Steps or Action: Enter Login credentials, Click on “login” button.

d. Test Case Expected result: Verify that user is successfully login to “Home” page.

e. Test Case Status: Pass or Fail.

f. Comments: If test case is fail the you can write why it is failed. Also you can write bug number here which you are going to be reporting.

You should ask your self a question before writing the test case "What should be the steps followed by different users to use this functionality". Surely you will get the answer and just you have to write that answer in the form of points in excel sheet. Those points will automatically become test cases :)

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written.

4. What is the suitable time to create Test case?
There are levels in which test cases should be analized/designed to avoid duplication efforts.

Level 1: In this level tester should write the basic test cases from the available specification documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
Level 3: This is the stage in which tester should group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases.

5. Automation vs Manual Test Cases
The following types of test cases can be preferred for automation:
a. Test cases that need to run on every build.
b. Test cases that use multiple data values for same action.
c. Identical test cases that need to be executed using different browsers.

The following types of test cases should not consider for automation testing:
a. Test Cases that will only be executed once.
b. Test Cases used for Ad-hoc/random Testing.
c. Test Cases that are infrequently selected for execution.
d. Test Cases that will require manual intervention i.e. a task not possible to automate.
e. Based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.

6. Examples

1. Basic Test Cases for Fan 1. It should have a hook for hanging in the roof.
2. It should have minimum three blades.
3. It should be moving once the electricity pass into it.
4. Speed of the fan should be controlled by the regulator.
5. It should be stop once the electric switch off.
6. The fan should run with minimum noise.
7. The blades should have proper distance from the ceiling.
8. The fan while in motion, should not vibrate.
9. The color of the fan should be dark.
10. Fan should work in clock-wise direction

2. Basic Test Cases for Credit Card Case 1: Check for invalid Characters in Credit Card.
Description: Enter invalid characters @@@@34534"asd".
Expected Result: Error message should appear informing that invalid value is entered.

Case 2: Check for wrong Credit Card type.
Description: Enter invalid Credit Card type e.g. Enter Am Ex in place of VISA.
Expected Result: Error message should appear informing that invalid Credit Card is entered.

Case 3: Check for wrong Expiry Date.
Description: Select wrong month & year of expiry date.
Expected Result: Error message should appear informing that invalid Expiry date has been entered.

Case 4: Check for CVV number with the invalid characters as well as with the alphabetic & alpha numeric values.
Description: Enter invalid CVV number. Like: ABC or a3c. or @@" or "1".
Expected Result: Error message should appear information. Invalid characters are entered.

Case 5: Check for validation messages while enter wrong billing information.
Description: Check for Maximum & Minimum value acceptance. Check for invalid Characters. Check for Numeric value acceptance where numeric values are required & vice-versa.
Expected Result: Error message should appear while enter invalid values.

3. Basic Test Cases for Printer 1) Open page setup by selecting File>Page Setup
Expected Result: Page Setup dialog appears

What to Print
2) In Page Setup, select Orientation = Portrait, Margins = 10 for Top, Bottom, Right, Left. Click OK.Expected Result: Error: “The margins overlap or they are off the paper. Enter a different margin size.” Click OK

3) Now select Orientation =Landscape
Expected Result: Notice that all margins are automatically reset to default values.

4) In Page Setup, click on Printer. In Printer, select a printer from the Name list., then click on Properties. Expected Result: Verify that the selected printer's name is displayed as part of the title of Document Properties popup.

5) In Document Properties, leave defaults as is (Portrait, None, Front to Back). On the Layout tab, click OK to close all popups belonging to Page Setup. File>Print. In Print, click on Properties. In Document Properties, select Landscape, Flip on Long Edge, and Pages Per Sheet = 2.. Click OK
Expected Result: Notice that printout is based on the settings in File>Print, i.e. This setup override the one in Page Setup.

Miscellaneous Cases:
6) Make changes to the setting and click the Default button
Expected Result: Settings should revert to defaults

7) Switch to a different printer
Expected Result: When printed, the diagram should be sent to alternate printer

8) Switch to the plotterExpected Result: When printed, the diagram should be sent to the plotter

9) Switch to a color printer
Expected Result: When printed, the diagram should be sent to the color printer

10) Change the paper size
Expected Result: When printed, the diagram should appear on the correct paper size

11) Switch to portrait orientationExpected Result: When printed, the diagram should appear in portrait orientation

12) Switch to landscape orientation
Expected Result: When printed, the diagram should appear in landscape orientation

Other Printer Test Cases:
Case 1: Ensure correct behavior of application with Print functionality.

Steps:

1. Verify that printer is connected with machine.

2. Open the application and click on Print. Verify printouts in all the views.

Case 2: Ensure that application behaves correctly if printer is not available. Steps:1. Verify that no printer is connected with machine. 2. Open the application and click on Print. 3. Verify that proper message appears for printer unavailability.

Case 3: Ensure that application queues prints in printer if papers are not available in printer.

Steps:

1. Verify that printer is connected with machine.

2. Verify that no papers are available.

3. Open the application and click on Print. Verify that all the prints which were in queue.

Case 4: Ensure correct behavior of application if printer is uninstalled.

Steps:

1. Verify that printer is uninstalled from machine.

2. Open the application and click on Print.

3. Verify that proper message appears for printer unavailability.

Case 5: Ensure correct behavior of Print functionality with new installed printer. Steps:

1. Verify that printer is uninstalled from machine.

2. Now, install printer on machine.

3. Open the application and click on Print.

4. Verify printouts in all the views.

4. Basic Test Cases for Paging Functionality Condition: Qty available is given and we have to fill Qty we want (Reffer iReuse.com paging)

Test Case 1:
1. Try to enter Qty we want more than Qty available (this should not happend).
2. Try to enter alphabets (this should not happend).
3. Submit without entering anything.

Test Case 2:
1. Select page 1 enter items.
2. select page 2 enter items.
3. Click again on page 1 and see if this remembers same entered items.
4. Click again on page 2 and see if this remembers same entered items.
5. Submit, check the email and match result.

Test Case 3:
1. Select page 1 do not enter items.
2. select page 2 enter items.
3. Click again on page 1 and now enter items.
4. Click again on page 2 and see if this remembers same entered items. Then change some items.
5. Submit, check the email and match result.

Expected critical errors: Sometime items exchanged the values from different pages.

5. Test Cases for Upload Images 1. Upload files with extensions like .jpg, .jpeg, .gif, .png, .bmp).
2. Upload files with extensions like .jPg, .JpeG, .GIf, .pNg, .bmP).
3. Upload files with extensions like .JPG, .JPEG, .GIF, .PNG, .BMP).
4. One thing we have to keep in mind while testing files uploading that we also should have to test files with long names.

Note: I had received the server error when uploading with long file name while functionality was working file with small filename. Also I received the server error when used .JPG, but application was working fine with extension .jpg.

Related Testing Topic:
a. Black Box testing

Testing Concepts

2009-09-18T21:49:00.000-07:00

1. SDLC

a. Feasibility study

b. Requirements analysis

c. Systems design: Describes desired features and business rules

d. Implementation: The real code is written here.

e. Integration and testing: Brings all the pieces together

f. Acceptance, installation, deployment

g. Maintenance

2. STLC

a. Requirements Analysis

b. Test Planning

c. Test Development

d. Test Execution

e. Bug Reporting and Result Analysis

f. Defect Retesting and Regression testing

3. Test Plan

a. Table of Contents
b. Objective of testing
c. Personnel responsible for each task
d. Personnel contact-info
e. Relevant naming conventions
f. Features to be Tested, Features not to be Tested
g. Assumptions and dependencies
h. Test environment - hardware, operating systems, Browsers etc
i. Project risk analysis
j. Initial smoke testing period and criteria
k. Process used to manage the bugs
l. Test suspension and restart criteria
m. Duration of test

4. Test Case

a. Component Name

b. Prerequsitie

c. Test Cases Steps

d. Expected Result

e. Status

f. Comments

5. Bug Life Cycle

a. New

b. Assigned

c. Resolved

d. Verified

e. Closed

f. Reopen

6. Testing Techniques (Testing approach)

The most popular Black box testing techniques are:

1. Equivalence Partitioning

2. Boundary Value Analysis

3. Error-Guessing

7. Testing Tools

1. Bug Tracking Tool: Bugzilla

2. Recording the bug in video format: Screencast-o-matic

3. Tool for taking Screen-shots for reporting the bug: Fireshot

4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab

5. Tool to Monitor CSS and HTML: Firebug

6. Tool to ensure valid HTML: HTML Validator

7. Performance Testing tool: Page Speed by Google

8. To find Broken Links: Pinger Ad-on and brokenlinkcheck

9. For checking the spelling of content: Spell Check

8. Severity: Determines the defect's effect

Priority: Determines the defect urgency

9. Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server.

10. Testing Process

a. GUI Testing

a. Content should be correct.

b. Wrap-around properly.

c. Switch images off for ALT texts

d. Switch JavaScript off and See if appropriate messages are displayed to user.

e. Check sensible page titles.

b. Usability Testing

a. Participation of QA and Designers

b. Participation of sample end user

c. Observation by test morderator

d. Development of research questions

e. Recomendation of improvements to the design of the product

c. Functional Testing

a. Check for broken links.

b. Validate the HTML (Validator W3).

Functional testing types:

a. Smoke testing / Sanity testing

b. Usability Testing

c. Regression Testing

d. Pre User Acceptance Testing which includes Alpha and Beta

e. User Acceptance Testing

f. Localization Testing

Non-functional testing types:

a. Load, Stress, Performance, Volume Testing

b. Compatibility

c. Security Testing

d. Installation Testing

d. Interface

a. Data display on browser should match with data available on server.

e. Compatibility

a. Windows

b. Browsers

f. Security Testing

a. Limit the number of tries.

b. Verify rules for password selection.

c. Is there a timeout limit?

d. Paste internal url directly without log-in

e. Test if SSL is used for security measures.

f. Type a single quote

g. SQL Injection: Try submitting following: (') single quote

h. Session hijacking: If your app has a session identifier number in the URL decrease that number

g. Performance

a. Can your site handle a large amount of users requesting a certain page.

b. Long period of continuous use: Is site able to run for long period, without downtime.

c. Apply Web page performance (speed) Tool

Performance Testing: The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.
Load test: To verify application behavior under normal and peak load conditions
Stress Testing: To determine application’s behavior when it is pushed beyond normal or peak load conditions.
Here are some ways in which stress can be applied to the system:
a. double the baseline number for concurrent users/HTTP connections
Volume testing:
a. testing a word processor by editing a very large document
b. testing a printer by sending it a very large job
Capacity test: To determine how many users and/or transactions a given system will support and still meet performance goals.

If chair is designed for 100 kg weight, and my weight is 70 kg then that testing is called as normal testing. If my weight is 100 kg then that testing is called as load testing. If my wt is 120 kg then that testing called as stress testing.

11. Smoke testing A smoke test is a cursory examination of all of the basic components of a software system to ensure that they work. Typically, smoke testing is conducted immediately after a software build is made. It ensures that the future testing is not blocked.

12. System testing
Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing is actually done to the entire system against the Functional Requirement Specification(s) (FRS) and/or the System Requirement Specification (SRS).

Types Of System Tests:

a. Functional testing
b. User interface testing
c. Usability testing
d. Compatibility testing
e. Security testing
f. Performance testing
g. Sanity testing
h. Regression testing
i. Installation testing

13. Defect or Bug density: Defect density is equal to the ratio of number of defects to the number of lines of code.

DD=Total Defect/KLOC( Kilo lines of Code)
Ex: Suppose 10 bugs are found in 1 KLOC
Therefore DD is 10/KLOC (Kilo lines of code)

14. Traceability Matrix - Requirement Traceability matrix (RTM)
Traceability matrix is a matrix which is used to keep track of the requirements. It is a mapping between the requrements and test cases, we will do this for identify missing test cases.

Exact requirements from the requirement doc given by the client are copied in this matrix. These requirements are assigned a unique number and the remark as testable or not. Against each testable requirement test objective and test case is identified. It is highly possible that for one req there could be multiple test objectives and test cases. For each of the test objective and test case unique number is assigned.

Advantages:
a. We can trace the missing test cases.
b. Whenever requirements changes then we can easily refer to matrix document, change the usecase and go to corresponding testcases and change them.
c. Easy to test any functionality. Only we need to refer matrix document and we can reach to related test cases.
d. We can trace the impact of functionalities on one another. Because different functionalities can have same test cases.

15. Bug: A software bug is the common term used to describe an error, mistake, failure, or fault in a computer program.

16. Monkey Testing

Monkey Testing is random testing.

a. Dumb Monkeys: A dumb monkey doesn't know anything about the software being tested; it just clicks or types randomly.

b. Semi-Smart Monkeys: Add logging to your monkey so that everything it does is recorded to a file. When the monkey finds a bug, you need only to look at the log file to see what it was doing before the failure.

Another solution to track what your monkey does is to set up a video camera to record what happens on the screen. When you notice that the software has failed, just rewind and replay the tape.

c. Smart Monkeys: A true smart monkey knows Where he is, What he can do there, Where he can go, Where he's been, If what he's seeing is correct.

A smart monkey isn't limited to just looking for crashing bugs, either. It can examine data as it goes, checking the results of its actions and looking for differences from what it expects.

17. Web Testing: Web testing nothing but Browser applications testing. They are usually a most visible, widely-used - and potentially most vulnerable - applications.

18. Server Side Interface: In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.

19. Client Side Compatibility: The client side compatibility is also tested in various platforms, using various browsers etc.

20. Desktop – Client server – Web Applications

Desktop application runs on personal computers and work stations.
Client server application you have two different components to test. Application is loaded on server machine while the application (exe) on every client machine.
Web application: Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers and different Operating Systems.

21. Why are there so many software bugs?

a. Unclear software requirements because there is miscommunication as to what the software should or shouldn’t do.
b. Software complexity.
c. Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
d. Changing requirements



Related Testing Topics:
a. Black Box testing
b. Web Testing Checklist
c. Desktop App Testing Checklist

2009-07-27T08:37:00.000-07:00

Testing Experiences

1) Sometimes we are able to reproduce a bug but we do not find a proper scenario to reproduce it because of its intermittent occurrence:

I faced the similar problem while Ad-hoc teasing on a desktop application. I was getting crash on it while scrolling the tiles. But I was not able to reproduce it because of its rare occurrence. Then I decided to call other QC Engineer and I told him to do Monkey testing on it. While he was testing it randomly without any scenario, I was observing him. He was able to reproduce that issue couple of times. At one point of time I caught the exact scenario by which crash was occurring. Then I realized that sometimes Monkey testing is very helpful to trace a bug.

2) While working on a website, new functionality was implemented i.e. uploading the image from admin section which will be seen at client side.

Smoke testing which is performed to ensure that application is ready for further testing was completed. Then Regression testing was in progress and we were confident that functionality is working fine. Suddenly I found that while uploading an image, site was crashed out. Before that I had used different types and sizes of images which were uploaded successfully without any crash on it. I was not able to understand why web page is crashing because same size and same type of images were easily uploading before. Then I stopped doing teasing and sit alone for sometime. Suddenly one point clicked on my mind and I enabled the extension option for files from the system. Then I found that its extension was in upper case (.JPG). Because of that application was crashing.

After few months I was assigned another application with similar feature on it. During Sanity Testing, first of all I executed the same scenario because of which I have faced lot of problem few months back. I changed the extension of .gif image to .GiF and tried to upload the image and found that crash occurs. Because of my past experience, I have reported this bug in early stage before starting the regression testing and saved the valuable time.

3) During my past experience I have realized that its very important that how to report a bug then how to communicate with developer and telling him about the bug.

As a Software Tester when we found a bug and report in bug tracking tool like in Bugzilla. But its our duty that we should describe steps to reproduce to developer when he need it. While doing this, we should consider few points:

a. We should know that developers treat software as their kid.

b. Nobody is allowed to tell them that their baby is ugly. By keep in mind this, we should tell him that if he will fix this bug, his baby (software product) will look beautiful.

c. Means we should be polite while addressing the developer.

d. We should not argue with them unnecessarily.

e. We should make them feel that QA Engineers are their friends and are here to help them so that software product will become Quality Software Product.

4) Database testing plays an important role while testing the application.

During testing a tool in which we have to create number of projects and hundreds of rows for each project. It became easier for us when we started using database queries to Create, update and delete the projects and rows. Otherwise it could take hours to create many projects for further testing. We have also used Code injection technique i.e. SQL injection that exploits a security vulnerability occurring in the database of web application. We use the SQL injection commands for security purpose to ensure that nobody can attack or harm the data of the database.

Related Testing Topic:

a. Black Box testing

Having Other People Test Your Software

2009-07-27T07:48:00.000-07:00

In one minute, try to find as many differences between the two scenes as you can.

After you finish looking, have several friends do the same. What you'll find is that everyone has very different results. The number of differences found, the order that they were found, even which ones were found will be different.

Combine all the lists and throw out the duplicates, you'll have a complete list.

Software testing works exactly the same way. You're likely under a tight schedule, you find as many bugs as possible in the time you have, but someone else can come in, test the same code, and find additional bugs.

It's easy to fall into the trap of wanting to be solely responsible for testing your own piece of the software, but don't do it. There's too much to gain by having others help you out.

Watching how someone else approaches a problem is a great way to learn new testing techniques.

Related Testing Topic:
a. Black Box testing
b. Testing Experiences

Test Strategy vs Test Plan

2009-03-18T00:16:00.000-07:00

Test Strategy: The test strategy describes the approach that the test team will use to test the software. If you were presented with a product to test, you'd need to decide if it's better to use black-box testing or white-box testing.

Once you decide test strategy then you can plan what are the modules you want to test, schedules, risks etc. This need prepared one more document for test plan. Some companies have a strategy or approach section in the test plan, others have a seperate document.

Test Plan: Test Plan is used to organize testing activities. Elements used in test plan:

a. Table of Contents
b. Objective of testing
c. Personnel responsible for each task
d. Personnel contact-info
e. Relevant naming conventions
f. Features to be Tested, Features not to be Tested
g. Assumptions and dependencies
h. Test environment - hardware, operating systems, Browsers etc
i. Project risk analysis
j. Initial smoke testing period and criteria
k. Process used to manage the bugs
l. Test suspension and restart criteria
m. Duration of test