Partition Hard disk drive

Hard Disk Partitioning

Disk Partitioning is dividing hard disk drive into multiple disks to treat one large physical disk drive as if it were multiple disks.

Advantages of Disk Partition:

1. Use of multi-boot setups, which allows to have and operate more than one operating system on a single computer.
2. The access time with smaller file systems is efficient when compared to big Master File System with a single Master File Table(MFT).

How to Partition Hard disk drive step-by-step process

Step 1:  Go to START and right click on Computer and select Manage.
Step 2:
1. A window similar to the below one opens, select Disk Management on the left side of the window toolbar.
2. Select the hard disk (C in this case) you want to partition.
3. Right click as shown on the hard drive (c).
4. Select Shrink Volume.

Step 3:
Enter the amount you want to shrink in MB (Example: if you want to partition 100GB from the hard drive, enter the amount to shrink as 102400 MB since 1GB = 1024 MB) and click Shrink.

Step 4:
After the hard disk had partitioned, we need to label that. Right click on the partitioned hard drive to select New Simple Volume.

Step 5: New Simple Volume wizard opens
1. Click Next and specify Volume size and Click Next.
2. Assign Drive Letter or Path(here you can select any letter you want)
3. Format Partition, where you can specify Volume Label (ie., name the partitioned hard disk space).

Once you click Finish, the hard disk is partitioned and labelled.

SCRUM ROLE : THE SCRUM TEAM

Scrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together".

A typical Scrum team is 5-9 people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. 

Although not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach each Scrum team proceeds as normal but each team identifies one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.

SCRUM ROLE : SCRUM MASTER

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project's key stakeholder, who is referred to as the product owner.

The ScrumMaster does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint. The ScrumMaster role is commonly filled by a former project manager or a technical team leader but can be anyone.

The ScrumMaster is also often viewed as a protector of the team. The most common example is that the ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint due to pressure from an overly aggressive product owner. However, a good ScrumMaster also protects the team from complacency.

Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, “You’re fired,” a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.

A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We didn’t do that this time. What can we do to make sure we do better the next sprint?” This is the Scrum- Master exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable. But because the ScrumMaster’s authority does not extend beyond the process, the same ScrumMaster should not say, “Because we failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in.” Having Tod review the code might be a good idea, but the decision is not the ScrumMaster’s to make. Doing so goes beyond authority over the process and enters into how the team works.

VMware Workstation

What is a Virtual Machine:

A Virtual Machine, is a computer software implementation of hardware in which you can install an  operating system(OS) that executes programs, applications and scripts just like the real machine do.

VMware:

VMware provides users to set/simulate  a group of computers in order to test software or applications prior to deployment in a known environment.

VMware in Software Testing:

Quality Assurance Teams use VMware Workstation to test applications/software on a variety of operating systems(OS), application platforms and browsers with different configurations of tasks.

Difference between VMware Player and VMware Workstation:

VMware Player is like a subset of VMware Workstation.

1. The major difference is in the previous versions(versions earlier than 3) of VMware Player, you can only run virtual machines created on other versions like VMware Workstation but you cannot create a virtual machine itself. But the newer Versions of VMware Player has the ability to create Virtual machine but the major difference would be VMware Player is available for free while the VMware Workstation costs.
2. In VMware Workstation, you can create multiple snapshots and Clones which helps in case of failures from software or hardware. That is this feature enables users  to create a base VM and Clone it and use it for other software installations and test applications and if there is any kind of crash or system failure you still have your base VMware Workstation. VMware Player is lacking this feature of creating Clones and multiple snapshots.
3. VMware Workstation has the ability to create and manage teams by grouping them while VMware Player is lacking this feature. By grouping multiple VM s into teams, certain operations can be performed on all the members of the team as if it is one machine.
4.  VMware Workstation has the ability to handle VRM(Virtual Rights Management) while the VMware Player does not.

Scrum Role : Product Owner

When working with Scrum the product owner is typically a project's key stakeholder. It is important that this person has a vision of what they wish to build and that he or she is able to convey that vision to the scrum team. This is key to successfully beginning any agile software development project. Product owner's do this through in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed. This of course varies tremendously based on whether the team is developing commercial software, software for internal use, hardware, or some other type of product. The key is the person in this role needs to have a vision for what is to be built.

