Checklist to start Testing.

If you are going to start on a new project than Don’t forget to check this Testing Checklist in each and every step of your Project life cycle.

List is mostly equivalent to Test plan, it will cover all quality assurance and testing standards.

Testing Checklist:
1 Create System and Acceptance Tests.
2 Start Acceptance test Creation.
3 Identify test team .
4 Create Workplan.
5 Create test Approach.
6 Link Acceptance Criteria and Requirements to form the basis of.
acceptance test.
7 Use subset of system test cases to form requirements portion of.
acceptance test.
8 Create scripts for use by the customer to demonstrate that the system meets.
requirements.
9 Create test schedule. Include people and all other resources.
10 Conduct Acceptance Test.
11 Start System Test Creation.
12 Identify test team members.
13 Create Workplan.
14 Determine resource requirements.
15 Identify productivity tools for testing.
16 Determine data requirements.
17 Reach agreement with data center.
18 Create test Approach.
19 Identify any facilities that are needed.
20 Obtain and review existing test material.
21 Create inventory of test items.
22 Identify Design states, conditions, processes, and procedures.
23 Determine the need for Code based (white box) testing. Identify conditions.
24 Identify all functional requirements.
25 End inventory creation.
26 Start test case creation.
27 Create test cases based on inventory of test items.
28 Identify logical groups of business function for new sysyem.
29 Divide test cases into functional groups traced to test item inventory 1.30 Design data sets to correspond to test cases.
31 End test case creation.
32 Review business functions, test cases, and data sets with users.
33 Get signoff on test design from Project leader and QA.
34 End Test Design.
35 Begin test Preparation.
36 Obtain test support resources.
37 Outline expected results for each test case.
38 Obtain test data. Validate and trace to test cases.
39 Prepare detailed test scripts for each test case.
40 Prepare & document environmental set up procedures. Include back up and
recovery plans.
41 End Test Preparation phase.
42 Conduct System Test.
43 Execute test scripts.
44 Compare actual result to expected.
45 Document discrepancies and create problem report.
46 Prepare maintenance phase input.
47 Re-execute test group after problem repairs.
48 Create final test report, include known bugs list.
49 Obtain formal signoff.

How to do Testing Without a Formal Test Plan?

Testing always requires a formal plan. But there are circumstances where testers need to skip plans to achieve their targets assigned and the tips below will help testers to work without a formal plan.

1) Finding High Level Functions
As always high level functions are of central purpose to the site or an application, modify those functions based on the priority frequently according to their significance to a user's ability. Determine the test direction as soon as possible to see changes happening rapid.

2) Test Before Display
Before the product is being displayed test it using different browsers and platforms also use designers and developers to review the tests. This is an instant where testers run out of time and they need to test without a formal plan.

3) Concentrate on Ideal Path Actions
Testers should assume themselves as users, focus on the ideal path and identify those factors most likely to be used in a majority of user interactions. Get to know about the sections where the user makes a frequent visit, because most of the user doesn't think the same way hence make a set of guess based on user's interest when he visits your website.

4) Focus on Intrinsic Factors
Intrinsic factors are internal and it can be fixed only by the tester also the user can do nothing with it. Hence these factors require an immediate attention before the error reflects in the user's end. These errors are time sensitive hence it needs to be fixed without a formal plan.

5) Boundary Test from Reasonable to Extreme
The systematic testing of error handling is called boundary testing. Unknown values may choke the system therefore start with all you know when you perform a boundary test. Finding reasonable and predictable mistakes is a better way to perform a progressive boundary test.

6) Good Values
Always use valid and current information. Enter in data formatted as the interface requires. Include all required fields all these good values will help testers to make less errors.

7) Reasonable and Predictable Mistakes
It is easier for testers to predict errors done based on design especially with interface interpretation. These errors are very common and occur frequently due to complex design in fact it is easy to fix without a formal plan.

8) Extreme Errors and Crazy Inputs
Testing for maximum size of inputs, long strings of garbage, numbers in the text fields and text in numeric fields will reduce extreme errors, proceed from most likely to less likely to save time.

9) Compatibility Testing from good to bad
It is always good to start a test with the configurations which is more familiar. Therefore when you test a cross platform application begin your testing process with the most used browser and then with least used browser.

10) Expected Bad Values
A tester should make sure that an error message pops out each time when some invalid entries are entered in places like online forms. Such test cases don't require a formal plan. A tester can easily give random values to test the application.

Ten Commandments of Software Testing

"Software Testing is a systematic activity but it also involves economics and human psychology."

Economics of software testing is to determine and predict the faults of the system early by using foreseeable models and applying structured test strategies and test methodologies to discover those at early phases of the software development life cycle.

Psychology of testing is to destructively test the application by identifying as many exceptional or out of the box scenarios or sometimes called as the third vision.

A set of good test scenarios evaluates every possible permutations and combinations of a program during ideal conditions. In addition, Software Test Engineer needs the proper vision to successfully test a piece/whole application to comply with the Standards and the Quality.

Whenever Software Test Engineer tests a program, they should add some value in it rather than performing only the requirements conformance and validation. A systematic and well planned test process adds the value of quality and reliability of the software program.

The most important considerations in the software testing are the issues of psychology, leading to the set of principles and guidelines to evaluate software quality:

1. Testing is the process of experimenting a software component by using a selected set of test cases, with the intent of revealing defects and evaluate quality Software Test Engineer executes the software using test cases to evaluate properties such as reliability, usability, maintainability, and level of performance. Test results are used to compare the actual properties of the software to those specified in the requirements document as quality goals.

