Оценка трудозатрат на тестирование - зачем нам это надо?

Уверенна, что перед каждым тестировщиком когда-либо стояла задача оценить своё время на тестирование той или иной фичи. Я даже могу на 100% сказать, что к каждому подбегал Project Manager (или QA Test Manager) с взъерошенными волосами и вопросом: "Прикинь быстренько время на тестирование вот этого функционала, который выпустят сегодня вечером разработчики". И ты сидишь, пытаясь оценить эту ерунду, не понимая, зачем всё это нужно. Тем более в эту оценку порой и не укладываешься. В этой статье я подробно опишу подход, как лучше, а может быть и даже правильно, оценивать трудозатраты на проект.

Во-первых, зачем нужна оценка. Ведь можно просто оговорить примерные сроки и уложиться в них.
Это нужно для Заказчика, а точнее для обоснования запрашиваемых денег перед Заказчиком. Потому что Заказчик:
1. Не понимает, откуда взялась такая цифра на тестирование. Почему вы делаете работу за 100 рублей, а ваши конкуренты за 50? (Тут ответ простой: скорее всего конкурент предлагает сделать далеко не все работы.)
2. Не видит всю декомпозицию работ. И в результате половину работы совсем забыли оценить: доработка тест-кейсов, создание методики, пользовательских документов и т.д.
3. Не знает, кто будет работать и какие виды работ будут выполнены.

Во-вторых, необходимо всегда и для каждого проекта:
- Определить сроки;
- Определить объем работ;
- Определить ресурсы;
- Рассчитать стоимость.
Потому что все перечисленные пункты нужны для того, чтобы понять "выгодность" проекта,  готовность компании (ресурсы) этот проект выполнять.
Но обычно оценки неверные, потому что:
- нет плана работ;
- нет документации или знания о системе;
-  ожидания Заказчика и исполнителя противоречивы.
Такое бывает, когда под давлением Заказчика Исполнитель не может обосновать свою оценку. Поэтому нужно уметь обосновать, каждый пункт аргументировать.

А теперь перейду непосредсвенно к оценке.
. Прежде чем оценивать проект необходимо:
- создать шаблоны - опросник для клиента, что он хочет видеть в проекте, согласовываем видение сторон; какие виды работ будет включать каждый пункт (подробно расписываем); определяем сумму, в которую должны уложиться. На выходе должен получиться документ с описанием систем и функций, процессов и взаимодействие между процессами.
- выделяем технического специалиста, ответсвенного за оценку (pre-sale consultant).
- выделяем эксперта, согласующего все оценки (опытный человек с производства).
На этом этапе следует четко определить, что нужно обязательно проходить эту процедуру. Нельзя просто подойти к какому-то специалисту и "быстренько" всё оценить. А потом выяснится, что всё уже показали и согласовали с клиентом. Нельзя взять человека, который ни разу не занимался оценками и сказать - а давай-ка ты сейчас оценишь трудозатраты.

Вот когда мы очень хорошо выполнили п1 (создание шаблонов), приступаем к черновой оценке, а точнее к определению шаблонов для оценки. Определяем единицу измерения - тест кейс, число тест кейсов для проверки функционала, виды тестирования и глубину тестового сценария. Исходя из этого считаем:
- время на написание тест кейсов и тест планов;
- длительность прохождения тест кейса. Не надо брать длительность прохождения самого большого или самого маленького тест кейса, потому что оценка выйдет очень грубой.
- длительность прохождения по одного методу тестирования;
- длительность на написание отчета (или отчетов) по тестированию;
Необходимо учесть, что время на занесение дефекта в BTS не расписывается, а включается в время прохождения тест кейса. Оно будет больше, и это необходимо заранее сообщить Заказчику, чтобы не возникало вопросов.
К черновой оценке добавляем этапы работ и состав команды. И самое главно - РИСКИ, включающие в себя основные пункты как квалификация сотрудников, которая у всех разная, налаженность коммуникаций и т.д.. Их необходимо включать в каждый пункт черновой оценки. Если в результате мы вышли за лимит проекта, то оценки следует откорректировать и переоценить, иначе все труды приведут к тому, что проект окажется не выгодным и принесет больше расходов, чем доходов.
И....СОГЛАСОВАНИЕ. После этого этапа приступаем к работе!

Каждый метод составления оценки трудозатрат имеет свои достоинства и недостатки:
+ прозрачная структура расходов;
+ снижение рисков проекта;
+ четкое обоснование выполняемых работ.

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

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

PS: погрешность оценки всегда не должна превышать 20%.

Надеюсь, эта статья была полезной для Вас.

Необходимые вопросы на собеседовании

