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

Подписаться

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

Конференции

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

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

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

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

.
Видеозаписи докладов с 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

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

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

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

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

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

Подробнее...
 
Бесплатная YouTube-трансляция Heisenbug 2017 Moscow
08.12.2017 10:47

Конференция: Heisenbug 2017 Moscow

Дата: 8-9 декабря 2017 года

Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте организаторов конференции.

Программа

Конференция проводится в течение двух дней. Первый день начинается в 10.00, второй — в 10.30. Каждый день оканчивается завершающим кейноутом (в 17.35 и 18.15 соответственно).

Актуальную программу первого зала можно увидеть на странице трансляции.

Подробнее...
 
Самый сложный случай, с которым я столкнулся, работая программистом
07.12.2017 11:16

Автор: Gerald M. Weinberg

Оригинальная публикация: http://secretsofconsulting.blogspot.ru/2017/10/my-most-challenging-experience-as.html

Перевод: Анастасия Данилкина

Читатели задали мне вопрос: «С каким самым сложным случаем вы столкнулись, работая программистом?»

Мы разрабатывали систему слежения для проекта Меркурий, которая должна была отправлять человека в космос и возвращать его живым обратно. Задача «вернуть живым» была сложной, но не единственной. Были и другие трудности:

- Система базировалась на всемирной сети довольно ненадежных телетайпных подключений.
- Мы должны были определить место приземления в Тихом океане в пределах небольшого радиуса, а для этого нам нужны были часы, идеально точно синхронизированные на компьютере и в космической капсуле.
- Нам также нужно было точно знать, где находятся наши станции слежения, но оказалось, что с достаточной точностью никто не знает, где находятся две австралийские станции. Нам пришлось создать целый подпроект для их обнаружения в Австралии.
- Нам нужна была информация о запуске ракеты, но поскольку это была также военная ракета, эта информация была засекречена. В конце концов мы нашли способ обойти эту проблему.

Подробнее...
 
Тестовая документация. Превращаем таблицы в деревья
06.12.2017 11:00
      Автор: Святушенко Елена Андреевна, руководитель отдела тестирования в компании Touch Instinct

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

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

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

      Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

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