QA: Estimation Techniques

There is bunch of techniques which can be used to estimate QA work.

• Industry averages, metrics, predictive models. Usually it is 30% of development work, but this is the most tricky estimates, for example developers changed store procedure this is approximately 5-8hrs of work for developer, so QA will be 1.5-2.5hrs. For QA this could mean to do full regression of application because this store procedure is using across application.
• Tester-developer ratio. This technique usually based on organization history. For example 4 developers generate work for 1 QA engineers, so QA time will be 0.25 of full development work.
• Experience (intuition, guess) based estimate. 
• Team estimation sessions. Estimates can be more accurate estimates when dev lead and BA participate in estimation sessions, more details can be provided and took into account.
• Test case based technique. This estimates can be used only when test cases created, or you can guess how many test cases you will create.
• Bottom-up approach of estimates. Work is breaking down on tasks, each task can be estimated individually and sum of tasks will be overall project estimates.

In addition to provided techniques add additional time for bugs creation and verification, for updating test case, and 30% of estimated time add as risks. Usually when QA starts estimate functionality no one know how this functionality will behave at the result. Better way to overestimate and use less time, than underestimate and use much more time of testing under pressure and not founded bugs.

StyleCop integration for .NET projects

Why it is important?

Coding conventions serve the following purposes:

• They create a consistent look to the code, so that readers can focus on content, not layout.
• They enable readers to understand the code more quickly by making assumptions based on previous experience.
• They facilitate copying, changing, and maintaining the code.
• They demonstrate C# best practices.

Code style recommendations

