Software-Testing.Ru

Автор: Алексей Баранцев

В предыдущей статье я рассказал о том, как автоматизировать снятие скриншотов при неуспешном прохождении теста, используя TestNG и Selenium RC. Для этого был разработан класс ScreenshotListener, который подключался к тестам при помощи аннотации @Listeners. Но реализация этого класса предполагала, что тесты выполняются на локальной машине, и скриншот снимался на ней же. В этой статье будет предложена альтернативная реализация, позволяющая снимать скриншоты как локально, так и удаленно. Кроме того, я расскажу о том, какие могут возникать проблемы при удаленном снятии скриншотов и как с ними бороться.

Автор: Алексей Лянгузов ( Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript )

Слайдкаст: http://www.slideshare.net/LeshaL/ss-4686660

Какое-то время назад, несколько наших проектов вышли в мир ПО с открытым исходным кодом. За эти годы было выпущено и протестировано несколько версий и накоплен вполне солидный опыт.

Данная статья рассказывает о том, какие особенности встречаются при тестировании программ с открытым исходным кодом. Что нужно для этого знать и уметь. К чему надо готовиться, чего ожидать, а чего опасаться и избегать. Ещё статья затрагивает тему того, как минимизировать затраты на тестирование.

Готовя статью, я практически не нашёл материалов по тестирование программ с открытым кодом в интернете. В частности, не нашёл ничего про то, что же отличает тестирование открытых программ от обычных.

Возможно считается, что тут нет никакой разницы? Или люди думают, что проекты с открытым кодом не нуждаются в тестировании, в традиционном его понимании?

Прочитайте статью, если вы так думаете или если вы собираетесь тестировать ПО с открытым кодом, и вероятно какие-то вопросы перестанут быть для вас вопросами.

Автор: Юлия Нечаева

Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.

Cтандартные в таких случаях советы: объясняйте, мирите, аргументируйте, — выглядят, как будто перед программистами оправдывают существование тестировщиков. Постфактум решать такую проблему (а это очень критичная проблема) очень трудно. Нужно закладывать правильную атмосферу при построении команды и носить это правильное отношение к работе за собой из команды в команду, из компании в компанию.

Один из самых увлекательных докладов на прошедшей конференции SQA Days 7 -- рассказ Юли Нечаевой о тестировании игр. Чем занимаются тестировщики в компаниях, производящих компьютерные игры? Действительно ли они играют на работе? Да, играют, конечно. Но каково это, проходить по сотне раз одни и те же предписанные сценарии? Чем ещё они занимаются? Что лучше -- нанимать тестировщика и учить играть, или нанимать игрока и учить тестировать? Что можно автоматизировать, а что приходится тестировать вручную? Конечно, за сорок минут невозможно раскрыть все секреты тестирования игр, но Юля постаралась выделить самые главные особенности.

Автор: Gojko Adzic
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Оригинальная публикация

Я сейчас пишу новую книгу и в связи с этим опрашиваю множество команд, внедривших приемочное тестирование. Большинство из уже опрошенных не в одном, так в другом месте наступали на грабли при автоматизации тестирования пользовательского интерфейса (UI). Пообщавшись несколько недель назад на Agile Acceptance Testing Days в Бельгии с некоторыми участниками, которые как раз опасно приблизились к тому месту, где спрятаны грабли, я хочу представить вашему вниманию хорошие, на мой взгляд, подходы к автоматизации UI-тестирования.

Некоторое время назад я уже высказывался против автоматизации тестирования пользовательского интерфейса, поэтому не буду повторяться. Однако многие из команд, с которыми я общался, судя по всему, предпочитают автоматизацию именно на этом уровне, или думают, что для подтверждения требуемой бизнес-функциональности необходимо тестирование на этом уровне. Почти все эти команды через 6-9 месяцев после первых попыток автоматизации обнаруживали, что цена поддержки UI-тестов больше, чем получаемая от них выгода. Многие в этот момент забрасывали свои тесты и благополучно теряли вложенные в них усилия. Если вам все-таки необходимо выполнить автоматизацию UI-тестов (в чем я сильно сомневаюсь), то ниже вы найдете рекомендации, как сделать так, чтобы в дальнейшем цена их поддержки не оказалась слишком высокой.

Несмотря на то, что прошедшая недавно конференция SoftwarePeople была ориентирована преимущественно на менеджерскую аудиторию, Юля Нечаева не побоялась выступить там с докладом о тестировании. Она рассказала менеджерам о том, чего они могут ожидать от тестировщиков -- с одной стороны, не совсем то, чего они обычно привыкли требовать, а с другой стороны -- гораздо больше, чем они обычно себе представляют.

Автор: Карен Н. Джонсон (Karen N. Johnson)

Перевод: Дмитрий Дудников по заказу Software-Testing.RU

Оригинальная публикация

Регрессионное тестирование порой может быть весьма трудоёмкой задачей. Регрессионное тестирование – это тестирование, предназначенное для повторной проверки свойств приложения или продукта с целью убедиться в том, что после внесения изменений или добавления новых возможностей приложение по-прежнему работает. Уже из определения видно, что регрессионное тестирование может быть очень обширным, поскольку может потребоваться повторная проверка практически каждого свойства продукта. Как правило, регрессионные тесты – это тесты, разработанные ранее, следовательно, основная работа при регрессионном тестировании заключается не столько в создании тестов, сколько в их выполнении. Таким образом, самая первая проблема – это планирование того, что мы будем перепроверять. Итак, как же выбрать, что подвергнуть регрессионному тестированию?

Оригинальная публикация: Dawn Haynes http://www.sqetraining.com/file/DawnHaynesArticle.pdf

Перевод: Лаборатория Качества.

Как сделать тестирование эффективнее и полезнее, почти не меняя действующую стратегию? За 10 лет я составила 10 эвристических правил «увеличения отдачи» от тестов с помощью разумных изменений в условиях, последовательности, данных или перспективе тестов во время их выполнения.

Автор: Майкл Болтон
Перевод: Дмитрий Дудников по заказу Software-Testing.Ru
Оригинал: http://www.developsense.com/articles/2005-04-ThePleasureOfFindingThingsOut.pdf

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

Не так давно Алексей Баранцев выложил в открытый доступ запись специального вводного семинара "Тестирование программного обеспечения: основные понятия".

См. полную текстовую расшифровку этого семинара в блоге "QA - грамотно".

Там же - скриншоты ключевых слайдов.