Google 2014

How to Install the Selenium IDE

Hi Webies, since excel automation has some limits in the web sites, Open Source tools like Selenium IDE has good exposure to web testing, so today I'm going to explain how to install the Selenium IDE (Integrated Developement Environment) in browser.

The Selenium-IDE (Integrated Development Environment) is the tool you use to develop your Selenium test cases. It’s an easy-to-use Firefox plug-in and is generally the most efficient way to develop test cases. It also contains a context menu that allows you to first select a UI element from the browser’s currently displayed page and then select from a list of Selenium commands with parameters pre-defined according to the context of the selected UI element. This is not only a time-saver, but also an excellent way of learning Selenium script syntax.
Step 1: Download the IDE from the SeleniumHQ downloads page
Step 2: Click ‘Allow’ to proceed with the installation.
Step 3: Select Install Now. The Firefox Add-ons window pops up, first showing a progress bar, and when the download is complete. Restart Firefox. After Firefox reboots you will find the Selenium-IDE listed under the Firefox Tools menu.

Dynamic Scripting Using Rational Functional Tester

**The following article provides brief introduction to a heavily used aspect of Rational Functional Tester(RFT).  The reader is expected to have basic knowledge of RFT**  .
Introduction -
Rational Functional Tester (RFT) provides user with a  "Recorder"  that, as the name suggests,  records user actions on an Application Under Test(AUT) to create a script and this script can be played back by RFT to perform the same actions back on the AUT.

The script when generated with the help of the Recorder is backed up by an Object Map which  consists of  Objects that correspond to the actual control that the recorder interacted with while recording.
These objects  in the object map are representations of the controls in the AUT and are stored with a hierarchy and set of properties ( called Recognition Properties for the object).
During Playback , the playback engine uses this hierarchy and recognition properties to find the control in the AUT and then performs the specified action on it.

For example, the following shows code snippet of a script that performs a click on a button.
This statement  has two parts to it , first one being the okbutton() , if you notice it is not a variable  but a method , this method (which is implemented by the Helper class of the script) finds the actual control in the AUT using the properties and hierarchy stored in the object map , once the object is found the the operation i.e  click() is performed on it.
Using  Dynamic Scripting -
The above mentioned scenario is a traditional usage of  the Rational Functional Tester as a testing tool. Now, lets proceed to the topic that is heart of this article ... Dynamic Scripting.
Rational Functional Tester also gives you capability to hand-code  your script  , so that you can define the object you are looking for and tell RFT to perform whatever action you wish to perform on the actual object.
When you do so you are no longer bound to a static object map , your script itself would determine what are the properties of an object and how to look for it.
 Let me explain it with an example again.
Following code snippet shows  how  we can use the find() api to find the  search Text box on the google search page.
                              public void testMain(Object[] args)
                                    Property p1 = new Property(".class","Html.INPUT.text");
                                    Property p2 =  new Property(".name","q");   
                                    Property[] properties = {p1, p2};       
                                    TestObject[] candidates = find(atDescendant(properties));
                                    System.out.println("Found "+ candidates.length + " objects");   
                                    if( candidates.length ==0)
                                         System.out.prinltn("No object found with the specified property set ");
                                     //Something found  , perform some action.
                                    ((TextGuiTestObject)candidates[0]).setText("hello world");                                

testMain()is a method that is invoked by RFT playback engine.
Property defines a property name-value pair ,these properties could be Properties that are exhibited by the control or may be defined by RFT.
For eg:   ".class" property is defined by RFT and corresponds to the "tag" of an element  , in the example above  ".class" "Html.INPUT.text" corresponds to the  html  tag <input type=text>
The second property that is being used above is  the  ".name" property which is same as the  "name" property of the <input tag>, so instead of using ".name"  you could very well use "name"  as the property name.
Next we have defined an array to hold this property which is what the one of the forms of find()api expects, there other forms of find()api which also expect  the  name and value pair directly  so you could specify the properties as :

