In the previous post of this series around Manual Testing, I tried to throw as much light as possible on the basics of Manual Testing.
If you missed it, you can read it here.
I hope it was successful in taking you as close as possible to the answers you were looking for.
In that case, wouldn’t you love to know more about the practical implementation of Manual Testing, how to get more familiar with it and how to actually start a career in it?
This article will throw light on all these aspects.
What You Will Learn:
- Manual Testing Cycle
- 7 Practical Manual Testing Steps Before Production Release
- #1) Requirement Gathering
- #2) Requirement Discussion/Sharing
- #3) Designing
- #4) Test Scenario/Test Case designing
- #5) Development phase
- #6) Testing phase
- #7) Business Analyst (BA) Review
- #8) Shipment/Release
- Types of Manual (read Human) Testing
- Recommended Reading
Manual Testing Cycle
To understand Manual Testing Cycle or Software Test Life Cycle (STLC), first of all, we need to understand 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 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 use anything to document these which suits them but 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 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 differ company to company.
Further reading => How to Review SRS Document
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 differ company to company.
For example, the documentation is called or break down as SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (possibly, smallest requirement unit), etc. On the similar lines, this meeting in which requirement is shared is called as 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 gets triggered at the same time, in no particular order, refer next two steps.
Development team starts with their technical designing as soon as the requirements are discussed and when there are no major pending points. What is done in this phase again differs company to company.
This phase may involve but not limited to the following tasks:
- Deciding the development approach
- Preparing design document
- Designing the flow charts
- Estimating the efforts
- Figuring out 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 new screen is to be developed. The UX team helps Development team and Testing team with 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 development team understand how the screens should be developed.
Note: Ideally these screens or at least their draft versions, are shown in Requirement discussion session only to help the team build a better understanding. It gets tagged to original requirement so that it can be referred to at any given time.
#4) Test Scenario/Test Case designing
Parallel to the Designing phase, the Testing team starts with building Test scenarios and/or Test cases based on discussed requirements. Whether Test scenarios are always written first and then break 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 down things further. Once the test case writing is over, it can be shared with Development team to give them an idea of the Testing scope and they can also make sure that development which has happened or happening is satisfying the written test cases.
Once the test case writing is over, it can be shared with Development team to give them an idea of the Testing scope and they can also make sure that development which has happened or 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 which 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 review and needed modification, they 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 given requirement 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 are chances you will miss on few of these. And at some time you might miss out even very basic ones, after all, you are human. But here, at least a good test case review and structured way of test case writing 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 on this. I believe strongly in the need for most of the information which is mentioned in the Test Plan, but documenting them all at the same place and making it absolute mandatory is something I find debatable.
Anyways, that’s altogether a separate topic to discuss. To share a ‘suits all’ information on this is difficult but let me try.
Either you, you with your test lead or your test lead prepare Test Plan or you document the required information at different places.
Further Reading => How to Write Test Plan Document
Information which should be absolutely frozen at this stage:
- The scope of Testing: Requirement, 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 think doesn’t really need separate mention as it should be a normal understanding rather.
- Entry Criteria (When to start testing): Few start when there is testable part of functionality available for testing. Few wait for 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 blocker, critical and major (subjected to impact) defects in open stage testing can be stopped. Or in mid-way, 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
The development team after designing phase 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 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 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 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 testing round (exploratory testing and execution of written test cases) and logging defects
- Development team resolves them as per priority.
- New build (code) is taken on environment on which testing is happening
- Resolved defects are then verified by Tester/Testing Team and marked as Fixed
- This cycle continues till the time exit criteria is reached.
- Please note that as needed, defects are also marked as Invalid, Duplicate and can also be categorized as Enhancements.
Another thing which differs company to company is how many testing rounds to be done. Like 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 fourth as sanity/smoke round.
The first agenda behind doing multiple testing rounds is testing the functionality on different environments and second for doing end-to-end testing once all story points are developed. Sanity round usually happens to gain quick confidence once all stories in a release are developed and tested independently.
Read detailed steps => Test Execution phase
#7) Business Analyst (BA) Review
Business analyst reviews the asked functionality either by referring to test result or by referring to test result plus playing around with application to get an actual feel. This step again is subjected to different actions across companies.
The BA may review the scope of entire release in one go or in chunks. Depending on the same, this step might come before final sanity testing or after 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.
The release is 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 few types based on scope and agenda of testing. Types listed in next para.
It gets further divided into few types based on scope and agenda of testing. Types listed in next para.
If I am allowed to, let me speak 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 Human mind can do.
Below is the list with some of the popular and important testing types which can be categorized into Human Testing:
- Manual Functional Testing: Testing the functionality of the application against the given requirement with human efforts 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 into NonFunctional Testing right? But again it is the human who implements it, though execution gets done by either human or tool. 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: Application under test should look and work as expected (obviously there can be a minor difference depending on 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 very huge testing type 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 available knowledge and wherever applicable.
- Multi-tenancy Testing: If your application is multi-tenant, i.e. single instance holding data of 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 kind of a development and testing crime.
Note: 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 years I have understood that whether you use something or nor, 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 comments.
In next and last part of this manual testing tutorial’s 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.
14 thoughts on “7-Step Practical Implementation of Manual Testing Before Production Release”
Very good practical insights on some points
Thank you @Kishor. Glad that it helped.
good back to basics :)
Thank you @Mittul
Great Article… I love to read your articles because your writing style is too good, its is very very helpful for all of us and I never get bored while reading your article because, they are becomes a more and more interesting from the starting lines until the end.
Thank you @Abiya for the kind words :)
Very good article !!
A knowledgeable and very helpful article to any software tester in his/her career. Thank you.
Good. I would like to have article based on the interview perspective.
Reading something and when it feels someone is really talking through makes it easily understandable. I can phrase it” understandable and unforgettable “. Thanks?
Thank you. We also offering manual software testing course in chennai for all streams of engineering students.
very nice and useful documentation on Testing. So simplified and easily understandable. thank you