As the reference for your coding conventions, please use Microsoft guidelines (https://msdn.microsoft.com/en-us/library/ff926074.aspx).  If they will conflict with this document, please use rules from the document.

Naming convention 

Entity	Pattern
Types and namespaces	UpperCamelCase
Interfaces	IUpperCamelCase
Type parameters	TUpperCamelCase
Methods, properties and events	UpperCamelCase
Local variables	lowerCamelCase
Local constants	lowerCamelCase
Parameters	lowerCamelCase
Fields (not private)	UpperCamelCase
Instance fields (private)	_lowerCamelCase
Static fields (private)	_lowerCamelCase
Constants fields (not private)	UpperCamelCase
Constants fields (private)	UpperCamelCase
Static read-only (not private)	UpperCamelCase
Static read-only (private)	UpperCamelCase
Enum members	UpperCamelCase
All other entities	UpperCamelCase

Try to give names for entities without any abbreviations. Name should describe entity’s purposes. 

Using statement

1. Please put “using statement” outside of namespace.

using System;  
using System.Text;  
using System.Web.Mvc; 
 
namespace SampleProject.Controllers  
{  
}

2. System usings should be placed first, then all others
3. Usings should be sorted alphabetically.

Return statement 

1. Please separate return statement from other code with single empty line.

public ActionResult DashBoard()  
{  
    DoSomething();

    return View();  
}  

Curved brackets

1. Curved brackets should be places for “foreach”, “if”, “for”, “while”, etc. all the time.

if (someVal)  
{  
   DoSomething();  
}  

How to implement rules if you are at the beginning of the project?

We assume that all team members should follow the code guidelines without any exceptions. So, know we have to think how we can achieve that statement. In general, all the cases will lead you to the following two cases.

1. Rely on people
2. Rely on tools

What does it mean to “Rely on people”? By this phrase, we assume that all team members will be responsible for following code style rules. There are some procs and cons of this approach. Although it is easy to start using it, there are some disadvantages of such approach. Among them – additional time for code style review and non-strict control of following the rules by all team members.

In such situation, tools can help the team to follow code style guidelines. Therefore, in this article, we will look at StyleCop tool (https://stylecop.codeplex.com/).

StyleCop

Installation

To install StyleCop on your machine you need to download installer from the https://stylecop.codeplex.com/ and run. Alternatively, you can open “Extensions and Updates” window in Visual Studio and install any appropriate extension, e.g. “Visual StyleCop”.

Create settings file

To create StyleCop settings file just right click on project and select “StyleCop settings”.

Select rules you want to follow and click “Apply”. After that, Settings.StyleCop file will appear in project folder.To download settings file click on following link Settings.StyleCop.

Enable StyleCop on build

1. Open NuGet Package Manager for project you would like to validate.

2. Search for “StyleCop.MSBuild” package and install it.

3. Create file with rules, which are acceptable for your team. 

4. Import that file to the project.

5. Build the project. As the result, you will see warning in “Error List” window.

Just described behavior is kind of soft behavior, because code compiled and application would work. To fix such situation you can do following things:

• In project’s properties change “Treat warning as errors” property
• Install “StyleCop.Error.MSBuild” NuGet package

After implementation all the steps above, you can be sure that everyone will follow the code style rules.

How to start using styling rules if you already have “billion” files?

It is no secret that majority projects does not have styling standards and we have to live with it. Let’s think how we can improve such situation. 

Assumptions:

• At the begging do not allow to fail build on style settings validation
• After some period build should fail on code styling issue

I would like to recommend following steps to rewrite all code according style standard:

1. Create styling rules for your project and introduce Settings.StyleCop  with them
2. Install on each developer’s machine StyleCop or another appropriate tool
3. Create milestones with percentage of cleaned files
4. Ask developers to change code according style rules in files, which they working on during current iteration
5. Allocate time for code style fixes as technical debt
6. Track progress
7. Start failing build on style issues

Approximate roadmap for code style changes

Step 1

The step's approximate time frame is 0 - 6 week. During step 1 team concentrates on following:

1. All team members have installed StyleCop tool on their machines
2. While working on some area teammates do code style refactoring
3. While code review first step to run StyleCop against created rules
4. Team will concentrate on “main” libraries
5. Team will allocate time for style fixes as part of technical debt stories

Step 2

The step's approximate time frame is  6 - 12 week. During step 2 team concentrates on following:

1. We will enable code style checks on build. “StyleCop.MSBuild” package will be installed to libraries we would like to validate
2. Code style warnings will appear
3. Steps 1, 2, 3, 5 from first row
4. Libraries coverage increased
5. We will track number of style warnings

Step 3

The step's approximate time frame is  from 12 week. During step 3 team concentrates on following:

1. Warnings replaced with build failures. By this moment, we assume that all files will have appropriate style. 
1. In project’s properties change “Treat warning as errors” property
2. Install “StyleCop.Error.MSBuild” NuGet package
2. Deprecate style review on code review sessions

FAQ

How to apply settings for solution?

It is easy when you have only one file with rules and all projects in solution have reference to that file. StyleCop allow us to do that. Put file with rules in the root folder of the project. Then add to each projects’ folder Settings.StyleCop file with following lines.

<StyleCopSettings Version="105">  
  <GlobalSettings>  
   <StringProperty Name="LinkedSettingsFile">..\Settings.StyleCop</StringProperty>  
   <StringProperty Name="MergeSettingsFiles">Linked</StringProperty>  
  </GlobalSettings>  
</StyleCopSettings>  

LinkedSettingsFile – path to the main settings file.

How can I extend existing rules?

First, you can try to find some already written rule extensions. E.g. StyleCop+ (StyleCop+ is a plug-in that extends original StyleCop features. It offers you a variety of rules for building C# code style that best suits your needs.) (https://stylecopplus.codeplex.com/)

Second, you can write your own rule. 

Интеграция OpenCover в .NET проект.

Что такое OpenCover?

OpenCover - это инструмент с открытым кодом, который показывает разработчикам .NET приложений на сколько существующий исходный код покрыт unit-тестами. Ссылка на официальный сайт - https://github.com/sawilde/opencover.

Интеграция OpenCover

Для того, чтобы интегрировать OpenCover в проек, для начала необходимо установить:

1. NUnit.Runners
2. OpenCover
3. ReportGenerator

Данную процедуру можно сделать при помощь Library Package Manager (NuGet). Сперва необходимо добавить поддержку востановления NuGet-packages для .sln-файла проекта.

Далее переходим в панель управление NuGet-packages.

В поле для поиска вводим поочередно название NuGet-package и устанавливаем его. В итоге в .nuget папке должен появиться файл packages.config с содержимым:

<?xml version="1.0" encoding="utf-8"?>
<packages>
    <package id="NUnit.Runners" version="2.6.3" />  
    <package id="OpenCover" version="4.5.3207" />  
    <package id="ReportGenerator" version="2.0.0.0" />
</packages>

Файл packages.config не появляется в файле проекта после добавления указанных выше NuGet-packages, поэтому можно добавить его руками.

Тестовой проект, в который мы интегорируем OpenCover, имеет следующую структуру:

Так как OpenCover не может сгенерировать coverage-отчет без unit-test runner, необходимо создать .bat файл, который выполнит все наши тесты (RunTests.bat). Содержимое RunTests.bat:

..\..\..\..\packages\NUnit.Runners.2.6.3\tools\nunit-console.exe OpenCoverSample.Core.UnitTests.dll /noshadow

После того, как мы научились выполнять unit-тесты, мы можем построить coverage-отчет. Для этого создадим RunOpenCover.bat файл со следующим содержимым:

..\..\..\..\packages\OpenCover.4.5.3207\OpenCover.Console.exe -target:RunTests.bat -register:user -filter:"+[OpenCoverSample*]* -[OpenCoverSample.Core.UnitTests]*"

..\..\..\..\packages\ReportGenerator.2.0.0.0\reportgenerator.exe -reports:results.xml -targetdir:coverag

.\coverag\index.htm

Так как мы не хотим, чтобы в coverage-отчет входили сборки с unit-тестами, мы добавили фильт, который будет игнорировать их.

Для файлов RunOpenCover.bat и RunTests.bat атрибуту Copy to Output Directory ставим значение "Copy always".

Далее добавим ссылку на проект с unit-тестами в проект OpenCoverSample .CoverageReportGenerator.

В OpenCoverSample.CoverageReportGenerator Program.cs добавляем код, который будет генерировать отчет:

namespace OpenCoverSample.CoverageReportGenerator

{

  class Program

  {

    static void Main(string[] args)

    {

      var process = new System.Diagnostics.Process();

               var startInfo = new System.Diagnostics.ProcessStartInfo

      {

        WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden,

        FileName = "RunOpenCover.bat",

        RedirectStandardOutput = true,

        UseShellExecute = false

               };

      

      process.StartInfo = startInfo;

      process.OutputDataReceived += (sender, a) => Console.WriteLine(a.Data);

      process.Start();

             process.BeginOutputReadLine();

             process.WaitForExit();

          }

  }

}

Компилируем приложение OpenCoverSample.CoverageReportGenerator и запускаем. В результате получаем coverage-отчет:

Файл с тестовым проектом, можно скачать по ссылке OpenCoverSample.zip

Использование StyleCop

Начало

Многие программисты за свою карьеру успели поработать на проектах, которые разрабатываются не один год. И все представляют какие страшные вещи можно найти в проекте, процесс написания которого был плохо поставлен.

Все началось, что к нам на проект, очень похожий на вышеупомянутые, пришел Женя. Он уже работал со StyleCop, поэтому идея интеграции StyleCop в проект принадлежала ему.

Шаги для интеграции

1) Мы начали с того, что разработали руководство по написанию кода, в которое попытались включить лучшие практики, которые существуют в мире разработки .NET приложений. За основу были взяты C# Coding Conventions (C# Programming Guide), немного доработаны в связи со спецификой нашего проекта и утверждены большими дядями типа Principal Solution Developer =).

2) Установка и использование StyleCop. Скачать и установить StyleCop можно пройдя по ссылке http://stylecop.codeplex.com/

Установка завершилась успешно, теперь можно открыть Visual Studio и попробовать поработать со StyleCop. Для начала нам необходимо создать файл с настройками, по которым будет проходить валидация существующего кода. Выбираем "StyleCop Settings" нажав правой кнопкой по проекту.

После того, как мы выбрали "StyleCop Settings" перед нами появится окно, в котором можно будет выбрать правила, которые подходят для нашего проекта.

После того, как правила были выбраны, можно запусить StyleCop и проверить, удовлетворяет ли проект, выбранным правилам. Для этого необходимо выбрать файлы, которые вы желаете провалидировать и запустить StyleCop.

3) Более продвинутая настройка StyleCop в соответсвии с правилами написания кода, принятых на нашем проекте. 

