LG To Debut Second Intel-Powered Smartphone At CES 2012

“If at first you don’t succeed, try try again.” It looks like LG and Intel have taken that old adage to heart, if a new report is to be believed. The Korea Times reports that LG will debut an Intel-powered smartphone at CES 2012, but the bigger question is whether or not the device will ever make it to market.

LG and Intel’s first mobile partnership yielded an Android smartphone running on Intel’s Moorestown chipset for CES 2011, but the device was ultimately scrapped. The reason for its premature demise? As the story goes, the device died because of it’s “lack of marketability.”

LG’s brass certainly thinks their Intel smartphone is viable — according to one of the Times’ executive sources, the device could be released as soon this March. Still, the original LG-Intel phone was pegged with a 2011 release date, so take those claims with a grain of salt for bow.

Hopefully LG’s second swing at an Intel-powered phone fares a little better — it’s said to run on Intel’s next-generation Medfield system-on-a-chip, and early tests have yielded some pretty impressive benchmarks when compared to NVIDIA’s Tegra 2 and Qualcomm’s Snapdragon MSM8260 SoCs.

Of course, the real competition is yet to come, as nearly every player in the mobile chipset market is hard at work on their next-generation platforms. Intel has a lot of brand recognition when it comes to PCs, but their lack of presence in the mobile market to date could mean that Medfield could drown in a sea of established ARM-based chipsets.

That’s why the partnership with LG is so critical — despite their handset division spending a few quarters in the red, LG is still the number two handset OEM in the U.S. Having a major hardware vendor taking a chance on their new platform could establish Intel as a real player in the mobile space, and right now Intel’s mobile efforts could use all the visibility they can get.

Windows Phone 7 will get three LTE phones in 2012

Yesterday we saw an alleged leak of Microsoft’s 2012 Windows Phone roadmap. It offers an eyebrow-raising view of a company that is trying to invade the smartphone market from the bottom up (starting with low-end phones). Today we have a new report that further materializes Microsoft’s near-term plans for Windows Phone 7.

The big news, which will apparently be officially announced at CES, is that there will be several LTE Windows Phone devices in 2012 — and they will all be on AT&T. The three phones — the Nokia ACE, HTC Radiant, and Samsung Mendel — will ship by the middle of the year. The ACE, specifically, is set to launch on March 18.

The LTE phones will probably all run Windows Phone 7.5 Mango, as the previous roadmap leak points to the Tango update, which is aimed towards low-end phones, coming earlier in the year. The Apollo update, which will support high-end handsets, won’t show until the fourth quarter of 2012.

A final detail of the new leak has Nokia’s Lumia 710 launching on T-Mobile on January 11, and on Verizon in April. The Lumia 710 will launch in the US before the Lumia 800, making Americans’ first impressions of the Nokia/Microsoft alliance that of a mid-range phone that doesn’t dazzle like the Lumia 800.

While the Microsoft/Nokia bottom-up strategy seems illogical, it could have something to do with the release of Windows 8. Though Windows 8 and Windows Phone 7 are two different operating systems, the Metro UI will bring them together on a cosmetic level. In the eyes of most customers, that may be enough to create a positive association and let Windows Phone ride Windows 8′s (expected) buzz. The strategy could fizzle, but it also may be a smart gamble.

* Note that the above image is a visualization: no Windows Phone marketing materials were part of the leak.

Android Ice Cream Sandwich on HTC G1! ROM jcarrz1 XDA

Getting started with Blackberry development in Eclipse - Links

Links:

http://www.blackberryforums.com/developer-forum/138210-setup-up-eclipse-blackberry-development.html

http://thinkingblackberry.com/?p=21

http://epicapplications.com/blog/2009/10/getting-started-with-blackberry-development-part-1/

Getting started with Blackberry Development in Eclipse

Setting up your development tools for BlackBerry Java applications

If you’re developing Java® applications for the BlackBerry® device, there are a number of tools you can use to develop your application. In this article, we will focus on setting up the BlackBerry® Java® Plug-in for Eclipse®.