Не один раз поднимался вопрос, что спрашивать на собеседовании у работодателя. Стоит ли вообще это делать?
Многие боятся, стесняются или просто забывают это сделать. Не следует воспринимать собеседование как "игру в одни ворота". Это разговор двух равных партнеров. Человек, с которым вы разговариваете для вас ещё никто, пока он - просто собеседник, предлагающий предложение. Не стоит выставлять себя просителем. Ведь работодатель тоже заинтересован в вас как в ценном работнике. Это ещё большой вопрос, кому выгоднее это собеседование. Не надо робеть перед работодателем и выставлять себя просителем. Но и перетягивать одеяло на себя тоже не стоит.  Ведь Ваша цель - показать себя с лучшей стороны, заинтересовать не только работодателя, но и себя!!! Да-да, именно себя.  Необходимо взвесить все преимущества компании, так сказать "все за и против", все достоинства и недостатки. Стоит ли покупаться на высокую зарплату? Ещё ведь не известно, что под ней скрывается? Возможно работа 7 дней в неделю или работа по 60, а то и больше часов в неделю, или работа круглый год без отпусков? Вот поэтому после того, как Вы показали себя с лучше стороны при техническом собеседовании, необходимо показать себя с лучше стороны в информативной части. Поверьте, такие вопросы не введут в ступор работодателя, а покажут Вас с более выгодной стороны. А чтобы не забыть их в панике (или от счастья), запишите в блокнотик все необходимые вопросы и ставьте пометку. Можно по ходу собеседования ставить пометки в нем, чтобы лучше представить мнение о компании. Вот некоторые из них (список может быть дополнен или наоборот, сокращен):

Карьера и оплата

1. Какие перспективы карьерного роста? - Тут необходимо заранее для себя определить, кем вы хотите стать в компании, существует ли у них требуемая позиция.

2. Что будет входить в мои обязанности? - будут ли они Вас устраивать? Сочетаются ли с первым вопросом.

3. Каковы самые важные умения и навыки необходимы сотруднику в данной должности?
4. Что выгодно отличает вашу компанию от конкурентов?
5. Как Вы предпочитаете общаться с командой?
6. Через какое время повышается зарплата и на сколько? Как часто?
7. Есть ли бонусы и от чего зависит их получение?
8. Бывают ли корпоративы?
9. Бывают ли перерывы в работе для отдыха? Возможно в компании предусмотрены корпоративные игры.
10. Как строится рабочий день сотрудника на этой должности?
11. Сколько часов в неделю предстоит работать сотруднику, желающему достичь успеха в данной должности?
12. Условия работы?
13. Бывают ли переработки? Как оплачиваются?
14. Сколько времени длится испытательный срок и какая оплата в это время? Будет ли повышение зарплаты после испытательного?
15. Сколько человек в отделе?
16. Есть ли столовая (внутри компании) или приходится ходить есть куда-то?
17. Оплачиваются ли обеды и если да, то на какую сумму?
18. Есть ли ДМС? Какие условия и на какую сумму?Для себя или для семьи тоже?
19. Оплачивается ли проезд?
20. Есть ли командировки? Если есть, то как часто? Сколько дней в месяц/в год? В какие страны? Как оплачиваются командировочные дни?
21. Предоставляет ли фирма бесплатное посещение бассейна, спортзала (других секций)?
22. Направляет ли фирма на какие-либо курсы? Как оплачивает?
23. Проводятся ли семинары, конференции?
24. Существуют ли выплаты при значимых жизненных событиях ( свадьба и т.д.

25. Отгулы - за свой счет или с возможностью отработок?
26. Больничные - оплачиваются по закону или нет?
27. Выплачивается ли вовремя зарплата или бывают задержки? Сколько раз в месяц (по каким дням)?
28. Зарплата «чёрная» или «белая»? Выдаётся наличными или в банке? Кто оплачивает банковскую карту?
29. Зарплата(сумма) - если не оговаривалось ранее.

Отпуск

30. Продолжительность отпуска в год?

31. Через какой промежуток времени его можно взять?

32. Можно ли взять его сразу или только по частям? На какие части можно разбить

33. Выплачивают ли отпускные? Как выплачивают (до или после)?

34. Если не берёшь отпуск, то он прогорает? Можно ли взять деньгами и не ходить в него?

Рабочее время

35. Со скольки до скольки?

36. Есть ли возможность работать по гибкому графику (раньше приходить и раньше уходить и наоборот)?

37. Если обедаешь не отрываясь от работы, можно ли уходить на 1 час раньше?

38. Бывают ли случаи работы в выходные («авралы»), оплачивается ли такая работа и как?

39. Сколько рабочих дней в неделю?

И многие-многие другие необходимо записать в блокнот и не бояться спросить.

Резюме тестировщика на английском

Решила опубликовать пример резюме на английском. Думаю, многим пригодится:
1. Во-первых, конструкция.
2. Во-вторых, язык - английский.
3. В-третьих, а вдруг поступят интересные предложения?! :)
4. В-четвертых, да просто так.

