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

Подписаться

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

Конференции

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

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

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

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

.
Исследуя исследовательский подход к тестированию
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/

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

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

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

      Подробнее...
       
      Расширяем тестирование граничных значений
      05.12.2017 10:52

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

      Оригинальная публикация: http://quality-lab.ru/extend-testing-of-boundary-values/

      Самый первый метод тест-анализа, который каждый начинающий тестировщик постигает инстинктивно, – это метод граничных значений. Но так ли он прост, как это кажется на первый взгляд? Давайте разберемся!

      Для сравнения разных подходов возьмем конкретный пример. Пусть у нас на сайте есть форма предварительного расчета стоимости страховки жизни, базирующаяся на очень простой формуле. Клиент вводит возраст и сумму в рублях, на которую он хочет застраховать свою жизнь. Если клиент моложе 18 лет или старше 60, выводится сообщение: «К сожалению, на данный момент у нас нет для вас подходящих предложений». Во всех остальных случаях мы просто считаем процент от введенной суммы; этот процент равен возрасту клиента. Да, я знаю, что в реальности расчет будет гораздо сложнее, но для наших целей такая модель подойдет.

      Подробнее...
       
      Атака на юзабилити
      04.12.2017 10:23

      Автор: Дэвид Гринлис (David Greenlees)

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

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

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

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

      Постоянство

      Его легко и просто оценить, и оно крайне важно для юзабилити. Сталкивались ли вы с сайтами, на которых текст был представлен в различных шрифтах и размерах, списки были то с буллетами, то с иконками, а цветовая схема менялась от страницы к странице? Долго ли вы оставались на этом сайте? Недолго? Вот и я не стал себя мучить – я стараюсь покидать такие сайты как можно быстрее. Пользователь рассматривает подобное непостоянство как непрофессионализм. Насколько хорош сервис/продукт, если даже сайт сам себе не соответствует? Даже быстрый просмотр страниц сайта может выявить несоответствия. Удивительно, насколько они бросаются в глаза, если вы просто сфокусируетесь на них на некоторое время.

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