7-Step Practical Implementation of Manual Testing Before Production Release

In the prior article of this sequence on Manual Testing, I imparted an extensive initiation to Manual Testing’s principles.

If you didn’t see it, you can access it here.

I trust that article clarifies the queries you had.

If it did, aren’t you compelled to discover more about Manual Testing’s practical application, how to gain proficiency in it, and how to embark on a profession in this industry?

This piece will tackle all these considerations.

Let’s delve in.

Manual Testing Cycle

To internalize the Manual Testing Cycle or Software Testing Life Cycle (STLC), it is crucial to primarily comprehend the Software Development Life Cycle (SDLC), on which I believe you already have a good grasp.

Although these cycles are often cited distinctively, they are closely associated. There are numerous iterations of these cycles at your disposal, with modifications relative to the selected development model.

With Agile methodologies being the present norm, I will concentrate on a simpler strategy rooted in Agile.

7 Practical Manual Testing Steps Before Product Launch

Let’s probe into these steps.

Bear in mind that these steps are applicable to both SDLC and STLC.

#1) Requirement Gathering

The Business Analyst (the individual/team designated for Requirement Gathering) puts the requirements into documentation. The emphasis ought to be on the arrangement of requirements, regardless of the chosen approach towards documentation.

For this task, a variety of platforms and tools can be utilized, such as MS Word, Jira/Rally, or Trello.

#2) Requirement Discourse/Dissemination

The Business Analyst disseminates the documented requirements among the Development Team, Testing Team, and the UX team (if needed). Generally, this involves a formal meeting where representatives from all three sectors convene to comprehend the requirements in depth.

In a conducive work culture, requirements are debated from multiple viewpoints, and all participants in the meeting are incited to pose questions and request clarifications. Once all queries have been addressed and necessary amendments to the requirements have been executed, this phase can be deemed complete. The terminology employed for this meeting and its documentation may fluctuate across organizations.

Keep reading => How to Assess SRS Document

This phase is regarded as complete once every question has been resolved, and mandatory revisions to the requirements have been implemented. Across different companies, the terminology used for this meeting and its documentation may vary.

For instance, the documentation may be referred to as SRS (System Requirement Specification), Requirement Document, Epic, User Story, or Story Point. Likewise, the meeting to share requirements may be named Requirement Discourse, Grooming, or Hole-punching meeting, among other titles. The principal idea is to comprehend the process, irrespective of the specific terminology employed.

Subsequent to this meeting, two procedures are activated concurrently, in no precise sequence. Let’s advance to the next couple of steps.

#3) Designing

After discussing the requirements and addressing any major outstanding topics, the Development Team initiates technical designing. The specific procedures involved in this phase can vary among firms.

In this phase, tasks may encompass:

• Deciding the development method
• Creating design documents
• Formulating flow charts
• Estimating efforts
• Appraising the repercussion of novel requirements on current functionality
• Addressing the necessity to patch existing data, etc.

The UX team might also participate in this stage, predominantly when UI changes or new screens need to be generated. The UX team can furnish the Development and Testing teams with UI mock-ups for the debated functionality/feature. These prototypes can be in the form of Photoshop documents, basic images, PowerPoint presentations, or any other medium that facilitates the Development team’s understanding of how the screens ought to be developed.

Note: These screens or their draft variants should ideally be demonstrated during the Requirement Discussion session to foster enhanced comprehension. They should be linked to the original requirement for hassle-free reference.

#4) Constructing Test Scenario/Test Case

Concurrently with the Designing phase, the Testing Team commences the creation of test scenarios and/or test cases based on the conferred requirements. The sequence in which test scenarios and test cases are fabricated may vary.

In my view, test scenarios always precede test cases. Test scenarios function as main points that navigate the formulation of thorough test cases. Once the test cases have been composed, they can be shared with the Development Team to offer a glimpse of the testing range and ensure that the development aligns with the written test cases.

Test cases should ideally be evaluated by a Test Lead or peer from various perspectives, such as requirement coverage, spelling and grammar, test case writing principles, backward compatibility, platform compatibility, test data references, and types of testing targeted.

Keep reading => Composing test cases from SRS document

Following review and necessary revisions, the test cases can be transferred to the Development Team.

When I stated “once test case writing is finished,” I meant that all the test cases have been composed based on a total understanding of the specified requirements and any previously uncovered test scenarios. It is unfeasible to achieve 100% test case coverage initially.

Defects might be detected during deliberate (but intended) actions, purely random actions (monkey testing), or rarely encountered scenarios. It’s possible to overlook some defects, including fundamental ones, as we are all human. Nevertheless, a thorough test case review and methodical test case writing can assist in recognizing and managing these issues.