Deviations or failure to achieve quality goals must be addressed. Software Testing has a broader scope rather being only limited to the execution of program or detecting errors more rigorously as described in the test process improvement models such as TMMi framework models.

2. When the test objective is to detect defects, then a good test case is one that has a high probability of revealing a yet undetected defect(s).

Principle 2 supports a strong and robust designing of test cases. This means that each test case should have a goal to identify or detect a specific type of defect. Software Test Engineer approaches the scientific method of designing the tests to prove or disapprove the hypothesis by the means of test procedures.

3. A test case must contain the expected output or result. Principle 3 supports the fact that a test case without expected result is of zero value. Expected output or result determines whether a defect has been revealed or the conditions have been passed during the execution cycle.

4. Test cases should be developed for both valid and invalid input conditions. Use of test cases that are based on invalid inputs is very useful for revealing defects since they may exercise the code in unexpected ways and identify unexpected software behaviour. Invalid inputs also help developers and Software Test Engineers to evaluate the robustness of the software, that is, its ability to recover when unexpected events occur (in this case an erroneous input).

For example, software users may have misunderstandings, or lack information about the nature of the inputs. They often make typographical errors even when complete/correct information is available. Devices or software program may also provide invalid inputs due to erroneous conditions and malfunctions.

5. The probability of the existence of additional defects in a software component is proportional to the number of defects already detected in that component. Principle 5 supports to the fact that the higher the number of defects already detected in a component, the more likely it is to have additional defects when it undergoes further testing.

For example, if there are two components A and B, and Software Test Engineers have found 20 defects in A and 3 defects in B, then the probability of the existence of additional defects in A is higher than B. This empirical observation may be due to several causes and degree of influence of the software factors. Defects often occur in clusters and often in code that has a high degree of complexity and is poorly designed.

6. Test Cases must be repeatable and reusable. Principle 6 is utmost important and plays a vital role supporting the fact that it is also useful for tests that need to be repeated after defect repair. The repetition and reuse of tests is also necessary during regression test (the retesting of software that has been modified) in the case of a new release of the software.

7. Testing should be carried out by a group that is independent of the development group. This principle holds true for psychological as well as practical reasons and does not say that it is impossible for a programming organization to find some of its errors, because organizations do accomplish this with some degree of success. Rather, it implies that it is more economical for testing to be performed by an objective, independent party which gives a direction of the third vision by the means of test cases. Finally, independence of the testing group does not call for an adversarial relationship between developers and Software Test Engineers.

8. Test Activities should be well planned. Test plans should be developed for each level of testing, and objectives for each level should be described in the associated plan. The objectives should be stated as quantitatively as possible. Plans, with their precisely specified objectives, are necessary to ensure that adequate time and resources are allocated for testing tasks, and that testing can be monitored and managed.

Test planning must be coordinated with project planning. A test plan is a roadmap for the testing which should be mapped to organizational goals and policies pertaining to the software program.

Test risks must be evaluated at each levels of testing. Careful test planning avoids wasteful "throwaway" tests and unproductive and unplanned "test-patch-retest" cycles that often lead to poor-quality software and the inability to deliver software on time and within budget.

9. Avoid throwaway test cases unless the program is truly a throwaway program. Whenever the program has to be tested, the test cases must be reinvented. More often than not, since this reinvention requires a considerable amount of work, Software Test Engineer tends to avoid it. Therefore, the retest of the program is rarely as rigorous as the original test, meaning that if the modification causes a previously functional part of the program to fail, this error often goes undetected.

10. Test results should be inspected meticulously. This is probably the most obvious principle, but again it is something that is often overlooked.

Weve seen numerous tests that show many subjects failed to detect certain errors, even when symptoms of those errors were clearly observable on the output listings. Put another way, errors that are found on later tests are often missed in the results from earlier tests.

For example:

I. A failure may be overlooked, and the test may be granted a "PASS" status when in reality the software has failed the test. Testing may continue based on erroneous test results. The defect may be revealed at some later stage of testing, but in that case it may be more costly and difficult to locate and repair.

II. A failure may be suspected when in reality none exists. In this case the test may be granted a "FAIL" status. Much time and effort may be spent on trying to find the defect that does not exist. A careful re-examination of the test results could finally indicate that no failure has occurred.

Summarizing all the above principles, Testing is an extremely creative and intellectually challenging task. Creativity required in testing a large program exceeds the creativity required in designing or developing that program. We already have seen that it is impossible to test a program sufficiently to guarantee the absence of all errors. This requires a systematic test process and methodologies to design the robust test cases.

This principle supports that:

A Software Test Engineer needs to have comprehensive knowledge of the software engineering discipline.

A Software Test Engineer needs to have knowledge from both experience and education as to how software is specified, designed, and developed.

A Software Test Engineer needs to have knowledge of fault types and where faults of a certain type might occur in code constructs.

A Software Test Engineer needs to reason like a scientist and propose hypotheses that relate to presence of specific types of defects.

A Software Test Engineer needs to have a good grasp of the problem domain of the software that he/she is testing.

A Software Test Engineer needs to create and document test cases. To design the test cases the Software Test Engineer must select inputs often from a very wide domain.

A Software Test Engineer needs to design and record test procedures for running the tests.

A Software Test Engineer needs to execute the tests and is responsible for recording results.

A Software Test Engineer needs to analyze test results and decide on success or failure for a test. This involves understanding and keeping track of an enormous amount of detailed information.

A Software Test Engineer needs to know the method for collecting and analyzing test related measurements.

Common programming bugs that every Software Tester should know.

