That's how a Paradigm is created :)

Mobile Websites -- WHY?

Mobile devices are gaining momentum. Companies of all types and sizes are developing and implementing mobile applications to increase productivity, help their distributed teams stay connected and allow customers to access essential services even when they are away from their computers.

If your goals are primarily related to marketing or public communications, a mobile website is almost always going to make sense as a practical first step in your mobile outreach strategy. This is because a mobile website has a number of inherent advantages over apps, including broader accessibility, compatibility and cost-effectiveness.

Immediacy – Mobile Websites Are Instantly Available

A mobile website is instantly accessible to users via a browser across a range of devices (iPhone, Android, BlackBerry etc). Apps on the other hand require the user to first download and install the app from an app marketplace before the content or application can be viewed - a significant barrier between initial engagement and action/conversion.

Compatibility – Mobile Websites are Compatible across Devices

A single mobile website can reach users across many different types of mobile devices, whereas native apps require a separate version to be developed for each type of device. Furthermore, mobile website URLs are easily integrated within other mobile technologies such as SMS, QR Codes and near field communication (NFC).

Upgradability – Mobile Websites Can Be Updated Instantly

A mobile website is much more dynamic than an app in terms of pure flexibility to update content. If you want to change the design or content of a mobile website you simply publish the edit once and the changes are immediately visible; updating an app on the other hand requires the updates to be pushed to users, which then must be downloaded in order to update the app on each type of device.

Findability – Mobile Websites Can be Found Easily

Mobile websites are much easier for users to find because their pages can be displayed in search results and listed in industry-specific directories, making it easy for qualified visitors to find you. Most importantly, visitors to your regular website can be automatically sent to your mobile site when they are on a handheld (using device-detection).  In contrast, the visibilities of apps are largely restricted to manufacturer app stores.

Shareability – Mobile Websites Can be Shared Easily by Publishers, and between Users

Mobile website URLs are easily shared between users via a simple link (e.g. within an email or text message, Facebook or Twitter post). Publishers can easily direct users to a mobile website from a blog or website, or even in print. An app simply cannot be shared in this fashion.

Reach – Mobile Websites Have Broader Reach

Because a mobile website is accessible across platforms and can be easily shared among users, as well as search engines, it has far greater reach capability than a native app.

LifeCycle – Mobile Websites Can’t be Deleted

The average shelf-life of an app is pretty short, less than 30 days according to some research, so unless your app is something truly unique and/or useful (ideally, both), it’s questionable how long it will last on a user’s device. Mobile websites on the other hand are always available for users to return to them.

A Mobile Website can be an App!

Just like a standard website, mobile websites can be developed as database-driven web applications that act very much like native apps. A mobile web application can be a practical alternative to native app development.

Time and Cost - Mobile Websites are Easier and Less Expensive

Last but certainly not least, mobile website development is considerably more time and cost-effective than development of a native app, especially if you need to have a presence on different platforms (requiring development of multiple apps).

Support and Sustainability

The investment considerations of app vs. website don’t end with the initial launch; properly supporting and developing an app (upgrades, testing, compatibility issues and ongoing development) is more much more expensive and involved than supporting a website over time

misConception about TESTING

Have you heard people saying “Testing doesn’t provide much value to the organization”, “anybody can do Testing”, “Testing is a boring, repetitive job with no creativeness involved”, “hire some out of school kids to test applications” or “Testers are in reality ‘developer wannabees’, can really have an impact on your team’s morale.

There are so many misconceptions that are out there but actuality is-

Testing is a skilled activity that requires the ability to think, explore and follow logic while questioning and reasoning at the same time. Sorry, you just can’t take anybody off the street to do Testing. It takes a skilled, intelligent professional who understands the needs of the organization and is ready for the task!

Your applications are a critical company asset. Depending on the nature of your business, direct profit and revenue can be impacted if an application goes down or performs poorly. And of course, a company’s reputation can also be seriously damaged when things don’t “work” right. Think about it. Will you hire an inexperienced, out of college kid to take care of your critical investments and financial assets? If you answer yes, then I would say sure, go ahead and hire an out of school kid to test your applications.

While it is true that some Testing engineers like to get into the code, and enjoy using automated scripts, there are other folks that prefer a “thinking & building test cases while executing manual tests” type of approach.

Testers represents the heterogeneous users of the products that your company produces, so they are there to improve product quality, ensure a better user experience and reduce support costs. To top it all, QA teams assess product conformance to specifications and standards, while checking interoperability with infrastructure, complementary products and/or third party vendor products.

Well, this one could be partially true, depending on the internal processes that you have in place. For example, if Tester is not involved with a project from the beginning, there is not much room to bring new ideas or feedback to product’s requirements. And this could translate into lack of empowerment, and not feeling appreciated.

Here are few points which can be used to improve/motivate your testing team without increasing the budget-

• Take a look at internal atmosphere of organization and try to understand the internal atmosphere. And identify the areas which require improvement in terms of Process, Attitude or anything.

• Brag about your team to stakeholders and peers – Show off your team in front of the Customer/Client/Stakeholders and don’t let any chance to go for this.

• Improve relations with the development team - try building a personal relationship between Dev and testing, and try to understand the point of view from both when discussing issues. Frequent Team Building could be a good option to success it.