The find()api returns an array of TestObject which match the specified property set so its upto you to decide which one to pick ,or perhaps you should give more properties or unique properties so that we get a single candidate as a result (if applicable).
Proceeding further, find() does not accept the property directly , the find expects a Subitem( a class that belongs to RFT)..this subitem  is what is returned by the method - atDescendant and the other like  atChild,atList etc.
These methods (atD
escendant,atChild,atList) tell whether to search for the given property set at  Descendant Level , or Child level, or through a list.
atChild() will be faster then atDescendant() as it will only search at the direct child level  unlike atDescendant() that is going to be exhaustive because it is going to drill down to each child and its children until there is none left.
atList() gives guided path for the object we are looking for.
You have to have good familiarity  with the Application Under Test(AUT)  in order to make a good use of the find()api.
find() api can also be called on another TestObject and in that case that TestObject becomes the  starting point for the search.
By default   RootTestObject becomes the parent for the find()api to start the search with.
so the  statement:  
is equivalent to
If  we were able to find the objects  (as returned by the find() API)  next we need to perform some action on it. 
Note that the find() api  returns an  Array of   TestObject   which  may not expose the required  functions  as it  plain test object   to perform some  GUI related action like click() ...
as done in the statement,
,we must typecast it to a ..   GuiTestObject .
The Next  statement :
                ((TextGuiTestObject)candidates[0]).setText("hello world");  
again  typecasts  the TestObject to TextGuiTestObject because now we want to invoke a "text" related operation .. i.e   setText().  
So you should know what kind of different TestObjects RFT provides( the  API help has documentation on  each one of them) .

Moving ahead there is a call to remove the binding of the returned testobjects as a result of find()api, through the call to :
 the other forms of this API are:
                                   unregister(candidates);  //where candidates is an Array of TestObject returned by the the find()api.
                                  TestObject.unregister(); //Where TestObject is an object found  by the find() api.
It is important to unregister the objects once done  using them because unless you free these objects which are returned by the find()api (or some other similar APIs like getChildren())  ,there will be some memory still held by these object to reference the actual controls in the application.  And it may have its effect on the application during long executions of scripts.(*Remember that the proxy gets loaded into the AUT process and hence using the memory allocated to the  AUT process )
So the conclusion is that RFT gives user the capability to do a custom search/find for the required object  along with a Recorder that generates the script and object map automatically.
A test-script  very well could be a combination of hand-coded  scripts and the code generated by the recorder.
On one hand using a recorder is pretty simple and straightforward  and may be sufficient  for most of the cases but Handed coded scripts give you the flexibility to find the objects the way you want(or in situations where recorder may not be able to detect a control or perhaps playback engine is not able to find the object the hierarchy and recognition properties of a mapped test object ) , however it would require you to have some coding skills (in Java or VB depending on the IDE you are using).
And last but important point to note is that when using the dynamic scripting  the onus of freeing the objects  found by the find() api is with the user.  Releasing object is as simple as just adding a call to  "unregisterAll() " (or other variants) once done with using the object.
The playback engine does this thing automatically  when the object  is a mapped test object thus explicit  release of objects is not required when using  traditional record and playback. 
Reference :

What Is Smoke Testing!!!!!

Hi Webies after a long back I'm here with some basic testing functionalities with example. In this article I'm going to deal with Smoke Testing. 

So what is Smoke Testing????? 

Smoke testing is the surface level testing to certify that build provided by development to QA is ready to accept for further testing. 

What is Smoke Testing?

Smoke testing is non-extensive software testing, which makes sure that the most crucial functions of a program work, but not bothering with finer details because in smoke testing we only checks the major functionality of the software.

Smoke testing is performed by developers before releasing the build to the testing team and after releasing the build to the testing team it is performed by testers whether to accept the build for further testing or not. 

Smoke Testing Example

For Example in a project there are five modules like login, view user, user detail page, new user creation, and task creation etc. So in this five modules first of all developer perform the smoke testing by executing all the major functionality of modules like user is able to login or not with valid login credentials and after login new user can created or not, and user that is created viewed or not. So it is obvious that this is the smoke testing always done by developing team before submitting (releasing) the build to the testing team.

Now once the build is released to the testing team than the testing team has to check whether to accept or reject the build by testing the major functionality of the build. So this is the smoke test done by testers.

Why Smoke Testing is known as Build Acceptance Testing?

Smoke testing is also known by the name BAT (Build Acceptance Test) because it establishes the acceptance criteria for QA to accept and reject a build for further testing. So apart from smoke testing it is also very important for software people to know about build. 

What is Build in Software Testing?

A build is called as the version of software, typically one that is still in testing stage.

If the build clears the Smoke test, then it is accepted by QA for further testing, however if the build fails the Smoke test, then it’s rejected and QA reverts back to previously accepted build.

Script is use for smoke testing but does not for sanity so do not get confused.

Testing Overview and Black-Box Testing Techniques

Testing Overview and Black-Box Testing Techniques

