Difference between Black Box Testing and White Box testing.

Difference between Black Box Testing and White Box testing.

S.No	Black Box Testing	White Box Testing
1	The main objective of this testing is to test the Functionality / Behavior of the application.	The main objective is to test the infrastructure of the application.
2	This can be performed by a tester without any coding knowledge of the AUT (Application Under Test).	Tester should have the knowledge of internal structure and how it works.
3	Testing can be performed only using the GUI.	Testing can be done at an early stage before the GUI gets ready.
4	This testing cannot cover all possible inputs.	This testing is more thorough as it can test each path.
5	Some test techniques include Boundary Value Analysis, Equivalence Partitioning, Error Guessing etc.	Some testing techniques include Conditional Testing, Data Flow Testing, Loop Testing etc.
6	Test cases should be written based on the Requirement Specification.	Test cases should be written based on the Detailed Design Document.
7	Test cases will have more details about input conditions, test steps, expected results and test data.	Test cases will be simple with the details of the technical concepts like statements, code coverage etc.
8	This is performed by professional Software Testers.	This is the responsibility of the Software Developers.
9	Programming and implementation knowledge is not required.	Programming and implementation knowledge is required.
10	Mainly used in higher level testing like Acceptance Testing, System Testing etc.	Is mainly used in the lower levels of testing like Unit Testing and Integration Testing.
11	This is less time consuming and exhaustive.	This is more time consuming and exhaustive.
12	Test data will have wide possibilities so it will be tough to identify the correct data.	It is easy to identify the test data as only a specific part of the functionality is focused at a time.
13	Main focus of the tester is on how the application is working.	Main focus will be on how the application is built.
14	Test coverage is less as it cannot create test data for all scenarios.	Almost all the paths/application flow are covered as it is easy to test in parts.
15	Code related errors cannot be identified or technical errors cannot be identified.	Helps to identify the hidden errors and helps in optimizing code.
16	Defects are identified once the basic code is developed.	Early defect detection is possible.
17	User should be able to identify any missing functionalities as the scope of this testing is wide.	Tester cannot identify the missing functionalities as the scope is limited only to the implemented feature.
18	Code access is not required.	Code access is required.
19	Test coverage will be less as the tester has limited knowledge about the technical aspects.	Test coverage will be more as the testers will have more knowledge about the technical concepts.
20	Professional tester focus is on how the entire application is working.	Tester/Developer focus is to check whether the particular path is working or not.

SDLC

SDLC: stands for Software development life cycle it is a standard procedure to develop the software.

It has got different Models like

1. Waterfall Model
2. Spiral Model
3. V Model
4. Prototype Model
5. Derived Model
6. Hybrid Model
7. Agile Model

It has got different stages like

1. Requirement collection
2. Feasibility study/Analysis
3. Design
4. Coding
5. Testing
6. Installation 
7. Maintenance

Popular Server name

Popular web serveres:
Apache HTTP Server.
IIS
Lighttpd
LiteSpeed Web server
---------------------------
Application Servers:
Apache Tomcat
WebLogic
GlassFish
JBoss
WebSphere
---------------------------
Data Base servers:
Oracle
My SQL
MS-SQL Server
DB2
Sybase
Terradata

Adhoc Testing

AD – HOC Testing ( also called Monkey Testing / Gorilla Testing )

Testing the application randomly is called Ad-hoc testing.

Why we do Ad-hoc testing ?

1) End-users use the application randomly and he may see a defect, but professional TE uses the application systematically so he may not find the same defect. In order to avoid this scenario, TE should go and then test the application randomly (i.e, behave like and end-user and test).

For ex,

In the above figure, after we have tested the application for FT, IT and ST – if we click on some feature instead of going to homepage (or) sometimes datapage, if it goes to blank page then it will be a bug. In order to avoid these kind of scenarios, we do Ad-hoc testing.

2) Development team looks at the requirements and build the product. Testing Team also look at the requirements and do the testing. By this method, Testing Team may not catch many bugs. They think everything works fine. In order to avoid this, we do random testing behaving like end-users.

3) Ad-hoc is a testing where we don’t follow the requirements (we just randomly check the application). Since we don’t follow requirements, we don’t write test cases.

