I thought of sharing 7 simple steps that can improve software testing as well as the software testing career

• Tip 1 - Written communication – This is applicable to all instructions or tasks given to you by your superior. No matter how friendly your lead or manager is but keep things in emails or documents.

• Tip 2 - Try to automate daily routine tasks – This will save time and energy by automating daily routine task no matter how small those tasks are.

•  Tip 3 - Admit mistakes but be confident about whatever tasks you did - Avoid doing the same mistake again. This is the best method to learn and adapt to new things.

•  Tip 4 - Continuous learning – Never stop learning. Explore better ways to test application.

•  Tip 5 - Get involved from the beginning – Ask your lead or manager to get you (QAs) involved in design discussions/meetings from the beginning.

•  Tip 6 - Keep notes on everything – Keep notes of daily new things learned on the project. This could be just simple commands to be executed for certain task to complete or complex testing steps, so that you don’t need to ask same things again and again to fellow testers or developers.

•  Tip 7 - Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings.

Security Testing

SQL Injection

SQL Injection vulnerabilites are quite common and very dangerous. An SQL injection vulnerability can only occur with a software application that fronts a database. Which just happens to be a very common occurance. SQL Injection attacks deal with the same problem of input not being validated. With a bit of understanding of the web application and a sniffer trace, a malicious user could create an SQL statement that was not intended and "trick" the web application to return or perform some other SQL command rather than the intended command.

The first thing that will need to be done is to understand how the web application interfaces with the backend database. Either you will have the design documents to work with or you can use a sniffer utility to determine what is occuring.

See the Tools sniffer applications for more information on types of sniffer applications.

If a site is vulnerable to SQL injection a large number of other problems could occur. This is a simple and easy vulnerability to exploit. All an attacker needs to know is SQL and have some understanding about how the information is passed.

Example of an SQL injection vulnerability

To understand how a SQL injection vulnerability could occur, imagine the following situation. For example say your website has a method to search for users. A usersearch page is created which could include something like the following.

<form method="post" action="searchuser.php"> <input type="text" name="username"> <input type="submit" value="Search" name="search"> </form>

This html snippet passes in the username to the dynamic page searchuser.php. The searchuser.php will take the username and add it to an SQL statement. Take for example the following php code snippet.

sqlResult = statement.executeQuery("SELECT * FROM users WHERE username = '" + $username + "';");

Think about this statement and see if you can figure out what is the problem. You might say the $username should be validated before it is added to the SQL statement. That is exactly what should be done. A malicious user could attach additional SQL statements to the username. This could be done by passing is something like.

admin' OR 1=1 --

Think about what the SQL statement would look like.

SELECT * FROM users WHERE username = 'admin' OR 1=1 --';

Notice this will either select the admin account or it will before 1=1 which will result in true. Which in SQL terms this will return the entire users table. Which the users table could contain all sorts of other additional sensitive information. This is just one example of what type of attack could be performed with SQL injection.

How to protect against SQL injection vulnerabilities

SQL injection vulnerabilities can occur anytime there is some type of input provided. They do not need to occur when output is sent. Any input should be validated, checked, and sanitized against a white list before being used.

Source: http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/SQL-Injection

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone they are wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Important Skills - Communication Skills

Here are six techniques you can use to help you say things simply but persuasively, and even forcefully:

1) Get your thinking straight. The most common source of confusing messages is muddled thinking. We have an idea we haven't thought through. Or we have so much we want to say that we can't possibly say it. Or we have an opinion that is so strong we can't keep it in. As a result, we are ill prepared when we speak, and we confuse everyone. The first rule of plain talk, then, is to think before you say anything. Organize your thoughts.

2) Say what you mean. Say exactly what you mean.

3) Get to the point. Effective communicators don't beat around the bush. If you want someone to buy something, ask for the order. If you want someone to do something, say exactly what you want done.

4) Be concise. Don't waste words. Confusion grows in direct proportion to the number of words used. Speak plainly and briefly, using the shortest, most familiar words.

5) Be real. Each of us has a personality -- a blending of traits, thought patterns and mannerisms -- which can aid us in communicating clearly. For maximum clarity, be natural, and let the real you come through. You'll be more convincing and much more comfortable.