The BlackBerry Java Plug-in for Eclipse extends the Eclipse® development framework to allow you to develop a BlackBerry Java application for the BlackBerry device. In Eclipse and Eclipse-based IDEs, the plug-in provides the tools to develop, debug, optimize, and localize your application.

System requirements

Before downloading the BlackBerry Java Plug-in for Eclipse, make sure your computer meets the following system requirements:

Intel® Pentium® 4 or AMD Athlon™ Desktop Processor 2.5GHz or faster
1.5 GB or more available hard disk space
2 GB RAM or more
Monitor with 1024 x 768 resolution or higher
Windows Vista®, Windows® XP, or Windows® 7 (Note: 64-bit versions require 32-bit Java® and 32-bit Eclipse).
Java® Platform, Standard Edition (Java SE) Development Kit (JDK) 6, update 14 or later

Task 1: Downloading and installing the Java SE JDK

Note: If you already have Java SE JDK 6 update 14 or later installed on your computer, you can proceed to the next task.

Go to www.oracle.com/technetwork/java/javase/downloads/index.html .
Click Download JDK.
From the Platform drop-down list, select the platform you are developing on.
After reviewing the license agreement, select the license checkbox. Click Continue.
Click the filename and save the file to a location on your computer.
Double-click the exe file and proceed with the installation.
Update the PATH environment variable to point to the newly installed JDK by completing the following steps:
From the Control Panel, select System.
On the Advanced tab, click Environment Variables.
Under System variables, select the Path variable and click Edit.
At the beginning of the Variable value field, type the path of the JDK followed by a semicolon ; For example, C:\Program Files\Java\jdk1.6.0_21\bin;
Click OK to save and close the Environment Variables window.
In the Environment Variables, update the JAVA_HOME variable to point to the newly installed JDK. Use the instructions in the prior step to update the JAVA_HOME variable.

Task 2: Downloading and installing the BlackBerry Java Plug-in and the Eclipse IDE

Note: If you have a registered account on the BlackBerry® Developer Zone, please log in. By using your registered account, you avoid having to complete download agreements for each time you download a file. You can log in or register for an account at www.blackberry.com/developers.

Go to www.blackberry.com/developers/java.
Click the Development tools and downloads link.
Click the Download the BlackBerry Java Plug-in for Eclipse v1.3 (full installer) link. This installer includes both the BlackBerry Java Plug-in-in for Eclipse and Eclipse 3.6.
Click Download.
Click Save, and then save the file to a location on your computer.
Double-click the setup application file.
Click Run.
On the Introduction screen, click Next.
Review the license agreement, and then select I accept the terms of the License Agreement.
Click Next.
Choose a location where you would like to install Eclipse. You can use the default location that’s specified on the screen or you specify a different folder location. Note: The folder must be empty.
Click Next.
On the Select Additional Tasks screen, select where you want the setup application to create shortcuts for the BlackBerry Java Plug-in.
Click Next.
Review the information on the Pre-installation Summary screen, and then click Install.
Click Done.

You have successfully completed the installation of the BlackBerry Java Plug-in for Eclipse and the Eclipse installation.

When you first launch the BlackBerry Java Plug-in for Eclipse, Eclipse will prompt you to specify a workspace. This workspace contains all the application projects you plan to work on.

7 Practices to Agile QA

If you are transitioning to Agile/Scrum and wondering how your existing QA practices need to evolve in the new world, here are 7 practices that you should consider implementing.

1. "In-cycle" QA. Traditionally QA team is a separate team and .QA testers should be integral part of the development team. They should be working very closely with the developers on stories in the same sprint/iteration. If QA testing is done in the next sprint for stories implemented in the previous (out-of-cycle), the team will always find itself doing a catch-up and end up accumulating "technical debt." As a rule of thumb, you would need 1 tester for every 3 developers. However, everybody on the team should be willing to jump in and help with QA testing. When planning, make sure to adequately account for QA activities. It is OK to take on fewer stories in the beginning to find the team rhythm before trying to increase the velocity.

