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

QA or Software Testing offers a great entry point into the IT industry for newbies, despite the false notion that it’s less lucrative.

The most vital skill needed for a tester is the knack for detecting bugs. If you are the kind of person who delights in uncovering bugs, this profession will suit you perfectly.

However, other skills are also crucial for better bug identification and boosting efficiency in QA processes.

This paper lays out the standard QA process employed within most companies to offer novice testers insights into testing approaches.

Specifically, you will obtain knowledge about documentation standards and processes, the tester’s initial tasks, constraint-based tests, testing during incomplete development, and the process of signing off.

Let’s dive in.

#1. Documentation

Documentation is a crucial aspect of testing. It is a role that is typically appointed to newcomers in many companies. To excel in this, you need to have a good command over language as factors such as documentation norms are reliant on the team and company processes, and are beyond your control.

Additionally, it is vital to perceive the importance of the documentation process. It carries several benefits like providing a trace of requirement changes, tracking test steps, and chronicling your work.

Suggested reading: => The Importance of Documentation in Software Testing

#2. Test Preparation

There are several essential documents that can’t be ignored. These documents or deliverable documents contribute to a better understanding among the client, coder, and tester.

a) Test Plan: Describes the Testing Workflow.

A test plan outlines the boundaries and tasks of the test phase. Though the QA lead usually drafts it, the whole team should contribute and remain updated about its context.

Some teams use numerous levels of test plans, like the Master Plan and Phase-wise plans.

Every test plan should comprise:

• Name of the project and its version
• Identification elements of a test plan – Author, draft number, date of creation, etc.
• Introduction – Overview, objectives, and limitations of the project
• References – A list of references used (ensure they are the latest and most accurate versions)
• Test items – Modules, versions, range, in-range, not in range, etc.
• Overall Test Method/Test Strategy – Tools to implement, procedure for defect tracking, testing levels, etc.
• Pass/Fail criteria – Rules for test execution
• Suspension & Resumption standards
• Test deliverables – Test case, test reports, bug reports, test metrics, etc.
• Details about the test environment
• Team Members with Contact Information for each module or type of test
• Test Estimates – Time and effort required. Budget specifics are confidential and are not included in this section
• Risks and their control plans
• Approvals
• Other guidelines

Further reading: =>

• Drafting a Test Plan Document from Scratch
• Format of a Test Plan
• Real-world Example of Test Plan (pdf) [download]

b) Test scenarios:

These are brief cues on “what to test” based on individual requirements, typically tracked and documented using spreadsheets.

Most test scenarios comprise:

• Name of the Module/Component/function (e.g., login, admin, registration)
• Scenario ID for reference (e.g., TS_Login_001)
• Scenario Description – Specifies “What to Test” (e.g., Verify if login permits users with valid credentials to log in successfully)
• Scenario Importance – Priority in case of time restrictions (High/Medium/Low)
• ID of the Requirement – For traceability

Additional reading: =>

• Composing Test Scenarios from an SRS Document
• Test Cases Vs. Test Scenarios

c) Test cases:

Accurate test cases lead to reliable test results. Spreadsheets are still widely used for writing test cases, particularly for newcomers, even though some enterprises turn to test management tools. The creation of a test case is primarily based on the SRS/FRD/Req document. However, further assumptions and conversations with BA/Dev teams might also be needed.

The crucial qualification for a tester lies in formulating efficient test cases. Generally, test cases are categorized into positive/negative. Positive test cases mean providing legitimate inputs and awaiting positive outcomes, while negative test cases imply providing incorrect inputs and expecting certain error messages.

For more details, visit:

• Classification of Positive and Negative Test Scenarios
• Writing Negative Test Cases

All test cases commonly comprise:

• Scenario ID – Acquired from the test scenario document
• Test case ID – For distinct identification and tracking (e.g., TC_login_001)
• Test description – Brief explanation of the test condition being examined
• Steps to execute – Detailed, step-wise guidelines about the testing procedure
• Test data – Data provided to the test steps
• Expected result – Anticipated outcome
• Actual result – Response from the AUT during the test execution
• Status – Pass/Fail/No Run/Incomplete/Blocked, indicating the outcome of the test
• Comments – Extra particulars
• Executed by – Name of the tester
• Execution date – Date when the test was run
• Defect ID – Defect noted against the test case (in the event of test failure)
• Configuration details – Details about the OS, Browser, Platform, and device information (optional)

Advised reading: =>

• Test Case Template Samples with Examples
• Over 180 Sample Test Cases

#3. Test Process – What Types of Tests to Conduct?

Several types of tests exist, but not all are suitable for a particular AUT. Aspects like time, budget, business type, nature of the application, and client preferences are crucial in choosing the right tests for an application.

For instance: An e-commerce portal might need stress testing and load testing. However, some fundamental test types should not be ignored, such as:

• Black box testing
• Grey box testing
• Unit testing (if possible)
• 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 Stage of Incomplete Development

In medium-sized and startup companies, time and resources are usually limited. In such situations, testers may start the testing process even before the module integration. This involves unit testing and intermediary integration tests.

Bear in mind, the results derived from these stages cannot be deemed accurate, making it essential to plan a comprehensive black box test when all components are ready. Overlooking this step could prove expensive and make the testing process ineffective.

#5. Bug Report Document

The bug report document is a crucial document in QA.

An efficient bug report should include the following sections:

• Defect ID – Typically a serial number
• Defect description – Brief description of the issue
• Location – Part of the AUT where the issue is found
• Build number – Version and code build number
• Steps to reproduce – Sequential steps to duplicate the issue
• Severity – Explains how serious the issue is (Low, Medium, High, Blocker, etc.)
• Priority – Determined by developers to set precedence for defect resolution (P1, P2, P3, etc. P1 being the most important)
• Assigned to – The person presently responsible for the defect
• Reported by – Name of the tester
• Status – Describes the stage of the bug’s lifecycle:
  • New – Bug has been reported but not yet confirmed
  • Open – Validated by the QA lead
  • Assigned – Forwarded to the development lead to assign to the suitable developer
  • In Progress/Work in Progress – Developer is currently working on it
  • Fixed/Resolved – Developer has fixed it
  • Verified/Closed – QA team has retested and confirmed the bug’s resolution
  • Retest – QA team disagrees with the resolution by the developer and refers the bug back for further work
  • Duplicate – A similar bug already exists
  • Deferred – Valid bug, but will be addressed in upcoming releases
  • Invalid – Either it’s not a bug or is non-reproducible, or provides inadequate information

More reading: =>

• The Right way to Write Bug Reports
• Example of Bug Report
• Effective Marketing and Getting Your Bugs Fixed
• Why Reporting Bugs is an Art

#6. Sign-off Process

Sign-off and the submission of the final document is the duty of the QA lead/manager. However, the team must deliver the above-mentioned documents (Test scenarios, Test cases, and Bug log document) for final auditing and reviews.

Be sure to carefully review these documents and turn in the concluding versions.

Also read: =>

• Writing an Effective Test Summary Report
• Smart Test Execution Reporting
• Sample Test Summary Report [download]

Conclusion

The aforementioned procedure is based on my direct experience as a tester. Hopefully, it has provided you with some useful insights.

Lastly, working as a tester has been a thoroughly enjoyable journey for me, and I hope it will be the same for you too.

Best of luck with your career!