Нам повезло, потому что нам не пришлось добавлять правила, которых не было в "коробке", поэтому для того, чтобы StyleCop валидация для нашего проекта проходила в соответсвии с нашими договоренностями по форматированию кода, мы удалили некоторые правила из стандартного набора. Файл с нашими настройками, можно скачать по ссылке Settings.StyleCop. 

Для того, чтобы применить данный файл к проекту, необходимо скопировать его в директорию, в которой находится файл проекта (*.sln)

Если ваш проект состоит из нескольких сборок и вы хотите, чтобы у вас был один файл со StyleCop настройками, в папку с проектом необходимо добавить файл Child Project Settings. В данном файле нужно указать путь к "Settings.StyleCop" файлу, который вы добавили в корень проекта.

Если случилось так, что набор предустановленных правил для вас не работает, StyleCop имеет возможность расширить набор правил. Узнать как это сделать можно по пройдя по ссылке: http://scottwhite.blogspot.com/2008/11/creating-custom-stylecop-rules-in-c.html

4) Как заставить программистов следовать правилам

StyleCop предоставляет возможность генерировать "Warning" или "Error" в случае, если код не соответсвует правилам. Мы долго спорили на тему, что же все таки лучше для нашего проекта и пришли к выводу, что "Warning" это хорошо, но данный подход не работает в большинстве случаев. Да и свалившийся билд подстегивает писать код красиво =). 