2. Implement 5 Quality Gates. Traditionally QA is seen as just performing functional/system tests. But, software development is a highly integrated process. The quality of each activity- requirements, design, and coding, could impact the amount of effort needed in testing. If quality issues that could have been detected and prevented during these other activities are left for testing to catch them, there may not be enough time to fix the issues. Even worse, it may not be found until after deployment. QAneeds to expand beyond just testing and should include the following QA gates.

Fig. 1: Quality Funnel

• Quality Gate#1- peer review of requirements. Make sure stories meet INVEST (independent, negotiable, valuable, estimable, small, and testable) criteria as much as possible. This could be an on-going activity as part of pre-planning/product backlog grooming and not tied to a specific sprint.
• Quality Gate#2- peer review of design. Make sure the design is in-line with the architecture guideline/style and appropriate alternatives are considered.
• Quality Gate#3- peer review of codes. Make sure appropriate unit tests are written, coding standards are followed, and above all ensure codes follows design.
• Quality Gate#4- continuous integration. Make sure code is being integrated and automated tests are run on a continuous basis and any issues that surfaces are addressed immediately.
• Quality Gate#5- automated functional tests. Make sure QA testers are testing using automated scripts as much as possible.

3. Target 90% test coverage with automated testing. Even though test coverage does not tell anything about the quality of tests, it tells you where you need to focus more than others. Without test automation, it would be difficult to accommodate adequate testing in a sprint.

4. Inspect and adapt. Do not just stop at identifying the technical cause of a bug. Understand where (the quality gate) this bug could have been caught and improve the associated process.

5. Definition of "Done." Include all quality gates as part of your definition of "done."

6. Fix all know bugs first. Traditionally bugs are triaged based on severity as well as other works in the pipeline. The danger of doing this is that a seemingly minor/cosmetic bug could result into a large cumulative technical debt over time. Fixing bugs as soon as they are found can be less costly and time consuming than to wait for the right time to fix them.

7. Prioritize test cases. The intention behind this practice may not be apparent at first. The idea is that tests cost time and money. You can spend inordinate time in tests without getting any incremental/marginal value. Knowing how much testing is enough as well as what tests are more important than others not only will save time but also will ensure quality of testing. In order to understand what to test first, you could map your stories along two dimensions- frequency of use and risks of having bugs. The stories that gets used more often and also would have high risks should bugs are encountered needs to tested first and more.



I would be interested to know how you are doing QA on your Agile projects.

Realism in UI Design

The history of the visual design of user interfaces can be described as a gradual change towards more realism. As computers have become faster, designers have added increasingly realistic details such as color, 3D effects, shadows, translucency, and even simple physics. Some of these changes have helped usability. Shadows behind windows help us see which window is active. The physicality of the iPhone’s user interface makes the device more natural to use.
In other areas, the improvements are questionable at best. Graphical user interfaces are typically full of symbols. Most graphical elements you see on your screen are meant to stand for ideas or concepts. The little house on your desktop isn’t a little house, it’s «home». The eye isn’t an actual eye, it means «look at the selected element». The cog isn’t a cog, it means «click me to see available commands». You are typically not trying to replicate physical objects, you are trying to communicate concepts.
Details and realism can distract from these concepts. To explain this, I’ll take a page from Scott McCloud’s «Understanding Comics», a book which should be required reading for all designers.

The image on the left is a face of a specific person. The image on the right is the concept «face»; it could be any person. When designing user interfaces, we rarely ever want to show a specific entity; typically, we want to convey an idea or a concept. Details can easily distract from that idea or concept.

At the same time, it’s obvious that some details are required. Too few details, and the user won’t recognize the idea at all.

The circle on the left clearly shows a face. The circle on the right isn’t recognizable as a face anymore.
Let’s look at a symbol we actually see in user interfaces, the home button. Typically, this button uses a little house as its symbol.

The thing on the left is a house. The thing on the right means «home». Somewhere between the two, the meaning switches from «a specific house» to «home as a concept». The more realistic something is, the harder it is to figure out the meaning. Again, if the image is simplified too much, it’s not clearly and immediately recognizable anymore.

The thing on the left is a home button. The thing on the right might as well be an arrow pointing up; or perhaps it’s the ⇧ key.
Let me explain this concept using an entirely unscientific graph:

People are confused by symbols if they have too many or too few details. They will recognize UI elements which are somewhere in the middle.
The trick is to figure out which details help users identify the UI element, and which details distract from its intended meaning. Some details help users figure out what they’re looking at and how they can interact with it; other details distract from the idea you’re trying to convey. They turn your interface element from a concept into a specific thing. Thus, if an interface element is too distinct from its real-life counterpart, it becomes too hard to recognize. On the other hand, if it is too realistic, people are unable to figure out that you’re trying to communicate an idea, and what idea that might be.

The button on the left is too realistic. The button on the right does not have enough details to be immediately recognizable as a button.

The same applies to these toggles. Shadows and gradients help the user figure out what he’s looking at and how to interact with it. Adding too many details, however, ends up being confusing. The toggle switch is no longer just a toggle switch that is part of a user interface, it is clearly recognizable as a photograph of a specific toggle switch; it loses its meaning. It’s no longer a symbol, it has become a specific thing.

An Exception

There is at least one specific area where more details are good: Application icons. You want your icon to depict one specific idea: Your application.

Coda’s leaf isn’t a representation of the idea of a leaf; it’s a very specific leaf, the Coda leaf. Acorn’s acorn isn’t just any acorn, it’s the Acorn. Adding details moves these images from a generic concept towards a specific entity, and in the case of an application icon, this is exactly what you want.

Conclusion

Graphical user interfaces are full of symbols. Symbols need to be reduced to their essence. This helps avoid cluttering the user interface with meaningless distractions, and makes it easier for people to «read» the symbol and figure out the meaning of an interface element. Realistic details can get in the way of what you’re trying to communicate to your users.
Unless you are creating a virtual version of an actual physical object, the goal is not to make your user interface as realistic as possible. The goal is to add those details which help users identify what an element is, and how to interact with it, and to add no more than those details. UI elements are abstractions which convey concepts and ideas; they should retain only those details that are relevant to their purpose. UI elements are almost never representations of real things. Adding too much realism can cause confusion.

How to be an effective software tester

Every one wants to be the best and do the best to come up in life/career etc. To achieve this many follow different methodologies and strategies and they come up in life paving a way for those who want to come up.

Software Testing is a vast field and whoever opts for this field also practice certain principles to become a good tester. This question often ponders in everyone’s mind even after spending few years into software testing and leading teams on different projects as to how can I become a good tester. Most often people acquire knowledge by going through various articles on internet, experiences, stories of those successful and many more. With this everyone reaches to a common conclusion that for any one to be successful there are some methods or strategy to follow.

Any one coming fresh into testing have many questions about software testing, what it is all about and the actual work that they are going to perform. As fresher in this field, you should be aware of certain facts in the software testing profession as an individual.

The common information or tips as generally called, below will certainly help to advance you in your software-testing career. These are not only for fresher’s but also for experienced testing professionals too. Applying these in your career you will mover forward in your career and will not regret for what you are doing.

Software Testing is a very demanding job because one needs to be vary cautious, logical and come up with different ideas and logic than that of those which are common. Testers should think differently and do things in a different way to see that bugs don’t go unnoticed and always try to break the system.

The following information will definitely help you to achieve good results in your career.

Knowledge of the Application under Test.

Many at times in most of the companies they get the application deployed on the test server and are asked to test the application and most of the tester do an exploratory testing to know the application. This is also based on the deadline and the process being followed in the company.

The best practice is not to start testing without understanding the requirements very clearly.
If an application is tested without adequate knowledge of the requirements it is very difficult to determine whether a program is functioning as desired and as per the design and will not be in a position to tell if required functionality is passed or missing.

Clear knowledge of requirements, before starting testing, is a must for any tester and the lead’s responsibility is to make sure that the tester has got enough knowledge of the system under test.

It is always said prevention is better than cure and it is also true in software development that it is better to know any missing issues and fix them than to find those issues during testing and fix them.

Acquire Domain Knowledge

It is always good if we acquire thorough knowledge of the domain on which you are working.

Being well versed in the domain will help you to give good suggestions and also solutions for any issues being faced because of the bugs.

