Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

Для бизнесменов есть разные книги: «Как сделать ЭТО», «Как сделать ТО». А есть книги, задача которых — мотивировать, помочь посмотреть на ситуацию с новой стороны, побороть страхи и начать действовать.

Именно к ним я обращаюсь в те моменты, когда что-то не прёт, наваливает усталость, и не совсем понятно зачем всё это. Ниже — моя любимая выборка из 3ёх книг, которые могут помочь любому бизнесмену и которые сделают бизнесмена даже НЕ из бизнесмена :)

Как обычно строят процесс тестирования непросветлённые тест-менеджеры?

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

Релиз.

Не работает основной функционал.

Почему такое возможно?

1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.

2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.

3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.

4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…

Что просветлённые тест-менеджеры делают по-другому?

Что они поменяют в первую очередь?

Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование — это либо очень скучно, либо тупая работа и т.д.
Что все эти люди делают в тестировании??

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

Я очень радовалась каждой «находке», особенно если в поиске она была нетривиальной. Ещё больше радовалась каждый раз, когда удавалось точно локализовать дефект. Мне действительно нравилось их заводить, стараясь это сделать наиболее понятным способом.

«А что, если?...», «А как проверить?...», «А как бы?...» и т.д. заполняют мозг, который включается на полную мощность.

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

Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!

И я задумалась. Кто пишет про «скучно», «рутина» и «тупая работа»? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

Уважаемые хабраюзеры! Простите, если пишу не туда или не то :) Но мне экстренно требуется инъекция коллективного разума.
На данный момент, замечаю следующую тенденцию: «Клиенты — это такие специальные устройства, которые достают деньги из кошелька. Соответственно, надо их заставить достать как можно больше». В связи с этим, есть масса книг по продажам, активным и пассивным, условно-честным и искренне-манипулятивным, PR-у и копирайтингу и т.д.
А что хочется: найти книгу / гайдлайн / большую (!) хорошую (!!!) статью о том, как правильно общаться с клиентами, чтобы они просто были рады и счастливы общению. К примеру: клиенту по почте надо отвечать в такой-то срок, не использовать узко-специализированные термины (которые могут быть непонятны клиенту), отвечать строго на поставленный вопрос (не растекаясь мыслью по древу, или растекаясь только после чёткого ответа) и т.д. Попыталась составить некий свод правил сама (мне это нужно для помощницы, дабы чувствовать гордость за её работу), но не получается — то ли штиль неподходящий, то ли у меня у самой опыта общения с клиентами недостаточно, чтобы разложить подобные правила по полочкам.
Помогите ссылкой или умной мыслью. Если умных мыслей будет много — оформлю отдельный максимально удобный пост под авторством коллективного разума.

Заранее спасибо!

Первый бизнес – это как первая любовь. А первый офис – как первый поцелуй. И каждый, ну или почти каждый начинающий бизнесмен хочет себе хороший офис: по меньшей мере – комфортный, а зачастую и понтовый :) И конечно, очень хочется, чтобы он был как можно ближе к дому: «ну теперь-то я не буду стоять в пробках!».
Но, к сожалению, малый бизнес – как маленький ребёнок. За ним надо ухаживать, его надо кормить, и ни о каких «понтах» на ранних стадиях и речи идти не может. Нам важны результативность, окупаемость и гибкость в принятии решений :) Поэтому, как бы я ни хотела офис поближе к дому, после непродолжительного анализа пришла к выводу, что офис в Москве – не есть ни результативно, ни гибко, да и с точки зрения окупаемости пришлось бы постараться.
Поэтому, ниже я приведу результаты анализа по стоимости открытия офиса в 10 городах России. Итоги подведём на конкретном кейзе: софтверная фирма, состоящая из 5 разработчиков.

Под катом — гипотезы, цифры и диаграммы.