SQL QUERY TO FIND THE 5TH MAX MARK FROM EXAM TABLE

SELECT Top 1 MARK AS MARK FROM exam

WHERE MARK IN

(SELECT DISTINCT TOP(5) MARK FROM exam ORDER BY MARK DESC)

ORDER BY MARK

Android OS

Android is an operating system for mobile devices such as smartphones and tablet computers. It is developed by the Open Handset Alliance led by Google.

Google purchased the initial developer of the software, Android Inc., in 2005. The unveiling of the Android distribution on November 5, 2007 was announced with the founding of the Open Handset Alliance, a consortium of 84 hardware, software, and telecommunication companies devoted to advancing open standards for mobile devices. Google released most of the Android code under the Apache License, a free software license. The Android Open Source Project (AOSP) is tasked with the maintenance and further development of Android.

Android consists of a kernel based on the Linux kernel, with middleware, libraries and APIs written in  C and application software running on an application framework which includes Java-compatible libraries based on Apache Harmony. Android uses the Dalvik virtual machine with just-in-time compilation to run Dalvik bytecode, which is usually translated from Java bytecode. Android has a large community of developers writing applications ("apps") that extend the functionality of the devices. Developers write primarily in a customized version of Java. There are currently approximately 300,000 apps available for Android, from a total of 500,000 apps over the life of Android. Apps can be downloaded from third-party sites or through online stores such as Android Market, the app store run by Google.

Version history

Android has seen a number of updates since its original release, each fixing bugs and adding new features. Each version is named, in alphabetical order, after a dessert.

Recent releases

• 2.3 Gingerbread refined the user interface, improved the soft keyboard and copy/paste features, improved gaming performance, added   SIP  support (VoIP calls), and added support for Near Field Communication. Android 2.3 Gingerbread is the latest Android version that is available to phones.
•  3.0 Honeycomb was a tablet-oriented release which supports larger screen devices and introduces many new user interface features, and supports multi-core processors and hardware acceleration for graphics. The first device featuring this version, the Motorola Xoom tablet, went on sale in February 2011.  
•   3.1 Honeycomb, released in May 2011, added support for extra input devices, USB host mode for transferring information directly from cameras and other devices, and the Google Movies and Books apps. 
•   3.2 Honeycomb, released in July 2011, added optimization for a broader range of screen sizes, new "zoom-to-fill" screen compatibility mode, loading media files directly from SD card, and an extended screen support API. Huawei Media Pad is the first 7 inch tablet to use this version

• 4.0 Ice Cream Sandwich, announced on October 19, 2011, brought Honeycomb features to smartphones and added new features including facial recognition unlock, network data usage monitoring and control, unified social networking contacts, photography enhancements, offline email searching, and information sharing using NFC.

Design

Linux

Android's kernel is a fork of the Linux kernel but has further architecture changes by Google outside the typical Linux kernel development cycle. Android does not have a native X Window System nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android.

Certain features Google contributed back to the kernel, notably a power management feature called wakelocks, were rejected by mainline kernel developers, partly because kernel maintainers felt that Google did not show any intent to maintain their own code. Even though Google announced in April 2010 that they would hire two employees to work with the Linux kernel community, Greg Kroah-Hartman, the current Linux kernel maintainer for the -stable branch, said in December 2010 that he was concerned that Google was no longer trying to get their code changes included in mainstream Linux Some Google Android developers hinted that "the Android team was getting fed up with the process", because they were a small team and had more urgent work to do on Android. However, in September 2010 Linux kernel developer Rafael J. Wysocki added a patch that improved the mainline Linux wakeup events framework. He said that Android device drivers that use wakelocks can now be easily merged into mainline Linux, but that Android's opportunistic suspend features should not be included in the mainline kernel. In 2011 Linus Torvalds said that "eventually Android and Linux would come back to a common kernel, but it will probably not be for four to five years."

Testing Software Requirement Specification

