7-Step Practical Implementation of Manual Testing Before Production Release

In a previous post in this series around Manual Testing, I tried to throw as much light as possible on the basics of Manual Testing.

In case you missed it, you can read it here.

I hope it was successful in getting you as close as possible to the answers you were looking for.

With that said, wouldn’t you love to know more about the practical implementation of Manual Testing, how to get more familiar with it and how to start a career in it? 

This article will throw light on all these aspects.

Implementation of Manual Testing

Let’s begin.

Manual Testing Cycle

To understand the Manual Testing Cycle and Software Test Life Cycle (STLC), we first need to understand the Software Development Life Cycle (SDLC), which I am sure you already have an understanding of.

People refer to them separately but not sure if they can really co-exist. They are that tightly integrated with each other. Well, even though these cycles have so many versions of them created and floating in the internet space, they vary majorly on which development model is selected.

As most of the world is going Agile these days, I will keep my stuff simplified around Agile.

7 Practical Manual Testing Steps Before Production Release

Here I go.

Remember I am talking about both SDLC and STLC.

#1) Requirement Gathering

Business Analyst (Person/Team responsible for Requirement Gathering) documents the requirements. They document the requirements, that’s the highlight, you can keep the focus on that only. Where it is documented matters less.

People can use anything to document these that suits them but is not limited to traditional platforms like MS word doc, modern platforms like Jira/Rally and new age tools like Trello.

#2) Requirement Discussion/Sharing

Business Analyst is then supposed to share documented requirements with Development Team, Testing Team, and the UX team (if needed). This usually happens via a formal meeting where SPOCs (Single Point of Contacts or an entire team, it depends) from all three functions meet and understand the entire requirement.

In a healthy work culture, requirements get discussed from every angle and each member of the meeting can ask questions and doubts. Once all the questions are answered and the needed modification in the requirement is done, this phase can be considered as Done. Again, what one calls this particular meeting/step and its documentation differs from company to company.

Further reading => How to Review SRS Documents

Once all the questions are answered and needed modifications in the requirement are done, this phase can be considered as Done.

Again, what one calls this particular meeting/step and its documentation differs from company to company.

For example, the documentation is called or broken down as SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (possibly, smallest requirement unit), etc. On a similar line, this meeting in which the requirements are shared is called a Requirement Discussion meeting, Grooming, Hole-punching meeting, etc., I hope you get my point?

Pressing on these terminologies so that you always remember the main idea irrespective of the different names.

Post this meeting two steps get triggered at the same time, in no particular order, refer to the next two steps.

#3) Designing

The development team will start with their technical design as soon as the requirements are discussed and when there are no major pending points. What is done in this phase again differs from company to company.

This phase may involve but not be limited to the following tasks:

• Deciding on the development approach
• Prepared design document
• Designing the flow charts
• Estimating the efforts
• Figuring out the impact of this new requirement on any existing functionality
• Need to patch existing data, etc.

The UX team may also get involved in this phase when there is an UI change or a new screen is to be developed. The UX team helps the Development team and Testing team with the UI prototype for the functionality/feature in the discussion. This can be a Photoshop document, simple image, PowerPoint presentation or anything else which will make the development team understand how the screens should be developed.

Note: Ideally these screens, or at least their draft versions, are shown in the Requirement discussion session only to help the team build a better understanding. It gets tagged as the original requirement so that it can be referred to at any given time.

#4) Test Scenario/Test Case design

Parallel to the Designing phase, the Testing team will start building Test scenarios and/or Test cases based on the discussed requirements. Whether Test scenarios are always written first and then broken into Test cases is something which is again not constant.

In my opinion, whether you document the Test scenarios or not, they are always there before Test cases. Test Scenario is your bullet point, you can say they guide you to drill things down further. Once the test case writing is over, it can be shared with the Development team to give them an idea of the Testing scope and they can also make sure that development which has happened or is happening is satisfying the written test cases.

Once the test case writing is over, it can be shared with the Development team to give them an idea of the Testing scope and they can also make sure that development which has happened or is happening is satisfying the written test cases.

Test cases once written ideally get reviewed by a Test Lead or peer from many angles like:

• Requirement coverage
• Spelling grammar
• Test case writing standards (nothing but a template that a team/company follows)
• Backward compatibility
• Platform compatibility
• Test data references
• Types of testing targeted, etc.

Further reading => Writing test cases from SRS document

Ideally, only after the review and needed modifications are passed on to the Development team.

When I said “once Test case writing is over”, I meant once all the test cases are written based on complete knowledge of the given requirements and possible test scenarios uncovered till that particular time’. It is near impossible to have 100% test case coverage on the first go.

There will be defects which you will find in random (but intended) actions, in purely random actions (monkey testing) and in some rare scenarios. There is a chance you will miss out on a few of these. And at some point you might miss out on even very basic ones, after all, you are human. But here’s at least a good test case review and structured way of test case writing that can save you.

More often than not, a tester or testing team keeps on adding more and more test cases to the existing chunk as they uncover the truth or think more about the requirements.

Well, by now some of you must be doubting my knowledge of Software Testing as some word (which has kind of become a norm in Software Testing) is not used by me yet. Test Plan right?

Let me say something about this. I believe strongly in the need for most of the information which is mentioned in the Test Plan, but documenting them all in the same place and making it absolutely mandatory is something I find debatable.

Anyways, that’s altogether a separate topic to discuss. Sharing all the information on this is difficult but let me try.

Either you, you with your test lead or your test lead prepare a Test Plan or you document the required information at different places.

Further Reading => How to Write a Test Plan Document

Information that should be absolutely frozen at this stage:

• Scope of Testing: Requirements, Backward Compatibility, Platforms, Devices, etc.
• Person/Team who is going to test
• Test effort estimation
• Limitations: Any assumptions made or limitations accepted in advance.
• People additionally document entry criteria, exit criteria, risk, etc. Which I don’t think really needs a separate mention as it should be a normal understanding rather.
  • Entry Criteria (When to start testing): Few start when there is a testable part of functionality available for testing. Few wait for the entire functionality to be testable. Once the basic flow is found to be working, testing starts.
  • Exit Criteria (When to stop): When there are no blockers, critical or major (subject to impact) defects in open stage testing can be stopped. Or mid-way through, when there are way too many defects being faced, testing can be stopped by appropriate stakeholders.
  • Risk: Business risk or functional risk if testing doesn’t happen as per documented plan.

#5) Development phase

After designing phases, the development team starts with actual development and unit testing as and when they are done with the development of testable requirement chunks. They can pass on the functionality for testing in chunks as and when it is implemented or they can pass the entire functionality at once.

In an ideal scenario, formal code review and white box testing happen before passing on the developed functionality for Testing. Ideally, the Development team should also refer to the Test cases provided by the testing team in addition to requirements and design documents.

#6) Testing phase

As mentioned earlier, the start of this phase differs from company to company, team to team.

The testing team starts testing either when testable (something which can be independently tested) part of the entire requirement is developed or when the entire requirement is developed.

Let me drill down further in this phase and talk about the important tasks:

• Tester/Testing Team starts with a testing round (exploratory testing and execution of written test cases) and logging defects
• Our development team will resolve this as per priority.
• New build (code) is taken in the environment on which testing is happening
• Resolved defects are then verified by the Tester/Testing Team and marked as Fixed
• This cycle continues until the time exit criteria is reached.
• Please note that as needed, defects are also marked as Invalid or Duplicate and can also be categorized as Enhancements.

Another thing which differs from company to company is how many testing rounds to be done. In some cases, the first round of testing happens on small feature parts as they are ready, followed by an end-to-end testing round on another environment once all requirements are developed. But again, I have also heard of people doing three proper full testing rounds and a fourth as a sanity/smoke round.

The first agenda behind doing multiple testing rounds is testing the functionality in different environments and second for doing end-to-end testing once all story points are developed. Sanity rounds usually happen to gain quick confidence once all stories in a release are developed and tested independently.

Read the detailed steps => Test Execution phase

#7) Business Analyst (BA) Review

Business analysts review the asked functionality either by referring to test results or by referring to test results plus playing around with the application to get an actual feel. This step again is subjected to different actions across companies.

BA may review the scope of the entire release in one go or in chunks. Depending on the same, this step might come before final sanity testing or after the final sanity testing round by the testing team.

Above 7 steps happen for all the user stories/requirements to be fulfilled in particular Release (Shipment). Once all these steps are completed for all the requirements, the release is said to be ready for shipment.

#8) Shipment/Release

The release will be tagged as Ready for Shipment post successful review by the Business Analyst.

Recommended read => Test release process

Types of Manual (Read Human) Testing

Well if we have to talk about overall types of testing in numbers then somewhere I found over 100 types of testing with different names. To be honest I am not smart enough to understand the distinction between all of those types (pun intended).

It is straight and simple: Testing the functionality of the application against the given requirement with human efforts and intelligence. It gets further divided into a few types based on the scope and agenda of testing. Types listed in the next para.

It gets further divided into a few types based on scope and agenda of testing. Types listed in the next para.

If I am allowed to, let me say a few lines of Human Testing (which I encourage every tester to do over just manual functional testing). Now don’t get confused, in my view manual functional testing is a subset of Human Testing. Because there are so many things that only the human mind can do.

Below is a list of some of the most popular and important testing types which can be categorized into Human Testing:

• Manual Functional Testing: Testing the functionality of the application against the given requirements with human effort and intelligence. Further gets divided into quite a few types based on scope and agenda of testing, like system testing, unit testing, smoke testing, sanity testing, integration testing, regression testing, UI Testing, etc.
• Performance Testing: This gets categorized as Non-Functional Testing right? But again it is the humans who implement it, though execution gets done by either humans or tools. The tester should at least do this testing in terms of response time (to see if it is acceptable) if he is not supposed to use any tool for load testing and all.
• Browser/Platform Compatibility Testing: Applications under testing should look and work as expected (obviously there can be a minor difference depending on the browser engine) across browsers and platforms (or devices if it is a mobile application).
• Usability Testing: Let me agree first of all that this is a huge topic in itself and usually owned by specialists in usability testing. I still believe that as a tester we should at least report or highlight if we find something as less usable, or we should share our view.
• Security Testing: Again a very huge type of testing and requires a lot of practical knowledge of course. The tester should try to learn and execute at least basic tests like URL tampering, Cross-site scripting, SQL injection, Session hijacking, etc. depending on your available knowledge and wherever applicable.
• Multi-tenancy Testing: If your application is multi-tenant, i.e. single instance holding data from multiple clients, then this testing is a must. Irrespective of explicit mention in requirements this should be done. One client’s data being shown to another is a kind of a development and testing crime.

Note: The above views are my personal views. I also recommend you to have a look at the extensive list of testing types for your knowledge and follow/use them if you find it necessary. Over the years I have understood that whether you use something or not, you believe in something or not, you should still have some knowledge of widely used concepts in your field.

That’s all for this part. Thank you for reading. Do share your views/feedback in the comments.

In the next and last part of this manual testing tutorial series, I will try to help you all with what preparation you should be doing if you are looking to get into the testing field and what are possible ways to get in there.