Software testing is an important technique for assessing the quality of a software product.
In this chapter, we will explain the following:
• the basics of software testing, a verification and validation practice, throughout
the entire software development lifecycle
• the two basic techniques of software testing, black-box testing and white-box
• six types of testing that involve both black- and white-box techniques.
• strategies for writing fewer test cases and still finding as many faults as possible
• using a template for writing repeatable, defined test cases
1 Introduction to Testing

Software testing is the process of analyzing a software item to detect the differences
between existing and required conditions (that is, bugs) and to evaluate the features of
the software item. Software testing is an activity that should be done throughout
the whole development process .
Software testing is one of the “verification and validation,” or V&V, software practices.
Some other V&V practices, such as inspections and pair programming, will be discussed
throughout this book. Verification (the first V) is the process of evaluating a system or
component to determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase. Verification activities include testing
and reviews. For example, in the software for the Monopoly game, we can verify that
two players cannot own the same house. Validation is the process of evaluating a system
or component during or at the end of the development process to determine whether it
satisfies specified requirements. At the end of development validation (the second V)
activities are used to evaluate whether the features that have been built into the software
satisfy the customer requirements and are traceable to customer requirements. For
example, we validate that when a player lands on “Free Parking,” they get all the money
that was collected. Boehm has informally defined verification and validation as

Verification: Are we building the product right?

Through verification, we make sure the product behaves the way we want it to. For
example, on the left in Figure 1, there was a problem because the specification said that
players should collect $200 if they land on or pass Go. Apparently a programmer
implemented this requirement as if the player had to pass Go to collect. A test case in
which the player landed on Go revealed this error.

Validation: Are we building the right product?

Through validation, we check to make sure that somewhere in the process a mistake
hasn’t been made such that the product build is not what the customer asked for;
validation always involves comparison against requirements. For example, on the right

Are we building the product right?


Are we building the right product?

Both of Boehm’s informal definitions use the term “right.” But what is “right”? In
software we need to have some kind of standard or specification to measure against so
that we can identify correct results from incorrect results. Let’s think about how the
incorrect results might originate. The following terms with their associated definitions are helpful for understanding these concepts:

o Mistake – a human action that produces an incorrect result.
o Fault [or Defect] – an incorrect step, process, or data definition in a program.
o Failure – the inability of a system or component to perform its required function
within the specified performance requirement.
o Error – the difference between a computed, observed, or measured value or
condition and the true, specified, or theoretically correct value or condition.
o Specification – a document that specifies in a complete, precise, verifiable
manner, the requirements, design, behavior, or other characteristic of a system or
component, and often the procedures for determining whether these provisions
have been satisfied.
A mistake committed by a person becomes a fault (or defect) in a software artifact, such
as the specification, design, or code. This fault, unless caught, propagates as a defect in
the executable code. When a defective piece of code is executed, the fault may become a
visible anomaly (a variance from the specification or desired behavior) and a failure is
“I know this game has money and
players and “Go” – but this is not the
game I wanted.”
“I landed on “Go” but didn’t get my
observed. Otherwise, the fault remains latent. Testing can reveal failures, but it is the
faults that must be found and removed ; finding a fault (the cause of a failure) can be
time consuming and unpredictable. Error is a measure of just how incorrect the results
A purpose of testing is
to cause failures in order to make faults visible  so that the faults can be fixed and not
be delivered in the code that goes to customers. Another purpose of testing is to assess
the overall quality level of the code. For example, a test team may determine a project
with too many high-severity defects should be sent back to development for additional
work to improve the quality before the testing effort should continue. Or, the
management may have a policy that no product can ship if testing is continuing to reveal
high-severity defects.
Compared with
specification or desired
A programmer makes a
The mistake manifests
itself as a fault1 [or
defect] in the program.
A failure is observed if
the fault [or defect] is
made visible. Other
faults remain latent in
the code until they are
observed (if ever).