It is always appreciated by the test manager/project manager for your suggestions which has an impact on the application and also if certain features can be fine tuned

Most of the time we as testers feel that our responsibility is to only logging the bugs but it is appreciated if solutions are provided and this will earn respect amongst the colleagues. Good domain knowledge will also help you to design better test cases with maximum test coverage.

Do not come up with Assumptions while Testing

It should always be kept in mind that every application under test has bugs and it is our responsibility to find bugs potential of breaking the system. Testing should not be started assuming that there will be no errors.
From a QA point of view you should always look for new bugs, different bugs, hidden bugs etc. no bug should be left unnoticed whether it will be fixed or not.

Keep updated about new technologies

with the advancement in technology there are constant changes in the technology we use and there requires new techniques even though old testing techniques still play a vital role in day-to-day testing, but it is always good to try to introduce new testing procedures that work for you.

Most of the time we rely on book knowledge and try to follow the procedures mentioned in them and most of the time we do not achieve results. One should be practical and come up with new ideas and techniques which will work for a particular system. They may work amazingly for you.

No one can certify after testing that it is a bug free application

No wonder how many rounds of testing you perform; you can’t guarantee a 100% bug free application. There are some constraints that may force your team to advance a product to the next level, knowing some common or low priority issues remain. Try to explore as many bugs as you can, but prioritize your efforts on basic and crucial functions. Put your best efforts doing good work.

Behave like an End User

This is the most important piece of advice we as testers should think and behave like the end user i.e the one who is going to really use this application. I don not say that you should not think technically but think like customers or end users and beyond. Test your application as an end user in different permutations and combination's. Do all sorts of transactions, navigation's, insert values, delete values etc and see that any way you do a function it should give the result same for different types of test carried out for the same functionality. Think how an end user will be using your application. Technical plus end user thinking will assure that your application is user friendly and will pass acceptance tests easily.

It is Not Possible to have 100% Test Coverage

Most of the time we think of having 100% test coverage with all the test data we have but most of the times we may not near it and don’t obsess about 100% test coverage. There are millions of inputs and test combination's that are simply impossible to cover instead use different testing techniques like boundary value analysis and equivalence partitioning testing to limit your test cases to manageable sizes and achieve the result.

Build Good Relations with Developers

It should always be remembered that as a tester we are there to bring quality into the application and should not become a hurdle in the SDLC or for the project instead we should behave as building blocks and should fillthe gap. As a tester we communicate with many other team members and specially the developers. There comes many times where we don’t agree upon each other on different issues and most of the time there exist a friction between the test team and the development team. It is by experience and skill to handle such situations without harming a good relationship with the developer. If you are wrong, admit it. If you are right, be diplomatic. Nothing should be taken personally. After all, it is a profession, and you both want a good product.

Learn From Mistakes

Every one of us knows the mistakes we commit while testing and if one says that there are no mistakes then there exists a doubt whether they are testing hard enough! You will learn things as you get experience. Use these mistakes as your learning experience. Try not to repeat the same mistakes.
It hurts when the client find any bug in an application tested by you and the creditability of the tester is at stake. It is definitely an embracing situation for you and cannot be avoided. However, don’t beat yourself up. Find the root cause of the failure. Try to find out why you didn’t find that bug, and avoid the same mistake in the future. If required, change some testing procedures you are following.

It is not your fault if some bugs are not fixed.

Some testers have assumptions that all bugs logged by them should get fixed. It is a wrong assumption based on the severity and priority of the bug and needs of the project the bugs gets fixed or will be carried over to the next phase saying that these are known issues. It is a good point to a certain level but you must be flexible according to the situation. All bugs may or may not be fixed. Management can defer bugs to fix later as some bugs have low priority, low severity or no time to fix.

Top 20 tips to test your application

Here are some of the best testing practices I learned by experience:

1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugsbut also provide solutions.

2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.

3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.

5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.

6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

7) Make your test cases available to developers prior to coding.Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

8 ) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

10) Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

11) Go beyond requirement testing. Test application for what it is not supposed to do.

12) While doing regression testing use previous bug graph (Bug graph – number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

17) Testing teams should share best testing practices, experience with other teams in their organization.

