Добрый день, возникла потребность обратиться куда-нибудь к тестировщикам на фриланс, т.к. сам не успеваю. Есть у меня приложение, есть старая инструкция которая этому приложение не особенно соответствует. Это не относится напрямую к вопросу, а больше в качестве вводных. Необходимо протестировать GUI после ряда изменений, просто убедиться что ничего не падает. Какой документ необходим для тестировщиков если я планирую искать их на фрилансе? Какое-нибудь ТЗ в стиле
Проферка ф-ла сложения.
Проверяем ф-ию А
Входные данные вводим 8 и 9
Жмем кнопку сложить
На выходе должны получить 17
Как это примерно по времени оценить, может какая литература есть?
Имхо быстрее самому проверить, чем объяснять человеку, который не в теме
Как ты будишь качество его работы проверять?
Ну он скажет, что проверил, а на самом деле ничего не делал
Или дать ему задание не тестировать, а использовать сайт. Например, создать столько то заказов
А ты со своей стороны проверишь, что заказы созданы
И если у него возникнут сложности, он тебе скажет
Здравствуйте, data17, Вы писали:
D>Добрый день, возникла потребность обратиться куда-нибудь к тестировщикам на фриланс, т.к. сам не успеваю. Есть у меня приложение, есть старая инструкция которая этому приложение не особенно соответствует. Это не относится напрямую к вопросу, а больше в качестве вводных. Необходимо протестировать GUI после ряда изменений, просто убедиться что ничего не падает. Какой документ необходим для тестировщиков если я планирую искать их на фрилансе? Какое-нибудь ТЗ в стиле
Не прямой ответ на вопрос, но может лучше попробовать автоматизировать тестирование.
D>Какое-нибудь ТЗ в стиле D>Проферка ф-ла сложения. D>Проверяем ф-ию А D>Входные данные вводим 8 и 9 D>Жмем кнопку сложить D>На выходе должны получить 17
В проектах, которые делаются по ГОСТам — бывают такие документы, как "Методика испытаний" или "Методика экспериментальных исследований", в которых обычно все бывает по такой схеме и расписано.
Конечно, вряд ли тебе для тестировщика надо писать именно такие документы — но ты можешь поискать примеры этих документов как они пишутся, посмотреть на них (обращая внимание на наиболее значимую часть — описание проводимых проверок) и написать для тестировщика в упрощенном виде что-то подобное.
Здравствуйте, data17, Вы писали:
D>Добрый день, возникла потребность обратиться куда-нибудь к тестировщикам на фриланс, т.к. сам не успеваю. Есть у меня приложение, есть старая инструкция которая этому приложение не особенно соответствует. Это не относится напрямую к вопросу, а больше в качестве вводных. Необходимо протестировать GUI после ряда изменений, просто убедиться что ничего не падает. Какой документ необходим для тестировщиков если я планирую искать их на фрилансе? Какое-нибудь ТЗ в стиле D>Проферка ф-ла сложения. D>Проверяем ф-ию А D>Входные данные вводим 8 и 9 D>Жмем кнопку сложить D>На выходе должны получить 17 D>Как это примерно по времени оценить, может какая литература есть?
По цене был опыт — оплата только за найденные баги, а так же просто оплата по времени, когда работали с проверенным испонителем.
Написать тест-план ему и пусть по нему проходит.
Обычно описывается что надо сделать, на что обратить внимание и что именно должно в итоге получиться.
На пример:
1 Нажать кнопку Print
2 Убедиться что появился диалог печати
3 Проверить поля на заполнение значениями по умолчанию (проверить на граничные и недопустимые значения)
4 Проверить что в поле "Формат бумаги" установлен по умолчанию как А4
5 Проверить возможность изменения фрмата бумаги
6 Распечатать документ и убедиться что изменение влияет на формат печати
Тестировщик должен написать отчеты о найденных ошибках с пошаговым описанием что сделать, чтобы воспроизвести ошибку (steps to reproduce...).
У меня опыт 24 лет тестирования ПО, своего продукта, причем со сложным функционалом, очень многими возможностями и десятками окон с разными настройками.
Вначале сам тестировал, потом нанимал бета-тестера.
В итоге пришел к выводу, что лучше самому тестировать, тем более не так сложно и долго. Тем более, если вы сами пишете код, то представляете какие правки, что могли затронуть.
Советую искать добровольцев бета тестеров, например на своем форуме-продукта, или на странице Facebook сделайте сообщество. Будут вам бесплатно находить ошибки. Причем намного лучше нанятых за деньги тестировщиков. Потому что это энтузиасты, которые реально используют ваш продукт.
Судя по тому что даже у Apple и Microsoft совершенно дурацкие ошибки в интерфейсе встречаются. А в продуктах Microsoft я постоянно нахожу визуальные баги, то им не помогают даже армия тестировщиков и миллиарды долларов.
Находишь опытного тестировщика, ставишь задачу чтобы он написал план тестирования. Потом по этому плану можешь отдавать любому исполнительному товарищу. Как контролировать — не знаю, наверное можно экран попросить записать.
Здравствуйте, Aleksid1, Вы писали:
A>У меня опыт 24 лет тестирования ПО, своего продукта, причем со сложным функционалом, очень многими возможностями и десятками окон с разными настройками.
A>Вначале сам тестировал, потом нанимал бета-тестера.
A>В итоге пришел к выводу, что лучше самому тестировать, тем более не так сложно и долго. Тем более, если вы сами пишете код, то представляете какие правки, что могли затронуть.
A>Советую искать добровольцев бета тестеров, например на своем форуме-продукта, или на странице Facebook сделайте сообщество. Будут вам бесплатно находить ошибки. Причем намного лучше нанятых за деньги тестировщиков. Потому что это энтузиасты, которые реально используют ваш продукт.
A>Судя по тому что даже у Apple и Microsoft совершенно дурацкие ошибки в интерфейсе встречаются. А в продуктах Microsoft я постоянно нахожу визуальные баги, то им не помогают даже армия тестировщиков и миллиарды долларов.
Интересно. Вообще у меня был опыт когда самим клиентам нужно было ПО так они сам организовали стенды и все достаточно глубоко проверили, каждый пункт. Нашли пару глубоких ошибок, которые никто не замечал. Затем писал автотесты.
Но в данном случае я бы просто хотел проверить, возможно это все сможет сэкономить мне несколько часов, т.к. сам могу быть занять другим или хотя бы в самой грубой форме проверить, что ничего не падает после крупных изменений. Оценить будет ли толкв. Ведь мало сейчас можно компаний без отдела тестирования найти.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Здравствуйте, data17, Вы писали:
D>>Добрый день, возникла потребность обратиться куда-нибудь к тестировщикам на фриланс, т.к. сам не успеваю. Есть у меня приложение, есть старая инструкция которая этому приложение не особенно соответствует. Это не относится напрямую к вопросу, а больше в качестве вводных. Необходимо протестировать GUI после ряда изменений, просто убедиться что ничего не падает. Какой документ необходим для тестировщиков если я планирую искать их на фрилансе? Какое-нибудь ТЗ в стиле
U_E>Не прямой ответ на вопрос, но может лучше попробовать автоматизировать тестирование.
Да-да. Согласен на все 100%, однажды написали модули для тестирования ПО, достаточно трудоемко, но помогло за короткое время баги исправить. Для этой задачи потребовался отдельный программист кто на PyQT сдела тесты базы данных, изменений в ней и т.д. после работы ПО. Но тут хотелось бы узнать, что можно сделать силами "ручника".
A>На пример: A>1 Нажать кнопку Print A>2 Убедиться что появился диалог печати A>3 Проверить поля на заполнение значениями по умолчанию (проверить на граничные и недопустимые значения) A>4 Проверить что в поле "Формат бумаги" установлен по умолчанию как А4 A>5 Проверить возможность изменения фрмата бумаги A>6 Распечатать документ и убедиться что изменение влияет на формат печати
Интересно, есть софт который это автоматизирует? Может кому-то как идея для shareware сгодится )
Здравствуйте, TailWind, Вы писали:
A>>На пример: A>>1 Нажать кнопку Print A>>2 Убедиться что появился диалог печати A>>3 Проверить поля на заполнение значениями по умолчанию (проверить на граничные и недопустимые значения) A>>4 Проверить что в поле "Формат бумаги" установлен по умолчанию как А4 A>>5 Проверить возможность изменения фрмата бумаги A>>6 Распечатать документ и убедиться что изменение влияет на формат печати
TW>Интересно, есть софт который это автоматизирует? Может кому-то как идея для shareware сгодится )
Ага, только все, что я встречал и пробовал было кривое. То не все контролы видит, то не понимает еще что-то.
В комплексе Rational (Rational Team Test и прочее, не помню точно, помоему это у IBM теперь) был раньше инструмент не плохой для этого, но разработчикам изначально надо было встраивать в код что-то чтобы оно потом позволяо и кейсы писать и автотесты составлять.
A> В итоге пришел к выводу, что лучше самому тестировать, тем более не так сложно и долго. Тем более, если вы сами пишете код, то представляете какие правки, что могли затронуть.
+100500
A> Советую искать добровольцев бета тестеров, например на своем форуме-продукта, или на странице Facebook сделайте сообщество. Будут вам бесплатно находить ошибки. Причем намного лучше нанятых за деньги тестировщиков. Потому что это энтузиасты, которые реально используют ваш продукт.
A> Судя по тому что даже у Apple и Microsoft совершенно дурацкие ошибки в интерфейсе встречаются. А в продуктах Microsoft я постоянно нахожу визуальные баги, то им не помогают даже армия тестировщиков и миллиарды долларов.
Ничего удивительного:
Бывший разработчик Microsoft Джерри Берг (Jerry Berg) объясняет, в чём дело. По его словам, в последние годы Microsoft ради экономии поменяла метод тестирования операционной системы. Раньше в компании работал большой отдел тестеров на зарплате. Потом их сократили, а тестирование переложили на широкое сообщество (бесплатных) добровольцев, которые участвуют в программе Windows Insider.
Здравствуйте, data17, Вы писали:
D>Добрый день, возникла потребность обратиться куда-нибудь к тестировщикам на фриланс, т.к. сам не успеваю.
Оптимальный вариант это тестирование силами сообщества, если оно у продукта есть. Это будут заинтересованные люди в теме, причем выгода взаимная: качество продукта растет для всех, можно еще добавлять функции, которые просят тестировщики, в приоритетном порядке.
По фрилансерам, я нанимаю если продукт новый и еще нет пользователей. Рекомендую следующее: оставить специально "баги":
1) такие, которые 100% появятся (например, падение при закрытии настроек или что-то такое)
2) менее очевидные, которые проявлябтся при опр. условиях.
Смысл первого типа бага: понять, что в принципе что-то тестировали, запускали. Реально есть ребята, которые пришлют вам отчет вроде "все протестировал, багов нет, продукт отличный, давайте деньги". Смысл второго типа багов — определить фрилансеров, которые реально делали работу и с ними продолжать дальше.
Оплата по кол-ву найденных багов, как выше предлагали, не очень правильно — если продукт качественный и багов мало, то для тестировщика это много работы и мало денег. Лучше заказать общее тестирование за фикс цену у нескольких фрилансеров, посмотреть кто нашел специально оставленные баги и у них уже дозаказать более глубокое тестирование.
Здравствуйте, Aleksid1, Вы писали:
A>В итоге пришел к выводу, что лучше самому тестировать, тем более не так сложно и долго. Тем более, если вы сами пишете код, то представляете какие правки, что могли затронуть.
Это как раз и мешает. Тестировать должен сторонний человек, который все делает по другому, в другом порядке, и он вам найдет еще ворох багов. Вы то свой продукт будете использовать "правильно", как "задумано", а пользователи или тестировщики — будут делать как-то иначе, по своему, и вот тут много интересного может вылезти.
Здравствуйте, data17, Вы писали:
D>Добрый день, возникла потребность обратиться куда-нибудь к тестировщикам на фриланс, т.к. сам не успеваю.
Ты или тестировщик должен написать тест план на фичи. Это сложная работа, НО если у тебя есть артефакты в виде user story, описания прецедентов или багов на фичи в джире, то это можно использовать как референс, т.е. нужно понимать как пользоваться той или иной фичей и какие сценарии провоерять. Если нет, то надо вместе с тестером над этим работать, писать тест-планы, строить матрицы покрытия(трейсабилити) чтобы минимизировать количество тестов и выполнять сами тесты. D>Необходимо протестировать GUI после ряда изменений, просто убедиться что ничего не падает.
Это называется санити тестирование. Оно строится на базе фича тестов куда включаются выбранные тобой приоритетные сценарии из документа выше. D>Как это примерно по времени оценить, может какая литература есть?
Оценка на базе метрик которые ты собрал для своего продукта. Ты собираешь метрики?
Здравствуйте, autopsist, Вы писали:
A>Здравствуйте, TailWind, Вы писали:
A>>>На пример: A>>>1 Нажать кнопку Print A>>>2 Убедиться что появился диалог печати A>>>3 Проверить поля на заполнение значениями по умолчанию (проверить на граничные и недопустимые значения) A>>>4 Проверить что в поле "Формат бумаги" установлен по умолчанию как А4 A>>>5 Проверить возможность изменения фрмата бумаги A>>>6 Распечатать документ и убедиться что изменение влияет на формат печати
TW>>Интересно, есть софт который это автоматизирует? Может кому-то как идея для shareware сгодится )
A>Ага, только все, что я встречал и пробовал было кривое. То не все контролы видит, то не понимает еще что-то. A>В комплексе Rational (Rational Team Test и прочее, не помню точно, помоему это у IBM теперь) был раньше инструмент не плохой для этого, но разработчикам изначально надо было встраивать в код что-то чтобы оно потом позволяо и кейсы писать и автотесты составлять.
Я UI тестирование через automation API делал, обычно из коробки это есть (в QT/.NET Forms/WPF точно есть). Местами правил код, но овчинка стоит выделки.
Параллельно с тестами делаются скриншоты для всех локализаций.
