|
22.03.2023 00:00 |
|
 Автор: Кит Клайн (Keith Klain)
Оригинал статьи
Перевод: Ольга Алифанова
Сокращение штата – это стрессовое, как правило, ненужное, и, по моему мнению, всегда вызванное плохим руководством дело, но я слежу за новостями и событиями в техническом секторе – кажется, сокращения штата снова в меню. Я управляю тестированием промышленных технологий более 25 лет, и сталкиваюсь с сокращением штатов ежегодно. Возможно, для кого-то это произойдет впервые, и тестировщики, как правило, стоят на выход первыми, поэтому вот мои советы, как повысить свою ценность для бизнеса и избежать увольнения.
|
|
Подробнее...
|
|
16.03.2023 00:00 |
|
 Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
Ранее я писала, как убедиться, что вы действительно нашли баг, прежде чем его заводить; как исследовать баг; и как написать баг-репорт, когда баг исследован. Но я никогда не писала о том, как добиться, чтобы баг исправили. Даже если вы зарепортили тщательно детализированный и внятно описанный баг, разработчик или команда все же могут решить, что он не достоин исправления. В этой статье мы разберем пять вещей, которые можно предпринять, чтобы помочь багу исчезнуть.
|
|
Подробнее...
|
|
15.03.2023 00:00 |
|
Оригинальная публикация
 Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию. |
|
Подробнее...
|
|
14.03.2023 00:00 |
|
 Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова
"К коду тестов нужно относиться так же, как и к коду продукта".
Недели не проходит, чтобы кто-нибудь об этом не заявил в докладе, статье, посте на LinkedIn.
Я согласен. Вы должны обращаться с кодом тестов так же, как и с кодом продукта. Проблема тут в том, что просто заявить "вы должны" недостаточно, чтобы это магическим образом произошло за одну ночь. К сожалению, я крайне редко вижу, чтобы сказавший это человек поделился практически применимыми советами, как же обращаться с кодом тестов аналогично коду продукта. |
|
Подробнее...
|
|
13.03.2023 00:00 |
|
Автор оригинала:
David Tzemach
«Начинайте тестировать как можно раньше» — эта фраза часто встречается в разных докладах и обучающих материалах. Это правда, чем раньше наши тесты найдут проблему, тем быстрее и дешевле мы ее решим. Это одна из главных причин эффективности CI. Часто встречаются команды, у которых очень много написанных автотестов, но они не используют тесты как подход к CI. Существуют различные причины, по которым команда считает, что эти тесты нельзя использовать в CI. Возможно, выполнение тестов занимает слишком много времени или они недостаточно надежны, чтобы давать правильные результаты, и требуют интерпретации человеком. При оценке тестовых наборов (suites) я рисую на доске таблицу, в которой вертикальная ось представляет важность тестов, а горизонтальная ось — время, необходимое набору для выполнения тестов. Затем мы с командой пишем название каждого набора тестов на стикере и приклеиваем его на нужное место. |
|
Подробнее...
|
|
07.03.2023 00:00 |
|
 Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова
Конфликт, возникающий при рассказе о проблемах исследовательского тестирования
Мы, как тестировщики, хотим найти и описать то, что, с нашей точки зрения, является важной проблемой. Эти проблемы могут угрожать ценности тестируемого продукта. Заинтересованные лица могут не особенно стремиться знать о них, потому что выявление таких проблем может порушить существующее расписание и привести к трудным разговорам с менеджером проекта. Некоторые разработчики могут воспринять это, как личный выпад – особенно если мы сообщаем о проблемах в терминах области кода, которая их, возможно, вызвала, не говоря о том, как эти проблемы угрожают ценности продукта. |
|
Подробнее...
|
|
06.03.2023 00:00 |
|
Автор: Алексей Никитин, Visiology CEO, https://www.linkedin.com/in/alexey-nikitin-5aa09869/
 Технологии Agile, Scrum и CI/CD становятся общепринятой нормой, и нам уже кажется, что новые релизы всегда можно выпускать постоянно, практически непрерывно. Технически, сейчас действительно есть реальная возможность выкатывать обновления каждый день, а некоторые разработчики готовы релизиться каждый час — для web- и мобильных приложений это совершенно нормально. При такой частоте возникает вопрос: на сколько хорошо должна быть отлажена система автоматизированного тестирования? Цена ошибки в таком релизном цикле невысока, а компания получает возможность переложить финальное тестирование на плечи своих клиентов. Если у кого-то что-то пошло не так, можно моментально выпустить исправление. Но возможен ли такой подход в разработке корпоративной BI-системы? Об этом и поговорим сегодня. |
|
Подробнее...
|
|
02.03.2023 00:00 |
|
 Автор: Тамоя Бекфорд, Жизель Тодд (Tamoya Beckford, Giselle Todd)
Оригинал статьи
Перевод: Ольга Алифанова
Исследование миграции данных 2017 года показало, что, согласно 61% респондентов, в среднем три или более легаси-систем причастны к какой-либо форме миграции данных. Можно предположить, что огромное количество компаний занимаются миграцией данных. То же исследование выявило, что 69% мигрировавших проектов были успешными – а что насчет оставшегося 31%? Вот в чем вопрос: насколько этот результат зависит от нехватки хороших практик тестирования?
Недостаточное тестирование было по факту указано как одна из причин провала проектов миграции данных. Работа с любой миграцией данных – это опасное дело, подверженное высокому риску. Мы, на основании нашего опыта, решили пролить свет на пять (5) наиболее важных факторов, которые нужно учитывать, проводя эффективное тестирование миграции базы данных – тогда проект будет успешным.
|
|
Подробнее...
|
|
|