1.1 The Economics of Software Testing
In software development, there are costs associated with testing our programs. We need
to write out test plan and our test cases, we need to set up the proper equipment, we need
to systematically execute the test cases, we need to follow up on problems that are
identified, and we need to remove most of the faults we find. Actually, sometimes we
can find low-priority faults in our code and decide that it is too expensive to fix the fault
1 The IEEE does not define defect however, the term defect is considered to be synonymous with fault.
because of the need to redesign, recode, or otherwise remove the fault. These faults can
remain latent in the product through a follow-on release or perhaps forever.
For faults that are not discovered and removed before the software has been shipped,
there are costs. Some of these costs are monetary, and some could be significant in less
tangible ways. Customers can lose faith in our business and can get very angry. They can
also lose a great deal of money if their system goes down because of our defects. (Think
of the effect on a grocery store that can’t check out the shoppers because of its “down”
point-of-sale system.) And, software development organizations have to spend a great
deal of money to obtain specific information about customer problems and to find and fix
the cause of their failures. Sometimes, programmers have to travel to customer locations
to work directly on the problem. These trips are costly to the development organization,
and the customers might not be overly cheerful to work with when the programmer
arrives. When we think about how expensive it is to test, we must also consider how
expensive it is to not test – including these intangible costs as well as the more obvious
direct costs.
We also need to consider the relative risk associated with a failure depending upon the
type of project we work on. Quality is much more important for safety- or missioncritical
software, like aviation software, than it is for video games. Therefore, when we
balance the cost of testing versus the cost of software failures, we will test aviation
software more than we will test video games. As a matter of fact, safety-critical software
can spend as much as three to five times as much on testing as all other software
engineering steps combined !
To minimize the costs associated with testing and with software failures, a goal of testing
must be to uncover as many defects as possible with as little testing as possible. In other
words, we want to write test cases that have a high likelihood of uncovering the faults
that are the most likely to be observed as a failure in normal use. It is simply impossible
to test every possible input-output combination of the system; there are simply too many
permutations and combinations. As testers, we need to consider the economics of testing
and strive to write test cases that will uncover as many faults in as few test cases as
possible. In this chapter, we provide you with disciplined strategies for creating efficient
sets of test cases – those that will find more faults with less effort and time.

1.2 The Basics of Software Testing
There are two basic classes of software testing, black box testing and white box testing.
For now, you just need to understand the very basic difference between the two classes,
clarified by the definitions below :

o Black box testing (also called functional testing) is testing that ignores the
internal mechanism of a system or component and focuses solely on the outputs
generated in response to selected inputs and execution conditions.

o White box testing (also called structural testing and glass box testing) is testing
that takes into account the internal mechanism of a system or component.

The classes of testing are denoted by colors to depict the opacity of the testers of the code.
With black box testing, the software tester does not (or should not) have access to the
source code itself. The code is considered to be a “big black box” to the tester who can’t
see inside the box. The tester knows only that information can be input into to the black
box, and the black box will send something back out. Based on the requirements
knowledge, the tester knows what to expect the black box to send out and tests to make
sure the black box sends out what it’s supposed to send out. Alternatively, white box
testing focuses on the internal structure of the software code. The white box tester (most
often the developer of the code) knows what the code looks like and writes test cases by
executing methods with certain parameters. In the language of V&V, black box testing is
often used for validation (are we building the right software?) and white box testing is
often used for verification (are we building the software right?). This chapter focuses on
black box testing.
All software testing is done with executable code. To do so, it might be necessary to
create scaffolding code. Scaffolding is defined as computer programs and data files built
to support software development and testing but not intended to be included in the final
product . Scaffolding code is code that simulates the functions of components that
don’t exist yet and allow the program to execute . Scaffolding code involves the
creation of stubs and test drivers. Stubs are modules that simulate components that aren’t
written yet, formally defined as a computer program statement substituting for the body
of a software module that is or will be defined elsewhere . For example, you might
write a skeleton of a method with just the method signature and a hard-coded but valid
return value. Test drivers are defined as a software module used to involve a module
under test and often, provide test inputs, controls, and monitor execution and report test
results . Test drivers simulate the calling components (e.g. hard-coded method calls)
and perhaps the entire environment under which the component is to be tested .
Another concept is mock objects. Mock objects are temporary substitutes for domain
code that emulates the real code. For example, if the program is to interface with a
database, you might not want to wait for the database to be fully designed and created
before you write and test a partial program. You can create a mock object of the database
that the program can use temporarily. The interface of the mock object and the real
object would be the same. The implementation of the object would mature from a dummy implementation to an actual database.

Excel 2013 - Keyboard shortcuts

Formatiing Shortcuts
Bold                                              CTRL+B
Italic                                              CTRL+I
Underline                                       CTRL+U
Format Box                                   CTRL+1
COPY                                           CTRL+C
PASTE                                          CTRL+V
Paste Only Format                         ALT+E+S+T
Paste Only Formulas                      ALT+E+S+F
Paste Only Values                          ALT+E+S+V
CUT                                              CTRL+X
REPEAT                                        CTRL+Y
Undo                                              CTRL+Z
Delete Cell Contents                       Delete
Delete all Cell Attributes                  ALT+H+E+A
Delete Cell Comment                      ALT+H+E+M
Outline Border                                SHIFT+CTRL+&
Remove Border                              SHIFT+CTRL+_
Insert a comment                            SHIFT+F2