Basically this is more useful for programmers but I think software testers can get insight on how developers can unknowingly leave bugs in software programs.

Each bug listed in this resource can lead to serious software vulnerabilities if not fixed. The top 12 security bugs list will help programmers to avoid some common but serious coding mistakes. For software testers list will be useful as a security testing checklist for Internet as well as for testing desktop application.

Here are few top security vulnerabilities discussed in detail in this article:

1. Improper input validation
2. Improper escaping of output or encoding
3. SQL injection
4. Cross-site scripting
5. Race conditions
6. Information leak in error messages
7. Error while transmitting sensitive information
8. Memory leak
9. External control of critical data and file paths
10. Improper initialization
11. Improper authorization
12. Client side security checks

The most common security vulnerability mistake developers make is “Client side enforcement of server side security”.

Usage-Based Statistical Testing

Usage-based testing is actually software for client usage. In case if any flaws are detected by patrons, some information about them can be reported to software vendors and integrated fixes may be formed and delivered to all the clients to avoid such defects.

However, because of the enormous quantities of software installations software bugs correcting after release could be very costly and frequent fixes could also harm the software vendor's reputation and long-term business vivacity.

A new product's expected usage can be captured and used in product consistency and software testing could be most straightly assured.

In usage-based statistical testing the testing environs looks like the definite operational environment for the software in the field & the overall testing sequence, as represented by the systematic implementation of specific test cases in a test suite. Test cases also resemble the usage scenarios, templates of actual software usage and sequences by the target customers. Because of the huge quantity of clients and diverse usage templates cannot be captured in an execution set of test cases. This is why one uses the term "statistical" in this tactic and terms the same as "random testing."

Most apposite to the final phase of software testing is commonly known as Usage-based statistical testing and is usually referred to as acceptance testing right before product release, so that stopping testing is of equivalent value to the product release.

7 Deadly Sins in Automated Testing

Automated testing is considered by companies as an easy way out to deliver high quality software and products, reducing testing costs and increase efficiency. But the truth is, not all bugs are found by automated testing, so it is very important to realize what can go undetected.

1. Over indulging on propriety testing tools
Many commercial testing tools provide simple features for automating the capture and replay of manual test cases. While this approach seems sound, it encourages testing through the user-interface and results in inherently brittle and difficult to maintain tests. Additionally, the cost and restrictions that licensed tools place on who can access the test cases is an overhead that tends to prevent collaboration and team work. Furthermore, storing test cases outside the version control system creates unnecessary complexity. As an alternative, open source test tools can usually solve most automated testing problems and the test cases can be easily included in the version control system.

2. Too lazy to setup CI server to execute tests
The cost and rapid feedback benefits of automated tests are best realised when the tests are regularly executed. If your automated tests are initiated manually rather than through the CI continuous integration system then there is significant risk that they are not being run regularly and therefore may in fact be failing. Make the effort to ensure automated tests are executed through the CI system.

3. Loving the UI so much that all tests are executed through the UI
Although automated UI tests provide a high level of confidence, they are expensive to build, slow to execute and fragile to maintain. Testing at the lowest possible level is a practice that encourages collaboration between developers and testers, increases the execution speed for tests and reduces the test implementation costs. Automated unit tests should be doing a majority of the test effort followed by integration, functional, system and acceptance tests. UI based tests should only be used when the UI is actually being tested or there is no practical alternative.

4. Jealously creating tests and not collaborating
Test driven development is an approach to development that is as much a design activity as it is a testing practice. The process of defining test cases (or executable specifications) is an excellent way ensuring that there is a shared understanding between all involved as to the actual requirement being developed and tested. The practice is often associated with unit testing but can be equally applied to other test types including acceptance testing.

5. Frustration with fragile tests that break intermittently
Unreliable tests are a major cause for teams ignoring or losing confidence in automated tests. Once confidence is lost the value initially invested in automated tests is dramatically reduced. Fixing failing tests and resolving issues associated with brittle tests should be a priority to eliminate false positives.

6. Thinking automated tests will replace all manual testing
Automated tests are not a replacement for manual exploratory testing. A mixture of testing types and levels is needed to achieve the desired quality mitigate the risk associated with defects. The automated testing triangle originally described by Mike Cohn explains the investment profile in tests should focus at the unit level and then reduce up through the application layers.

7. Too much automated testing not matched to defined system quality
Testing effort needs to match the desired system quality otherwise there is a risk that too-much, too-little or not the right things will be tested. It is important to define the required quality and then match the testing effort to suit. This approach can be done in collaboration with business and technical stakeholders to ensure there is a shared understanding of risks and potential technical debt implications.

Seven Mistakes in Software Testing

Trial and error method is the best way of testing, but repeatedly not fixing of errors would ruin the efforts taken in testing and is a mere waste of time. Software Testing engineers while testing make small mistakes unintentionally which seems to be insignificant but are of high importance.

The following are the mistakes we usually find in software testing:

The first mistake:

Unit Testing is a method by which smallest testable part of an application of source code are tested to determine if they are fit for use. By just calling all utility methods, it's easy to test a utility class, passing some values and examining if the expected result is returned.

