Привет тебе, хабр! Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе в нашем 2к17 году.
Если разбить статью на части, то она будет выглядеть так:
Источники информации для максимально успешного тестирования
Никто не любит наступать на одни и те же грабли. Чтобы избегать их на этапе анализа и тестирования требований, мы завели общую шпаргалку. Она включает в себя те вопросы, которые в идеале должны быть выявлены и зафиксированы до разработки. Мы используем её как чек-лист, с помощью которого стараемся глубже вникнуть в логику мобильного приложения и разобраться, какие потенциальные проблемы могут возникнуть у пользователя.
Статья ориентирована на тестировщиков, которых просят провести ревью ТЗ и найти в нём несоответствия, и на аналитиков, которым разработчики после прочтения ТЗ часто задают вопросы формата: «А что должно быть, если …?».
Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.
Сегодня я расскажу о том, как мы в Badoo упростили работу с Selenium-тестами, научили ребят из отдела ручного тестирования работать с ними и какой профит с этого получили. Прочитав статью, вы сможете оценить трудозатратность каждого из этапов и, возможно, захотите частично перенять наш опыт.
В предыдущей статье я рассказывала, как в нашей компании проходит первая стадия тестирования проекта — анализ. Сегодня расскажу о следующем этапе — проектирования и документирования тестов.
Этот этап опционален. На некоторых проектах нет задокументированных требований, и тогда зачастую поддержка тестовой документации является единственным разумным способом хранения и передачи знаний о продукте. Иногда тестовую документацию требует заказчик, иногда мы пишем ее для себя. Иногда, если у нас есть хорошо написанные требования, мы отказываемся от документирования тестов в пользу экономии ресурсов.
Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.
Каждая по-настоящему революционная технология проходит четыре стадии развития: идея, демо, успешных проект, массовый продукт. Это хорошо заметно на примере мультитач-устройств. Давайте оглянемся на предыдущие годы и посмотрим, какова ситуация с технологией дополненной реальности, и пофантазируем, какой она может стать в качестве действительно массового продукта.
У каждого тестировщика рано или поздно наступает неловкий момент. Обнаружился вредный баг и его необходимо локализовать. По закону подлости баг воспроизводится нестабильно, при непонятных шагах и только на некоторых устройствах. Есть логи, но они не информативны. Разработчик занимается новой функциональностью, он не может отвлечься от текущих задач, пока не будут найдены четкие шаги воспроизведения. Менеджер ждет исправления (надо быстрее, заказчик переживает).
Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.
Привет тебе, хабр! Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе в нашем 2к17 году.
