Entries Tagged 'Manual Testing' ↓

The first and Second part of our Manual Testing Series covered the basics of Manual Testing and its process. If you haven’t read it yet, please do so before continuing with this article to connect better.

Can’t do? Of course, thoughts and suggestions shared in this article can be used independently as well. This last part is about the preparation and possible ways to get into a software testing job/career.

Continue reading →

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?  Continue reading →

A Complete List of 100+ Manual Testing Tutorials:

This is going to be the most in-depth series of tutorials on Manual Software Testing. Go through the topics mentioned in this series carefully to learn the basic and advanced testing techniques.

This series of tutorials would really enrich your knowledge and will, in turn, mold your testing skills in a much better way. Continue reading →

In this tutorial, we will learn the components involved in a Java application and the various types of testing that need to be carried out to ensure a high quality, bug-free application.

This is a three-part series on testing JAVA applications.

1. In this article, we will learn the J2EE components and Manual testing approach for a J2EE application.
2. In the second, we will review the Automated testing approach for testing J2EE applications, and
3. In the third, we will review a comprehensive list of tools that are available for testing J2EE applications.

Continue reading →

Nobody wants to be known for their mistakes and their negligence, and same is the case with the Testers. When the Testers are assigned any application to test, then from that moment, they take the responsibility and the application also acts as a platform to show their practical and technical testing knowledge.

So, to describe it technically, to ensure that testing is done completely, it is necessary to perform “End to End testing”. Continue reading →

Today in this era of Automation Testing, almost in every QA testing departments’ automation is the first preference. But there are few QA departments where 70-80% of testing is carried out manually. Indeed, there are cases where quality is completely determined manually as no automation is carried out there.

One of the crucial reasons for companies to continue with the manual test is the inability of automation tools to cope with the changes that some application faces on regular basis. In certain cases, the only option left with QA is of manual testing. Continue reading →

Difference between Test Scenario Vs Test Case:

6 years ago, while working with a medium sized MNC, when I suggested to document test scenarios rather than wasting time on preparing the full proof document called test cases, all the heads turned to me in annoyance.

The look on the faces was clearly conveying that I made a big mistake by suggesting it. Although no one denied the idea no one even accepted. Everyone felt that following the tradition, i.e. writing test case document, would be safer. I could not argue.

After 4 years, the company received a testing project, where the only constraint was time and only expectation was full proof testing.

We were in the meet again and were discussing ideas to meet the critical deadline. The application was mainly about search and generating different reports via different menu items. Documenting test cases was supposed to snatch most of the time and we were not sure, how much the document was going to use to the client.

I suggested documenting test scenarios and somehow with some hesitation, everyone agreed. No need to mention that we could save precious time of documentation and could utilize it for testing.

Are Test Cases being replaced fast with test scenarios?

With time, as everything is changing, software industry and processes also have changed a lot.

Traditional waterfall and v-models are being replaced by agile and iterative models. Documentation is necessary but to meet deadlines and making the process easy and transparent, the way of documentation can be changed.

Documentation of test cases is important when:

1. The client has asked for the same as part of the project
2. There is no time constraint (I don’t think it’s possible)
3. Testers are fresher or unknown to product
4. Company policy (I strongly believe that it can be changed)

Let me share with you one experience:

I and my team were involved in testing a project from fortune 500 company with flexible timelines. We documented test cases with a best available template and got it approved by the client. Once the build started releasing to QA team, for most of the day, our duty was, mechanically follow 100 test cases per day, update document with pass/fail result and send it to the client at the end of the day. Most of the team members started complaining about monotonous work but the company was generating revenue.

Then there was a break for one day in between with no new build to test. We sat together at the beginning of the day and were discussing what we were going to do for the day. When I proposed to generate more ideas to improve the test case document, all the team members denied putting in efforts. As per them, there was nothing more to think about as we had covered all the scenarios. And convincing them to think out of a box and generate more ideas was really tough.

Most of the time, when we document test cases and that too once approved by the client, that human mind thinks that we have done our job and our mind automatically stops considering any effort to think about other ways to test the product.

And believe me, when test cases document is prepared, we just want to follow it mechanically. Tell me for how many times in your career, you have experienced that you or the teammate offered additional test cases to the approved test cases document?

One more experience:

During weekly team challenge activity, we announced the application and asked the team members to pour in test scenarios. All the team members, including those late responders or non-responders, put in ideas. Why? There was no formal documentation where they had to fill expected result for every sequence of functionality and pre-condition for each test case. We collected 40 test scenarios in a day and that was a great experience.

To favor my experience, I would like to present an example.

Take a sample application, say login page with username, password, login, and cancel buttons. If asked to write test cases for the same, we will end up writing more than 50 test cases by combining different options and details.

But if test scenarios to be written, it will be a matter of 10 lines as below:

High-Level Scenario:   Login Functionality
Low-Level Scenarios:

1. To check Application is Launching
2. To check text contents on login page
3. To check Username field
4. To check Password field
5. To check Login Button and cancel button functionality

See Also => 180+ Sample Test scenarios for testing web and desktop applications.

As we all are at short of time, test scenarios work as painkiller spray rather than that old time IODEX. And still, the effect is same.

Finally, I would like to summarize the difference between test scenario vs test case:

Finally, this post should be concluded as:

Test cases are most important part of Software Development Life Cycle and without the one, it’s tough to track, understand, follow and reason out something. But in the era of Agile, test cases are being replaced fast with test scenarios.

A common test checklist for each type of testing (database testing, GUI testing, functionality testing etc) coupled with test scenarios is the modern artillery for Software Testers.  Discussions, training, questions, and practice can definitely change the final graph of your productivity as well as Bug report matrix.

About the Author: This awesome post is written by STH author Bhumika M.

As usual, we welcome your thoughts and queries. Please tune in.

PREV Tutorial | NEXT Tutorial

How to test the most common components of your AUT effectively, every single time

This article is a list of common validations on most widely found elements of AUT – that is put together for the convenience of testers (especially in the agile environment where frequent short-term releases happen).

Every AUT (Application Under Test) is unique and has a very specific business purpose. The individual aspects (modules) of the AUT cater to different operations/actions that are crucial to the success of the business that the AUT supports. Though each AUT is designed differently, Continue reading →

“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 no time.

There are significant changes in the Software Testing pertaining to these recent days. In this ebook are the exact basic steps and testing fundamentals you must know before starting to test any application. Continue reading →

This will be basic “how-to” article and is not any automation tool specific. Basically, what I am trying to do here is put the thought process that goes into creating an automation test case into words. As always, I hope this will be useful to you all.

How to design an automation test case or script?

Automation always follows manual testing. Typically, one or more rounds of manual testing already would be performed on the AUT. This implies that manual test cases already exist and have been executed at least once.

Continue reading →