Although the product owner prioritizes the product backlog, during the sprint planning meeting the team selects the amount of work they believe they can do during each sprint and how many sprints will be required. The product owner does not get to say, "We have four sprints left, therefore you must do one-fourth of the product backlog this sprint." The product owner's job is to motivate the team with a clear, elevating goal. Team members know best what they are capable of and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.

In return for the scrum team's commitment to completing the selected user stories from the top of the product backlog, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

An Overview of Scrum for Agile Software Development

As a brief introduction, Scrum is an agile process most commonly used for product development, especially software development. Scrum is, however, a general-purpose project management framework that is applicable to any project with aggressive deadlines with complex requirements and a degree of uniqueness. In Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long.

• Scrum has three roles product owner, Scrum Master and The Team Members.
• Scrum uses three artefacts Product backlog, Sprint Backlogs and Burn down Chart to guide the team during the sprint.
• The product owner takes care of the Product Backlogs. The Backlog is the list of the every desirable outcome user expect from the product. This is the centrally TO DO LIST of GOAL.
• Scrum defines three ceremonies Sprint Planning, Daily Scrum and Sprint Review & Retrospective.
• The Scrum Master is the facility there for the team. He helps the team members to follow the ceremonies and effectively use the artefacts. 

SCRUM OVERVIEW - INTRODUCTION TO SCRUM TERMS:

An introduction to Scrum would not be complete without giving details on all the Scrum terms that you will come across. This section of our Scrum overview lists all these terms and gives you some brief details with a link to more detailed information.

A typical scrum team has between five and nine people, but Scrum projects can easily scale into the hundreds. Scrum can easily be used by one-person teams and often is. The team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”

The product owner is the project’s key stakeholder and represents users, customers and others in the process. The product owner is often someone from product management or marketing, a key stakeholder or a key user.

The ScrumMaster is responsible for making sure the team is as productive as possible. The ScrumMaster does this by helping the team use the Scrum process, by removing impediments (Obstacles) to progress, by protecting the team from outside, and so on.

The product backlog is a prioritized features list containing every desired feature or change to the product. At the start of each sprint, a sprint planning meeting is held during which the product owner presents the top items on the product backlog to the team, and the Scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to a sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.

Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum.

At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal way; for example, PowerPoint slides are not allowed. The meeting must not become a task in itself nor a distraction from the process.

Also at the end of each sprint, the team conducts a sprint retrospective, which is a meeting during which the team (including its ScrumMaster and product owner) reflect on how well Scrum is working for them and what changes they may wish to make for it to work even better.

Note: The term “backlog” can get confusing because it’s used for two different things. To clarify: the product backlog is a list of desired features for the product. The sprint backlog is a list of tasks to be completed in a sprint.

Project Life Cycle (PLC) and System Development Life Cycle (SDLC)

Project Life Cycle (PLC) and System Development Life Cycle (SDLC)

The Project Life Cycle (PLC) focuses on the phases, processes, tools, knowledge and skills for managing a project.

The Systems Development Life Cycle (SDLC) focuses on  creating and implementing the project’s product or the application.

SDLC is a part of PLC, as many of the development activities happen during the execution phase of the PLC.

What is Scrum?

What is Scrum?

“Scrum” is agile framework that helps teams deliver customer value early and often in a highly predictable manner.

The Scrum Way:

Scrum Roles:

1. Product Owner
2. Scrum Master
3. The Team

1. Product Owner is responsible for maximizing the business value delivered by the team.

• One person responsible for the backlog and story priority
• Accepts or rejects work
• Helps define “Done”
• Knowledgeable, empowered, engaged.
• Motivates team, celebrates success!

2. Scrum Master is responsible for facilitating the scrum process and ensuring the team is delivering value.

• Helps builds self-organizing teams
• Removes impediments
• Keep the process healthy
• Empowers the team – Servant Leader !!!

3. The Team is responsible for turning the product backlog items into increments of value each sprint.

• Cross Functional team, 7 or +-2
• Self-Organizing, Collaborative
• Committed
• Generalizing Specialists
• Deliver Value in small Chunks
• Focused on Customer, Build in Quality

How to Improve Software Testing Process / Practice

Improving the testing process is not the responsibility of test team only. It is a joint effort of Development & Testing team and Management to understand the health of existing testing process and identify the necessary measures to improve it.

Points for Software Testers:

