Edited by Vijay Here is the complete software testing guide with 100+ Manual Testing Tutorials covering Testing Definitions, Types, Methods, and Processes. What is Software Testing? Software testing is a process of verifying and validating the functionality of an application to find whether it satisfies the specified requirements. It is the process of finding defects in an application and checking where the application functions according to the end user’s requirements. What is Manual Testing? Manual Testing is a process in which you compare the behavior of a developed piece of code (software, module, API, feature, etc.) against the expected behavior (Requirements). Table of Contents: List of ALL Manual Testing Tutorials What is Manual Testing? Why is Manual Testing Required How Automation Complements Manual Testing How to Perform Manual Testing Step-By-Step 7 Practical Manual Testing Steps Before Production Release #1) Requirement Gathering #2) Requirement Discussion/Sharing #3) Design #4) Test Scenario/Test Case Design #5) Development Phase #6) Testing Phase #7) Business Analyst (BA) Review #1) Requirement Gathering #2) Requirement Discussion/Sharing #4) Test Scenario/Test Case Design #5) Development Phase #6) Testing Phase #7) Business Analyst (BA) Review Types of Manual (Read Human) Testing List of ALL Manual Testing Tutorials This is the most in-depth series of tutorials on Software Testing. Go through the topics mentioned in this series carefully to learn the basic and advanced testing techniques. This series of tutorials will enrich your knowledge and will, in turn, enhance your testing skills. Practical End-to-End Manual Testing Free Training on a Live Project: Tutorial #1: Basics of Manual Software Testing Tutorial #2: Live Project Introduction Tutorial #3: Test Scenario Writing Tutorial #4: Write a Test Plan Document from Scratch Tutorial #5: Writing Test Cases from a SRS Document Tutorial #6: Test Execution Tutorial #7: Bug Tracking and Test Sign Off Tutorial #8: Software Testing Course Software Testing Life-Cycle: Tutorial #1: STLC Tutorial #1: Web Application Testing Tutorial #2: Cross Browser Testing Test Case Management: Tutorial #1: Test Cases Tutorial #2: Sample Test Case Template Tutorial #3: Requirements Traceability Matrix (RTM) Tutorial #4: Test Coverage Tutorial #5: Test Data Management Test Management: Tutorial #1: Test Strategy Tutorial #2: Test Plan Template Tutorial #3: Test Estimation Tutorial #4: Test Management Tools Tutorial #5: HP ALM Tutorial Tutorial #6: Jira Tutorial #7: TestLink Tutorial Test Techniques: Tutorial #1: Use Case Testing Tutorial #2: State Transition Testing Tutorial #3: Boundary Value Analysis Tutorial #4: Equivalence Partitioning Tutorial #5: Software testing methodologies Tutorial #6: Agile Methodology Defect Management: Tutorial #1: Bug Life Cycle Tutorial #2: Bug Reporting Tutorial #3: Defect Priority Tutorial #4: Bugzilla Tutorial Functional Testing Tutorial #1: Unit Testing Tutorial #2: Sanity and Smoke Testing Tutorial #3: Regression Testing Tutorial #4: System Testing Tutorial #5: Acceptance Testing Tutorial #6: Integration Testing Tutorial #7: UAT User Acceptance Testing Non-Functional Testing: Tutorial #1: Non-Functional Testing Tutorial #2: Performance Testing Tutorial #3: Security Testing Tutorial #4: Web Application Security Testing Tutorial #5: Usability Testing Tutorial #6: Compatibility Testing Tutorial #7: Installation Testing Tutorial #8: Documentation Testing Software Testing Types: Tutorial #1: Types of Testing Tutorial #2 : Black Box Testing Tutorial #3: Database Testing Tutorial #4: End to end Testing Tutorial #5: Exploratory Testing Tutorial #6: Incremental Testing Tutorial #7: Accessibility Testing Tutorial #8: Negative Testing Tutorial #9: Backend Testing Tutorial #10: Alpha Testing Tutorial #11: Beta Testing Tutorial #12: Alpha vs Beta Testing Tutorial #13: Gamma Testing Tutorial #14: ERP Testing Tutorial #15: Static and Dynamic Testing Tutorial #16: Adhoc testing Tutorial #17: Localization and Internationalization Testing Tutorial #18: Automation Testing Tutorial #19: White Box Testing Software Testing Career: Tutorial #1: Choosing a Software Testing Career Tutorial #2: How to Get QA Testing Job – Complete Guide Tutorial # 3: Career options for Testers Tutorial #4: Non-IT to Software Testing Switch Tutorial #5: Kick Start Your Manual Testing Career Tutorial #6: Lessons Learned from 10 Years in Testing Tutorial #7: Survive and Progress in Testing Field Interview Preparation: Tutorial #1: QA Resume Preparation Tutorial #2: Manual Testing Interview Questions Tutorial #3: Automation Testing Interview Questions Tutorial #4: QA Interview Questions Tutorial #5: Handle Any Job Interview Tutorial #6: Get Testing Job as a Fresher Testing Different Domain Applications: Tutorial #1 : Banking Application Testing Tutorial #2: Health Care Application Testing Tutorial #3: Payment Gateway Testing Tutorial #4: Test Point of Sale (POS) System Tutorial #5: eCommerce Website Testing Testing QA Certification: Tutorial #1: Software Testing Certification Guide Tutorial #2: CSTE Certification Guide Tutorial #3: CSQA Certification Guide Tutorial #4: ISTQB Guide Tutorial #5: ISTQB Advanced Advanced Manual Testing Topics: Tutorial #1: Cyclomatic Complexity Tutorial #2: Migration Testing Tutorial #3: Cloud Testing Tutorial #4: ETL Testing Tutorial #5: Software Testing Metrics Tutorial #6: Web Services Get ready to explore the Manual Testing series!!! What is Manual Testing? Manual Testing is a process in which you compare the behavior of a developed piece of code (software, module, API, feature, etc.) against the expected behavior (Requirements). How will you know what the expected behavior is? You will know it by reading or listening to the requirements carefully and understanding it completely. Remember, understanding the requirements completely is very, very important. Think of yourself as an end-user of what you are going to test. After that, you are not bound to the software requirement document or the words in it anymore. You can then understand the core requirements and not just check the system’s behavior against what is written or told, but also against your understanding and against things that are not written or told. At times, it can be a missing requirement (incomplete requirement) or an implicit requirement (something which doesn’t need separate mention but should be met), and you need to test for this too. Furthermore, a requirement need not necessarily be documented. You can very well have knowledge of the software functionality, or you can even guess and then test one step at a time. We generally call it ad-hoc testing or exploratory testing. Let’s have an In-Depth Look: First, let’s understand the fact – Whether you are comparing testing a software application or something else (let’s say a vehicle), the concept remains the same. Approaches, tools, and priorities might differ, but the core objective remains the SAME and it is SIMPLE, i.e., comparing the actual behavior with the expected behavior. Second – Testing is like an attitude or mindset that should come from within. Skills can be learned, but you will become a successful tester only when you have a few qualities within you by default. When I say testing skills can be learned, I mean focused and formal education around the software testing process. But what are the qualities of a successful tester? You can learn about them at the link below: Click here => Qualities of Highly Effective Testers I highly recommend going through the above article before continuing with this tutorial. This will help you compare your characteristics against the ones that are expected in the Software Tester’s role. For those who don’t have time to go through the article, here is a synopsis: “Your curiosity, attentiveness, discipline, logical thinking, passion for work, and ability to dissect things matter a lot to be a Destructive and Successful Tester. It worked for me, and I strongly believe that it will work for you as well. If you have these qualities already, then indeed it’s got to work for you too.” We have talked about the core pre-requisites of becoming a software tester. Now let’s understand why Manual Testing has and will always have its independent existence with or without Automation Testing. Why is Manual Testing Required Do you know what the best thing about being a Tester, that too a Manual Tester? It’s a fact that you can’t depend only on skillset here. You’ve got to have/develop, and enhance your thought process. This is something you can’t really buy for a few bucks. You have to work on it. You will have to develop the habit of asking questions , and you will have to ask them every minute when you are testing. Most of the time, you should be asking these questions to yourself rather than to others. I hope that you have gone through the article that I recommended in the previous section (i.e the quality of highly effective testers). If yes, then you would know that testing is considered a thought process, and how successful you will be as a tester completely depends on the qualities that you possess as a person. Let’s look at this simple flow: You do something ( perform actions ) while you observe it with some intent (comparing against the expected). Now your observation skills and discipline to perform things come into the picture here. Voila! What was that? You noticed something. You noticed it because you were giving perfect attention to the details in front of you. You won’t let it go because you are curious . This was not in your plan that something unexpected/strange would happen, you would notice it, and you would investigate it further. But now you are doing it. You can let it go. But you shouldn’t let it go. We are happy that you found the cause, steps, and the scenario. You will now communicate this properly and constructively to the development team and other stakeholders in your team. You might do it via some defect tracking tool or verbally, but you’ve got to make sure that you are communicating it constructively . Oops! What if I do it that way? What if I enter a proper integer as input but with leading white spaces? What if? What if? What if? It doesn’t end easily, and it shouldn’t end easily. You will imagine a lot of situations & scenarios and indeed you will be tempted to perform them as well. The diagram given below represents the Life of a Tester: Read the four bullet points mentioned above once again. Did you notice that I kept it very short but still highlighted the richest part of being a manual tester? Also, did you notice the bold highlighting over a few words? These are precisely the most important qualities that a manual tester needs. Now, do you think that these acts can be completely replaced by anything else? And the hot trend today – can it ever get replaced with automation? In SDLC with any development methodology, a few things always remain constant. As a tester, you will consume the requirements and convert them into Test Scenarios/Test cases. You will then execute those test cases or directly automate them (I know a few companies that do it). When you automate it, your focus is steady, which is automating the steps written. Let’s go back to the formal part i.e., executing the test cases written manually. Here, you not only focus on executing the written test cases, but you also perform a lot of exploratory testing while doing so. Remember, are you curious? And you would imagine. And you won’t be able to resist, you will indeed do what you imagined. The image given below depicts how Test Case writing is simplified: I am filling out the form, and I’m done filling out the first field. I am too lazy to go for the mouse to shift focus to the next field. I hit the ‘tab’ key. I am done filling up the next and last fields too, now I need to click on the Submit button, but the focus is still on the last field. Oops, I accidentally hit the “Enter” key. Let me check what happened. OR there is a submit button, I am going to double click it. Not satisfied. I clicked it multiple times, too fast. Did you notice? There are so many possible user actions, both intended and unintended ones. You won’t succeed in writing all the test cases that cover your application under test 100%. This has to happen in an exploratory way. You can continue adding new test cases as you test the application. These will be test cases for bugs that you encountered, for which previously there were no test cases written. Or, while you are testing, something triggers your thought process, and you have a few more test cases that you would like to add to your test case suite and execute. Even after all this, there is no guarantee that there are no hidden bugs . Software with zero bugs is a myth. You can only target to get it close to zero, but that just can’t happen without a human mind continuously targeting the same, similar to, but not limited to, the example process we saw above. At least as of today, no software will think like a human mind, observe like a human eye, ask questions and answer like a human, and then perform intended and unintended actions. Even if such a thing happens, whose mind, thoughts and eyes will it mimic? Yours or mine? We, humans, are also not on the same right. We are all different. And then? Need for Manual Testing when Automation is Around: Automated testing has its own share of glory these days and will have even more in the upcoming years, but it simply can’t replace manual QA testing (read human/exploratory testing). You’ve probably heard this before: “You don’t automate testing, you automate checking.” This sentence speaks a lot about where manual QA testing stands with automation testing. Many big names across the globe have written and spoken about this topic, so I won’t stress much about this. Automation can’t replace Human Testing because: It demands runtime judgments about everything that happens in front of your eyes (while you test) and in a few cases behind the scenes too. It demands clear and constant observation. It demands questioning. It demands an investigation. It demands reasoning. This demands unplanned action as required during testing. Testing can be replaced by a tool/machine which will be able to absorb the details, process them, command actions and perform them like a human mind and human, and all this at runtime and in all possible contexts. This tool again has to be like all possible humans. So in short, human testing can’t be replaced. Maybe some Hollywood sci-fi flick in a few years will look close to it, but in real life, I can’t see it coming for a few hundred years, that I can imagine. I won’t write it off forever as I believe in endless possibilities. On a separate note, even if it really happens after a few hundred years, the picture I can imagine is that of a scary world for sure. Age of the Transformers. 🙂 Recommended Reading => Best Manual Testing Service Companies How Automation Complements Manual Testing As I said before, I’m saying again that Automation can’t be ignored anymore. In a world where continuous integration, continuous delivery, and continuous deployment are becoming mandatory things, continuous testing can’t sit idle. We have to find ways to do it. Most of the time, deploying more and more workforce doesn’t help in the long run for this task. Hence, the Tester (Test Lead/Architect/Manager) has to decide cautiously on what to automate and what should still be done manually. It is becoming extremely important to have very precise tests/checks written so that they can be automated without any deviation to the original expectation and can be used while regressing the product as a part of ‘Continuous Testing’. Note: The word continuous from the term “Continuous Testing” is subject to conditional and logical calls similar to the other terms that we used above with the same prefix. Continuous in this context means more and more often, faster than yesterday. While in meaning, it can very well mean every second or nanosecond. Without having a perfect match between human testers and automated checks (tests with precise steps, expected results, and exit criteria of said tests documented), achieving Continuous Testing is very difficult, and this, in turn, will make continuous integration, continuous delivery, and continuous deployment more difficult. I purposely used the term exit criteria for the test above. Our automation suits can’t be similar to the traditional ones anymore. We have to make sure that if they fail, they fail fast. And to make them fail fast, exit criteria too should be automated. Let’s say there is a blocker defect wherein I am unable to log in to Facebook. Login functionality then has to be your first automated check and your automation suite should not run the next check where login is a pre-requisite, like posting a status. You very well know it is bound to fail. So make it fail faster, and publish the results faster so that the defects can be resolved faster. The next thing is again something that you must have heard before – you cannot and should not try to automate everything. Select test cases that , if automated, will benefit considerably from Human Testers and have a good Return on Investment. For that matter, there is a general rule which says that you should try to automate all your Priority 1 test cases, and if possible, then Priority 2. Automation is not easy to implement and is time-consuming, so it is advised to avoid automating low-priority cases at least until you are done with the high ones. Selecting what to automate and focusing on it improves the application quality when used and maintained continuously. In a previous post in this series on Manual Testing, we covered all 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 cover everything about how to perform manual testing with practical examples. How to Perform Manual Testing Step-By-Step 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 co-exist. They are that tightly integrated. Well, even though these cycles have so many versions of them created and floating in the internet space, they vary significantly 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 Remember I’m 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 the documented requirements with the Development, Testing, and UX teams (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 express doubts. Once all the questions are answered and the required modification is done, this phase can be considered done. Again, what one calls this particular meeting/step and its documentation differ from company to company. Further Reading => How to Review SRS Documents Once all the questions are answered and the needed modifications in the requirements are done, this phase can be considered as Done . Again, what one calls this particular meeting/step and its documentation differ from company to company. The documentation can be referred to as SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (possibly, the 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, and are referred to as the next two steps. 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 is not limited to, the following tasks: Deciding on the development approach Prepared design document Designing flow charts Estimating the effort 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 a 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, a simple image, a PowerPoint presentation, or anything else that 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 Design 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 that is again not constant. In my opinion, whether you document the test scenarios or not, they are always there before Test cases. Test Scenarios are your bullet points, 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 the development that 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 the development that 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, such as: 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 nearly impossible to have 100% test case coverage on the first go. There will be defects that you will find in random (but intended) actions, in purely random actions (monkey testing), and some rare scenarios. There is a chance you will miss out on a few of these. At some point, you might miss out on even very basic ones, after all, you are human. But here’s at least one good test case review and a 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 words (which have kind of become a norm in Software Testing) are 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 that is mentioned in the Test Plan, but documenting it all in the same place and making it mandatory is something I find debatable. Anyway, that’s altogether a separate topic to discuss. Sharing all the information on this is difficult, but let me try. Either you, the developer, or your test lead or your test lead prepares a Test Plan, or you document the required information in different places. Further Reading => How to Write a Test Plan Document Information that should be 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, risks, etc. Which I don’t think 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 the appropriate stakeholders. Risk : Business or functional risk if testing doesn’t happen as per the documented plan. 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 the appropriate stakeholders. Risk : Business or functional risk if testing doesn’t happen as per the documented plan. #5) Development Phase After the design phase, the development team starts with actual development and unit testing as soon as 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 on 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 the 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 the 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 into this phase and talk about the important tasks: The 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 from 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 are reached. Please note that, as needed, defects are also marked as Invalid or Duplicate and can also be categorized as Enhancements. Another thing that differs from company to company is how many testing rounds are 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 to test the functionality in different environments, and the second is to do 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. Suggested Reading => Test Execution Phase #7) Business Analyst (BA) Review Business analysts review the requested 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 is again subject 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 the final sanity testing or after the final sanity testing round by the testing team. The above 7 steps happen for all the user stories/requirements to be fulfilled in a 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 the scope and agenda of testing. Types are listed in the next paragraph. If I am allowed to, let me say a few lines about 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, it gets divided into quite a few types based on the 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 the 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 so all. Browser /Platform Compatibility Testing: Applications under testing should look and work as expected (obviously, there can be minor differences 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 testers, we should at least report or highlight if we find something less usable, or we should share our view. Security Testing : Again, a 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 their 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 the requirements, this should be done. One client’s data being shown to another is a kind of development and testing crime. I hope by now you must have understood why and how badly manual/human testing is required to deliver Quality Products and how Automation compliments it. Accepting the importance of QA Manual Testing and knowing why it is special is the very first step towards being an excellent manual tester. The above views are my personal views. I also recommend that you 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, whether you believe in something or not, you should still have some knowledge of widely used concepts in your field. In our upcoming manual testing tutorials, we will cover a generic approach for doing Manual Testing, how it will co-exist with Automation, and many other important aspects as well. I’m sure that you will gain immense knowledge of Software Testing once you go through the entire list of tutorials in this series. Was this helpful? Recommended Reading Manual Testing Help eBook Free Download I am happy to share the "Manual Testing Help" eBook prepared by one of our readers. The content of this eBook is very useful to understand manual testing concepts, testing methodologies and preparing for Software Testing interviews. Here are some of the topics covered in this book: Fundamentals of software… I am happy to share the "Manual Testing Help" eBook prepared by one of our readers. The content of this eBook is very useful to understand manual testing concepts, testing methodologies and preparing for Software Testing interviews. Here are some of the topics covered in this book: Fundamentals of software… What is Positive Testing in Software Testing? Examples A Complete Overview of Positive Testing: This tutorial will give you a brief introduction to one of the most prominent testing types: Positive testing. Software Testing is in the process of verifying and validating the software and confirming that it is working as expected. A software tester should have the… A Complete Overview of Positive Testing: This tutorial will give you a brief introduction to one of the most prominent testing types: Positive testing. Software Testing is in the process of verifying and validating the software and confirming that it is working as expected. A software tester should have the… Practical Software Testing - New FREE eBook [Download] "Practical Software Testing - Manual Testing Help eBook Version 2.0" - A free ebook from STH in association with Chindam Damodar. Assuming that you have no idea where to start in learning Software Testing, we have designed this free ebook just for you so that you can get started in… "Practical Software Testing - Manual Testing Help eBook Version 2.0" - A free ebook from STH in association with Chindam Damodar. Assuming that you have no idea where to start in learning Software Testing, we have designed this free ebook just for you so that you can get started in… Destructive Testing and Non Destructive Testing Tutorial Difference Between Destructive Testing and Non-Destructive Testing with Its Types and Methods: In this article, we are going to discuss details about destructive testing and non-destructive software testing. We will learn about them one by one and will also see the differences between these two testing types at the end… Difference Between Destructive Testing and Non-Destructive Testing with Its Types and Methods: In this article, we are going to discuss details about destructive testing and non-destructive software testing. We will learn about them one by one and will also see the differences between these two testing types at the end… Manual and Automation Testing Challenges Manual Testing Help eBook Free Download Steps to Convert Manual Test Cases into Automation Scripts Automation Test Plan Template Practical Software Testing – New FREE eBook [Download] How to Do Performance/Load Testing Manually Manual Testing Tutorial By Software Testing Help (Examples) How to Get Job in Manual Testing and Become a Manual Tester Moving From Manual to Automation Testing: 5 Steps Process 45 thoughts on “Manual Testing Tutorial By Software Testing Help (Examples)” very nice useful article mahesh Reply Thank you @Devasis. Reply very nice useful article mahesh Thank you @Devasis. Reply Thank you @Devasis. Hi i want to know, ether i am eligible for software testing coz i completed Bsc Chemistry and i want to switch in IT field Reply Hi i want to know, ether i am eligible for software testing coz i completed Bsc Chemistry and i want to switch in IT field Hi the software testing is best in supply management softare Reply Hi the software testing is best in supply management softare Nice way to put or describe the importance of Manual Testing. I have about 15 years of experience in Testing both manual and automation. I can strongly say from my heart, I always found complex (high priority) bugs using manual testing. Automation testing will help to save your schedule by burning the normal test cases quickly, so the remaining time can spend on finding quality bugs by applying all the qualities mentioned here. This is what I’m doing in all these years in industry and it earned me lot of respect from others and quick identification for me whichever project I land. So I will again re-iterate there is no replacement for manual testing (fully? even after robots come to testing in near future) and the complexity bugs (I mean which will really come after product or application is launched for end users) will be found only by applying above mentioned qualities “curiosity, attention to details, discipline, logical thinking, passion for work and ability to dissect things” Reply Thanks @Sudhakar. And yes I agree that both Human Testing and Automation will co exist always. Reply Thanks to share your experience Sir. Reply Nice way to put or describe the importance of Manual Testing. I have about 15 years of experience in Testing both manual and automation. I can strongly say from my heart, I always found complex (high priority) bugs using manual testing. Automation testing will help to save your schedule by burning the normal test cases quickly, so the remaining time can spend on finding quality bugs by applying all the qualities mentioned here. This is what I’m doing in all these years in industry and it earned me lot of respect from others and quick identification for me whichever project I land. So I will again re-iterate there is no replacement for manual testing (fully? even after robots come to testing in near future) and the complexity bugs (I mean which will really come after product or application is launched for end users) will be found only by applying above mentioned qualities “curiosity, attention to details, discipline, logical thinking, passion for work and ability to dissect things” Thanks @Sudhakar. And yes I agree that both Human Testing and Automation will co exist always. Reply Thanks @Sudhakar. And yes I agree that both Human Testing and Automation will co exist always. Thanks to share your experience Sir. Reply Thanks to share your experience Sir. It is such a nice information for beginner it is very useful guide for software testing learner Reply It is such a nice information for beginner it is very useful guide for software testing learner Yes I think that,as we came to know actual defects with ui Reply Yes I think that,as we came to know actual defects with ui You are not a manual tester, unless you are testing manuals. You are a tester. You DO use tools. You may not be writing automated checks.- Micheal bolton Reply You are not a manual tester, unless you are testing manuals. You are a tester. You DO use tools. You may not be writing automated checks.- Micheal bolton Nice post…Thanks for sharinh your blog Reply Nice post…Thanks for sharinh your blog I read the entire blog and gained an understanding of the uses of testing in the software field. It’s very useful for newbies to understand. Reply I read the entire blog and gained an understanding of the uses of testing in the software field. It’s very useful for newbies to understand. I Love you STH Reply Great article.Especially the Qualities of highly effective testers para.. was amazing. Reply Great article.Especially the Qualities of highly effective testers para.. was amazing. Can someone tell me what are the questions we can ask in initial project discussion meeting with client? Reply Can someone tell me what are the questions we can ask in initial project discussion meeting with client? Much appreciated! This current one’s a decent perused! Manual testing expects us to be inventive in making experiments to ensure we cover however much situations as could reasonably be expected. It likewise enables us to better comprehend the application, programming, API, or highlight and upgrade our specialized abilities too. Computerization then again is similarly vital to spare us time doing manual and tedious tests. Reply Much appreciated! This current one’s a decent perused! Manual testing expects us to be inventive in making experiments to ensure we cover however much situations as could reasonably be expected. It likewise enables us to better comprehend the application, programming, API, or highlight and upgrade our specialized abilities too. Computerization then again is similarly vital to spare us time doing manual and tedious tests. Thanks! This one’s a good read! Manual testing requires us to be creative in creating test cases to make sure we cover as much scenarios as possible. It also allows us to better understand the application, software, API, or feature and enhance our technical skills as well. Automation on the other hand is equally important to save us time doing manual and repetitive tests. Although automation is the current trend, it can never replace manual testing. Reply Rightly said @Kangkong, and Thanks. Reply Thanks! This one’s a good read! Manual testing requires us to be creative in creating test cases to make sure we cover as much scenarios as possible. It also allows us to better understand the application, software, API, or feature and enhance our technical skills as well. Automation on the other hand is equally important to save us time doing manual and repetitive tests. Although automation is the current trend, it can never replace manual testing. Rightly said @Kangkong, and Thanks. Reply Rightly said @Kangkong, and Thanks. clearly understandable ,explained in simple words Reply clearly understandable ,explained in simple words Hi, After clicking on the “Gamma Testing” under Software Testing Types, It shows only the image of Gamma Testing and not the content. Reply After clicking on the “Gamma Testing” under Software Testing Types, It shows only the image of Gamma Testing and not the content. Explained it is in genuine and open straight way to the Testers, But every manual tester should have any other expertise lie automation/API testing or other ETL testing along with technical knowledge(LINUX/ XML configuration testing). I just give sample as per my knowledge. Reply Explained it is in genuine and open straight way to the Testers, But every manual tester should have any other expertise lie automation/API testing or other ETL testing along with technical knowledge(LINUX/ XML configuration testing). I just give sample as per my knowledge. Very much useful article for me as I am an Electrical Engineer and working in the Software company by holding the position of Software Tester. I am the one who not had deep knowledge of Computer field. But I planned to do some courses for software languages which will be useful to me to be a Great Tester. Reply Very much useful article for me as I am an Electrical Engineer and working in the Software company by holding the position of Software Tester. I am the one who not had deep knowledge of Computer field. But I planned to do some courses for software languages which will be useful to me to be a Great Tester. The content is very Good and very needful, the subject is very clear to understand. Reply The content is very Good and very needful, the subject is very clear to understand. Apply equivalence partition & boundary value analysis for below scenario: – Withdraw 2000 rs from ATM and 500 rs note only available in ATM Reply Apply equivalence partition & boundary value analysis for below scenario: – Withdraw 2000 rs from ATM and 500 rs note only available in ATM “Automated testing” is usually just a bunch of scripts running continuously doing regression checks. It’s not like replacing manual labour in manufacturing, where the term “automation” probably comes from. You really haven’t automated anything. But it’s understandable why sales agents likes the term. Reply “Automated testing” is usually just a bunch of scripts running continuously doing regression checks. It’s not like replacing manual labour in manufacturing, where the term “automation” probably comes from. You really haven’t automated anything. But it’s understandable why sales agents likes the term. I need some guidance on this course. Actually I am design engineer with 8 yrs of experience in machine design and after that 5 yrs of break. Can I join this course and change my field? Reply I need some guidance on this course. Actually I am design engineer with 8 yrs of experience in machine design and after that 5 yrs of break. Can I join this course and change my field? Very Helpful in self motivation and interview point of view. i found that i an inbuilt tester. thank you soo much.. Reply Very Helpful in self motivation and interview point of view. i found that i an inbuilt tester. thank you soo much.. i want to open own software Reply i want to open own software Best place for software testing course online, Providing software testing tools, courses, certification, tutorials online. software testing tools. software testing Reply Best place for software testing course online, Providing software testing tools, courses, certification, tutorials online. software testing tools. software testing Thanks Vijay! I agree with Naga Sekhar that one technical knowledge should be here along with manual function testing. But expecting a blog of steps for manual tester to learn Automation without any knowledge of any language. Reply Yes @Deepak,Technical knowledge always helps. Reply Thanks Vijay! I agree with Naga Sekhar that one technical knowledge should be here along with manual function testing. But expecting a blog of steps for manual tester to learn Automation without any knowledge of any language. Yes @Deepak,Technical knowledge always helps. Reply Yes @Deepak,Technical knowledge always helps. The content is very useful to us and gathering for more knowledge in the domain. we provding the manual software testing training in trichy for all streaming of students. Reply The content is very useful to us and gathering for more knowledge in the domain. we provding the manual software testing training in trichy for all streaming of students. very good information. Reply very good information. Yes I think that,as we came to know actual defects with ui Reply Yes I think that,as we came to know actual defects with ui very well guide for software tseting ,it is very useful information useful online course Thanks for sharing it Reply very well guide for software tseting ,it is very useful information useful online course Thanks for sharing it Hii Mahesh! Thanks for such a valuable information about software testing and I agree with you that automation cant replace human testing. I am currently a beginner in this field and would love to gain more knowledge about this in depth. In today’s world software testing helps in software adaptability, identify errors, avoid extra costs, accelerates software development, avoid risks and to optimise business which is so important. I know that many of the beginners in this field would love to gain more knowledge, also would have questions regarding it and it is not possible for everyone to get their answers. Reply Hii Mahesh! Thanks for such a valuable information about software testing and I agree with you that automation cant replace human testing. I am currently a beginner in this field and would love to gain more knowledge about this in depth. In today’s world software testing helps in software adaptability, identify errors, avoid extra costs, accelerates software development, avoid risks and to optimise business which is so important. I know that many of the beginners in this field would love to gain more knowledge, also would have questions regarding it and it is not possible for everyone to get their answers. Thanks a lot.The article was very helpful to understand the basics of testing. Reply Thanks a lot.The article was very helpful to understand the basics of testing. Thanks for sharing your view. Last 3-4 paragraphs are really very interesting. But these days most of the companies have jobs more and more in automation testing even if we know most of the work is done manually in most of the companies. Reply Thanks for sharing your view. Last 3-4 paragraphs are really very interesting. But these days most of the companies have jobs more and more in automation testing even if we know most of the work is done manually in most of the companies. softwaretestinghelp.com/what-is-software-testing-life-cycle-stlc/ In the below link SDLC phases are provided instead of STLC or provided one is correct..? Reply softwaretestinghelp.com/what-is-software-testing-life-cycle-stlc/ In the below link SDLC phases are provided instead of STLC or provided one is correct..? Do you guys have same thing for automation testing. Reply Do you guys have same thing for automation testing. very well described, the knowledge shared was very useful. thanks for guiding beginners. Reply very well described, the knowledge shared was very useful. thanks for guiding beginners. I WANT TO STUDY SOFTWARE TESTING, CAN YOU SUGGEST FEW GOOD INSTITUTE? Reply http://softwaretestinghelp.org/ Reply I WANT TO STUDY SOFTWARE TESTING, CAN YOU SUGGEST FEW GOOD INSTITUTE? http://softwaretestinghelp.org/ Reply http://softwaretestinghelp.org/ As a manual tester in the age of automation I’m hitting a brick wall in the work search. Automation has it’s place but it only looks where you tell it. If I’m doing a functional test opening a screen and half the screen turns blue or audio starts screeching I know it’s an issue. If the automation is looking for the page to come up without looking for these other issues it would pas. I’m an old hand tester having been in the industry since 1990. Reply Hello @Roger, first of all respect to your so many years of service to community. Wish you luck. Agree with what you said. Reply As a manual tester in the age of automation I’m hitting a brick wall in the work search. Automation has it’s place but it only looks where you tell it. If I’m doing a functional test opening a screen and half the screen turns blue or audio starts screeching I know it’s an issue. If the automation is looking for the page to come up without looking for these other issues it would pas. I’m an old hand tester having been in the industry since 1990. Hello @Roger, first of all respect to your so many years of service to community. Wish you luck. Agree with what you said. Reply Hello @Roger, first of all respect to your so many years of service to community. Wish you luck. Agree with what you said. Leave a Comment Cancel reply