Поскольку постоянное тестирование дело недешевое, да и необходимо не всем и не всегда, я продаю трехчасовые тест-сессии ручного тестирования.
Общий смысл:
- я пришел на три/шесть/восемь часов в офис (или удаленно),
- провел пару раундов тестирования,
- написал подробный отчет о состоянии приложения и о проделанной работе.
Принципиально стоимость моих работочасов такая же, как и работа тестировщика, постоянно сидящего в офисе. Но поскольку я прихожу лишь при действительной необходимости, такой подход обходится проекту в разы дешевле, а результаты иногда сопоставимы с работой full-time работника.
До недавнего времени я был, в общем-то, типичным “постоянцем”, и не представлял себе иного способа работы. Семья, обязательства, всё такое… И не верил эффективность “краткосрочного” подхода, ведь это так противоречит многим постулатам в тестировании.
Но важнее того, что в общих чертах пишет, например, Рекс Блэк, является реальность – чаще всего тестировщика приглашают “под занавес”. Или когда программисты уже задрались фиксэндкодить, и хотят как-то улучшить дела с тестированием. Поэтому теперь я отношусь к таким вещам нормально. Постарел, наверное 
Для большей надежности тестирование следует начинать как можно раньше и проводить постоянно на протяжении всего жизненного цикла проекта, ага. В конце концов, должен же кто-то постоянно сидеть в офисе на случай “Где тут у нас тестировщик?!”
В остальных случаях кратковременные набеги тестировщиков – даже круто.
Собственно, поэтому с некоторыми моими клиентами я работаю на уже почти регулярной основе (разумеется, это подразумевает скидки и всевозможные послабления со сроками оплаты). Не каждый день, пришел, ушел, не требую ни медицинской страховки, ни постоянных 4 кв. метров, ни танцовщиц с халвой. Все это у меня уже есть. Взаимное удобство и соглашения ценнее.
Не во всех компаниях программисты пользуются баг-трекерами (спокойно, собрат, welcome to reality world show). Поэтому при необходимости я логгирую найденные дефекты на мой личный сервер с баг-трекером (использую Mantis), с разграниченными проектными правами доступа к тамошнему контенту для клиентов. Могу работать с любой баг-трекинговой системой, но предпочитаю эту, простую и надежную.
Скидки и послабления – для постоянных клиентов и для тех, кто приходит с рекомендацией.
Если случается что-то непредвиденное, а деньги уже переведены, я возвращаю их тем же способом за свой счет (хорошо, что это случается редко, поскольку я очень осторожный в оценках, и вряд ли возьмусь за работу, на которую у меня не будет по какми-то причинам времени).
Доступен по емайлу (astenix AT testitquickly.com), skype (astenix), в LinkedIn, и по телефону почти постоянно.
[...] Тест-сессии [...]
А отзывы от клиентов есть уже?
Не озаботился этим.
Хотите написать первый отзыв? Precondition – стать клиентом.
Мда….не удался наверно проект
а статейка про excel пригодилась!
Это какой проект подразумевается под неудачным?
Как успехи?
У меня сейчас счастье фрилансера – постоянная занятость в рамках нескольких долгоживущих и постоянно разрабатываемых проектов.
И количество “пустых” контактов довольно велико. Фрилансить в тестировании весьма сложно.
Это так, имхо на uTest платят копейки, и там можно работать только от нечего делать.
А найти клиентов для услуг по тестированию проблематично. Все скорее возьмут сотрудника в офис. Надо выходить на стартапы каким-то образом.
Когда-то тоже был уверен, что “скорее возьмут сотрудника”. Но это не так.
Большинству не нужны постоянно действующие тестировщики, но приходится брать их в штат, просто потому, что среди фрилансеров тестировщиков очень мало, и которые есть – очень общего профиля.
Вообще, ведь тестировщик – очень технически зависимый работник, и быстро найти со стороны кого-то уже грамотного и умеющего работать с нужными нюансами – сложно.
Надо аутсорсить по-серьезному. Из мелочи ведь вырастают большие компании.
Алексей, просто ради интереса. Представьте ситуацию: Вы приходите на проект который совсем не знаете, в котором Вы еще не имели опыта работы. Чтобы его нормально протестировать Вам необходимо узнать о использующихся программных и аппаратных платформах, тонкостях кода и архитектуры. Как Вы считаете, возможно ли адекватное тестирование без подобных знаний, которые возможно получить только с достаточно большим опытом работы с конкретным продуктом?
Как мне кажется, приходящий тестировщик может лишь выполнять обязанности робомартышки, прокликивая тестируемый продукт не задумываясь о особенностях его реализации.
Итак, что лучше: иметь постоянного тестировщика, который будет разбираться в продукте и знать нюансы его работы для полноценного тестирования или же приглашать на “тест-сессии” специалиста со стороны?
Если попытаться ответить односложно, то лучше, чтобы тестировщик на проекте был постоянным.
Но односложно ответить сложно, ведь это дело ЗАВИСИТ от ситуации.
Главное отличительное свойство тут следующее: надо чисто технически что-то протестировать, или надо работать с включенным мозгом? Есть ситуации, когда нужно просто по тест-кейсам пробежаться, ничего более. Упомянутая робомартышка, ага.
Конечно, каждый скажет, что всегда надо “включать мозг”…
Всегда лучше, когда в разработке участвует постоянный (или даже – ые) тестировщик. Ключевое слово – участвует в разработке. Наравне со всеми. Но ведь так бывает не всегда
Бывает так, что “глаз замыливается”, и нужно какие-то аспекты или области проверить “еще одним тестировщиком”, пусть даже второй не полностью разбирается в нюансах и аспектах.
“Постоянный” человек действительно силен не только в нюансах, но и в тестовом окружении – знает названия серверов, логины, особенности логинов, особенности бизнеса и внутреннюю политику, и всякое такое. И иногда все это открывать для “пришлого” нецелесообразно. В таком случае “внутренний” опять же лучше.
Бывает такой софт, который намного проще и дешевле проверят фрилансерами – сайт какой-нибудь не особо замороченный, например, для промо-акции какой-нибудь. Краткосрочный проект, который появился и довольно быстро исчезнет, или будет оживать лишь периодически.
Бывает так, что нужно устроить “коридорное тестирование” – проверить какие-то штуки не посредством опытного тестировщика, а посредством опытного человека в теме. Например, софт для трейдеров лучше проверить обычным живым трейдером, а не мною.
Мною в случае трейдерства можно проверить то, как было организовано тестирование упомянутой софтины, посмотреть, как в принципе продуманы какие-то высокоуровневые проверки.
Или сделать так, как это бывает у меня: ребята-индусы пишут (и тестируют) софт для ребят-американцев. Меня они просят протестировать то, что только что сами протестировали (или сейчас тестируют) они.
И мне и им удобно тем, что я уже знаю их проект, знаю тонкости, и они знают, что и как я делаю.
Ключевой момент, опять же, во времени. Я не могу и не хочу сидеть днями или неделями над тестированием чего-то в качестве фрилансера – у меня есть основная работа, которую я ценю и люблю. “Отвлечение” на стороннюю работу я воспринимаю и как “накачивание мускулов”, и как нарабатывание опыта, которого много никогда не бывает, и просто как развлечение и отвлечение, но не как самое важное для жизни дело – деньги это приносит относительно небольшие. Поэтому я работаю “на сторону” на протяжении нескольких часов в неделю, редко больше пяти суммарно за все семь дней. А иногда за неделю вообще ни минуты не фрилансю, и это нормально.
Раньше посвящал этому выходные как полноценные рабочие дни, но со временем забил – есть семья, есть блог, есть достаток, есть много интересных дел, которые проходят мимо, и если не открывать для них своё процессорное время – нарушаются баланс и гармония быта, что в моем возрасте уже очень важно…
Здравствуйте!
“… трехчасовые тест-сессии ручного тестирования…”
Скажите пожалуйста, на сколько это продуктивно? Например я менеджер, нанимаю Вас на работу, вы приходите на 3 часа в офис и какие вы даете результаты по завершению? по каким принципам вы проводите тесты, ведь приложения бывают разные и не всегда хватает 3-х часов даже чтобы понять как фича должна работать…
У меня есть определенный уровень понимания предметной области. Если мне нужно три часа, чтобы только понять, как работает какая-то фича, я вряд ли гожусь для ее тестирования.
У меня есть опыт работы с интернет-магазинами (вот пример того, что приносит подобный опыт). Соответственно, я выбираю для себя задачи по уму и плечу. Каждое предложение (или отклик на мое предложение) предварительно рассматривается и обсуждается, обоюдно прощупывается почва – правильно ли мы понимаем то, что обсуждаем, и совпадают ли наши ожидания от того, что должно получиться в итоге.
Главная задача тестировщика – снабжать информацией лиц, которые ответственны за качество ПО или за принятие решений относительно его. Я и продаю информацию о состоянии ПО, которую добываю по итогам своей работы (тут отнюдь не подразумевается “список багов” – это только один из аспектов отчета).
Если информация обстоятельна, доказательна и весома, значит, я работал продуктивно. Если нет – то увы мне.
Например, однажды один грамотный ПМ заплатил мне за сессию из своих личных средств, просто чтобы убедиться, что в его зоне ответственности в ПО все ок или совсем не ок – это информация, которую надо как-то добыть. Оказалось – кирдык с его проектом. Вкратце: сайт типа “биржа объявлений” разрабатывали больше полугода, и вроде все было хорошо. За два дня до передачи продукта на тестирование со стороны заказчика (там ожидалось очень грамотное и детальное тестирование) ПМ почуял что-то неладное, заволновался, и пригласил меня “покликать”. За восемь часов (суммарно) я нашел около восьмидесяти багов. Но в принципе сайт всем когда-то выдвинутым требованиям соответствовал полностью, просто никто не смог посмотреть на него “в принципе”, отвлеченно, глазами “пользователя”. На сайт смотрели как на детище, которое растет и которое надо развивать. Одна из основных ролей тестировщика – эмулировать конечного пользователя. Если бы я был в команде разработки с самого начала проекта, то весьма вероятно, что и мой глаз замылился бы точно так же, как это произошло с членами команды.
Поэтому решение ПМа о привлечении стороннего тестировщика на поздних этапах проекта ИНОГДА бывает верным. В принципе же проверять (тестировать) нужно на протяжении всего цикла разработки, итерациями. Вот на таких проектах приходящие тестировщики не нужны – нужны постоянные.
У меня есть в активе сессии на ряде проектов, в ходе которых я изрядно потел, но существенных багов не находил – вообще. Информация о том, что существенных багов нет – тоже ценна, и тоже является результатом работы тестировщика.
Продуктивность также ограничена чисто физическими моими возможностями.
Обычно такая работа продуктивна, если работаем с сайтом, который постоянно в разработке. Для примера: я работаю с ребятами, сайт которых (и бизнес которых) мне уже полгода как известен и понятен. Появился у них новый функционал – я его проверил, как мог (с учетом ограничения по времени, если есть такое ограничение, или в силу нынешнего понимания проверяемого функционала), и иногда этого бывает достаточно, последующие багфиксы они могут проверить и самостоятельно. А иногда нет – предлагается проверять и багфиксы.
[...] Тест-сессии [...]
Спасибо за информацию.
Очень интересная мысль и подход, как для тестировщиков (в плане реализации своих потенциалов), так и для разработчиков софта (в плане методов работы с контролем качества).