1. Try to understand the logic behind the screen and try to break that logic. Understand the internal workings of code from developers during lunch time or tea breaks.
2. Analyse test results thoroughly. Try to identify root cause from functional perspective.
3. Break the application into smaller functional modules.
4. First write test cases for valid conditions, then cover invalid conditions.
5. While writing test cases, refer design documents as well.
6. As soon as you complete the test case writing, share test case with development team. It could result in time saving.
7. During test case writing phase, group test cases using impact analysis. It will help in effective regression testing in less time.
8. If you are new tester for a old development team, have a look on old bug reports of modules / project where development worked previously. Generally developers, repeat similar mistakes.
9. Test the application for both implicit as well as explicit requirements.
10. Never communicate bugs verbally. For any critical / show stopper bugs, have an immediate discussion & then document via mail and share it to relevant stack holders.

Difference Between System Testing and End to End Testing

System Testing: In System testing, we will test the functional, performance and usability of the software. This includes stress, usability and performance testing. For Example, if we are testing a web application, we will check if the website is performing correctly as per the software requirements or not.

End to End Testing:  End to end testing means testing the flow of the functionality of the software from start point to end point. For Example, checking whether the functionality of web application from starting to end.

Severity and Priority of Defects

Generally we have to set the Severity and Priority level for a Defect. Severity level will be set by the Testing Team and the Priority level will be set by the Development Team.

Severity : Severity means how much severe is the particular defect in the application (i.e.) how it affects the functionality of the application.

Severity levels: Trivial, Minor, Major, Critical, Block

Priority : Priority means the importance and urgency to fix the defect by the developers (i.e.) which defect should be fixed first and which should be fixed in later versions.

Priority Levels: Low, Medium, High, Urgent, Immediate.

The Severity and Priority levels must vary depends upon the company and the defect tracking tool used by the company.

Some E.G:

Low Priority: Spelling mistakes, grammatical errors, Textual Errors, Orphan pages, broken links, GUI errors,

High Priority: Wrong Functionality, Applications Crashes, Errors.

Practical Differences in Verification and Validation

No	Verification	Validation
1	Verification is a STATIC testing procedure.	Validation is DYNAMIC testing procedure.
2	It involves verifying the requirements, detailed design documents, test plans, walkthroughs and inspections of various documents produced during the development and testing process.	Validation involves actual testing of the product as per the test plan (unit test, integration test, system test and acceptance test etc).
3	It is a PREVENTIVE procedure.	It is a CORRECTIVE procedure.
4	Are we building the product RIGHT?	Are we building the RIGHT product?
5	It involves more than two to three persons and is a group activity.	It involves the testers and sometimes user.
6	It is also called Human testing, since it involves finding the errors by persons participating in a review or walk through.	It is also called Computer testing, since errors are found out by testing the software on a computer.
7	Verification occurs on Requirements, Design and code.	Validation occurs only on code and the executable application.
8	Verification is made both in the Executable and Non Executable forms of a work product	Validation is done only on Executable forms of a work product.
9	Verification finds errors early in the requirement & design phase and hence reduces the cost of errors.	Validation finds errors only during the testing stage and hence cost of errors reduced is less than Verification.
10	An effective tool for verification tool is a Checklist.	Various manual and automated test tools are available for Validation.
11	It requires cooperation and scheduling of meetings and discussions.	It is to check that the product satisfies the requirements and is accepted by the user.
12	Verification tasks include: 1) Planning 2) Execution	Validation tasks include: 1) Planning 2) Test Development 3) Test Execution 4) Test Maintenance
13	Verification activities include: 1) Requirements Verification 2) Functional design verification 3) Internal Design Verification 4) Code Verification	Validation activities include: 1) Unit testing 2) Usability testing 3) Function testing 4) System testing 5) Acceptance testing
14	Verification deliverables (work products) are: 1) Verification test plan 2) Inspection report 3) Verification test report	Validation deliverables are: 1) Test plan 2) Test Design Specification 3) Test Case Specification 4) Test Procedure Specification 5) Test log 6) Test incident report

Test Case Design - Effectiveness and Efficiency

A test that exercises the software in ways that we know will work proves nothing.

We know that if we run the same test twice we learn very little second time round. If we know before we run a test, that it will almost certainly work, we learn nothing. If we prepare a test that explores a new piece of functionality or a new situation, we know that if the test passes we will learn something new - we have evidence that something works. If we test for faults in code and we try to find faults in many places, we increase our knowledge about the quality of the software. If we find faults, we can fix them. If we do not find faults, our confidence in the software increases.

