Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Тестирование «без» требований: поиск и организация информации
25.12.2017 00:00

Автор: Дженнифер Харрелл (Jennifer Hurrell)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=3

Автор: Ольга Алифанова

Когда-то давно я встретилась с потенциальным клиентом, чтобы обсудить тестирование его проекта. Вскоре после начала нашей встречи он, однако, осознал, что тестировать его проект нельзя, потому что полностью отсутствуют формальные требования. Короче говоря, они ничего не записывали. Он скептично отнесся к моему заявлению, что письменно зафиксированные требования необязательны для тестирования. «Но как же вы будете тестировать без требований? Как вы узнаете, баг это или не баг?» - «Спрошу».

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

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

Что же такое «требование», и почему тестировщикам оно необходимо?

Подробнее...
 
Kirk + chrome devtools
20.12.2017 18:15
chrome dev tool

Автор: Сергей Пирогов

Оригинальная публикация: http://automation-remarks.com/2017/kirk-chrome-devtools/index.html

Привет, друзья-айтишники. Сегодня хочу поделиться с вами очередной порцией полезной информации из мира автоматизации тестирования. Поговорим более детально о возможностях использования Сhrome developer tools во время прогонов автотестов.

Записывать видео мы уже давно научились, а вот использовать такой мощный инструмент, как devtools, пока еще нет.

Developer tools обладает обширным кругом возможностей. Мы с вами используем его каждый день: для поиска элеметов, для того, чтобы посмотреть в network, возможно, даже попытаться замедлить браузер, чтобы посмотреть на поведение вашего сайта.

Использование devtools в тестах было невозможно, пока на одной из конференций не был показан инструмент devtools proxy.

Сам прокси написан на Python, но это не ограничивает нас от использования его в Java проектах.

Подробнее...
 
Где я? Подсказки для старта проекта
21.12.2017 00:00

Автор: Марк Толфтс (Mark Tolfts)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=9

Перевод: Ольга Алифанова

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

Начнем с ряда определений, которые я вынес из курса Rapid Software Testing Джеймса Баха и Майкла Болтона:

Миссия тестирования – результаты, которых от вас хотят заказчики. Покройте продукт тестами так, чтобы оценить риски, основанные на требованиях.

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

Подробнее...
 
Видеозаписи докладов с Avito Automation meetup
20.12.2017 11:39

Оригинальная публикация: https://habrahabr.ru/company/avito/blog/337118/


26 августа прошёл первый Avito Automation meetup. Говорили о проблемах управления тестами, векторах развития систем автоматизации тестирования, эффективности каждого из тестов, инструментах для тестирования iOS-приложений и запуске тестов в Continuous Integration.


В рамках встречи прозвучали доклады:


1. Векторы развития систем автоматизации тестирования. Дмитрий Химион (Avito)

2. Прокачиваем WebDriverAgent, или Как тестировать iOS-приложения после ядерного взрыва. Алексей Махов (Avito)

3. Проблемы управления тестами, или Что мешает создавать дешевые и полезные тесты при наличии искреннего желания это делать. Федор Зволинский (Yandex)

4. Запускаем тесты в Continuous Integration. Сергей Пак (JetBrains)

5. Добиваемся эффективности каждого из 9000+ UI-тестов. Максим Сахаров (Tutu.ru)

Подробнее...
 
Особенности организации работы распределенных тестовых команд
19.12.2017 12:07

Автор: Павла Толоконина, ведущий специалист по тестированию в компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/features-of-organization-of-distributed-test-commands/

Распределенная команда – это возможность найти нужного специалиста без ограничений конкретной территории, а также сэкономить на рабочем месте. Конечно, в такой работе есть немало особенностей. Вот уже четвертый год я управляю распределенными командами. На это накладывается предыдущий опыт классической схемы «одна команда – один офис». За это время мной «собрано немало шишек» и подготовлено немало наработок.

Если вы уже стали руководителем распределенной команды, только задумываетесь над ее созданием или просто хотите узнать о нюансах работы в тесной связке на расстоянии – эта статья для вас. Я постараюсь разобрать вопросы организации работы, осветить распространенные проблемы и стандартные страшилки.
Подробнее...
 
