CSG. Аутсорсят тестирование!

Друзья, недавно мне в скайп постучался один хороший человек. Мы с ним общались года два назад по поводу большого сотрудничества. По независимым от нас причинам поработать тогда вместе не получилось, зато у меня теперь есть в контакт-листе Владимир. Очень толковый специалист.
Сейчас он со своей командой аутсорсит тестирование. Да, вещь нужна далеко не каждому. Но если вы:
1. Руководите отделом разработки в большой компании,
2. Ваши специалисты гуру в разработке вашего внутреннего продукта, каждый из программистов почти бизнес-аналитик, а бизнес-аналитики потихоньку учат программирование
3. И вам нужно качество (то, что QA), а нарушать идиллию и садить опытного разработчика писать тупые тесты не хочется,
4. А при том набирать "студентов" на написание тестов это лишний "геморрой",
то Владимир и его группа CSG сделают вам красиво.
В такой ситуации лучше "отдать деньгами". Отдайте написание тестовых сценариев на аутсорс профессионалам и все решено.
Про метрики и прочее всякое это вы лучше с ним сами пообщайтесь. Скайп вот - vl.snow
Еще есть презентация.

P.S.: Понятно, что это все типа рекламы (да, да, где мои миллионы), но тенденция в отечественном IT радует. Такие штуки, как аутсорс тестирования, нужно развивать. А, может, они и тестовыми инструментами к 1С владеть будут, все-таки 8.3? Кто знает?

1С:Центр управления производительностью

Если вы почему-то не в курсе, что есть такой продукт, обязательно посмотрите хотя бы описание на сайте 1С.

Основные задачи, которые могут быть решены при помощи ЦУП:

• Анализ и интегральная оценка текущей производительности работающей многопользовательской информационной системы:
  
  • Как работает система?
  • Имеются ли проблемы производительности?
  • Можно ли повысить производительность? 
• Сбор и хранение информации о динамике производительности системы:
  
  • Как менялась производительность системы с течением времени?
  • Как менялась производительность системы при внесении каких-либо изменений? 
• Поиск и анализ «узких мест» в коде конфигурации. Получение детальной технической информации обо всех проблемах производительности, имеющихся в системе с целью дальнейшей оптимизации:
  
  • Какие проблемы производительности имеются в системе и насколько они серьезны?
  • Какие проблемы следует решать в первую очередь?
  • В чем конкретно заключается каждая проблема?
  • Какие объекты метаданных и строки кода конфигурации следует оптимизировать для того, чтобы решить данную проблему? 
• Регламентный мониторинг производительности системы с автоматическим контролем значений показателей производительности и реакцией на их изменения. 

Эти задачи могут быть решены как для системы, активность в которой эмулируется при помощи Тест-центра, так и для системы, в которой работают реальные пользователи.

Одним из типичных применений "Центра управления производительностью" является анализ производительности и оптимизация работающей многопользовательской информационной системы.

UPD.: И, конечно, не могу не привести замечательную статью по настройке на infostart.

Тестирование в 1С

Несколько ссылок на тему.
Юниттестирование на восьмерке. Очень сырой драфт.
Тестирование разработок на платформе 1С. Управление данными.
Удобство разработки и тестирование.

Идеалисты против реалистов

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

забывают - значит, в этом для них нет ценности (низко приоритетная задача). Такая себе, ествественная автоматическая оптимизация (не срочно, не важно => вообще не делаем). "Вам, менеджмерам, надо - вы и собирайте, а мне голову не морочьте".

А если и нагрузка у тестировщиков близка к 100%, то тем более на такие "мелочи" не находят времени.

Из моего опыта (касательно test case design/review): помогает peer review with checklist (шпаргалка - что именно должно быть заполнено): таким образом за тест кейс отвечают уже не один, а два человека, причем в 1ую очередь спрашивают с peer reviewer'a: почему поля и данные (четко указанные в чеклисте), пропущены.
Плюс ревьюеры могут потом рассказать, кто лучший и кто худший в этом процессе (сколько раз возвращали они тест кейсы на доделку) - и тут адресно можно помочь людям.

Проблема не в людях, а в системе.

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

Да, и все что можно собрать автоматически (дата создания, обновления, прохождения, и т.д.) - не надо перекладывать на людей, а возложите эти функции на инструмент.

