Archive for the ‘Software Testing’ Category

Hi guys,

I found these some important concepts for any tester to know. So sharing with you all –

Black Box Testing – These tests are based on requirements and functionality, not based on any knowledge of internal design or code.
Tester has to test just the input and expected/actual output.
Synonyms for Black-box include: behavioral, functional, opaque-box, and closed-box.

White Box Testing – These are based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths, and conditions. For conducting these tests, tester should have the knowledge and access to internal code, algorithms and software designs.
Synonyms for white-box include: structural, glass-box and clear-box.

Gray Box Testing – It is a software testing technique that uses a combination of black box testing and white box testing. Gray box testing is not black box testing, because the tester does know some of the internal workings of the software under test. In gray box testing, the tester uses the internal code, algorithms for creating the Test Cases, one takes a black box approach in applying inputs to the software under test and observing the outputs.

Gray box testing is a powerful idea. The concept is simple; if one knows something about how the product works on the inside, one can test it better, even from the outside. Gray box testing is not to be confused with white box testing; i.e. a testing approach that attempts to cover the internals of the product in detail. Gray box testing is a test strategy based partly on internals. The testing approach is known as gray box testing, when one does have some knowledge, but not the full knowledge of the internals of the product one is testing.



Read Full Post »

Friends… I have seen in many places that more importance is given to Automated Testing than Manual Testing,it is a doubt in every tester’s mind as they move ahead in career. I have attended some Testing Forums about it as well.. but everyone has their own opinion about it. I strongly believe that both the types of testing methods are equally important at their side.

Some tests inherently require an automated approach to be effective, but others must be manual.
Generally Automated testing tools are quite expensive and only big MNCs can afford to buy them… in that case they use the Automation testing and things can be automated only if the environment is conducive and the tasks are repetitive. If there is an activity which requires a human intervention / supervision, it cannot be automated. More ever automation can be done only if few things are stabilized. But an effective automation tester can sprout only if he / she has adequate manual testing experience.

But small scale companies can not afford the expensive Automation testing tools, therefore they follow Manual Testing method. In this method each & every module of the application is tested thoroughly by the tester. If it is a constantly changing application, then Manual Testing makes sense.

I would say Manual & Automated both the testings are sides of the same coin. Manual testing serves as a stepping stone for automation testing. If a tester hasn’t done much of manual testing, he can’t hone his automation skills.

Read Full Post »

What is a Test Plan ?

A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.
It can also be defined as the high level testing documents that describe test project.
Test plan includes :
1. Scope of Testing
2. Schedule : It contains Test Strategy or Approach.
3. Test Deliverables
4. Release Criteria
5. Risks and Contingencies

What is a Test Case ?

The good test case is one which has maximum probability of finding the bugs.
The test cases should be good enough explanator, because problem well stated means its half solved.
“The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty).”
Test Cases usually have the following components.

* Test Case Summary
* Configuration
* Initial Condition
* Steps to run the test case
* Expected behavior/outcome
* Priority

Click here for Test case format.

Read Full Post »

When we test a Software Product, we have to fix a Test Plan first. While creating a Test Plan, deciding the Testing methodology plays a vital role followed by writing the Test Cases. Test Methodology is the strategy used to test the system.
Following are the steps included in Testing Methodology,
1) Unit Testing – Unit Testing is done @the developers’ end. In this they have to check whether the functionality implemented by them is working properly or not. Each smallest unit of the application is tested whether it is correctly working.

2) Integration Testing – In this kind of Testing, tester test various modules of the application. It deals with the defects in the interfaces and interaction between the modules.

3) System Testing – It tests a completely integrated system to verify whether the software meets the requirements.

4) System Integration Testing – verifies that a system is integrated to any external or third party systems defined in the system requirements.

Before shipping the final version of software, alpha & beta testing are done finally.

5) Alpha Testing – Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

6) Beta Testing – Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

7) Acceptance Testing – Finally Acceptance Testing can be conducted by the End-user, customer or client whether or not to accept the product. This testing can be performed as the part of Hand-off process between any two phases of developement. Successful Acceptance Testing is required before handing over the product to the customer.

8 ) Regression Testing – After modifying the software, either for a change in functionality or to fix defects, a Regression Test reruns the previously run Test cases. Regression Tests are often automated, they can be performed at any or all level of Testing.

Read Full Post »

We should consider the following points while testing any Web application:

1) Who are the users of the application and what is the motive behind the application?

2) The overall UI of the application should be catchy and impressive.

3) Home Page UI should be designed in a way that it should give the overview of the application and should depend upon the major features & contents of the application.

4) Appearancewise we should test the consistant layout , look & feel.
For ex: We should maintain the consistancy between color, font types, page title, Status bar Messages, Maximise/Minimise/Resize Window.

5) Navigation : In this we should mainly test the Pagination Pattern, Bread-crumps, links.

6) We should focus and emphasize on clear indication of current page and all kind of validations.

7) We should take care of the Header & Footer position and its contents.

8 ) The most important thing is that Web application should be fast in speed and efficient enough for better performance.

Refer the link given below for more info :
Web Application Testing

Read Full Post »

While testing the application you will need to select the severity and priority of the bug. It helps developer to fix the bug according to its need and priority. Different Severity and Priority levels communicate the bugs.

Priority –

  • P1 – FIX the bug ASAP

  • P2 – Bug can be fixed before release

  • P3 – We can fix the bug after release too

  • P4 – The bug is very minor, can be fixed whenever possible.

In general the assignment of priorities may vary depending upon the release date.

Severity –

  • Blocker
  • Critical
  • Major
  • Normal
  • Minor
  • Trivial (Also known as Cosmetic)
  • Enhancement (Suggestions)

1) Define Low priority and High severity Bug :

Suppose that some functionality blocks the application but not needed for current deliverable that is Highest severity and Lowest priority.


2) Define High priority and Low severity Bug :

For example client asks to change the Label of a button for current deliverable then that is a highest priority and Lowest severity.


3) Define High priority and High severity Bug :

Any functionality which blocks the application & that is needed for rhe current deliverable too, then that is a High priority and High severity.

In general Severity means it has Blocker condition for an application and Priority means it has critical condition for current deliverable.

Hope this article help you out guys 🙂

Read Full Post »

Some guys have doubts about the difference between Bug and Enhancement.

Its very simple ~

If the functionality implemented by us is not working properly and not giving desired results then that is a BUG. Whereas if we have some suggestions for the S/W product to improve its quality and garnish the features then it is an ENHANCEMENT.

Many people who don’t have much knowledge about it & usually having misconceptions about these things, do the kiddish mistakes. I have a very funny example for this, One of my ex-colleague (who is not a Testing Professional) had an account in Bugzilla. Once he found some issues in the In house Product, so he reported 4-5 bugs all with P1 priority and BLOCKER severity! But those issues were very minor:)

So every Software Professional in general should know about these basic yet very important Bug related terms.

Read Full Post »

Older Posts »