• Enhance your testing JD – A job description leaves an impression about the organization before any one actually joins. So that JD should be attractive and should leave a positive message about the Company

• Involve testing in your development cycles from the beginning – Identify and Try to get involve testers at the very beginning of projects and let the give opportunity with responsibilities to understand and make a hold on the whole project.

• Gaze the ways to automate – to be part of Automation Team is always a dream for a tester who is working in a Dev-Testing Project. Run a drive to identify the people who are skilled and can be fit for automation and let them research and discover the new tools and systems for their current projects/clients, and if there is success you can get a lot advantage by selling them to the customer.

• Consider rotating projects and responsibilities across team – anyone will be bored by doing the same/monotonous job after a significant time, to avoid this make it in practice to change the teams/responsibilities or project if feasible. Let them explore the different projects domains.

• Engage your team in customer interactions - If there is an interest within the team look for opportunities to engage your team in customer interactions (customer visits, demos, conference calls, booth duties at conferences, etc). It will translate into increased job satisfaction among your team, and more job security 

Static Testing vs Dynamic Testing

Static testing is performed using the software documentation. The code is not executing during static testing. 

The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. 

Review's, Inspection's and walkthrough's are static testing methodologies

Dynamic testing requires the code to be in an executable state to perform the tests

Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. 

Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies

Following points would help to understand-

• Static testing is about prevention, dynamic testing is about cure
• Static testing is many times more cost-effective than dynamic testing
• Static testing beats dynamic testing by a wide margin
• Static testing gives you comprehensive diagnostics for your code
• Dynamic testing finds fewer bugs than static testing
• Static testing achieves 100% statement coverage in a relatively short time, while dynamic testing often often achieves less than 50% statement coverage, because dynamic testing finds bugs only in parts of the code that are actually executed
• Dynamic testing usually takes longer than static testing. Dynamic testing may involve running several test cases, each of which may take longer than compilation.
• Static testing can be done before compilation, while dynamic testing can take place only after compilation and linking
• Static testing can find all of the followings that dynamic testing cannot find: syntax errors, code that is hard to maintain, code that is hard to test, code that does not conform to coding standards, and ANSI violations

Verification vs Validation

The terms ‘Verification‘ and ‘Validation‘ are frequently used in the software testing world but the meaning of those terms are mostly vague and debatable. You will encounter (or have encountered) all kinds of usage and interpretations of those terms, and it is our humble attempt here to distinguish between them as clearly as possible.

Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review or non-executable methods.

Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated.

Verification answers the question, “Did we build the right system?”

while 

Validations addresses, “Did we build the system right?”

Keep in mind that verification and validation techniques can be applied to every element of the computerized system. You’ll find these techniques in publications dealing with the design and implementation of user manuals and training courses, as well as in industry publications.

Quality Assurance vs Quality Control

There is often confusion in the IT industry regarding the difference between quality control and quality assurance. Many “quality assurance” groups, in fact, practice quality control. Quality methods can be segmented into two categories: preventive methods and detective methods.

Quality has two working definitions:

Producer’s Viewpoint – The quality of the product meets the requirements

Customer’s Viewpoint – The quality of the product is “fit for use” or meets the customer’s needs

There are many “products” produced from the software development process in addition to the software itself, including requirements, design documents, data models, GUI screens, programs, and so on. To ensure that these products meet both requirements and user needs, both quality assurance and quality control are necessary.

Quality Assurance

Is a planned and systematic set of activities necessary to provide adequate confidence that products and services will conform to specified requirements and meet user needs.

Quality assurance is a staff function, responsible for implementing the quality policy defined through the development and continuous improvement of software development processes.

Quality assurance is an activity that establishes and evaluates the processes that produce products.

If there is no need for process, there is no role for quality assurance. For example, quality assurance activities in an IT environment would determine the need for, acquire, or help install:

• System development methodologies
• Estimation processes
• System maintenance processes
• Requirements definition processes
• Testing processes and standards

Once installed, quality assurance would measure these processes to identify weaknesses, and then correct those weaknesses to continually improve the process.

 Quality Control

Is the process by which product quality is compared with applicable standards, and the action taken when non-conformance is detected. Quality control is a line function, and the work is done within a process to ensure that the work product conforms to standards and requirements.

Quality control activities focus on identifying defects in the actual products produced. These activities begin at the start of the software development process with reviews of requirements, and continue until all application testing is complete.

It is possible to have quality control without quality assurance. For example, a test team may be in place to conduct system testing at the end of development, regardless of whether that system is produced using a software development methodology.

The following statements help differentiate quality control from quality assurance: 

• Quality control relates to a specific product or service.
• Quality control verifies whether specific attribute(s) are in, or are not in, a specific product or service.
• Quality control identifies defects for the primary purpose of correcting defects.
• Quality control is the responsibility of the team/worker.
• Quality control is concerned with a specific product.
• Quality assurance helps establish processes.
• Quality assurance sets up measurement programs to evaluate processes.
• Quality assurance identifies weaknesses in processes and improves them.
• Quality assurance is a management responsibility, frequently performed by a staff function.
• Quality assurance is concerned with all of the products that will ever be produced by a process.
• Quality assurance is sometimes called quality control over quality control because it evaluates whether quality control is working.
• Quality assurance personnel should not ever perform quality control unless it is to validate quality control.