A first mistake arises here. Majority of the developers don't think out of the box, or not adequate.
Developers can test that 1 + 1 =2, that 2 + 1 = 3 and that 3 + 1 = 4. But what is the use of doing nearly 3 times the same test? Testing boundary cases is better. Are the arguments of the sum ( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?

The second mistake:

Mocks - For example the service layer is unit tested, all other components like the DAO layer should be mocked. Manually in many cases it's been done. That's the second mistake.

It's much better to use mocking frameworks because when one mocks stuff manually the mocks are tightly coupled to the implementation as they are made for it. Just believe that they will create the mocks the way they want. Some mocking frameworks are capable of doing more than others; some are easier to use than others. Some of the best mocking framework is Mockito and EasyMock. Mockito is preferred because of its power and simplicity and EasyMock is by far the best known but it's a bit complex too to use. So it's not only a matter of choosing a mocking framework. It's also a matter of choosing the right one.

The third mistake:

Integration Tests are the tests over different integrated parts of an application while unit tests only tests a LUW (logical unit of work). In integration tests - the best known type of are tests of the DAO layer.

In these tests, multiple things are validated:

The input parameters,
The use of the ORM tool
The correctness of the generated query (functional)
If the DB can be accessed
The fact that the query is working and
The fact that the correct ResultSet is returned.

The third mistake that is made often is that in the dbUnit XML dataset developers provide test data. Most of the time this data has no representation of live data; the best way to handle this is to make functional-providing people and maintaining this test data. Because one doesn't want to make them struggle with a specific XML format, good practice is to use the XlsDataSet format (Excel Sheet).

The fourth mistake:

Functional Tests are forgotten too often because the perception is that they are difficult and expensive to maintain. It's true that we'll have to tweak to make them maintainable but executing all the same tests manually over and over again will cost much more. Also when functionality is tested and automated by means of continuous integration, there's no need for stress for screens/ functionality that will be broken in the next release.

Selenium is a great framework that is able to record functionality in the browser. The fourth mistake is made here. Most people will just record and replay the tests the way they are. Selenium--HTML components by their HTML id can be tracked. If developers don't specify id's in their HTML code, they can easily change if a page is updated. This will break the tests immediately even when functionality still works.

The fifth mistake:

This mistake is made in a JUnit test by just pasting the recorded test. Login and logout are common functionalities, the time to wait for a response, should be added to a superior level.
For example, a login can be done before each test, afterwards a logout is done. This way, if something changes in login or logout functionality, tests won't break.

The sixth mistake:

Absence of testing logical flows sixth mistake happens. It's perfectly possible that an insert, a search, an update, and a delete work on their own but that the complete flow from the creation, search, and update until delete of the same entry won't work. The great way to group multiple tests and run them in sequence all together is by the TestSuites.

The seventh mistake:

BDD (Behavior Driven Design) Instead of functional tests most of the tests are technical tests. To test logical behavior than to test if the things work technically is much more important. That can be done by means of Behavior Driven Design. Given some things, when an event occurs, then what should be the outcome? Mockito has some great stuff to easily write tests in a BDD way.

Cookie Testing – How to do Cookie Testing?

What is Cookie?

Cookie is to be known as text a file that gets saved in the hard disk of the user’s system. Browsers are required to use the cookies which have been saved in the desired location. Informative data is recorded in the cookie and that can be retrieved for the web pages.

How to do Cookie Testing?

Being a tester, testing for the cookies is very essential since there are many web applications which include informative content and payment transactions. Below are the steps which should be considered while doing testing:
Major cookie testing involves disabling the cookie from the option available in every browser. You need to make sure that cookies are disabled and access the respective website and check the functionality of the pages that are working properly or not. Browse the whole website and see for crashes. Basically, message should be displayed as “Cookies are disabled. Please enable the cookies to browse the website easily”.
Another testing should be performed after corrupting the cookies. For corrupting the cookies you make sure the location of the cookies and manually edit respective cookie with fake figures or with any invalid data and save them. In some cases, internal information of the domain can be easily accessed/ hacked with the help of corrupted cookies. If you are testing banking or finance domain then this point should come first in your checklist.
Remove all the cookies for the website you are testing and check all the website pages that are working properly.
Cookie testing can be performed on different browsers to check whether the website is writing the cookies or not. You can check cookies manually for the existence for each and every page.
If you are testing an application which authenticate login then get logged in with valid details. You will see the Username parameter in the address bar and can change it to see the behavior of the application. You should not get logged into different user’s account. Proper message is getting displayed or not for the action you have performed.

Therefore, above discussed is the most important cookie testing concepts that tell how to do cookie testing. Cookie testing is really necessary and it should not be missed from the hands of testers while testing any web application. Cookie testing really make the application more stable if any issues found.

GUI Testing Checklist

GUI Testing Checklist

Ideally, motive of the GUI testing is to recognize your application which is according to the specific standards for graphical user interface. These checklists would be beneficial for the QA and development team. Checklist must be comprises of all the GUI components that will be tested systematically. Below is the checklist which is really beneficial for every tester to perform under GUI testing for specific application:

Colors used in the web application:
Check the colors for the hyperlinks.
Background color for all the pages should be tested.
Color for the warning message should be checked.

Content used in the web application:
Font on the whole website should be same according the requirements.
Check that content is properly aligned or not.
All the labels should be proper aligned
Check all the content for respective words to be in lower and upper case.
Check all the error message on the screen and should not have any spelling mistake.

Images used in the web application:
Check all the graphics should be proper aligned.
Check for the broken images all over.
Check the size for the graphics used or uploaded.
Check all the banners and their size.
Check the buttons for the respective command like size, font and font size.

Navigation in the application:
All the tabs should be loaded on time.
Tabs should be displayed in sequence.
All the tabs from the left to right should be correct according to the requirements.
Check scrollbar is getting displayed if required.
Check all the links given in the sitemap and see for broken links.

Usability in the application:
Check the font size and it should be readable.
Check the spelling for all the fields that they are prompting properly or not.
Check whole website’s look and feel.
Test the website in all resolutions like 640×480 etc.

Hence, if the entire checklist followed then there is no chance of missing any requirement from the hands of tester and developer. It is suggested to draft all the points in the excel sheet and add the columns pass and fail against each checklist. And send the development team after performing testing cycle. There are other tools which are also available and it is apart from the manual testing like web link validator to check broken link and online w3c validator tool for checking usability standards.

How to Perform GUI Testing? Points to take care

How to Perform GUI Testing?

Basically GUI testing is performed to check the user interface and test the functionality working properly or not. GUI testing involves several tasks like to test all object events, mouse events, menus, fonts, images, content, control lists, etc. GUI testing improves the overall look and feel of the application according to the requirements. User interface for the website should be designed to attract the audiences globally. There are both options available to the testers one is manual and second is to automate with the use of an automation tool like QTP. There is planning required for all the stages in testing.

Below discussed points will let to know how to perform GUI Testing:
First of all tester should be aware and understand design documents for the testing application. All the mentioned requirements need to be checked properly with exact figures for font size, images, navigations, controls listed in the application.
Create the environment and test the application in different browsers like Mozilla, IE, Opera, and Safari. Sometimes design for the application does not work or behave properly in other browsers. So, make sure you are testing in all the browsers.
Testers can check manually and if you are finding it difficult to test if application has N number of pages then chooses the option to automate the application. You can easily record the application with all respective controls to test with. And at the end iterations can be checked that they are passed or failed.
Prepare a checklist for the GUI testing since there are many things which is related to the user interface. Make out in one sheet and execute them for the application.
Prepare all the test cases for the user interface to perform the GUI testing effectively.
Tester should divide all the modules which are available in the application and start performing testing module wise. This process can be easily tested and there are high chances of getting defects.

Above mentioned points are very beneficial in performing GUI testing. Tester should be more focussed on how to test the application. Planning to test the system or application is very necessary to achieve the respective goals with the help of GUI testing. Testing should be performed in keeping mind the perspective of the users who will come and use the application. Remember first impression is last impression.

Commands in UNIX

Basic UNIX Commands and there description.

cat --- for creating and displaying short files
Syntax: cat filename
Ex: cat > filename
cat file1 >> file2

chmod --- change permissions for three classes of users: the user (u), group (g), or others (o) by entering
Syntax: chmod ugo filename

cd --- change directory
Syntax: cd directory
EX: From the subdirectory, /users/jones/memos, change to the directory, /users/jones/samples with the command,
cd /users/jones/samples

cp --- for copying files
Syntax: cp [options] old_filename new_filename
Ex: cp file1 file2

ftp --- connect to a remote machine to download or upload files
Syntax: ftp options hostname
options
-d enable debugging.
-g disable filename globbing.
-i turn off interactive prompts.
-v verbose on. show all responses from remote server.
ftp hostname by default will connect you to the system, you must have a login id to be able to transfer the files. Two types of files can be transferred, ASCII or Binary. bin at ftp> prompt will set the transfer to binary. Practice FTP by ftping to nic.funet.fi loggin in as anomymous with password being your e-mail address.

head --- display first 10 lines of a file.
Syntax: head [-count] filename
Ex: If you want first 50 lines you can use head -50 filename or for 37 lines head -37 filename.

ls --- see what files you have
Examples: ls List files in current directory
ls -l Lists files in “long” format

lpr --- standard print command (see also print )
Syntax: [ lpr -P(<--capital P) printername ]

more --- use to read files
Syntax: more filename
More is a command used to read text files. For example, we could do this:
% more poems
The effect of this to let you read the file "poems ". It probably will not fit in one screen, so you need to know how to "turn pages". Here are the basic commands:
q --- quit more
spacebar --- read next page
return key --- read next line
b --- go back one page
For still more information, use the command man more.


mkdir --- create directory
Syntax: [ mkdir directoryname ]

mv --- for moving and renaming files
Syntax:[ mv filename directory OR mv filename newfilename ]

pwd --- find out what directory you are in (will print your home directory on screen).
Syntax: [ pwd ]

rm --- remove a file
Syntax: [ rm filename ]

rmdir --- remove directory
Options:
rm -r directory_name will remove all files even if directory is not empty.
rmdir sandeep is how you use it to remove sandeep directory.
rmdir -p will remove directories and any parent directories that are empty.
rmdir -s will suppress standard error messages caused by -p.

sort --- sort file
Syntax: sort filename
Example : suppose we have a file dict with contents
red rojo
green verde
blue azul
white blanco
black negro
Then we can do this:
% sort dict
black negro
blue azul
green verde
red rojo
white blanco
Here the output of sort went to the screen. To store the output in file we do this:
% sort dict >dict.sorted
You can check the contents of the file dict.sorted using cat , more , or emacs .
tail --- display last 10 lines of a file.
Syntax: tail [-count] filename
Ex: last 50 lines then use ----- tail -50 filename.

telnet --- log in to another machine( remote system)
Syntax:[ telnet hostname ]

wc --- count characters, words, lines in a file depending upon the option.
Syntax: wc [options] filename
Options
wc -l filename will print total number of lines in a file.
wc -w filename will print total number of words in a file.
wc -c filename will print total number of characters in a file.



tar --- create an archive, add or extract files
Use create compressed archives of directories and files, and also to extract directories and files from an archive. Example:
% tar -tvzf foo.tar.gz
displays the file names in the compressed archive foo.tar.gz while
% tar -xvzf foo.tar.gz
extracts the files.


rsh --- remote shell
Use this command if you want to work on a computer different from the one you are currently working on. One reason to do this is that the remote machine might be faster. For example, the command
% rsh solitude
connects you to the machine solitude. This is one of our public workstations and is fairly fast.


setenv --- set an environment variable
Ex:   % echo $PRINTER
labprinter
% setenv PRINTER myprinter
% echo $PRINTER
myprinter


ncftp --- especially good for downloading files via anonymous ftp.
Use ncftp for anonymous ftp --- that means you don't have to have a password.
% ncftp ftp.fubar.net
Connected to ftp.fubar.net
> get jokes.txt
The file jokes.txt is downloaded from the machine ftp.fubar.net.

print --- custom print command (see also lpr )
This is a moderately intelligent print command.
% print foo
% print notes.ps
% print manuscript.dvi
In each case print does the right thing, regardless of whether the file is a text file (like foo ), a postcript file (like notes.ps, or a dvi file (like manuscript.dvi. In these examples the file is printed on the default printer. To see what this is, do
% print
and read the message displayed. To print on a specific printer, do this:
% print foo jwb321
% print notes.ps jwb321
% print manuscript.dvi jwb321
To change the default printer, do this:
% setenv PRINTER jwb321

grep(Global search for Regular Expression and Print.) --- search file
Use this command to search for information in a file or files. For example, suppose that we have a file dict whose contents are
red rojo
green verde
blue azul
white blanco
black negro
Then we can look up items in our file like this;
% grep red dict
red rojo
% grep blanco dict
white blanco
% grep brown dict
%
Notice that no output was returned by grep brown. This is because "brown" is not in our dictionary file.
Grep can also be combined with other commands. For example, if one had a file of phone numbers named "ph", one entry per line, then the following command would give an alphabetical list of all persons whose name contains the string "Fred".
% grep Fred ph | sort
Alpha, Fred: 333-6565
Beta, Freddie: 656-0099
Frederickson, Molly: 444-0981
Gamma, Fred-George: 111-7676
Zeta, Frederick: 431-0987
The symbol "|" is called "pipe." It pipes the output of the grep command into the input of the sort command.
For more information on grep, consult
% man grep


date --- display date (Use this command to check the date and time.)
Syntax : % date
Fri Jan 6 08:52:42 MST 1995

echo --- echo argument
Ex: $ echo This is a test.

UNIX for Software Testers

WHAT IS UNIX?

UNIX is an operating system which was first developed in the 1960s, and has been under constant development ever since. By operating system, we mean the suite of programs which make the computer work. It is a stable, multi-user, multi-tasking system for servers, desktops and laptops.
UNIX systems also have a graphical user interface (GUI) similar to Microsoft Windows which provides an easy to use environment. However, knowledge of UNIX is required for operations which aren't covered by a graphical program, or for when there is no windows interface available, for example, in a telnet session.

TYPES OF UNIX
There are many different versions of UNIX, although they share common similarities. The most popular varieties of UNIX are Sun Solaris, GNU/Linux, and MacOS X.


THE UNIX OPERATING SYSTEM

The UNIX operating system is made up of three parts; the kernel, the shell and the programs.

The kernel

The kernel of UNIX is the hub of the operating system: it allocates time and memory to programs and handles the filestore and communications in response to system calls.
As an illustration of the way that the shell and the kernel work together, suppose a user types rm myfile (which has the effect of removing the file myfile). The shell searches the filestore for the file containing the program rm, and then requests the kernel, through system calls, to execute the program rm on myfile. When the process rm myfile has finished running, the shell then returns the UNIX prompt % to the user, indicating that it is waiting for further commands.

The shell


The shell acts as an interface between the user and the kernel. When a user logs in, the login program checks the username and password, and then starts another program called the shell. The shell is a command line interpreter (CLI). It interprets the commands the user types in and arranges for them to be carried out. The commands are themselves programs: when they terminate, the shell gives the user another prompt (% on our systems).
The adept user can customise his/her own shell, and users can use different shells on the same machine. Staff and students in the school have the tcsh shell by default.
The tcsh shell has certain features to help the user inputting commands.
Filename Completion - By typing part of the name of a command, filename or directory and pressing the [Tab] key, the tcsh shell will complete the rest of the name automatically. If the shell finds more than one name beginning with those letters you have typed, it will beep, prompting you to type a few more letters before pressing the tab key again.
History - The shell keeps a list of the commands you have typed in. If you need to repeat a command, use the cursor keys to scroll up and down the list or type history for a list of previous commands.

FILES AND PROCESSES

Everything in UNIX is either a file or a process.
A process is an executing program identified by a unique PID (process identifier).
A file is a collection of data. They are created by users using text editors, running compilers etc.
Examples of files:
a document (report, essay etc.)
the text of a program written in some high-level programming language
instructions comprehensible directly to the machine and incomprehensible to a casual user, for example, a collection of binary digits (an executable or binary file);
a directory, containing information about its contents, which may be a mixture of other directories (subdirectories) and ordinary files.


THE DIRECTORY STRUCTURE

All the files are grouped together in the directory structure. The file-system is arranged in a hierarchical structure, like an inverted tree. The top of the hierarchy is traditionally called root (written as a slash / )



Commands in UNIX

Test Case For Captcha?

1. Ensure that the CAPTCHA code screen should be viewable.
2. Ensure that the CAPTCHA code should be in Image format.
3. Ensure that the CAPTCHA code should be reusable.(able to get new code by clicked link)
4. Ensure that the CAPTCHA code should generate new code once the page is refreshed.
5. Ensure that the CAPTCHA code should generate new code once entered the wrong code.
6. Ensure that the CAPTCHA code should not able to copy/paste.
7. Ensure that the CAPTCHA code should be Case Sensitive or vice versa(According to the Requirement).
8. Ensure that the CAPTCHA code should not distruot the other fields in the form once entered wrong.(Other form fields should not clear)
9. Application should not accept the Invalid CAPTCHA code on form feed and should display proper alert message.
10. Application should accept the Valid CAPTCHA code on form feed.

Testcase for Yahoo Mail Page after login

Steps:

Testcase1: To verify that when we click mail button whether it list all the compose and check mail etc options or not
Description: click on the mail button
Expected result: Clicking of the mail button lists all the options check mail and compose etc

Testcase2: To verify that when we click check mail option in the mail list whether it takes you to inbox page or not
Description: click on check mail option
Expected result: check mail option opens the inbox page

Testcase3: To verify that when you click the inbox whether it displays u r received mails or not
Description: click the inbox button
Expected result: It lists all the mails u received in the inbox

Testcase4: To verify when u click the compose option in the mail button whether it takes u to compose page where u can compose and send mails
Description: click on the compose option in the mail button
Expected result: it takes u to compose page

Testcase5: To verify that after writing message when you click on ‘Send’ whether mail is sent to the address where you specified
Description: give mail id for which you want to send the message in the ‘To’ field and write the message in compose box and click on send button
Expected result: it sending the mail to the mail id which u are given in the TO field

Testcase6: To verify if you give wrong id whether it gives failure notice or not
Description: Give wrong mail id in compose page in the ‘To’ field and see what happens
Expected result: In your inbox one failure notice will come

Test case for withdraw module in banking project and sending of the emails.

Test case for withdraw module in banking project

Step1: when the balance in the account is nil, try to withdraw some amount (amount>0) should display msg as " insufficient funds in acc"
Step 2: when the account has some balance amount, try to withdraw amount(amount>balance amount in account), should display "insufficient funds in acc"
Step 3: when the account has some balance amount, enter a amount (amount<=balance amount), should withdrawn correct amount from account.
Step 4: when the account has some balance amount, enter the amount as 0, should display msg as withdrawal amount should be > 0 and should be in multiple of hundreds( varies depending on reqs docs).
In the case of Minimum balance mandatory in the Account:
Step 5: When the account has balance amount, try to withdraw whole amount , should display msg as " Minimum balance should be maintained".
Step 6: When the account has balance amount=minimum balance, try to withdraw any amount , should display msg as " Minimum balance should be maintained".

Test cases for sending of the emails?

For testing sending an email you can write test cases for.
1) Performance: By using connections from different ISP's i.e. the speed.
2) If your email id is POP compliant, then check if you can sent it using email clients.
3) If you email can be sent using an attachment.
4) Maximum attachment limit.
5) Maximum mail size.
6) Sending to valid / invalid id's if mail is received / bounced back respectively.

