Feeds:
Posts
Comments

Posts Tagged ‘Software Testing’

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.

HTH 🙂

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 »

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 »

Friends… today I am going to write about some axioms of the Software Testing.
First of all the word “axiom” – It means a self evident or universally recognized truth.
An established rule/principle or law.

We should always keep in mind one thing as NEVER say that “The Software (Product) is tested completely!” Followed by it as “There are no BUGS in it!” These kind of statements will definitely result in many harsh issues. See “To err is human!” No entity in this world will be without defects or bugs!
So avoid using the above mentioned 2 terms for the S/W Product.

Following are some Software Testing Axioms –

  • It is impossible to test the program completely.
  • Software Testing is Risk based exercise.
  • Testing can’t show the bugs that doesn’t exist.
  • The more bugs you find, the more bugs are there.
  • Not all the bugs you find will be fixed.
  • Product specifications are never fixed.

Kindly let me know your views about these articles.

Read Full Post »

Older Posts »