Для того, чтобы интегрировать StyleCop в процесс сборки проекта необходимо:

1. Установить StyleCop.MSBuild. Данную операцию можно проделать через "Manage Nuget Pacakges" в Visual Studio.
2. Добавить в файл проекта (*.csproj) свойство <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>

    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>

    ...    

    <AssemblyName>SampleProject</AssemblyName>

    <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>

  </PropertyGroup>

Валидация существующих файлов

В нашем проекте было около 10 тысяч файлов, которые не удовлетворяли разработанным нами правилам. Приведение всех файлов к определенному формату могло занять кучу времени не только программистов, но и тестировщиков. Поэтому нам была необходима возможность постепенного изменения существующих файлов.

StyleCop предоставляет такую возможность. Более подробно можно прочитать в документации Using StyleCop on Legacy Projects. Для того, чтобы игнорировать валидацию для конкретного файла необходимо нажать правой кнопкой мыши по файлу и выбрать в меню "Exclude From StyleCop".

К сожаление данное решение работает только для выбранный файлов и является крайне неудобным, если в проекте их много.

Именно для такой ситуации команда StyleCop предоставляет небольшое приложение, которое может обновить файлы из указанного проекта. Скачать данное приложение можно по ссылке ExcludeFromStyleCop.

Заключение

StyleCop отличное средство для того, чтобы привести стиль написания исходного кода в порядок. На мой взгляд данное средство должно интегрироваться в проект со старта. Потом будет сложнее все поправить.

Правила настройки системы контроля доступа к исходному коду программы.

В проектах, над которыми работает большое количество людей, важно огранизовать работу таким образом, чтобы разработчики следовали определенному процессу в работе над исходным кодом.

Данное соответсвие может достигаться несколькими способами:

1. Огранизационный. (Разработчики договариваются между собой, что они будут следовать определенному процессу)
2. Технический. (Для системы контроля версий вводятся правила, которые не позволяют добавить код в систему, пока разработчик не выполнит все атрибуты процесса)

Основным приемуществом огранизационного подхода является простота реализации. Данный подход будет работать в относительно небольшой команде опытных разработчиков, которые никогда ничего не забывают и делают все правильно =). Утопично, не правда ли... ?!

Рассмотрим, второй способ, который на мой взляг является наиболее действенным в реальной жизни. Выделим правила, которым необходимо сделовать при настройке системы контроля доступа к исходным кодам.

1. Не разрешать добавлять код, разработчик не указал комментарий к изменению. Комментарий должен быть понятным и отражать проделанную работу. Технически выполнить данное требование можно путем создания правила, которое будет запрещать добавлять код с пустым комментарием или с комментарием содержащим менее 5 слов.
2. Добавление исходного кода должно быть привязано к задаче из списка задач для выполнения. К примеру это можно огранизовать в следующем виде:  

• Создать определенный формат: Feature #(XXX): //Comment; Bug #(XXX): //Comment; etc;
• Создавать ссылки на исходный код в системе контроля дефектов/задач. 

Возможны еще более делатальные настройки, которые будут специфичны для конкретного проекта, но на мой взгляд, указанные выше два правила должны быть в каждом проекте, если команда заботится о возможности отлеживания измений исходного кода.