Effective Tests: When we prepare a test, we should have some view on the type of faults we are trying to detect. If we postulate a fault and look for that, it is likely we will be more effective. In other words, tests that are designed to catch specific faults are more likely to find faults and are therefore more effective.

Efficient Tests: If we postulate a fault and prepare a test to detect that, we usually have a choice of tests. We should select the test that has the best chance of finding the fault. Sometimes, a single test could detect several faults at once. Efficient tests are those that have the best chance of detecting a fault.

By: Mann Bhammar

      Test Analyst

Object Identification in QTP

Generally for every object 20-25 properties description are available in QTP, it recognizes object uniquely using 2 or 3 important one.

QTP has default object identification configuration for every environment, if we feel that configuration is not sufficient for recognizing objects in our application, we can configure some more.

There are three type of Object Identification:

1. Normal Identification: Mandatory and Assistive Properties
2. Smart Identification: Base Filter and Optional Filter Properties
3. Ordinal Identifier: Location, Index and Creation Time (Only for Browser).

1. Normal identification:

First of all the QTP learns all the mandatory properties whether these are enough to identify the object uniquely. If it still can’t identify the object then it looks for assistive properties. Ordinal Identifier is used when mandatory and assistive properties are failed to identify the object.

2. Smart Identification:

Smart identification is an optional feature, if we feel normal identification is not sufficient for any object, and then we configure Smart Identification for that object, in order to avoid Ordinal Identifier.

After normal identification if QTP is not satisfied then it goes to smart identification. In smart identification 2 types of properties available, first QTP learns all base filter properties at a time and thinks whether these properties are sufficient for identifying the object uniquely. If it feels sufficient, then it stops learning otherwise it goes Optional Filter Properties and learns one by one. Still it feels not satisfied finally it goes to Ordinal Identifier.

3. Ordinal Identifier: For more information on ordinal identifier click here....

By: Mann Bhammar
      Test Analyst

Difference between wait and sync in QTP

Wait:-Wait statements instruct QuickTest to wait a specified amount of time before proceeding to the next step.

syntax: Wait(10)
Here the QTP will wait for 10 sec and after that it will proceed for the execution of the next step

Sync:
This method is only available for Web.
This method can be used to synchronize the test execution with a new web page that has to appear in the browser.
This method is used when QTP is not sure how long it is going to take to load page

Regular Expressions in QTP

Regular expressions enable QTP to identify objects and text strings with varying values. You can use regular expressions only for values of type string.

It can be used when:

• Defining the property values of an object in dialog boxes or in programmatic descriptions.
• Parameterizing a step.
• Creating checkpoints with varying values.

We can define a regular expression for a constant value, a Data Table parameter value, an Environment parameter value, or a property value in Descriptive programming. 

We can define a regular expression in standard checkpoint to verify the property values of an object; we can set the expected value of an object's property as a regular expression so that an object with a varying value can be verified.

We can define the text string as a regular expression, when creating a text checkpoint to check that a varying text string is displayed on our application, For XML checkpoints we can set attribute or element values as regular expressions. 

In QTP, when working with Regular Expressions and varying object descriptions can be handled by using Descriptive Programming.

E.G:  Let assume in my Gmail Account I have one unread mail into my Inbox(2) and once I read one mail now it is Inbox(1). In this scenario we will use Regular Expression as shown in script.

'DP for Inbox(2)

cm_d("text").value = "Inbox.*"     ‘.* is used as Regular Expression

If Link(cm_d).Exist(2) Then

    Link(cm_d).Click

            else

            msgbox "Link not present"

End If

By Mann Bhammar

     Test Analyst

What is IIS?

IIS stands for Internet Information Services. It’s a group of Internet servers (including a web or hypertext Transfer Protocol server and a File Transfer Protocol) with additional capabilities for   Microsoft’s Windows NT and Windows 2000 server operating systems.

IIS is used to make the computer as a web server. If we want to have a web server for developing dynamic website or want to publish web site on our own server then we install the IIS. IIS is used on windows platform. For other platform we have different web servers (Example: Apache for Linux)