Most of the bugs in software are due to incomplete or inaccurate functional requirements?” The software code, doesn’t matter how well it’s written, can’t do anything if there are ambiguities in requirements.It’s better to catch the requirement ambiguities and fix them in early development life cycle. Cost of fixing the bug after completion of development or product release is too high.  So it’s important to have requirement analysis and catch these incorrect requirements before design specifications and project implementation phases of SDLC.

we need to define some standard tests to measure the requirements. Once each requirement is passed through these tests you can evaluate and freeze the functional requirements.

Client (stakeholders) specified the project requirements for initial phase of the project development. Once manager circulated all the requirements in the team for review. When the discussion was started on these requirements. Everyone was having their own conception about the requirements. We found lot of ambiguities in the ‘terms’ specified in requirement documents, which later on sent to client for review/clarification.

Client used many ambiguous terms, which were having many different meanings, making it difficult to analyze the exact meaning. The next version of the requirement doc from client was clear enough to freeze for design phase.

Next criteria for testing the requirements specification is “Discover missing requirements”

Many times project designers don’t get clear idea about specific modules and they simply assume some requirements while design phase. Any requirement should not be based on assumptions. Requirements should be complete, covering each and every aspect of the system under development.

Specifications should state both type of requirements i.e. what system should do and what should not.

When one  read the software requirements specification document (SRS), they should  note down their own understanding of the requirements that are specified, plus other requirements SRS document should supposed to cover. This helps me to ask the questions about unspecified requirements making it clearer.

For checking the requirements completeness, divide requirements in three sections, ‘Must implement’ requirements, requirements those are not specified but are ‘assumed’ and third type is ‘imagination’ type of requirements. Check if all type of requirements is addressed before software design phase.

Check if the requirements are related to the project goal.
Sometimes stakeholders have their own expertise, which they expect to come in system under development. They don’t think if that requirement is relevant to project in hand. Make sure to identify such requirements. Try to avoid the irrelevant requirements in first phase of the project development cycle. If not possible ask the questions to stakeholders: why one  want to implement this specific requirement? This will describe the particular requirement in detail making it easier for designing the system considering the future scope.

How to decide the requirements are relevant or not?
Set the project goal and ask this question: If not implementing this requirement will cause any problem achieving our specified goal? If not, then this is irrelevant requirement. Ask the stakeholders if they really want to implement these types of requirements.

In short requirements specification (SRS) doc should address following:
Project functionality (What should be done and what should not)
Software, Hardware interfaces and user interface
System Correctness, Security and performance criteria
Implementation issues (risks) if any

“Requirements should be clear and specific with no uncertainty, requirements should be measurable in terms of specific values, requirements should be testable having some evaluation criteria for each requirement, and requirements should be complete, without any contradictions”

Testing should start at requirement phase to avoid further requirement related bugs. Communicate more and more with your stakeholder to clarify all the requirements before starting project design and implementation.

Boundary Value Analysis

Boundary value analysis is a technique for test data selection. A test engineer chooses values that lie along data extremes. Boundary values include maximum, minimum, just inside boundaries, just outside boundaries, typical values, and error values. The expectation is that, if a systems works correctly for these extreme or special values, then it will work correctly for all values in between. An effective way to test code is to exercise it at its natural boundaries.


Boundary Value Analysis is a method of testing that complements equivalence partitioning. In this case, data input as well as data output are tested. The rationale behind Boundary Value Analysis  is that the errors typically occur at the boundaries of the data. The boundaries refer to the upper limit and the lower limit of a range of values or more commonly known as the "edges" of the boundary.

Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:
 
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case.

2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.

3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.

Boundary value analysis is often called as a part of stress and negative testing.

GUI Testing On Smart Devices

GUI (Graphical User Interface) does matter and creates a lot of difference. Importance of decent and attractive GUI can be felt more significantly in smart devices  environment where screen size is much small.

GUI testing can be toughest part especially while testing on smart device. One should pay full attention to the GUI while testing on smart devices and surely it is an important task that deserves significant time and resource allocation