18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute – make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.

19) Don’t run out of time to do high priority testing tasks.Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.

Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.

7 basic tips for testing Multi - Ligual web sites

Testing web sites supporting multiple languages has its own fair share of challenges. In this article,I will share seven tips with you that will enable you to test the multi-lingual browser-based applications in a complete way:

Tip # 1 – Prepare and use the required test environment

If a web site is hosted in English and Japanese languages, it is not enough to simply change the default browser language and perform identical tests in both the languages. Depending on its implementation, a web site may figure out the correct language for its interface from the browser language setting, the regional and language settings of the machine, a configuration in the web application or other factors. Therefore, in order to perform a realistic test, it is imperative that the web site be tested from two machines – one with the English operating system and one with the Japanese operating system. You might want to keep the default settings on each machine since many users do not change the default settings on their machines.

Tip # 2 – Acquire correct translations

A native speaker of the language, belonging to the same region as the users, is usually the best resource to provide translations that are accurate in both meaning as well as context. If such a person is not available to provide you the translations of the text, you might have to depend on automated web translations available on web sites like wordreference.com and dictionary.com. It is a good idea to compare automated translations from multiple sources before using them in the test.

Tip # 3 – Get really comfortable with the application

Since you might not know the languages supported by the web site, it is always a good idea for you to be very conversant with the functionality of the web site. Execute the test cases in the English version of the site a number of times. This will help you find your way easily within the other language version. Otherwise, you might have to keep the English version of the site open in another browser in order to figure out how to proceed in the other language version (and this could slow you down).

Tip # 4 – Start with testing the labels

You could start testing the other language version of the web site by first looking at all the labels. Labels are the more static items in the web site. English labels are usually short and translated labels tend to expand. It is important to spot any issues related to label truncation, overlay on/ under other controls, incorrect word wrapping etc. It is even more important to compare the labels with their translations in the other language.

Tip # 5 – Move on to the other controls

Next, you could move on to checking the other controls for correct translations and any user interface issues. It is important that the web site provides correct error messages in the other language. The test should include generating all the error messages. Usually for any text that is not translated, three possibilities exist. The text will be missing or its English equivalent will be present or you will see junk characters in its place.

Tip # 6 – Do test the data

Usually, multi-lingual web sites store the data in the UTF-8 Unicode encoding format. To check the character encoding for your website in mozilla: go to View -> Character Encoding and in IE go to View -> Encoding. Data in different languages can be easily represented in this format. Make sure to check the input data. It should be possible to enter data in the other language in the web site. The data displayed by the web site should be correct. The output data should be compared with its translation.

Tip # 7 – Be aware of cultural issues

A challenge in testing multi-lingual web sites is that each language might be meant for users from a particular culture. Many things such as preferred (and not preferred) colors, text direction (this can be left to right, right to left or top to bottom), format of salutations and addresses, measures, currency etc. are different in different cultures. Not only should the other language version of the web site provide correct translations, other elements of the user interface e.g. text direction, currency symbol, date format etc. should also be correct.

As you might have gathered from the tips given above, using the correct test environment and acquiring correct translations is critical in performing a successful test of other language versions of a web site.

Best Practices in performance Testing

Check out the video Link of Performance testing:

http://www.soasta.com/download/BestPracticesMobileDA.mp4

http://www.soasta.com/download/BestPracticesMobileDA.mp4

Taking screenshots on an Android-based phone

Even before playing with the new Android phone, the T-Mobile G1, I knew that I would need to be able to take screenshots of the phone itself. Using a digital camera to capture screens externally just wasn't going to cut it. Because the Android platform is open (and now, open source), I really didn't expect this to be a problem. If anything, I thought there would be a way to take screenshots directly from the device like you can with the iPhone and iPod Touch.

Alas, I discovered this is not the case. After scouring Google trying to find answers, I asked Engadget's Editor-in-Chief Josh Topolsky what they used for the screenshots in their review, and he was nice enough to fill me in on the details.

Warning: right now, taking screenshots from an Android device requires installing the SDK. That doesn't make it as simple as pressing a button, but it's not the end of the world. If you've got a few minutes, and a quick connection with which to download the SDK, we'll show you how to take delicious Android screenshots of your own.