IIS takes a request from user and executes the required files and sends result back to the user. It also provides the services of SMTP (Simple Mail Transport Protocol). We can send emails using SMTP.

When to use Descriptive Programming in QTP ?????

• When object (properties) are dynamic. Ex: “Logout << Username >> or You are Signed in as << User >>
• When Object Repository is getting very large.
• When you don’t want to use Object Repository. As the OR is being shared and used by other scripts, and you don’t want to change the properties in shared OR.
• When there is no object repository. Ex: When the application is still in development and we are building an automation framework parallel to the SDLC.
• When same objects repeat in every page. Ex: Links like Logout, Help, Contact FAQ’s are present in every page of your web application and adding these repetitive objects to repository is not a good option.

By: Mann Bhammar

      Test Analyst

Fundamental Test Process in Software Testing

Fundamental Test Process:

It involves planning, specification, execution, recording and checking for completion.

·         Specification:

It involves designing test cases and test conditions using Test techniques identified at the planning stage. It is important to determine the expected results prior to test execution.

Test Techniques

1.       Formal technical review:

      A formal technical review is conducted by the software quality assurance group.  It examines only a small part of the software project. Only one developer is responsible for the artifact. The artefact is examined on various levels. It includes things like function and logic as well as implementation. It ensures that all artifacts of the project developed in a uniform manner. Typically a review will last 2 hours. The review may consist of walk-through s, code inspections or any other examination. Since the purpose of a review is to find errors, a review can be difficult to control

2.       Code walk-through :

      A source code walk through often is called a technical code walk through or a peer code review. The typical scenario finds a developer inviting his technical lead, a database administrator, and one or more peers to a meeting to review a set of source modules prior to production implementation. Often the modified code is indicated after the fact on a hard copy listing with annotations or a highlighting pen, or within the code itself with comments. 

        A code walk through is an effective tool in the areas of quality assurance and education. The developer is exposed to alternate methods and processes as the technical lead and database administrator suggest and discuss improvements to the code. The technical lead is assured of an acceptable level of quality and the database administrator is assured of an acceptable level of database performance. The result is better performance of the developer, his programs, and the entire application. 

       Despite all the benefits of source code walk through s, few organizations implement and enforce them as a shop standard. Many excuses are given, but each has a practical solution.

·         Execution:

It involves running the specified test on a computer system either manually or by using an automated test tool.

·         Recording:

       It involves keeping good records of the test. The tested versions, the tested specifications of software and the test specifications are recorded along with the actual outcome of each test.

·         Successful tests detect faults:

        A successful test is one that detects a fault and may cause a delay.

·         Completion or exit criteria:

      Completion or exit criteria are used to determine when testing is complete. It may be defined in terms of cost, time, faults found or coverage criteria.

·         Coverage criteria:

       Coverage criteria are defined in terms of items that are exercised by test suites, such as branches, user requirements, most frequently used transactions etc

Functional (Black Box) Testing and Structural (White Box) Testing

Functional Part is a software testing approach in which: 

• This is done by Testers.
• Functional Testing is also known as Black Box Testing or behavioural testing.
• The tester will have a user perspective in mind.
• It focuses on the functional part of the application.
• He doesn’t know how the program works in back end.
• He will only concentrate in input and output of the application or product.
• The tester acts as if he/she is the final user of the program.

On other hand Structural Part, is a software testing approach in which: 

• Structural Testing is also known as white-box testing or Glass Box testing.
• The tester will have a developer perspective in mind or this is done by Developer.
• Sometime tester acts as a developer of the program who knows the internal structure of the program very well.
• He or she will know how the program works behind the scene, with knowing the Internal Knowledge of the product /Application.
• Its main focus is on the structural part means in coding/programming part.
• Structural is mainly focused on internal code whereas functionality is verified with respect to SRS. 

Please also refer below table for more understanding.

Differences between Black Box Testing and White Box Testing:

Criteria	Black Box Testing	White Box Testing
Definition	Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester	White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.
Levels Applicable To	Mainly applicable to higher levels of testing: Acceptance Testing and System Testing	Mainly applicable to lower levels of testing: Unit Testing & Integration Testing
Responsibility	Generally, independent Software Testers	Generally, Software Developers
Programming Knowledge	Not Required	Required
Implementation Knowledge	Not Required	Required
Basis for Test Cases	Requirement Specifications	Detail Design

By: Mann Bhammar

       Test Analyst