Test Case Samples

Test case for Login window where user name is editable to only upto 8 alpha characters?

1 Enter User Name and press LOGIN Button. User Name= COES. Should Display Warning Message Box "Please Enter User name and Password"

2 Enter Password and press LOGIN Button. Password= COES. Should Display Warning Message Box "Please Enter User name and Password”

3 Enter user Name and Password and press LOGIN Button. "USER = COES AND Password = XYZ" (Wrong user name & password). Should Display Warning Message Box "Please Enter User name and Password"

6 Enter user Name and Password and press LOGIN Button. "USER ="" "" AND Password = "" """(Blank values). Should Display Warning Message Box "Please Enter User name and Password"

7 Enter User Name and Password and press LOGIN Button. "USER = COES AND Password = COES" (Correct user name & password). Should navigate to next page.

8 Enter User Name and Password and press LOGIN Button "USER = ADMIN AND Password = ADMIN" (Correct user name & password). Should navigate to Maintenance page.

Some other test case sample

Test case for withdraw module in banking project
Test cases for sending of the emails?
Testcase for Yahoo Mail Page after login
Test Case For Captcha

Test Case Template

Test Case Template:

What is Test Case?

One or more inputs, execution per-requisites, preconditions, expected result and post conditions developed for a particular objective as per requirements.