It’s common to append more test cases as new insights are gathered and the testing process advances.

By this point, you might be curious about why I haven’t referenced the term “Test Plan,” which is often linked with Software Testing. Let me share my perspectives on this matter. While I acknowledge the significance of the information typically incorporated in a Test Plan, I’m skeptical about the practice of documenting everything in a single location.

The Test Plan can be prepared by either the testers or the Test Lead, or the required information can be put into the documentation in different places.

Further Reading => How to Write a Test Plan Document

The information that should be put into the documentation at this stage encompasses:

• Testing Scope: Requirements, Backward Compatibility, Platforms, Devices, etc.
• Person/team accountable for testing
• Estimation of testing effort
• Limitations: Assumptions or accepted limitations
• Entry criteria for testing
• Exit criteria for testing
• Risks associated with not adhering to the documented plan

#5) Development Stage

Upon the completion of the Designing phase and the availability of testable requirement chunks, the Development Team launches actual development and unit testing. They can deliver the completed functionality for testing either in chunks or all at once.

Before transferring the developed functionality for testing, formal code reviews and white box testing should ideally occur. In addition to the requirements and design documents, the Development Team should consult the test cases supplied by the Testing Team.

#6) Testing Stage

As previously mentioned, the commencement of the Testing Stage might differ among firms and teams.

The Testing Team initiates testing when a testable section of the entire requirement is developed or when the complete requirement is developed.

Let’s delve deeper into this phase and discuss crucial tasks:

• The Tester/Testing Team conducts exploratory testing, executes written test cases, and logs defects.
• Based on their priority, the Development Team rectifies the reported defects.
• A new build is deployed for testing.
• The Tester/Testing Team verifies the rectified defects and marks them as fixed.
• This cycle continues until the exit criteria are met.

During this phase, defects might be marked as invalid, duplicate, or enhancements. It’s also essential to determine the number of testing rounds. Some firms conduct the first round of testing on smaller feature parts, followed by complete testing on a different environment once all requirements are developed. Others may execute three full testing rounds and a fourth round as a sanity/smoke test.

The goal of multiple testing rounds is to evaluate functionality on diverse environments and carry out complete testing. The sanity round is typically conducted to swiftly gain confidence after all stories in a release have been independently developed and tested.

Read detailed steps => Test Execution stage

#7) Business Analyst (BA) Evaluation

The Business Analyst appraises the functionality based on the test results or by directly interacting with the application to gain perceptual clarity. The timing of this step might oscillate across firms.

The BA might review the scope of the entire release at once or in sections. Based on this, the BA review might happen before or after the final sanity testing conducted by the Testing Team.

After successfully completing these 7 steps for all the requirements, the release is set for delivery.

#8) Delivery/Launch

A release is deemed ready for delivery after a successful review by the Business Analyst.

Suggested read => Test release process

Manual (Human) Testing Categories

There are over 100 different names for types of testing, but comprehending the distinction among them all is not required.

Testing the functionality of an application against its given requirements using human efforts and intellect constitutes the crux of Manual Testing. This can be further dissected based on the testing’s scope and objectives. Here are several crucial and popular types of Manual (Human) Testing:

• Manual Functional Testing: Testing the application’s functionality against the given requirements using human efforts and intellect. This class includes system testing, unit testing, smoke testing, sanity testing, integration testing, regression testing, UI testing, etc.
• Performance Testing: Although it’s considered non-functional testing, it requires human implementation, even though execution can be performed by a tool. Testers should be able to execute basic performance tests, such as measuring response times, even without the use of specialized tools.
• Browser/Platform Compatibility Testing: Ensuring that the application appears and functions as intended across varying browsers and platforms (or devices for mobile applications).
• Usability Testing: Although this is a specialized domain, it is crucial for testers to identify and report usability issues and offer their perceptual insights, even if they lack expertise in this area.
• Security Testing: This is another form of specialized testing that necessitates practical knowledge. Testers should comprehend and conduct simple security tests, such as URL alteration, cross-site scripting, SQL injection, and session hijacking.
• Multi-tenancy Testing: If the application is multi-tenant, implying it manages data from multiple clients, this type of testing is vital. Regardless of explicit requirement, this testing should invariably be conducted to prevent data leakage between clients.

Note: These views are derived from personal experience. I suggest acquainting yourself with the extensive list of testing types for a wider understanding of the field.

This concludes this segment of the tutorial. Thank you for reading. Please share your feedback in the comments.

In the upcoming and concluding part of this manual testing tutorial series, I will give guidance on how to prepare for a career in testing and survey potential routes to enter the industry.