There also come the situations where we are given an already built GUI to test. In such situations also think about the missing controls, the controls that will add value to the screen and compare their importance with the current ones. If you think you need to make a change go ahead.

Once you have decided which controls will be shown on the screen, think thoroughly about size, style and location of the controls on the screen and more important how user will interact with them?

3 important factors to be considered while testing GUI on Smart Devices:

Size:

There are too many variations in screen sizes and available resolutions. In smart devices especially, controls sizes are not static, they have relation to the available screen size.

While testing, make sure that controls size looks esthetically good and control is completely visible on the screen without any scrolling. Test the GUI on different devices with different screen sizes and resolutions.

Emulators are good for this purpose but nothing matches the real device. So make sure that we test on at least two or three real devices. Also don’t forget to test on landscape and portrait orientations if the device supports it.

Style:

Definitely the application has a specific design. And style of the controls should match with that design. You might have seen many applications where some controls e.g. panels have round edges and text boxes in them have sharp edges. Although this type of issues don’t affect the usability or functionality but still a consistent look of the application helps to build a friendly relation between the application and the user.

Relatively more important thing in style is font on the different pages. Most of the times, we focus the text that is visible in normal situations and ignore the text that appears in specific situations. Success and Failure messages are an example of such type of text.

Another factor, important in style is relation between the font color and the situation in which text is displayed. For example Red color is used for Error messages, Green for success, Yellow for warnings and Blue (now a day occasionally) for hyperlinks.

Location:

Location and position are the two words that are used alternatively and it is interesting that they are further used to convey two different concepts that are explained below.

1. Sometimes it is the area on the screen where a control appears. For example Header is located on Top of the page, Labels are Left Aligned, and Text boxes are Right Aligned etc. Here text in bold are relative positions of the controls

2. Sometimes it is the order of a control among the other controls. For example while getting personal info, First Name is followed by the last name or format of controls to ask for an address should be in order ZIP, City, State.

For both these situations, make sure that everything is logical and shows a good aesthetic sense.

Forgot something even more important. There are situations where one or more controls appear on more than one screen, in this situation make sure that they appear on same location and in the same order on all the pages.

User Acceptance Testing(UAT)

User Acceptance Testing is often the final step before rolling out the application.

Usually the end users who will be using the applications test the application before ‘accepting’ the application.

This type of testing gives the end users the confidence that the application being delivered to them meets their requirements.

This testing also helps nail bugs related to usability of the application.

User acceptance testing is different from System Testing. System testing is invariably performed by the development team which includes developer and tester. User acceptance testing on the other hand should be carried out by the end user. This could be in the form of

Alpha Testing Where test are conducted at the development site by the end users. Environment can be controlled a little bit in this case.

Beta Testing Where test are conducted at customer site and development team do not have any control on the test environment.

Before the User Acceptance testing can be done the application is fully developed.
Various levels of testing (Unit, Integration and System) are already completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT. 

User Acceptance Testing – What to Test? 

To ensure an effective User Acceptance Testing Test cases are created.
These Test cases can be created using various use cases identified during the Requirements definition stage.
The Test cases ensure proper coverage of all the scenarios during testing.

During this type of testing the specific focus is the exact real world usage of the application. The Testing is done in an environment that simulates the production environment.
The Test cases are written using real world scenarios for the application 

User Acceptance Testing – How to Test? 

The user acceptance testing is usually a black box type of testing. In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing.

 However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment. 

The steps taken for User Acceptance Testing typically involve one or more of the following:
.......1) User Acceptance Test (UAT) Planning
.......2) Designing UA Test Cases
.......3) Selecting a Team that would execute the (UAT) Test Cases
.......4) Executing Test Cases
.......5) Documenting the Defects found during UAT
.......6) Resolving the issues/Bug Fixing
.......7) Sign Off 

User Acceptance Test (UAT) Planning: 

As always the Planning Process is the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria. 

Designing UA Test Cases: 

The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios.
The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating.

Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something.

The Business Analysts and the Project Team review the User Acceptance Test Cases. 

