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:
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.
Here I go.
Remember I am talking about both SDLC and STLC.
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.
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:
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.
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:
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 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.
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:
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
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
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:
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.