Tab navigation

Move/ Copy a tab                          ALT + H + O + M
Change tab name                           ALT + H + O + R
Moving to left/right tabs                 CTRL + Pg Up/Down
New tab                                        SHIFT + F11
Insert worksheet                            ALT + I + W

Row / column shortcuts

Select column                                CTRL + Space
Select row                                     Shift + Space
Delete row(s) / column(s)               CTRL + 'minus sign'
Add row(s) / column(s)                  CTRL + SHIFT + 'plus sign'
Group / ungroup rows and column  SHIFT + ALT + left / right arrow key
Delete Fit column width                  ALT + H + O + I

Data editing shortcuts

Select All                                         CTRL + A
Fill Down                                         CTRL + D
Fill right                                            CTRL + R
Find                                                 CTRL + F
Replace                                           CTRL + H
Flash Fill                                          CTRL + E
Edit cells                                          F2
Start a formula                                 = (equal sign)
Insert AutoSum formula                   ALT + “+“ (hold down ALT)

Workbook navigation shortcuts Replace 

Toggle Excel workbooks                 CTRL + TAB
Split Screen                                     ALT + W + S (F6 to jump from pane to pane)
Freeze pane                                     ALT + W + F + F
New workbook                               CTRL + N
Print                                                CTRL + P
Open workbook                              CTRL + O (CTRL + F12)
Save workbook                               CTRL + S
Activate menu bar                            ALT or F10
Min / Restore Ribbon                      CTRL + F1
Print preview                                  CTRL F2
Close window                                CTRL + F4
Close program                               ALT + F4

Cell navigation shortcuts
Go to end of contiguous range        CTRL + Arrow keys
Select a cell range                          SHIFT + Arrow keys
Highlight contiguous range              SHIFT + CTRL + Arrow keys
Move to beginning of line               Home
Move to cell                                  “A1”  CTRL + Home
Move to cell above                          SHIFT + ENTER
Move to cell to the right                   TAB
Move to cell to the left                     SHIFT + TAB
Delete cell and get inside                  BACKSPACE
Delete cell/selection                          DELETE
Show formulas/values                       CTRL + ~
Fill selection w/ entry                        CTRL + Enter

Capture Screen Shot of your Excel

Hi Webies after a long gap i'm here again with some new tips and tricks on excel....
In todays article im going to explain how to capture screen shot of your excel..

There is a quick and easy way of capturing an Excel screen shot without buying commercial software.
Step A: Launch PAINT by going: Start => All Programs => Accessories => Paint
Step B: Go back to Excel, and press ALT and PRTSC ... on my keyboard, the PRTSC button is to the right of F12. This takes a copy of your Excel window.
NOTE – if you press JUST the PRTSC button, it will take a copy of your entire screen.

Step C: Select Paint, and press CTRL + V

Step D: Now you can hone in on interesting part that you actually wanted to capture. Press the square in paint:
Step E: Drag it around the interesting part of your screen shot.

Step F: Press CTRL and C to copy this to the clipboard.
Step G: Press CTRL and N to create a new picture in paint, and press CTRL + V to paste back into paint
From here you can save this as a JPEG or a bitmap or whatever you want, and insert into a mail, or powerpoint.
NOTE: If you don’t actually want to save the screen shot, you can paste directly into outlook after Step G 

Happy excelling.....!

Moto E!!!!! Budget smartphone ---- Review

 Motorola in its comeback avatar appears to have geared up to overtake all competition in budget smartphone market in India which is otherwise dominated by homegrown manufacturers such as Micromax, Lava, and Xolo. Having already won much goodwill with its budget Moto G smartphone, the company on Tuesday introduced its much-awaited, low-cost Moto E smartphone, that packs in a lot of potential.
The Moto E has been launched in India at a price of Rs 6,999 and will be available in India only via online store Flipkart. Here are my first impressions on Motorola's entry-level Android smartphone from the brief period that I used it at the Delhi launch event.

The Moto E is in line with
 the design principles that the Moto G and Moto X are based on, making it look like the other two Motorola phones, but the absence of front camera and flash on the rear will make it easier for you to identify the phone. There are phones in this price range that come with front camera, but these cameras are so poor in quality that they remain more of a showpiece than of any value. The phone's 5 megapixel camera captures impressive pictures in terms of both colour and detail.