Selecting a Team that would execute the (UAT) Test Cases: 

Selecting a Team that would execute the UAT Test Cases is an important step.
The UAT Team is generally a good representation of the real world end users.
The Team thus comprises of the actual end users who will be using the application. 

Executing Test Cases: 

The Testing Team executes the Test Cases and may additional perform random Tests relevant to them 

Documenting the Defects found during UAT: 

The Team logs their comments and any defects or issues found during testing. 

Resolving the issues/Bug Fixing: 

The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users. 

Sign Off: 

Upon successful completion of the User Acceptance Testing and resolution of the issues the team generally indicates the acceptance of the application. This step is important in commercial software sales. Once the User “Accept” the Software delivered they indicate that the software meets their requirements.

How Do we Know when to stop Testing?

This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are...


How much of the application has actually been tested (both by unit test and functionally).


One need to assess each potential use case (and parameters for that use case) for likelihood of it actually being used (so you may drop edge cases), complexity (simpler things being less likely to contain bugs, or rather less likely to contain hard to find bugs), cost to test (in terms of time) and potential impact of a defect if discovered in that area (this is where the nuclear reactor vs. blogging platform comes in).

Other Points to be considered are


·Deadlines have been reached, e.g. release deadlines, testing deadlines;


·Test cases completed with certain percentage passed;


·Test budget has been depleted;


·Coverage of code, functionality, or requirements reaches a specified point;


·Bug rate falls below a certain level;
               or


·Beta or alpha testing period ends.

Preparing for a Load Test

The first step in designing a Web site load test is to measure as accurately as possible the current load levels.

 

 Measuring Current Load Levels

 The best way to capture the nature of Web site load is to identify and track, [e.g. using a log analyser] a set of key user session variables that are applicable and relevant to the Web site traffic.

Some of the variables that could be tracked include:

• the length of the session (measured in pages)
• the duration of the session (measured in minutes and seconds)
• the type of pages that were visited during the session (e.g., home page, product information page, credit card information page etc.)
• the typical/most popular ‘flow’ or path through the website
• the % of ‘browse’ vs. ‘purchase’ sessions
• the % type of users (new user vs. returning registered user)

Measure how many people visit the site per week/month or day. Then  break down these current traffic patterns into one-hour time slices, and identify the peak-hours (i.e. if you get lots of traffic during lunch time etc.), and the numbers of users during those peak hours. This information can then be used to estimate the number of concurrent users on your site.

Concurrent Users 

Although the site may be handling x number of users per day, only a small percentage of these users would be hitting your site at the same time. For example, if you have 3000 unique users hitting your site on one day, all 3000 are not going to be using the site between 11.01 and 11.05 am.

So, once we have identified the peak hour, divide this hour into 5 or 10 minute slices [one should use your own judgement here, based on the length of the average user session] to get the number of concurrent users for that time slice.

Estimating Target Load Levels

Once we have identified the current load levels, the next step is to understand as accurately and as objectively as possible the nature of the load that must be generated during the testing. 

Using the current usage figures, estimate how many people will visit the site per week/month or day. Then divide that number to attain realistic peak-hour scenarios.

It is important to understand the volume patterns, and to determine what load levels your web site might be subjected to (and must therefore be tested for).  

There are four key variables that must be understood in order to estimate target load levels:

• how the overall amount of traffic to your Web site is expected to grow
• the peak load level which might occur within the overall traffic
• how quickly the number of users might ramp up to that peak load level
• how long that peak load level is expected to last  

Once you have an estimate of overall traffic growth, you’ll need to estimate the peak level you might expect within that overall volume.

  

Estimating Test Duration

 The duration of the peak is also very important-a Web site that may deal very well with a peak level for five or ten minutes may crumble if that same load level is sustained longer than that. You should use the length of the average user session as a base for determining the load test duration.

Ramp-up Rate

 As mentioned earlier, Although your site may be handling x number of users per day, only a small percentage of these users would be hitting your site at the same time.

 Therefore, when preparing your load test scenario, you should take into account the fact that users will hit the website at different times, and that during your peak hour the number of concurrent users will likely gradually build up to reach the peak number of users, before tailing off as the peak hour comes to a close. 