Еще вариант: сделайте ретроспективу с тестировщиками - объясните зачем вам то, что вы требуете, и дайте им возможность предложить альтернативы, которые по их мнению будут работать.

Через некоторое время выясняется, что тестировщики - вьетнамцы.
И сразу появляется еще один ответ в тему:

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

Вопрос на сообразительность: как вы думаете, чей способ окажется эффективнее?
И вопрос на подумать: а вы уверены, что в вашей компании вас не считают "вьетнамцем"? =)

Кто такие тестировщики?

Уважаемый w_bf выложил забавное видео о тестировщиках.



P.S.: Я обещал себе не высказываться публично о тестировщиках, потому никак комментировать не буду, но видео и комментарии в блоге w_bf наводят на мысль о том, что следует сесть и написать большой пост о сабже, чем "феерически расставить точки".

Корпоративный инструментальный пакет

Кое-какие общие мысли о производительности и начало о КИП на сайте Вячеслава Гилёва:

Тренинг "Разработка через тестирование"

Компания SCRUMguids приглашает на тренинг "Разработка через тестирование".
Думаю, будет интересно.

Вебинар: "Что такое тестирование?"

Учебный центр Luxoft проведет вебинар на тему "Что такое тестирование?". Поскольку тестирование это важная часть разработки, то всем рекомендую.
Зарегистрироваться можно на сайте учебного центра.

Немного о сценарном тестировании

На замечательном сайте www.software-testing.ru есть небольшая статья о 1С:Сценарное тестирование

И мы не лыком шиты.

Для 1С тоже есть инструменты тестирования (и TDD и юнит-тесты). Например, FuncTest Федора Езеева предоставляет хорошие возможности для тестирования проектов 7.7
Для 8.x есть продукт "1С:Сценарное тестирование 8".

Жаль, что я серьезно не задумывался о тестировании раньше. Думаю, что я не буду внедрять тестирование в моем текущем проекте (на котором, кстати, и без того было опробовано много хороших практик), а начну использовать сразу на новом.

Обезьянки, роботы и почему QA не Agile?

Открытый семинар по тестированию оказался очень интересным.
Начнем с того, что основной темой семинара было то, что QA-шникам (Quality Assurance) надоело что их все чмырят и теперь они пропагандируют мысль о том, что они - часть команды не менее важная, чем все остальные и равноправная со всеми. И, конечно, ответственность за результат теперь лежит на всей команде. При этом часто звучала мысль о том, что девелоперы в свободное время могут помогать тестерам писать автоматизированные тесты, и таким образом один тестер может обслуживать нескольких девелоперов лишь определяя общую структуру тестов. Ну, как их можно не чмырить и рассматривать, как равноправных членов команды, если предложение сделать так, чтобы несколько тестеров обслуживало одного девелопера в свободное время помогая ему писать код ни разу не было даже упомянуто. =)

На самом деле то, что я описал выше, конечно же шутка. То есть, на семинаре, конечно, все это было, но так как проводил его матерый девелопер (и еще этот... коучер!), то легко можно понять зачем все это делалось. А все дело в том, что QA, конечно же нужны. Причем нужны они и в Agile-командах тоже. Но гибкие, динамичные подходы agile-разработки опережают консервативных QA. Agile-подход требует больших знаний от QA, требует развития. Но, как сдвинуть QA с мертвой точки, чем его мотивировать, если его все чмырят? Вот тут и нужно сделать так, чтобы QA чувствовал себя частью целой команды. В конечном итоге несмотря на очевидное неравенство ролей тестера и девелопера их взаимодействие, когда тестер считает себя равным, а девелопер перестает относиться к тому предвзято, повышает эффективность команды. И это хорошая практика.

И в завершение хочу привести кое-что с самого семинара:

• Во-первых совершенно замечательная презентация Макса Дорофеева "Обезьянки против роботов".
• Во-вторых точное определение проектов, где не ведется тестирование или ведется вручную: "Регрессионная спираль смерти". Очень обнадеживает, не так ли?
• В-третьих я узнал о существовании таких инструментов, как Selenium и системы тайм-менеджмента Pomodoro. И с тем и с другим, я считаю, следует ознакомиться, а может и использовать.
• Ну и, наконец, наблюдение о том, что среди тестеров очень много девушек (и есть даже очень милые). По-моему это прекрасно.

И немного фото:

Открытый семинар по тестированию

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