Buy Moto E: Mobile 

Motorola appears to have geared up to overtake all competition in budget smartphone market in India which is otherwise dominated by homegrown manufacturers.

I tested the camera in both soft-light and outdoor conditions, and the results were far better than what I had envisioned after first hearing the price. You may feel the absence of flash in low-light conditions. Given the experience it offers at this price, many would ignore the absence of flash, but I do wish Motorola had included the flash. Yet, I would not state the absence of front camera here as a major downside. The phone's camera settings offers limited options to customise images. It also lets you trim and edit videos shot on the phone in slow motion on the device itself.

The phone has a 4.3-inch display and therefore is compact. It feels comfortable in hands; its plastic back with matte finish has a slightly rubbery feel that makes it easier to grip the device. The 12.3mm thickness of the phone may make you presume it to be weird-looking device, but it is not the case. Its curved back makes it look less thicker than what it would have appeared otherwise. The phone looks sophisticated.
Its display has good viewing angles and produces vivid colours. The touchscreen is very responsive and it's smooth to navigate on the phone. The phone has a speaker at the front that produces loud music and fairly clear sound.
The phone is available in standard black and white colours, but its back panel is changeable. The swappable Motorola Shells for the Moto E come in a wide variety of colours, which will be listed on Flipkart, where the phone will go on sale starting Wednesday. The phone has three slots under the rear panel - two for SIMs and one for microSD card that supports up to 32GB of cards. The phone's internal memory - which stands at 4GB (out of which only 2.2GB is user accessible) - is unlikely to suffice users, so they have an option for additional storage. While its rear panel is removable, users can't take out the battery.
While some Android phones lack the built-in FM radio, the Moto E has it. The dual-SIM Moto E, as the company says, has an intelligent calling feature that learns your usage pattern to determine the best SIM for an outgoing call - which is actually based on your past behaviour.
On the software front also, the Moto E is a step ahead of other devices in this price range. The phone runs the latest version of Android - Android 4.4.2 KitKat. It comes with a guaranteed software update. The Moto E, Motorola says, will receive at least one software update to the current OS. Under the hood is a dual-core Qualcomm Snapdragon 200 processor along with 1GB of RAM.
The phone looks promising, but I would like to hold my verdict until I test it on other parametres including performance and battery.
Motorola Moto E: Detailed specifications
General Featires
In the BoxHandset with Built-in Battery, QSG and Warranty Card, Charger, Headset, Back Door
Model IDXT1022
SIM SizeMicro SIM
SIM TypeDual SIM, GSM + GSM, (Dual Standby)
Touch ScreenYes, Capacitive
Call FeaturesLoudspeaker
Handset ColorBlack
Operating FreqGSM - 850, 900, 1800, 1900; UMTS - 2100
OSAndroid v4.4 (KitKat)
Processor1.2 GHz Qualcomm Snapdragon 200, Dual Core
GraphicsAdreno 302, 400 MHz Single
Size4.3 Inches
ResolutionqHD, 960 x 540 Pixels
Other Display FeaturesCorning Gorilla Glass 3
Primary CameraYes, 5 Megapixel
Secondary CameraNo
Video RecordingYes, 30 fps
Size64.8x124.8x12.3 mm
Weight142 g
TypeLi-Ion, 1980 mAh
Memory and Storage
Internal4 GB
Expandable MemorymicroSD, upto 32 GB
Memory1 GB RAM
Internet & Connectivity
Internet FeaturesEmail
Preinstalled BrowserAndroid
3GYes, 21.1 Mbps HSDPA; 5.76 Mbps HSUPA; HSPA+
WifiYes, 802.11 b/g/n
USB ConnectivityYes, micro USB, v2
Navigation TechnologyGPS, GLONASS, BeiDou, with Google Maps
BluetoothYes, v4, Supported Profiles (LE)
Audio Jack3.5 mm
Music PlayerYes, Supports MP3
Video PlayerYes, Supports H.264, H.263, MP4, HD
Sound EnhancementFront Ported Loudspeaker Orientation, Audio Chip
Other Features
Call MemoryYes
SMS MemoryYes
Phone Book MemoryYes
SensorsAccelerometer, Proximity Sensor, Ambient Light Sensor
Additional FeaturesP2i, Single White LED
Warranty Summary1 year manufacturer warranty for Phone and 6 months warranty for in the box accessories

Check the moto e specs in flipkart here : Moto E - 6999 Rs

Source : CNN IBN, Flipkart.