The rate at which the number of users builds up, the "Ramp-up Rate" should be factored into the load test scenarios (i.e. you should not just jump to the maximum value, but increase in a series of steps).  

Scenario Identification

 The information gathered during the analysis of the current traffic is used to create the scenarios that are to be used to load test the web site.

 The identified scenarios aim to accurately emulate the behavior of real users navigating through the Web site.

 for example, a seven-page session that results in a purchase is going to create more load on the Web site than a seven-page session that involves only browsing. A browsing  session might only involve the serving of static pages, while a purchase session will  involve a number of elements, including the inventory database, the customer database,  a credit card transaction with verification going through a third-party system, and a  notification email. A single purchase session might put as much load on some of the  system’s resources as twenty browsing sessions.

 Similar reasoning may apply to purchases from new vs. returning users. A new user  purchase might involve a significant amount of account setup and verification —something existing users may not require. The database load created by a single new user purchase may equal that of five purchases by existing users, so you should differentiate the two types of purchases.

Script Preparation

Next, program your load test tool to run each scenario with the number of types of users concurrently playing back to give you a the load scenario.

 The key elements of a load test design are:

• test objective
• pass/fail criteria
• script description
• scenario description

Load Test Objective

The objective of this load test is to determine if the Web site, as currently configured, will be able to handle the X number of sessions/hr peak load level anticipated. If the system fails to scale as anticipated, the results will be analysed to identify the bottlenecks.

Pass/Fail Criteria The load test will be considered a success if the Web site will handle the target load of X number of sessions/hr while maintaining the pre-defined average page response times (if applicable). The page response time will be measured and will represent the elapsed time between a page request and the time the last byte is received. Source:http://bazman.tripod.com/loadtest.html

Security Testing

security testing is performed to check whether there is any information outflow in the sense by encrypting the application or using wide range of software’s and hardware's and firewall etc.

The six basic security concepts that need to be covered by security testing are: confidentiality, integrity, authentication, availability, authorization and non-repudiation.

Confidentiality

• A security measure which protects against the disclosure of information to parties other than the intended recipient that is by no means the only way of ensuring the security....

Integrity

• A measure intended to allow the receiver to determine that the information which it is providing is correct.
• Integrity schemes often use some of the same underlying technologies as confidentiality schemes, but they usually involve adding additional information to a communication to form the basis of an algorithmic check rather than the encoding all of the communication.

Authentication

Authentication involves confirming the identity of a person, tracing the origins of an artifact, ensuring that a product is what its packaging and labeling claims to be, or assuring that a computer program is a trusted one.

The ways in which someone may be authenticated fall into three categories, based on what are known as the factors of authentication: something you know, something you have, or something you are. Each authentication factor covers a range of elements used to authenticate or verify a person's identity prior to being granted access, approving a transaction request, signing a document or other work product, granting authority to others, and establishing a chain of authority.

Security research has determined that for a positive identification, elements from at least two, and preferably all three, factors be verified. The three factors (classes) and some of elements of each factor are:

• ownership factors: Something the user has (e.g., ID card, security token, )
• Knowledge factors: Something the user knows (e.g., Password, (PIN)Personal Identification Number)
• inherence factors: Something the user is or does (e.g., Finger Print,  DNA sequence (there are assorted definitions of what is sufficient),signature, face,Retinal Pattern, voice, unique bio-electric signals, or other biometric identifier).

Authorization

Authorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy. During operation, the system uses the access control rules to decide whether access requests from consumers shall be approved (granted) or disapproved (rejected). Determining that a requester is allowed to receive a service or perform an operation.

Availability

• Assuring information and communications services will be ready for use when expected.
• Information must be kept available to authorized persons when they need it.

Non-repudiation

Interchange  of authentication information with some form of provable time stamp e.g. with session id etc. Nonrepudiation is a way to guarantee that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message.