Test Case Template may vary from one company to another and one project to another.

A model Test Case Template:

Test Case ID: a unique name (It may consists of Characters and Numbers)

Test Case Name: Name of the Test case

Test Suite ID: Test batch/set/suite ID

Precondition: Required state for Executing the Test Case

Post Condition: State after execution

Steps: Execution steps /Navigation

Expected Result: expected result as per requirements

Actual Results:

Test Results: Pass or Fail

Remarks:

Web Testing

Things to check while doing Web Application Testing

Functionality Testing:

Test for - all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing.

Check all the links:

Test the outgoing links from all the pages from specific domain under test.
Test all internal links.
Test links jumping on the same pages.
Test links used to send the email to admin or other users from web pages.
Test to check if there are any orphan pages.
Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages:

Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?
First check all the validations on each field.
Check for the default values of fields.
Wrong inputs to the fields in the forms.
Options to create forms if any, form delete, view or modify the forms.

Cookies testing:

Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the sessions ends) check for login sessions and user stats after session end. Check effect on application security by deleting the cookies.

Validate your HTML/CSS:

If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors. Check if site is crawl able to different search engines.

Database testing:

Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality. Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below.

Usability Testing:

Test for navigation:

Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose. Main menu should be provided on each page. It should be consistent.

Content checking:

Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing

Other user information for user help:

Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap.
“Search in the site” option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.

Interface Testing:

The main interfaces are:
Web server and application server interface
Application server and Database server interface.
Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between?

Compatibility Testing:

Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:
Browser compatibility
Operating system compatibility
Mobile browsing
Printing options


Browser compatibility:

In my web-testing career I have experienced this as most influencing part on web site testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.

OS compatibility:

Some functionality in your web application is 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, Unix, MAC, Linux, Solaris with different OS flavors.

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.

Printing options:

If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option.

Performance testing:

Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web Stress Testing
Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing:

Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes. Stress is generally given on input fields, login and sign up areas.
In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,

Security Testing:

Following are some tests for web security testing:
Test by pasting internal URL directly into browser address bar without login. Internal pages should not open.
If you are logged in using username and password and browsing internal pages then try changing URL options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the URL site ID parameter to different site ID which is not related to log in user. Access should deny for this user to view others stats.
Try some invalid inputs in input fields like login username, password and input text boxes. Check the system reaction on all invalid inputs.
Web directories or files should not be accessible directly unless given download option.
Test the CAPTCHA for automates scripts logins.
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.
All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

Web Applications Testing

Now a days Web Applications are getting more popular in the IT Industry, having so many advantages like supporting more clients, no client side installation and accessing from any ware etc…