Step 1: Enable USB Debugging

On your Android phone (in this case, the G1), go to Settings, then Applications, and then Development. Check the checkbox for "USB debugging."

Step 2: Download the Android SDK

Download the SDK for your platform here. Google also has some great installation documentation if you get lost. You will need to make sure you have a current copy of the JDK. To use the SDK, you also need to download an IDE like Eclipse. After installing Eclipse, you can install the Eclipse plugin to connect Android and the IDE together, or just do a lot of stuff via the command line.

Go ahead and plugin your Android handset into a USB port on your computer, if it is not plugged in already.

Step 3: Run DDMS

After configuring Eclipse or whatever IDE you use to work with Android, you need to open up the DDMS application from within the "tools" folder in the Android SDK's main folder.

After DDMS launches, select your handset from the menu on the left (it should be the only device listed). You might see an error message, but the debug tool should be loaded. Then, click CTRL-S on your keyboard. This will bring up the "Device Screen Capture" interface. From here, a static image is captured from what is appearing on your handset. You can save the image (nicely defaulted as PNG) and then refresh to your heart's content to grab updated or different screenshots from your phone.

That's it!

There is a caveat: Because your device has to be plugged into USB to be accessed by the SDK, the SD card cannot be used for taking photographs, playing music or downloading music from the Amazon.com MP3 store. You can take pictures of some of those screens, but to actually download anything, take movies, or take a photo, you cannot have your device plugged into the computer and accessed by the SDK.

How to capture screen shots in Blackberry

How to Capture Screenshots of your Blackberry Screen

2X ApplicationServer XG www.2x.com/applicationserver/
Free & secure application & desktop delivery to any operating system.

I recommended some commercial screen capture utilities in my previousguide for BlackBerry but you can safely ignore that advice as here are alternate solutions that aren't just free, some of them will even help you grab images of your BlackBerry screen without having to connect the phone to the computer.

1. Capture BlackBerry Screenshots from Command Prompt

Get the free Java Loader Commander utility fromBBforums (mirror) and unzip the file to some folder on your hard drive. Now connect the BlackBerry device to your computer via the USB cable and navigate to the screen that you want to save as an image.

Open the command prompt and switch to the folder that contains the extracted files. Type JL_Cmder.cmd and press enter. Just follow the simple wizard to save screenshots of your BlackBerry screen.

2. Take Screenshots with BB Screenshooter

The official RIM command line utility discussed above can be a bit intimidating for non-techies so here's a standard GUI based application for capturing screenshots of BlackBerry.

The utility is called BBScreenshooter and it lets you take captures in multiple image formats from your Windows desktop. You can even preview screenshots before shooting.

To use BB Screeenshoter, first download the JavaLoadertool and unzip it to a folder. Then download theBBscreenshoter.exe file in the same folder and run. Specify the location of Java Loader utility and the application is now ready to take pictures of your BlackBerry screen.

3. Wireless Screen Captures for BlackBerry

The downside with either of the above solutions is that they both are desktop based so you first need to connect the BlackBerry phone to the computer before taking screen captures.

Now in situations where you want to grab the BlackBerry screen while you're miles away from the computer, CaptureIt will come very handy. Openm.thetechmogul.com in your BlackBerry browser and install the CaptureIt application (mirror).

This will add a "Capture It" option to your BlackBerry menu - you can select that option, wait until the vibration is over and an image of your current BlackBerry screen will get saved either in the external memory card or to the device memory.

Alternatively, you can go to Home - Options - Screen Keyboard and assign a convenience key to the Capture It application. Then you'll be able to capture screenshots with a simple click without having to use the menu option.

Negative Testing

Negative Testing

1) Testing the application for fail conditions, negative testing is testing the tool with improper inputs.for example entering the special characters for phone number.

2) Testing aimed at showing software does not work. Also known as "test to fail".

3) Negative testing is testing that is directed to showing that something will -not- work. It's such a natural part of regular testing that I doubt that most people know that there is both a "positive" and "negative" testing.