6) Speak in images. The quote that "a picture is worth a thousand words" isn't exactly true (try explaining the Internal Revenue code using nothing but pictures). But words that help people visualize concepts can be tremendous aids in communicating a message. Once Ronald Reagan's Strategic Defense Initiative became known as Star Wars, its opponents had a powerful weapon against it. The name gave it the image of a far-out, futuristic dream beyond the reach of current technology. Reagan was never able to come up with a more powerful positive image.

Your one-on-one communication will acquire real power if you learn to send messages that are simple, clear, and assertive; if you learn to monitor the hearer to determine that your message was accurately received; and if you learn to obtain the desired response by approaching people with due regard for their behavioral styles. 

Your finesse as a communicator will grow as you learn to identify and overcome the obstacles to communication. Practice the six techniques I just mentioned, and you'll find your effectiveness as a message-sender growing steadily.

But sending messages is only half the process of communicating. To be a truly accomplished communicator, you must also cultivate the art of listening.

If you're approaching a railroad crossing around a blind curve, you can send a message with your car horn. But that's not the most important part of your communication task. The communication that counts takes place when you stop, look and listen. 

We're all familiar with the warning on the signs at railroad crossings: Stop, Look and Listen. It's also a useful admonition for communication.

It's easy to think of communication as a process of sending messages. But sending is only half the process. Receiving is the other half. So at the appropriate time, we have to stop sending and prepare to receive.

Work Smart For Your Career Development

• Have a strategy or plan one if you don’t have initially

No one likes to work for more than 8 hours a day. Psychologically too, working for more than 8 hours a day will falter your concentration and reduce the quality of your own productivity - and, this ‘overtime’ work that you have to do is usually due having no pre-planned strategy. This is one simple strategy that you should apply when you are working: which is simply, do what is more important first and less important saved up for later. So you can start by writing down all your targeted tasks to be done and have a priority check list.

• Have an effective schedule

There are times too when you find it hard to accomplish as your scheduled plans. Perhaps you are forgetting something when you did that schedules before. Another thing that you should always bear in mind is to be sure that you are arranging your work according to your ability and capacity. You should know your working skills, development and ability more than others do. But this is of no reason for you to put a full stop to improve your working skills. Always keep it at an ongoing base.

• Clean your table

Few have taken notes to this particular factor, assuming it doesn’t do much good anyway. But actually, by tidying up your table, and moderately decorating it without making it look slapdash, you are able to boost your own positive working mood. Another benefit of cleaning your table is to save time to find stuffs that’s part of that trash piles.

• Finish your work

Rule no. 1 when you are working is to get that particular job entrusted to you done, and in time. If you’ve practice proper scheduling, have a working strategy, you should be able to get by this one pretty easily.

• Starting immediately

Postponed workloads will only give you more pressure than leisure, of course. So whichever work that you feel can be done in an instant and fast, you should do it first without hesitation. It’ll take you off from that tedious string of work. The human brain functions sharper in the morning so that is the best time to get some little stuff done.

• Private time Vs Working time

The inability to differentiate private time with working time is a real threat in your career advancement. It may seems like not a problem for you but sometimes we tend to get carried away and forgot what we were supposed to do in the first place. You should remember the trust that your superior has put onto you and respect that trust. Be professional when you’re working. But it doesn’t mean that you have to work like a robot day after day, there’s no harm in taking a 5 minutes break ever 2 to 3 hours of work to get back your focus and calm your mind.

Another key factor that enables you to further develop your career is your ability to love your work. If you love you work, you won’t feel burden much by it.

What is a Test Case & Test Case Designing

A test case is a document that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.

A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

The key issue under Test case designing is to identify a subset of all possible Test Cases (set of data to be used as input) that have a high probability of detecting errors.

Test Case-Definitions

IEEE Standard 610 (1990) defines test case as follows:

"A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement."

IEEE Standard 829 (1983) defines test case as follows:

"Documentation specifying inputs, predicted results, and a set of execution conditions for a test item."

According to Ron Patton (2001)
"Test cases are the specific inputs that you'll try and the procedures that you'll follow when you test the software."

Boris Beizer (1995)
"A sequence of one or more subtests executed as a sequence because the outcome and/or final state of one subtest is the input and/or initial state of the next. The word 'test' is used to include subtests, tests proper, and test suites."