Комментария, пожелания, все положительные и отрицательные эмоции очень приветсвуются (как в блоге, так и в гугле, где опубликован документ) дабы довести до совершенства резюме, которое может пригодиться как шаблон и на русском языке. Возможно, кое-что доработаю и подправлю в скором времени, но основа вряд ли изменится. Вот ссылка:

https://docs.google.com/document/d/1AfHhLEa3Y9cUMIxa2_2X60j4eEON4bsleDSMn5Q28HU/edit

ЗЫ: в других городах работу не рассматрива, только в Ижевске.

Создание тестовой документации on-line

Недавно обнаружила довольно интересный сервис по созданию тестовой документации: sitechco.ru. Пока ещё не довелось испробовать в действии, но на первый взгляд кажется довольно приличным. Что тут можно сделать?
1. Создать множество проектов, на которых работаешь.
2. Создать задачи по проектам с фильтрами: исполнитель, сроки, готовность. Необходимая штука для тест-менеджеров.
3. Создание тест-планов + импорт.
4. Создание чек-листов и отчетов + импорт. (Интересно, на сколько подробно можно разбить и какая структура?)
5. Проведение тестирования по чек-листу.
6. А также будет возможность приглашать пользователей к проекту с различными правами доступа.

Обязательно займусь тестированием сервиса и отпишусь о результатах. Мне думается, что сайт будет просто необходим для тест-лидов, тест-менеджеров для распределения и ведения задач.

Нагрузочное тестирование JMeter

Было актуально не так давно для меня:
http://habrahabr.ru/company/luxoft/blog/146988/

Жалко, что статья не появилась чуть раньше.

PS: в будущем точно пригодится!

Как мы разбились на команды

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

Когда я только пришла, нас определили на проект и предложили объединиться команде в одной комнате. Что и было сделано. Но в комнате у нас сидят не только те, кто участвует в проекте, но и просто слушатели, незаинтересованные лица. Проводились ежедневные митинги по скайпу несмотря на то, что вся команда сидит в одном городе и в одном офисе. Что здесь лишнее?
На протяжении всего процесса у нас были "недопонимания" (пусть называется так) между разработчиками, тестировщиками и аналитиками. Это заключалось в следующем: работа разработчиков и тестировщиков происходила одновременно, не было четкой организации процесса, из них постоянно требовалось выпытывать информацию обо всём, даже о предстоящем новом билде. С бизнес-аналитиками тоже случились трудности: обновленные документы выкладывались на шару, а запрос об обновлении требовали писать либо в скайпе, либо на почту, потому что не все могли услышать бизнес-аналитика (кто в наушниках, кто спал...да мало ли что!). И вот тут у меня рушится представление о совместимости команды в одном помещении. Зачем мы все тут собрались? Мы с таким же успехом могли просто находиться на разных этажах, в разных комнатах, ведь вся информация поступала и фиксировалась посредством интернета, все вопросы регулировались не при личной беседе, а посредством скайпа. Зачем? Мы же в одном помещении, на одном этаже. Мы и так должны слышать друг друга и понимать. Зачем устраивать ежедневные митинги и спрашивать кто чем занимался, если мы и так все вместе, все рядом?

На прошлой работе было так же. Нас просили разбиться "по звездочкам" (разработчик, тестировщик, интегратор), хотя проектный менеджер (он же и бизнес-аналитик) находился далеко за океаном. У разработчиков одни вопросы, у тестировщиков другие. Письма пишем разные. Для чего мы тогда разбились, если основа проекта не с нами и нам в любом случае надо устраивать митинги по телефону или скайпу? Чтобы лиду было проще увидеть команду в одной комнате, а не искать по всем кабинетам?

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

Переезд и разбиение команды на группы

Ну вот мы наконец-то и переехали в отличный офис на 10 лет октября :) И вот такой у нас вид:

 

Жалко, что только с крыши....

Но сейчас не об этом....перед переездом мы были разбиты на команды: две команды имплементации, команды ядра, саппорта и 2 интегратора. Мне такое разбиение не нравилось никогда. Во-первых, несмотря на то, что работала я всего в 2х компаниях по специализации "Тестировщик", это странно: деление людей...попахивает как минимум рабовладельческим строем; во-вторых, непродуктивно: если с одним из членов команды что-то случится, неужели никто из других пострадавшей команде не поможет???
Бог услышал мои молитвы и нас решили разделить. Разделили только тестировщиков и интеграторов: нас посадили по отдельным кабинетам.
И вот на фоне этих событий я и решила задуматься, а какое разделение команды более продуктивно для команды: посадить всех отдельно - отдельно бизнес-аналитики, отдельно тестировщики, разработчики и так далее, посадить по звездочкам - бизнес-аналитик, пара разработчиков, тестировщик и интегратор или просто посадить всех вместе в один большущий кабинет?
Над этой темой буду думать ближайшее время. Результаты будут приведены позже. Комментарии приветствуются ;)