Examples of Ad-Hoc testing for Gmail :

1) Login to Gmail using valid username and password. Logout  from Gmail. Click on Back button. It should not go back to Inbox page. If it does, then it is a javascript error and it is a bug. It should go back to Login page and say session expired.

2) Login to Gmail homepage using valid username and password. Once we are in Inbox page, copy the URL of the inbox which is in the address bar of the homepage and paste it in Notepad file. Logout from Gmail. Now, open browser page and paste the URL of the inbox in the address bar. It should not go to the inbox, instead it must go to the welcome page of Gmail.

3) Login into Gmail. Go to Settings and Change Password. Set the old password only as the new password and see what happens.

Let us consider an example of Fraud Management System of Online Banking Application.

When we click on the Block Account link, we are transferred to the Block Account page where we find several features in that. Enter the data and click on Block Account, then that account has to be blocked.

Now, we will see how we can do Ad-hoc testing on this application.

1) Login as Bank Manager and enter the Account Number and click Block and see whether it is blocked or not.

2) Before blocking the Account, Go and Delete the person whose account is to be blocked and again Login and check whether it is blocked or not. As we click the Block it should throw a message saying customer not available as an error message. Here, we randomly check the application and nothing is mentioned in the requirements. Thus here we do Ad-hoc testing.

3) Suppose some User B transfers money to A whose account is blocked. In this case also, we should get a message saying Account(of A) is blocked [ i.e, by the time B transfers money, manager blocks A’s account].

Actually the requirement does not say check for money transfer from other account and do testing. But this testing is done by TE not against the requirement. Even sometimes without throwing message that Account is blocked the money gets transferred. In this case also, the TE checks for it and thus it becomes Ad-hoc Testing.

NOTE :-

·         Ad-hoc testing is basically negative testing because we are testing against requirements ( out of requirements ).

·         Here, the objective is to somehow break the product.

When to do Ad-Hoc testing ?

·         Whenever we are free, we do Ad-hoc testing. i.e, developers develop the application and give it to testing team. Testing team is given 15days for doing FT. In that he spends 12 days doing FT and another 3days he does Ad-hoc testing. We must always do Ad-hoc testing in the last because we always 1^st concentrate on customer satisfaction

·         After testing as per requirements, then we start with ad-hoc testing

·         When a good scenario comes, we can stop FT, IT, ST and try that scenario for Ad-hoc testing. But we should not spend more time doing Ad-hoc testing and immediately resume with formal testing.

·         If there are more such scenarios, then we record it and do it at the last when we have time.

Forms of Adhoc Testing

1.   Buddy Testing: Two buddies, one from development team and one from test team mutually work on identifying defects in the same module. Buddy testing helps the testers develop better test cases while development team can also make design changes early. This kind of testing happens usually after completing the unit testing.

2.   Pair Testing: Two testers are assigned the same modules and they share ideas and work on the same systems to find defects. One tester executes the tests while another tester records the notes on their findings.

3. Monkey Testing: Testing is performed randomly without any test cases in order to break the system 

Smoke Testing

*** SMOKE  TESTING or SANITY TESTING or DRY RUN or SKIM TESTING or BUILD VERIFICATION TESTING or Skim Testing or Confidence Testing *** (Very very important interview question)

Testing the basic or critical features of an application before doing thorough testing or rigorous testing is called as smoke testing.

It is also called Build Verification Testing – because we check whether the build is broken or not.

Whenever a new build comes in, we always start with smoke testing, because for every new build – there might be some changes which might have broken a major feature ( fixing the bug or adding a new feature could have affected a major portion of the original software).

In smoke testing, we do only positive testing – i.e, we enter only valid data and not invalid data.

Advantages:

1. Test engineer can find blocker and critical defects in the early stage itself.
2. Development team will get sufficient time to fix the defects.
3. Test cycle will not be postponed and hence release will not be delayed.

How to do smoke testing?

Here we should list the feature to be tested as part of smoke testing and the features not to be tested as part of smoke testing.

When we are doing smoke testing, we do only positive testing (only valid data is entered)

Here, we test only basic or critical features

Here, we take basic features and test for important scenarios

How to write smoke testing scenarios?