Why We Need Test Cases?

• Provides a standardized set of baselines for each testing cycle
• Help "jump start" the testing for the inexperienced testers or for new team members
• Help define the scope of testing Stop asking "Did I miss anything?"
• Repeatability Help Repeat the same tests regardless of the tester
• Helps you to concentrate on the quality aspects of testing
• Help correctly estimate the effort for future regression test cycles

Types of Test Cases

• Positive Test Cases: Entering valid data into an application to determine if its processing results are correctly produced as defined in the requirement specification.
• Negative Test Cases: Entering incorrect data intentionally to determine if an application will recognize the data entered is invalid and take appropriate action

Elements of a Test Case

•The purpose of the test or description of what requirement is being tested
•Test Data
•The method of how it will be tested
•The setup to test: version of application under test, hardware, software, operating system, data files, security access, logical or physical data, prerequisites such as other tests, and any other setup information pertinent to the requirement(s) being tested
• Actions and expected results, or inputs and outputs
• Any proofs or attachments (optional)
• Requirement number
• For each section cover all possible scenario's for one field together.

Attributes of a Good Test Case
• Accurate: They test what their descriptions say they will test.
• Economical: They have only the steps or fields needed for their purpose.
• Repeatable, self-standing: A test case is a controlled experiment. It should get the same results every time no matter who tests it.
• Appropriate: A test case has to be appropriate for the testers and environment.
• Traceable: You have to know what requirement the case is testing.

Common Mistakes in Test Case Generation
• Making case too long
• Incomplete, incorrect or incoherent setup
• Leaving out a step
• Naming fields that changes or no longer exist
• Unclear whether tester or system does action
• Unclear what is a pass or fail result
• Test intent/objective is an action step, not an objective
• Test data drives the test object
• Test cases have unrealistic interdependencies.

Design Test Objective

Objective:

• To identify test procedure that show how the test cases will be identified
• To identify a set of verifiable test cases for the system requirements

Scope:

• Scope of Quality Assurance Test Case (QATC) extends to covering/testing the functional aspects of the application
• Unit testing and integration testing is not covered under this activity.

Design Test Case Activities Steps

● Analyze the Requirement
● Identify the Test Procedure
● Identify and Describe Test cases
● Identify test data
● Perform Workload Analysis (for performance testing only)
● Review and Assess Test Coverage
● Generate / Update Traceability Matrix

Identifying Test Conditions and Designing Tests

The process of identifying test conditions and designing tests consists of a number of steps :
• Designing tests by identifying test conditions
• Specifying test cases
• Specifying test procedures
• The process can be done in different ways, from very informal with little or no documentation, to  very formal 
• The level of formality depends on :
* Context of the testing
* Organization,
* Maturity of testing and development processes
* Time constraints
* People involved

Guidelines for Writing Test Cases

1. The Test Case objective should be Brief & Clear
2. The Test Case should correctly Verify the requirement
3. Expected result should specify the Behavior of the function being tested when we do certain action
4. Test Case should be Easy to determine the result
5. Test Case should be Maintainable
6. Test Case should be Manageable

Bad Practices

1. Test cases should NOT be Long and Invalid
2. Test cases should NOT be Complicated
3. Avoid writing Unobvious tests
4. Duplicate test cases to be avoided
5. Test cases should not be written with out Expected Results
6. Test Cases should be written with proper Header / Pre-Conditions
7. Test case should not be outdated

10 tips to write better bug reports

1. Structure - Careful approach to testing and take careful notes.

2. Reproduce - Check reproducibility of a failure before writing a bug report. 

3. Isolate - Proceed to isolate the bug. This information gives developers a head start on debugging.

4. Generalize - Does the same failure occur in other modules or locations? Can you find more severe occurrences of the same fault?

5. Compare - Check whether the bug is a case of regression

6. Summarize - Think through how the failure observed will affect the customer.

7. Condense - Reread focusing on eliminating extraneous steps or words. 

8. Disambiguate - In addition to eliminating wordiness, go through the report to make sure it is not subject to misinterpretation. 

9. Neutralize - Bug reports should be fair-minded in their wording. 

Source : http://www.rbcs-us.com/documents/FineArtofWritingaGoodBugReport(Paper).pdf