Всем привет, меня зовут Таня и это моя первая статья на Хабре.
В начале декабря проходила конференция Heisenbug 2018 в Москве. Это событие было уже освещено многими: раз, два, три.
Я отметила для себя, что в основном были затронуты только положительные моменты, хотя были и отрицательные. Я хочу поделиться своим взглядом на это событие. Если кто-то не согласен с моим мнением, то пусть так и будет.
Читать полностью »
В Новый год многие подводят итоги, анализируя прошедший год, вспоминают все свои результаты и строят планы на будущее. В 12-ом выпуске нашего календаря Анастасия Ронжина, тестировщик сервиса Контур.Маркет, расскажет о том, почему стоит пробовать что-то новое, менять свои взгляды, подходы, ошибаться и снова пробовать.
У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.
Эволюционирует место тестировщика в процессе разработки, да и сами процессы. Например, Максим и Ирина из нашей компании рассказывали про эволюцию автотестов, о том, как можно ускорить разработку с помощью тестов и изменении взглядов на то, кто и на каком этапе их должен писать. Лена и Илария рассказывали о том, что можно менять свои инструменты, подключаться к общению с пользователем, к подготовке ТЗ и прототипов, чтобы повысить качество продукта.
Мне очень грустно, когда я очередной раз слышу мнение, что тестировщик может достичь своего предела за 1,5 года, а дальше либо в автоматизацию, либо смена роли на менеджера, аналитика, разработчика и т. п. Когда твой каждый день — это просто повторение алгоритма: почитал аналитику, посмотрел прототипы, потестировал, запостил баги, перепроверил баги — то легко понять, почему ты устаёшь и разочаровываешься в профессии. Это же просто скучно!
Работая над последним проектом, столкнулся с тестированием мобильного приложения, связанного на уровне бизнес-логики с различными сторонними сервисами. Тестирование этих сервисов не входило в мою задачу, однако проблемы с их API блокировали работу по самому приложению – тесты падали не из-за проблем внутри, а из-за неработоспособности API, даже не доходя до проверки нужной функциональности.
Традиционно для тестирования таких приложений используются стенды. Но они не всегда работают нормально, и это мешает работе. В качестве альтернативного решения я использовал моки. Об этом тернистом пути и хочу рассказать сегодня.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).
Поэтому сегодня всё реже можно полагаться исключительно на морально-волевые качества для входа в IT в свете возросших аппетитов рынка и обилия конференций, курсов, тренингов, литературы, статей и прочих информационных источников, которые находятся на расстоянии вытянутой руки начинающих специалистов.
Читать полностью »
Добрый день, уважаемые читатели.
Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.
Надеюсь статьи будет полезна начинающим автотестерам.
Всем привет!
Я Катя, тестирую мобильные приложения в Badoo. Сегодня я расскажу о том, почему тестировать бета-версии так важно, как мы проводим мануальное тестирование таких версий и что интересного мы обнаружили в ходе проверки iOS 12 Beta.
Читать полностью »
С тестированием связано много стереотипов: к нему относятся как к быстрому старту в IT с перспективой высокой зарплаты, но не видят в этом серьезной профессии. Кажется, что тестирование — сплошная рутина, где нет места творчеству и реализации собственных идей.
Вместе с руководителем отдела QA/QC в Redmadrobot и куратором нашего курса Software Testing Marishunya_QA мы разобрались, какими навыками нужно обладать тестировщику, куда можно развиваться в тестировании, с чем на самом деле связана текучка кадров и почему даже хорошим программистам не следует брать на себя обязанности тестировщика.
Читать полностью »
В прошлый раз мы рассказывали, как доказать всем участникам проекта, что тестирование — полезная штука. Надеемся, что доводы были убедительны. Теперь можно поговорить о том, как подойти к созданию и планированию тестов, их классификации и оценке.
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Читать полностью »
Закономерно, что с развитием продукта повышается и внимание к его качеству. Причем не только по части функционирования, но и в отношении пользовательской эстетики.
Несколько лет и версий назад мы столкнулись с недостаточным качеством отображения видео в Macroscop. Присутствовали “рывки”, из-за которых страдала плавность отображения, что в итоге ухудшало общее визуальное восприятие.
Когда пользователь видит, что изображение не экране “дергается”, его мало волнует, чем это обусловлено. Причин же тому может быть много, так как видеосистема состоит из многих компонент, и софт — лишь одна из них. Но мы должны были сделать все, чтобы Macroscop со своей стороны отображал максимально плавно.
А для этого разработчикам необходимо было четко понимать задачу с измеряемыми требованиями, а группе качества — иметь инструмент для оценки. В этой статье мы расскажем, какую метрику используем для измерения плавности и с помощью какого инструмента ее оцениваем.
#спойлер
Читать полностью »
