git pull origin master
git commit -am “test file created”
git push origin master
Tag Archives: SQL Quick Reference
In Selenium we have to first assign keyword for that scripts(create common functions which we can use in any classes).
public class keyword
private static final String String = null;
public static WebDriver driver;
public static By Byelement (String Type, String Path)
else if (Type.equals(“className”))
else if (Type.equals(“name”))
- Check broken links.
- Check missing content, e.g. images.
- Check missing page titles.
- Check spelling and grammar of content.
- Check missing metadata.
- Check the file sizes of pages to ensure they are not too large.
- Check browser compatibility.
- Check that applications are functioning correctly, e.g. online forms.
- Check that any Server Side Scripting or other languages function correctly.
- Check that legal and regulatory guidelines are being adhered to, e.g. data protection and privacy.
- Check that pages conform to your organisation’s Web-Accessibility standard (if any), e.g. missing ‘alt-tags’.
- Check that the Website Design standard is maintained.
AND / OR
SELECT column_name(s)FROM table_nameWHERE conditionAND|OR condition
ALTER TABLE table_nameADD column_name datatype
ALTER TABLE table_name
DROP COLUMN column_name
|AS (alias)||SELECT column_name AS column_aliasFROM table_nameorSELECT column_nameFROM table_name AS table_alias|
|BETWEEN||SELECT column_name(s)FROM table_nameWHERE column_nameBETWEEN value1 AND value2|
|CREATE DATABASE||CREATE DATABASE database_name|
|CREATE TABLE||CREATE TABLE table_name(column_name1 data_type,column_name2 data_type,column_name2 data_type,…
What is compatibility testing?
In computer world, compatibility is to check whether your software is capable of running on different hardware, operating systems, applications , network environments or mobile devices.
Compatibility Testing is a type of the Non-functional testing
Types of compatibility tests
Let’s look into compatibility testing types
Levels of Software Testing
1 Unit Testing is a level of the software testing process where individual units/components of a software/system are tested. The purpose is to validate that each unit of the software performs as designed.
2 Integration Testing is a level of the software testing process where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units.
3 System Testing is a level of the software testing process where a complete, integrated system/software is tested. The purpose of this test is to evaluate the system’s compliance with the specified requirements.
4 Acceptance Testing is a level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.
Note: Some tend to include Regression Testing as a separate level of software testing but that is a misconception. Regression Testing is, in fact, just a type of testing that can be performed at any of the four main levels.
There are different levels during the process of Testing. In this chapter a brief description is provided about these levels.
Why to we required Automation testing?
Reusing the test scripts:
- When you want to execute the regression test scripts after every build it makes more sense to automate them. In case of testing web based application there is a more need to automate as the test suite has to be run on various browsers like Internet Explorer, Firefox and other browsers.
- Running unattended automated test scripts saves human time as well as machine time than executing scripts manually.
Better use of resource:
- While automated scripts are running unattended on machines, testers can do more useful tasks.
- On test engagements requiring a lot of regression testing, usage of automated testing reduces the people count and time requirement to complete the engagement and helps reduce the costs.
To Automate or Not to Automate?
- It is not always advantageous to automate test cases. There are times when manual testing may be more appropriate.
- For instance, if the application’s user interface will change considerably in the near future, then any automation would need to be rewritten. Also, sometimes there simply is not enough time to build test automation. For the short term, manual testing may be more effective. If an application has a very tight deadline, there is currently no test automation available, and it’s imperative that the testing get done within that time frame, then manual testing is the best solution.
Decide What Test Cases to Automate
- Repetitive tests that run for multiple builds.
- Tests that tend to cause human error.
- Tests that require multiple data sets.
- Frequently used functionality that introduces high risk conditions.
- Tests those are impossible to perform manually.
- Tests that run on several different hardware or software platforms and configurations.
- Tests that take a lot of effort and time when manual testing.
Create Automated Tests that are Resistant to Changes in the UI
- Automated tests created with scripts or keyword tests are dependent on the application under test.
- The user interface of the application may change between builds, especially in the early stages. These changes may affect the test results, or your automated tests may no longer work with future versions of the application.
- The problem is automated testing tools use a series of properties to identify and locate an object.
- Sometimes a testing tool relies on location coordinates to find the object. For instance, if the location has changed, the automated test will no longer be able to find the object when it runs and will fail.
- To run the automated test successfully, you may need to replace old names with new ones in the entire project, before running the test against the new version of the application.
- However, if you provide unique names for your controls, it makes your automated tests resistant to these UI changes and ensures that your automated tests work without having to make changes to the test itself.
- This also eliminates the automated testing tool from relying on location coordinates to find the control, which is less stable and breaks easily.
- However, automation has specific advantages for improving the long-term efficiency of a software team’s testing processes.
Test automation supports:
- Frequent regression testing
- Rapid feedback to developers during the development process
- Virtually unlimited iterations of test case execution
- Customized reporting of application defects
- Disciplined documentation of test cases
- Finding defects missed by manual testing
Automated tests should be
Concise: Test should be as simple as possible and no simpler.
Self Checking: Test should report its results such that no human interpretation is necessary.
Repeatable: Test can be run repeatedly without human intervention.
Robust: Test produces same result now and forever. Tests are not affected by changes in the external environment.
Sufficient: Tests verify all the requirements of the software being tested.
Necessary: Everything in each test contributes to the specification of desired behavior.
Clear: Every statement is easy to understand.
Efficient: Tests run in a reasonable amount of time.
Specific: Each test failure points to a specific piece of broken functionality (e.g. each test case tests one possible point of failure).
Independent: Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.
Maintainable: Tests should be easy to modify and extend.
Traceable: Tests should be traceable to the requirements; requirements should be traceable to the tests.
Defect Management Process
- Defect Prevention – Implementation of techniques, methodology and standard processes to reduce the risk of defects.
- Deliverable Baseline – Establishment of milestones where deliverable will be considered complete and ready for further development work. When a deliverable is base lined, any further changes are controlled. Errors in a deliverable are not considered defects until after the deliverable is base lined.
- Defect Discovery – Identification and reporting of defects for development team acknowledgment. A defect is only termed discovered when it has been documented and acknowledged as a valid defect by the development team member(s) responsible for the component(s) in error.
- Defect Resolution – Work by the development team to prioritize, schedule and fix a defect, and document the resolution. This also includes notification back to the tester to ensure that the resolution is verified.
- Process Improvement — Identification and analysis of the process in which a defect originated to identify ways to improve the process to prevent future occurrences of similar defects. Also the validation process that should have identified the defect earlier is analyzed to determine ways to strengthen that process.
- Management Reporting – Analysis and reporting of defect information to assist management with risk management, process improvement and project management.
Verification and Validation detail image
Validation(FDA): Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. Contrast with data validation.
Validation, Verification, and Testing (NIST): Used as an entity to define a procedure of review, analysis, and testing throughout the software life cycle to discover errors, determine functionality, and ensure the production of quality software.
Verification, Software (NBS): In general the demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle. See: validation, software.
ANDROID APPLICATIONS TEST
Android testing has several approaches:
- Test Android implementations: it’s the object of CTS
Test mobile application: it’s the object of this document
To complete these tests, the user can use tools:
- CTS has automated the test plan
This document proposes a test plan manually ran but during the event different solutions to partially automate these tests will be tested
CTS are designed to test Android implementations.
This test plan is designed to test Android mobile applications. The test cases are intended to be ran manually. But some parts can be automated with specific tools.
This section provides general tests about launching the application.
2.1. Is the application launched successfully? Yes/No
2.2. Once launched, does the application gain control?
2.3. Does the installation of your application not interfere with the pre-installed applications?
2.4. Can you come back to the application main menu screen in less than 3 seconds?
1. Load Testing Tools (Per. Testing)
a) reduces the time spent by the testers
b) reduces the resources spent (hardware)
c) mostly used in web testing
d) all of the above
2. Test coverage analysis is the process of (Testing concepts)
a) Creating additional test cases to increase coverage
b) Finding areas of program exercised by the test cases
c) Determining a quantitative measure of code coverage, which is a direct measure of quality.
d) All of the above.
3. Critical in Web Testing (Testing concepts)
a) Performance and Functionality
b) Functionality and usability
c) Usability and Performance
d) None of the above
4. Class testing (Testing concepts)
a) require a driver to test
b) no need of instances of other classes
c) no need to test the transitions
d) all of the above.
5. Defect Tracking (Defect Mgmt)
a) is the communication channel between test team and development team
b) is the communication channel between testing team and the rest of the team
c) is the communication channel between the testing team and end users
d) all of the above