Исследуя исследовательский подход к тестированию
18.12.2017 10:53

Автор: Виктория Кузнецова (Viktoria Kuznetcova)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=25

Перевод: Ольга Алифанова

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

Мне кажется, проблема в том, что люди пытаются освоить практики исследовательского тестирования, не пытаясь понять идеи, лежащие в его основании. Если вы понимаете эти идеи, вы можете выбирать подходы, изобретать что-то новое, думать о том, что лучше сработает в этом конкретном проекте с его конкретной командой. Если все, что вам известно – это набор инструментов, то вы не занимаетесь исследовательским тестированием – вы просите кейс у людей, которые как раз им-то и занимались. Не то чтобы это плохо, но, по моему мнению, это вовсе не исследовательское тестирование. Не думаю, что у меня есть универсальный ответ на этот вопрос, но мне хотелось бы поделиться своим пониманием исследовательского тестирования и причинами, по которым я так его люблю.

Подробнее...
 
Притягательная сила тестирования
15.12.2017 11:26

Автор: Alan Page

Оригинальная статья: http://angryweasel.com/blog/the-lure-of-testing/

Перевод: Анна Радионова

Люди много говорят о том, как они оказались в тестировании (мне, например, говорили, что у меня задатки тестировщика, с первого дня моей работы в техсаппорте), но для тех из нас, кто работает в тестировании достаточно долго, не менее важно задуматься о том, почему мы остались работать в сфере тестирования или на других ролях, связанных с контролем качества.

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

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

Подробнее...
 
Тестирование производительности, специфика юнит-тестов, чек-лист юзабилити и многое другое: самые интересные материалы по тестированию за начало декабря 2017 года
14.12.2017 11:38

Вышел выпуск рассылки за первую половину декабря, его содержание доступно по ссылке.

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Подписаться на рассылку можно по ссылке.

Обсудить в форуме

 
Ты ж тестировщик или как правильно составлять Bug report
13.12.2017 12:45

Автор: Алексей Потемкин, QA engineer компании "JetRuby Agency"

Оригинальная публикация:https://jetruby.com/ru/blog/kak-napisat-bug-report/

Так уж случилось, что у нас накопилась масса материала, посвященного теме создания идеального отчета об ошибках (bug report). Обобщив эту информацию и вооружившись практическим опытом, мы решили написать статью. Перед вами подробный текст о стандарте написания баг репортов.

Каналы поступления багов

Начнем с каналов поступления багов. Мы можем столкнуться с проблемами и получить информацию об их появлении следующим образом:

  • В процессе тестирования — функционального и нефункционального.
  • Обращение клиента (заказчика) с информацией о возникшей проблеме.
  • Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
  • Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.

Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.

Подробнее...
 
Юнит тесты. Первый шаг к качеству
12.12.2017 11:30

Автор: Фомин Владимир, Инфосеть-С, Senior Javascript Developer

Оригинальная публикация: https://habrahabr.ru/post/336030/

Однажды меня попросили рассказать о юнит тестировании в javascript, но прежде чем рассказывать о тестировании в мире front-end, надо было сделать небольшой обзор юнит тестирования как такового. В результате чего на свет и появилась эта статья, в которой я попытался рассказать о самых важных моментах в юнит тестировании.

Несмотря на различные трактовки юнит тестирования, есть несколько вещей которые объединяют этот термин.

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

Подробнее...
 
Могут ли тест-менеджеры снизить качество продукта, чересчур помогая ему?
11.12.2017 10:11

Автор: Ким Энджел (Kim Engel)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=10

Перевод: Ольга Алифанова

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

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

  • Автоматизированные юнит-тесты не проверяются неделями или месяцами.
  • Релизы для тестирования и для прода выполняются разными командами.

Это серьезные риски для качества продукта, которые тест-менеджер не может игнорировать. Я работала с выдающимися людьми в индустрии разработки ПО. Их тоже волновали эти риски, но ограничения по времени, ресурсам и бюджетам не позволяли им внедрять решения этих проблем. Каждый раз я соглашалась (и зачастую вызывалась сама) брать эти задачи на себя вместо того, чтобы принять их как данность.

Подробнее...