Clone your VSO git Repository locally

Introduction

This article explains several ways to clone your git project locally.

From Visual Studio

To get starting you need to clone the repository to your local machine. To find the repository login with your Microsoft account, Click on Clone and observe Clone URL. That’s what you are looking for:

Open Visual Studio 2013 or 2015, connect to your project and click on Clone this repository. Enter the local path where you want to store the project and press Clone button.

To add new files/presentations/code, in the cloned repository add them and then go to Team Explorer à changes. Enter a comment and click Commit and push. If you have untracked files add them to the project.

You can find more documentation about this topic on: https://msdn.microsoft.com/en-us/library/vs/alm/code/git/get-started

From Windows PowerShell

Open Windows Powershell. Go to the location where you want to clone your project. Type command:

Git clone repository_url:

Add your new file with command git add filename. Commit your file with git commit file name. Add to repository with your file with git push. To take files added by others perform a git pull. More documentation about this:

https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository

From GIT for Windows GUI

1.       To do this install it from: https://git-scm.com/download/win

Open GIT GUI:

More about GIT version control you can find in this book: Version Control with Git: Powerful tools and techniques for collaborative software development.

Happy testing and... make it green, becomes a dream :).

Build Triggers in Jenkins

Introduction

This article explains how you can trigger your builds in Jenkins.

Build Triggers

Open any build configuration and search for Build Triggers group.

Check Build periodically. In this filed you can enter values in this format: * * * * * where

1* MINUTES Minutes in one hour (0-59)
2* HOURS Hours in one day (0-23)
3* DAYMONTH Day in a month (1-31)
4* MONTH Month in a year (1-12)
5* DAYWEEK Day of the week (0-7) where 0 and 7 are Sunday

Examples:
0 8 * * * will trigger the build every day at 8 AM
0 8 * * 7 will trigger the build every Sunday at 8 AM

More about Jenkins Essentials you can find in this book: Jenkins Essentials

Enjoy the book!

Happy testing and... make it green, becomes a dream :).

Deleting your Test Plans from TFS

Introduction

This article explains how you can delete your test plans from versions >= TFS 2012 via Developer Command Prompt with witadmin.

Why like this?

Trying to delete the test plan from MTM or from TFS web UI is not possible.

So, In MTM2012/MTM2013/MTM2015, there is no direct way to delete a test plan. We need delete the corresponding work item using TFS command line options in command prompt in order to delete a test plan.

Developer Command Prompt

If you installed Visual Studio 2012/2013/2015 but you are not able to find the “developer command prompt” in your Windows 8/10 environment, the solution is simple. Go to folder: “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts” (12.0 varies depending on the VS version).

Run witadmin command

Then, you need to run your command for deleting the test plan:

witadmin destroywi /collection:http://<your server name>:8080/tfs/<your collection name> /id:<the id o the test plan you want to delete>

More about TFS 2013 you can find in this book: 
Professional Team Foundation Server 2013 (Wrox Programmer to Programmer)

Enjoy the book!

Happy testing and... make it green, becomes a dream :).

Agile Testing

A few days ago I started to read a book about testing: Agile Testing: A Practical Guide for Testers and Agile Teams.
The book is in the top 10, best books about testing, it is written by Lisa Crispin and Janet Gregory, testers with extensive experience in both traditional as well as agile projects, in large or small teams.

Below is an excerpt from the book that you might find interesting:

"WHAT DO WE MEAN BY AGILE TESTING?

You might have noticed that we use the term “tester” to describe a person whose main activities revolve around testing and quality assurance. You’ll also see that we often use the word “programmer” to describe a person whose main activities revolve around writing production code. We don’t intend that these terms sound narrow or insignificant. Programmers do more than turn
a specification into a program. We don’t call them “developers,” because everyone involved in delivering software is a developer. Testers do more than perform “testing tasks.” Each agile team member is focused on delivering a high-quality product that provides business value. Agile testers work to ensure that their team delivers the quality their customers need. We use the terms “programmer” and “tester” for convenience."

"WHOLE-TEAM APPROACH

One of the biggest differences in agile development versus traditional development is the agile “whole-team” approach. With agile, it’s not only the testers or a quality assurance team who feel responsible for quality. We don’t think of “departments,” we just think of the skills and resources we need to deliver the best possible product. The focus of agile development is producing highquality
software in a time frame that maximizes its value to the business. This is the job of the whole team, not just testers or designated quality assurance professionals. Everyone on an agile team gets “test-infected.” Tests, from the unit level on up, drive the coding, help the team learn how the application
should work, and let us know when we’re “done” with a task or story. An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization. While this might mean including specialists on the team, such as expert testers, it doesn’t limit particular tasks to particular team members. Any task might be completed by any team member, or a pair of team members. This means that the team takes responsibility for all kinds of testing tasks, such as automating tests and manual exploratory testing. It also means that the whole team thinks constantly about designing code for testability. The whole-team approach involves constant collaboration. Testers collaborate with programmers, the customer team, and other team specialists—and not just for testing tasks, but other tasks related to testing, such as building infrastructure and designing for testability.
The whole-team approach means everyone takes responsibility for testing tasks. It means team members have a range of skill sets and experience to employ in attacking challenges such as designing for testability by turning examples into tests and into code to make those tests pass. These diverse viewpoints can only mean better tests and test coverage.
Most importantly, on an agile team, anyone can ask for and receive help. The team commits to providing the highest possible business value as a team, and the team does whatever is needed to deliver it. Some folks who are new to agile perceive it as all about speed. The fact is, it’s all about quality—and if it’s not, we question whether it’s really an “agile” team. Your situation is unique. That’s why you need to be aware of the potential testing obstacles your team might face and how you can apply agile values and principles to overcome them."

