11 April 2016

Concluding day of GMI Training

Concluding day of GMI Training

I collected my feedback and bid farewell to all my colleagues who assured to be in touch forever. I collected my experience letter from AMIT and the two completion certificates on Testing and Quality Management. I am extremely grateful that I had a chance to get real industry exposure and learn a lot of new things, made new contacts. This is something i can cherish for a lifetime and awarded by top managements at GMI for exhibiting core value of Creativity.

08 April 2016

Quality Management At Sapient

Quality Management At Sapient
Sapient|Approach emphasizes on quality delivery being the responsibility of each team member. Our processes and tools are geared towards enabling each team member in ensuring quality of their respective deliverables.
The guiding principles of Sapient’s Quality Management approach are to “make quality a way of life” and to “catch defects as early as possible”. To this end, our QM approach includes industry best practices for Quality Planning, Quality Assurance, Quality Control and Quality Improvement, and covers the entire life cycle of a product/software.
Below is a representation of the focus areas of our Quality Management approach: 
Test Driven Development: Test Driven Development (TDD) is a technique whereby developers code unit tests first. The tests determine what system code needs to get written. Using this technique ensures that there is unit test coverage for each functionality that gets developed and that there are no system code changes unless there is a failing test case. This technique also enables us to develop functionality in incremental steps and refactor as we go along, always ensuring that the developed code is of good quality. This leads our teams to maintain an exhaustive suite of automated unit tests using the best practices tools available.

Continuous Delivery: The design principle behind Continuous Delivery (CD) is to that “every change is releasable”. Continuous Delivery is about having a deployment pipeline and a team that work towards ensuring that the software is releasable at any point of time. This technique enforces discipline within the software project team and ensures that the continuous integration and deployment infrastructure required is setup - including version control, automated builds, automated unit, functional, acceptance and regression testing, and builds packaging. Sapient has a dedicated Delivery Agility team that has expertise in the industry leading tools that enable us to setup a continuous delivery framework for a project team.

Automation: Automation is an integral part of our delivery approach and helps increase efficiency by automating repeatable tasks. Listed below are some of the candidates for automation:
·         Test Automation: The design principles built into our test automation framework are to “Support multitude of test cases without linearly increasing level of effort” and to “Make the framework keyword driven, extensible and modular”.  Test Automation using industry best practices and tools enables our teams to shorten testing times, ensure consistency, allow for extensibility and improve predictability.
·         Process Automation: Our teams always look for opportunities to automate repeatable components of project processes. Our teams have also built excel macro-based program dashboards that present a snapshot of project status on demand.

Full Life Cycle Quality Assurance: Each project team has dedicated Quality Assurance personnel embedded within, that ensure quality of deliverables throughout the lifecycle of the project. Test lead and QA engineers work in parallel with the developers, business analysts from the beginning of the project until final acceptance. Test lead is responsible for test strategy plan (including tool selection) and its execution. Testers are responsible for designing, executing and automating functional/integration/system tests.

These focus areas, along with quality gates and continuous improvement enabled by our iterative development approach ensure that quality is given prime consideration throughout the project lifecycle.


05 April 2016

UFT Settings


UFT Settings
Global Testing Options
Global testing options affect both how to work with tests and the general appearance of UFT. For example, choose not to display the Start Page when UFT starts, or set the timing-related settings used by UFT when running a test. The values set remain in effect for all tests and for subsequent testing sessions.
Set global testing options using the Options dialog box (Tools >> Options) or by inserting statements in the Expert View.
Individual Test Settings
Use the Test Settings dialog box to set testing options that affect how UFT works with a specific test. For example, instruct UFT to run a parameterized test for only certain lines in the data table. The individual testing options specified are saved when a test is saved.
Set Individual Test settings using the Settings dialog box (File > Settings )


Phases in Quick Test/UFT testing process
1.PREPARING TO RECORD
oBefore recording a test, confirm that application and Quick Test/UFT are set to match the needs of your test.
2.RECORDING A SESSION ON THE APPLICATION
oNavigate through the application or Web site, Quick Test/UFT graphically displays each step that is performed as a row in the Keyword View
3.ENHANCING THE TEST
oInserting checkpoints to search for a specific value of a page, object, or text string, which helps in determining whether application or site is functioning correctly.
oParameterize the code to check that application performs the same operations with multiple sets of data.
oAdding logic and conditional or loop statements to add sophisticated checks in the test.

Recording Modes
Normal Recording Mode
oRecording based on events performed on the objects in the User Interface.
oDefault recording mode, is it also known as context sensitive.
oRecognizes objects in application regardless of their location on the screen.
Analog Recording
oAnalog recording is used for applications in which the actual movement of the mouse needs to be recorded. E.g. Drawing a mouse signature or working with drawing applications that create images by dragging the mouse.
oThe track of the operations recorded are stored in an external data file.
oUFT adds to your test action or scripted component a single RunAnalog statement that calls the recorded analog file. You cannot edit analog recording steps from within UFT
oTypes of Analog Recording:
oRecord relative to a specified window
oRecord relative to the screen
Low Level Recording
oLow-Level Recording is used when the need is to record the exact location of the operation on your application screen
oAll the keyboard input and mouse clicks are recorded based on coordinates(X,Y)
Insight Recording Mode
oThis mode enables you to record on any control (object) displayed on your screen, whether or not UFT recognizes the object's technology.
oYou can switch to Insight recording in the middle of a recording session for specific steps.
oUFT recognizes controls based on their appearance, and not their native properties.

Running Test Script
•Run – Execute UFT Test Script
•RUN FROM : Run a selected part of your test. Enables you to check a specific section of your application or to confirm that a certain part of your test runs smoothly.
•RUN TO: You can instruct UFT to run from the beginning of the test or action (Expert View only)—or from the current location in the test or action—and to stop at a particular step.
•DEBUG FROM STEP: can begin debugging from a specific step in your test or action when editing a test or action.
•RUN CURRENT ACTION option to run a single action in your test.
Update Run Mode - Updates the test object description, Checkpoints properties, active screen images and values.
Maintenance Run Mode - UFT identifies discrepancies between the objects in the repository and those in your application and then offers a solution for updating your objects and steps in real time.

Analyzing Test Results
•When a run session ends, view the run session results in the Test Results window.
•The Test Results window contains a description of the steps performed during the run session. For a test that does not contain Data Table parameters, the Test Results window shows a single test iteration.
•If the test contains Data Table parameters, and the test settings are configured to run multiple iterations, the Test Results window displays details for each iteration of the test run.
•The results are grouped by the actions in the test.
•Filters can be used to filter down only failed, passed, warning result nodes.