Types of Web Application
We can categorize web applications in two ways

a) Business Classification

1) Web Sites (They provide information about Organizations or Industries or persons)
2) Web Portals (They are Business gateways, ex: Online Shopping sites, Job portals etc.)
3) Web Applications (They are Service providers (both Free and Paid), apart from information) Ex: Net Banking Applications, Insurance Applications etc…)

b) Technical Classification
1) Intranet Applications (They are private applications, uses local area network (LAN))
2) Internet Applications (They are Public applications, uses Wide area network (WAN)
3) Extranet Applications (They also Private applications over Internet (WAN))


Browser:
It is a Software Application, which retrieves, and Presents information in text, image and voice like different file formats.

The browser is the viewer of a Web Site and there are so many different browsers and browser options that a well-done Web Site is probably designed to look good on as many browsers as possible.

Popular Browsers:
1) Internet Explorer
2) Mozilla Firefox
3) Google Chrome
4) Safari
5) Opera
Etc…

Selenium

Selenium is a suite of tools used to automate web application testing across many platforms. It is an open source tool developed in Java Script and browser technologies and hence supports all the major browsers on all the platforms. It was developed by ThoughtWorks Inc.

There are 4 components of Selenium:

1) Selenium Core:

This is the original JavaScript-based testing system. It is now used primarily as a component of Selenium Remote Control, but it can also be used as a pure JavaScript/HTML testing system. To run Selenium Core tests, they normally have to be installed on the server on which you want to test.

2) Selenium IDE:

Selenium IDE is an integrated development environment for Selenium tests. It is implemented as a Firefox (2+) extension, and allows you to record, edit, and debug tests.

Features:

* Easy record and playback
* Intelligent field selection using IDs, names, or Xpath, as needed
* Autocomplete for all common Selenium commands
* Walk through tests
* Debug and set breakpoints
* Save tests as HTML, Ruby scripts, or any other format
* Support for Selenium user-extensions.js file
* Option to automatically assert the title of every page

Drawbacks:

* The biggest drawback of Selenium IDE is its limitation in terms of browser support. Though Selenium scripts can be used for most of the browsers and operating systems, scripts written using Selenium IDE can be used for only the Firefox browser if it is not used with Selenium RC or Selenium Core.
* Selenese, the simple scripting language used by IDE, is somewhat primitive as it has no conditionals (no "if" statements), and no loops (no "for" statements).
* Does not help with the launching and closing of the browser

Note: Selenium IDE can be configured to repeat a specific test by using flowControl extensions: goto, While, and so on, by installing the selenium-goto extension (download it from http://wiki.openqa.org/pages/viewpageattachments.action?pageId=379). To install it, open the Options panel in the Selenium IDE browser extension and specify the location of the user-extension.js file.


3) Selenium Remote Control:

Selenium Remote Control (RC) is a test tool that allows you to write automated web application UI tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser. The RC server also bundles Selenium Core, and automatically loads it into the browser.

Selenium RC comes in two parts:

a) A server, which automatically launches and kills browsers, and acts as a HTTP proxy for web requests from them.

b) Client libraries for your favorite computer language (Java, .NET, Perl, Python, C#, PHP and Ruby).

Click on selenium for a simplified architectural representation.

As a test suite starts, the following happens

* The client/driver reaches out to the Selenium-Server.
* The Selenium-Server launches a browser (or reuses an old one) with a URL that will load the Selenium core web page.
* The Selenium-Core gets the first instruction from the client/driver (via the HTTP Proxy built into the Selenium RC Server).
* The Selenium-Core acts on that first instruction, typically opening a page of the AUT.
* The web server is asked for that page, and it renders it in the frame/window reserved for it.

4) Selenium Grid:

Selenium Grid runs tests on many servers at the same time, cutting down on the time it takes to test multiple browsers or operating systems.

Installation:

1. Selenium IDE:
* Selenium IDE can be downloaded from http://seleniumhq.org/download/.
* Open Mozilla Firefox.
* Drag and drop the file into it.
* Install it and restart Firefox
* If installed properly, Selenium can be accessed from Tool –> Selenium IDE in your browser toolbar.
2. Selenium RC:
* Selenium RC can be downloaded from http://seleniumhq.org/download/.
* Unzip the file and extract it in the directory of your choice.
* JRE 1.5 or higher version should be installed on your machine. To check the version, type the following command at the dos prompt: java -version.