Enjoy the book!

Happy testing and... make it green, becomes a dream :).

Bug Magnet - A 'nice to have' Chrome extension

Introduction

Bug Magnet it's an useful extension for testers that gives you the possibility of entering values for inputs in a web page and that can be helpful in your exploratory testing, via a right-click context menu.

 

How to Use it?

Very easily. Add your Bug Magnet to Chrome. Right click any input in your application and open Bug Magnet contextual menu. This will add common problematic values and edge cases to the context menu (right-click) for editable elements, so you can keep them handy and access them easily during exploratory testing sessions. Examples:
- valid/invalid emails

- sql injection

- html parsing

- numbers, etc

Happy testing and... make it green, becomes a dream :).

Linking your Selenium Tests to Microsoft Test Manager (2)

Introduction

Last time we talked about a way of linking selenium Mstests to MTM. This week we will see another way of linking an automated test with a MTM test plan by using tcm import tool (so we don't need to to this manually).

TCM Import

Here you have the link to MSDN documentation https://msdn.microsoft.com/en-us/library/ff942471(v=vs.120).aspx. 
The purpose of this tool is to import automated tests (selenium, codedui, unit tests, etc.) to a Test plan written in MTM (Microsoft test manager). The import will be done only for MSTests methods (not NUnit). The result of the import will create an work item of type Test Case in TFS, for every existing TestMethod in your projects. The example from the last post was this.

Here we have only one method named CodedUiTestMethod1, which, in fact contains Selenium code. 
In order to create a corresponding Test Case work item I did this:
- Opened Developer Command Prompt for VS2013 that you can find it in Visual Studio Tools folder (e.g. C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts for VS 2013)
- In cmd navigated to the location of your .dll with tests
- Run this command

tcm testcase /import /collection:https://myonlineproject.visualstudio.com/DefaultCollection

/teamproject:myProjectName /storage:LinkMTMSelenium.dll

- Now the Work item of type Test case with the name CodedUiTestMethod1 is created
- Associate this Test Case to a Project Plan in MTM

- Set your environment in MTM like described in the previous post
- Run your test from MTM from Test tab. Run will be run on the configured environment 

- Search results will be displayed at the end and the required 

- You will be able to see the test results also in VS Online

Happy testing and... make it green, becomes a dream :).

Linking your Selenium Tests to Microsoft Test Manager

Introduction

In this article we will write about how you can link your selenium web driver tests from Visual Studio to Microsoft Test Manager.

Why should we do this? Because with CodedUI you can run your tests only on a IE browser (even there is a plugin that allows you to run coded ui tests on FF/Ch, which is unfortunately not very stable). With selenium, you'll be able to run them much easier on different browsers.

What do you need for this:

- knowledge about Visual Studio Controllers and agents

- knowledge about TFS builds

- knowledge about MTM (Microsoft Test Manager) and how to set an environment

- Have some tools installed: Visual Studio 2013 Online

- know how to work with Selenium WebDriver with C#

- MSTest (not NUnit)to run the tests

Visual Studio Test Controllers and Agent

I'm not going to give you details about this subject because this is a complex one. But, in order to explain you this post, you need to know what MTM environment is. In order to run your automated tests on a specific page, you need to set an environment, which requires a controller that controls one ore more agents. For more details visit this link: https://msdn.microsoft.com/en-us/library/hh546460(v=vs.120).aspx.

Visual studio agent and controllers can be downloaded from here: https://www.microsoft.com/en-us/download/confirmation.aspx?id=40750.

Once you set your controller, you need to add an environment in MTM. To do this open MTM as an admin --> Lab center and create a new environment.
In Type and name, leave the default standard environment and give a name to this new env
In Machines enter the name of the computer where you want to install your agent that will execute the tests and that will be connected to a controller.

In Advanced, select the controller and check Configure environment to run UI tests = Web Client

Verify and restart computer. After restart you'll see a popup with your agent

MTM Build

Another important setting is the build for your automated testing project (with selenium tests).

A build for a MSTest project can be created from Visual Studio. Having your selenium web driver solution opened, go to Team Explorer --> Builds --> New Build Definition.

In Source Settings Add the Repository name:

Build Default -> if you use Visual Studio Online, you can leave it to Hosted Build Controller

Process --> set the path to your .sln solution

Run your build

Adding Environment and Build to MTM Test Plan

Once you have add your agent and build, you need to assign these two, to your test plan in MTM.
Open it, select your test plan, go to Organize and made the settings below.

Create your Selenium Test and Associate it to a Manual Test from MTM

Now you should create your selenium tests. To be much easier, instead new MSTest, create a new CodedUI test. Why, because you'll need (in order to run it from MTM) the CodedUI attribute for a class. Inspect the code below:

This will only open google home page. You can see the DeploymentItems attributes. They are required, in order to deploy chrome and ie drivers on the agent you'll run your tests.
After you created your test, you need to associate it to a dummy MTM test (or to an existing recording in MTM - see this link for more details: http://blogs.infosupport.com/testing-your-web-application-with-selenium-and-mtm-part-2/).
To associate Mstest to MTM test in Visual Studio (with the solution opened), go to TeamExplorer --> Work Items-->made a new query that will return all manual test cases written for this project --> open your manual tc --> go to Associated Automation and select your MSTest

Now you can start running your test from MTM. While the test runs, you'll see this in Agent Popup.

Happy testing and... make it green, becomes a dream :).