1.      To check that when user entered test-url welcome page should be displayed
2.      To check that when the user click on sign up link, signup page should be displayed.
3.      To check that when user entered valid data to all the fields in the sign up page and click on submit button, account should be created.
4.      To check that when user entered valid login credentials and click on login button, home page should be displayed.
5.      To verify used can compose and send a mail.
6.      To verify that user can receive the mails
7.      To verify send mails are displayed in sent item.

When we do smoke testing?

1.      As soon as we get new build from development team we do smoke testing.

 (Because for every new build – there might be some changes which might have broken a major feature ( fixing the bug or adding a new feature could have affected a major portion of the original software).)

2.      Whenever the build comes to the customer, before the customer / client does Acceptance Testing, he also do Smoke Testing to verify all the files are received and build is installed properly or not.

3.      Build engineer/Release engineer will do smoke testing to verify whether build is installed properly or not in test server or in production server.

4.      Developer will do smoke testing after WBT and before giving a build to testing team.

Why we do smoke testing?

1.      To check whether software is testable or not

2.      First day itself while doing smoke testing if we find bugs send it to developers so that they will get sufficient time to fix the defect.

3.      To verify whether build is installed properly or not.

4.      Developers are giving build means they would have done some changes, chances are there that changes might affecting old basic or critical features in order  to find that we do smoke testing,

5.      It is like a health check of the product so smoke testing should be done.

6.      It is like a build verification testing, here we check build is broken or not (if the build is having more number of defects then the build is called as broken build.

Important Points to Remember

·         When we are doing smoke testing, we do only positive testing (only valid data is entered)

·         Here, we test only basic or critical features

·         Here, we take basic features and test for important scenarios

·         Before doing through FT/IT/ST we do smoke testing.

·         Before acceptance testing customers will do smoke testing

·         Once after the software is deployed to the production server, before using the software for the business, smoke testing should be done.

Types of Smoke testing:

Smoke testing is classified into two types,

·         Formal Smoke Testing – the development team sends the s/w to the test lead. The test lead then instructs the testing team to do smoke testing and send report after smoke testing. Once, the testing team is done with smoke testing, they send the smoke testing report to the Test lead.

·         Informal Smoke Testing – here, the test lead says the product is ready and to start testing. He does not specify to do smoke testing. But, still the testing team start testing the product by doing smoke testing.

What are the ways to do smoke testing?

There are 2 ways to do smoke testing.

1.      Manual

2.      Automation

Do you write smoke test scenarios?

Yes

Can we automate smoke test scenarios?

Yes

What is the difference between smoke and sanity testing?

As per my knowledge there is no difference between smoke and sanity testing but I have gone through some website and documents were in i got to know there are some difference between smoke and sanity testing.

Smoke Testing	Sanity Testing
It is wide and shallow testing approach	It is a deep and narrow testing approach
Smoke testing is Positive testing.	It is both positive and negative testing.
Here we document scenarios and test case. (Scripted)	Here we don’t document scenarios and test case( unscripted)
We can go for automation	We don’t go for automation
It is done by both developer and tester	It is done by only tester

Build verification testing:

As soon as we get the build, first we verify are there any blocker bugs are there or not is called build verification testing.

Confidence Testing:

While doing smoke testing we get to know there is no blocker bugs in the basic features this is called confidence testing.

Dry Run - A dry run is a testing process where the effects of a  possible failure are intentionally mitigated. For example,  an aerospace company may conduct a "dry run" of a takeoff  using a new aircraft on a runway before the first test  flight.

First day itself if you get to know product is not testable as a test engineer how will you spend your time?

I will spend my time in analyzing and understanding requirement, identifying scenarios and write test cases.  

Defect status

·  Rejected: If the defect is not considered as a genuine defect by the developer then it is marked as ‘Rejected’ by the developer.

·  Duplicate: If the developer finds the defect as same as any other defect or if the concept of the defect matches with any other defect then the status of the defect is changed to ‘Duplicate’ by the developer.

·  Deferred: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as ‘Deferred’.

What type of defect is a not reproducible defect?
Answer: A defect which is not occurring repeatedly in every execution and is producing only at some instances and whose steps as proof have to be captured with the help of screenshots, then such a defect is called as a ‘not reproducible’ defect.