6 Basic Skills That Every Tester (Mainly Fresher) Should Have

Software Testing or QA is the best platform for newcomers to enter into IT industry despite the misconceptions that it is a lesser or lower paid job.

The most important skill that a tester needs is the ability to find bugs.  And, if you are the sort of person who loves finding bugs, then you are going to love and grow in this field.

Having said that, there are few more skills that can help you find bugs and work with QA processes better. 

This is the article that will show the QA process as it is followed in most companies and will give new-testers clarifications on testing.  

In detail, you learn the documentation process and standards, pre-work of the tester, constraints based testing, testing during partial development and finally the sign-off process.

Let’s begin.

#1. Documentation

Documentation is essential to testing. Most companies assign this task to new-comers. To succeed, you should have good vocabulary because the rest of things such as documentation standards, etc. are not in your control and depend on the team’s and company’s processes.

Also, make sure that you see the value of the documentation process. The advantages are many – they help you track requirement changes, trace your test steps, log your work, etc.

Recommended read => Why Documentation is Important in Software Testing

#2. Test Preparation

Of all the documents available, the following can’t be neglected. These are also called as deliverable documents and they bridge client, developer and tester understanding.

a) Test Plan: Charts the flow of testing from start to finish.

Test plan portrays scope and activities of the testing phase. Created by the QA lead, the team has to contribute and stay updated about everything that is written in the test plan.

Some teams have multiple levels of test plans: Master Plan and Phase wise plans.

A test plan must have:

• Project Name and version
• Test plan identifiers – Creator, draft no., date created, etc.
• Introduction – Overview of the project, objective, and constraints
• References – List of references used as the input.(make sure you use the accurate and latest versions)
• Test items – Modules, version, scope, out of scope, etc.
• Overall Test Approach/Test Strategy – Tools to use, defect tracking process, levels of testing to perform, etc.
• Pass/ Fail item criteria – Test Execution guidelines
• Suspension & Resumption criteria
• Test deliverables – Test case, test reports, bug report, test metrics, etc.
• Test environment details
• Team Roster with Point-of-contact info. for each module or testing type
• Test Estimates – Time and effort. Budget details are confidential and you will not find them here
• Risks and mitigation plans
• Approvals
• Other guidelines

Also read => 

• How to Write a Test Plan Document from Scratch
• Test Plan Format
• Real Test Plan Example (pdf) [download]

b) Test scenarios:

One line pointers on ‘what to test’ based on each requirement and usually documented and tracked through spreadsheets.

Most of them contain:

• Module/Component/function name (login, admin, registration, etc.)
• Scenario ID is for reference(E.g.: TS_Login_001)
• Scenario Description – ‘What to Test’ E.g.: Validate if login allows users with valid credentials to login successfully
• Scenario Importance – To prioritize in case of insufficient time – High/Medium/Low
• Requirement ID – For traceability

Further reading => 

• How to write a Test Scenarios from SRS document
• Test Cases Vs. Test Scenarios

c) Test cases:

Accurate Test cases give accurate test results. Spreadsheets are still the popular medium for test case writing, especially for beginners, even though some companies adapt test management tools. The basis for test case writing is the SRS/FRD/Req document. But, it is not often sufficient, so you will have to use a lot of assumption and discussion with BA/Dev teams.

Writing effective test cases is the most important qualification a tester must have. Usually, all test cases are categorized as positive/negative. Positive test case is giving valid inputs and getting positive results. Negative test case is giving invalid inputs and getting the exact error message.

For more information on these, check:

• How to Classify Positive and Negative Test Scenarios
• How to Write Negative Test Cases?

Some of the common attributes that all test cases have are:

• Scenario ID – Taken from test scenario document
• Test case ID – For unique identification and tracking. E.g.: TC_login_001
• Test description – Brief explanation of the test condition tested
• Steps to execute – Detailed step by steps instructions on how to test
• Test data – Data supplied to the test steps
• Expected result – Outcome as expected
• Actual result – Response of the AUT when the test is run
• Status – Pass/Fail/No Run/Incomplete/Blocked – Describes the result of the test
• Comments – To additional details
• Executed by – Tester’s name
• Executed date – Date on which the test is run
• Defect ID – Defect logged against the test case, in case of test failure
• Configuration details – OS, Browser, Platform, device information (optional)

Recommended read => 

• Sample Test Case Template with Examples
• 180+ Sample Test Cases

#3. Test Process – What tests to perform?

There are a huge number of testing types, but not all of them can be carried out on that AUT. Time, budget, nature of the business, nature of the application, and client’s interest are the key players in the choice of what tests to do on the application.

For example: If it is an online commerce portal, then stress testing and load testing are mandatory. However, some of the test types that should not be missed are:

• Black box testing
• Grey box testing
• Unit testing (If applicable)
• Integration testing
• Incremental integration testing
• Regression testing
• Functional testing
• Retesting
• Sanity Testing
• Smoke testing
• Acceptance testing
• Usability testing
• Compatibility testing
• End to End testing
• Alpha testing
• Beta testing

#4. Testing at the partial development stage

Generally, with medium level and start-up companies, there is limited time and resources. Testers here might start their testing process before module integration, which means we might be doing unit and intermediary integration tests.

It is important to note that the results from these stages cannot be counted as accurate, so you might have to plan for an overall black box test once everything is ready-to-go. Overlooking that part might prove costly and testing, ineffective.

#5. Bug report document

Hands on, this is the most critical QA document you will ever be making.

The following are the fields a good bug report must have:

• Defect ID – Usually a serial number
• Defect description – One line explanation of the problem
• Location – Module/area of the AUT where the problem is found
• Build number – Version and code build no.
• Steps to reproduce – List of steps that lead you to the problem
• Severity – Set a level to describe the seriousness of the problem – Low, medium, high, blocker, etc.
• Priority – Set by developers to determine the order in which the defect will be fixed (P1, P2, P3, etc. P1- highest)
• Assigned to – Owner of the defect at that point of time
• Reported by – Tester’s name
• Status – Different status to represent the bug life cycle stage
  • New – Bug is found and is just reported
  • Open – Validated by the QA lead
  • Assigned – Sent to the dev lead for assignment to the respective developer
  • In Progress/Work in Progress – Dev started working on it
  • Fixed/Resolved – Developer is done working on it
  • Verified/Closed – QA Team has retested and found the bug fixed
  • Retest – QA team does not agree with the resolution by Dev and further progress the bug for rework
  • Duplicate – Similar bug already exists
  • Deferred – Valid bug but will be fixed in later releases
  • Invalid – Not a bug or is not reproducible or there is not enough information

Further reading => 

• How to write a good bug report
• Sample bug report
• How to Market and Get Your Bugs Fixed
• Why Bug Reporting is an Art

#6. Sign-off process

Sign off and sending final documentation is the QA lead/manager’s task. However, the team has to submit the above documents (Test scenario, Test case, and defect log document) for final reviews and audit.

Make sure, you proofread all of them and send the final versions.

Also read =>

• How to Write an Effective Test Summary Report
• How to Report Test Execution Smartly
• Sample Test Summary Report [download]

Conclusion

This is the process as I have witnessed and experienced firsthand when I was a tester and I hope this has given you some useful pointers.

Finally, a career in testing has been an absolute joy for me and I hope it is for you too.

All the best for your career!