4) Negative Testing is simply testing the application beyond and below of its limits. For example:
A) We want to enter a name for that negative test can be first we enter numbers.
B) We enter some ASCII characters and we will check
C) First numbers and characters we will check
D) Name should have some minimum length below that we will check

5) Negative testing is testing the tool with improper inputs. For example entering the special characters for phone number.

6) Negative testing is kind of testing doing with the Boundary values, may be max val and min val or with some other kind of data type input etc.

7) Testing the application for fail conditions.

8) here we test if system is doing something which it is not supposed to do ex in password field we try to enter only alphabets were as in requirement it is specified password should have at least 1 no, if it accepts only alphabets then test case is fail otherwise it's pass.

9) Negative testing is testing an application giving invalid data, for example entering wrong user id or wrong password to make the test unacceptable.

10) Negative testing is testing the application with negative assumptions and navigations to get a negative result which leads to positive one.

11) This is a type of testing which is done by tester's to make sure that the system works fine for the Inputs which the code dosen't designed for.

12) Negative testing is a testing which ensures that the application should not do what it is not supposed to do.

13) Negative testing is performed to check how the application works if an unexpected input is given which is out of requirements, to check the stability of the application. "For a error to be thrown it doesn’t throw error and error shouldn’t thrown it throws an error".

14) Testing the application for fail conditions, negative testing is testing the tool with improper inputs.for example entering the special characters for phone number.

15) Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.

16) In negative testing, we check whether the application or system handles the exception properly or not. It is nothing but "Test to Break" testing.

Agile Testing

 

Agile means being able to quickly change direction. Agile software development is a group of software development methodologies.


Agile software development methods:
1. Agile Modeling
2. Agile Unified Process (AUP)
3. Dynamic Systems Development Method (DSDM)
4. Essential Unified Process (EssUP)
5. Extreme Programming (XP)
6. Feature Driven Development (FDD)
7. Open Unified Process (OpenUP)
8. Scrum
9. Velocity tracking


Agile method: Scrum (development)
Scrum is an iterative incremental process of software development commonly used with agile software development.


Software developed during one unit of time is referred to as an iteration, which typically lasts from two to four weeks. Each iteration passes through a full software development cycle, including planning, requirements analysis, design, writing unit tests, then coding until the unit tests pass and a working product is finally demonstrated to stakeholders. 


The Product Backlog is the master list of all functionality desired in the product. A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.


Sprint Backlog: The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner.


Daily SCRUM meeting rules: 
1. Hold the daily scrum in the same place at the same time every work day. 
2. All team members are required to attend. 
3. The scrum master begins the meeting by starting with the person to his or her left and proceeding counter clockwise around the room until everyone has reported. 
4. Each team member should respond to three questions only: 
a) What have you done since the last daily scrum regarding this project? 
b) What will you do between now and the next daily scrum meeting regarding this project?

QC Process followed in small companies

1) If there is small project then we opt for Ad-hoc testing. Ad-hoc testing is done without test cases. But for this, software tester should have enough knowledge about the project. And it is done by experienced QA engineer.

2) If software tester don't know anything about the project then we perform exploratory testing on that project. We explore all the features and then create and execute test cases.

3) In general, following Testing process is followed by small companies:

a) Requirement Stage: Analyze requirement document, discuss with team internally, ask doubts from client if required.

b) Test Plan: Create test plan which defines the type of testing should be done, who will test this, duration for which we have to test, availability of test resources, types of Testing performed, features to be tested, features not to be tested etc.

4) Test Cases: Test cases (sequence of steps to test the correct behavior of a functionality) are prepared by reviewing the functional requirements in use cases or by
exploring the application.

5) Execution of Test Cases: Each test case is executed by more than one QC engineer and on different configuration PCs to ensure that its working 100% fine.

6) Instant Bug reporting: If we find number of bugs then initially we report the bugs in excel sheet and send it to developers so that they can make a proper plan and start work on it.

7) Bug reporting in bug tracking tool: Then we post each bug with more details in to bug tracking tool.

8) Explain the required bug to developer with exact scenario

9) Re test the issue fixed by developer

10) Mark the status in bug tracking tool.