Иногда я думаю о том, чего люди ожидают от вида тестировщика в процессе тестирования? Как, с их точки зрения, выглядит «тестирование»?
Если я заменю «тестировщика» на «программиста» или «разработчика» (а тестирование – на программирование или разработку), что вы себе представите? Когда я говорю, что я тестировщик, зачастую на меня тупо пялятся в ответ – как минимум тогда, когда я разговариваю с людьми, не работающими в сфере ПО. В результате я немного рассказываю про то, как я помогаю разрабатывать ПО и трачу время на выяснение, получат ли люди в итоге то, что на самом деле хотят – это определение, я надеюсь, легче для понимания. Дискуссия становится более прямолинейной, если мои собеседники тоже заняты в сфере ПО, но даже тогда я часто сталкиваюсь с целой линейкой предположений о том, что такое тестирование, или чем оно может быть.
Мобильные дип линки (mobile deep links) все чаще используются во многих мобильных приложениях, но до сих пор многие разработчики и тестировщики сталкиваются с различными проблемами при их разработке и интеграции. Мы в GetSocial более 4 лет разрабатываем свое deep links решение. За это время мы столкнулись со множеством изменений в мобильной экосистеме, включая изменения в ОС, браузерах и стандартах самих дип линков.
В этой статье описаны самые распространенные проблемы при работе с дип линками, а также советы по их тестированию. Но для начала короткое напоминание, что они из себя представляют.
Дип линкинг (deep linking) позволяет конечному пользователю открыть страницу с нужным контентом внутри мобильного приложения, минуя его домашнюю страницу и минимизируя трату времени на поиск необходимого контента.
Автоматизатор мобильных приложений – одна из наиболее высокооплачиваемых профессий на рынке. Учитывая дефицит кадров, многие автоматизаторы стоят дороже программистов. Поэтому любому хорошему тестировщику стоит освоить базовые навыки мобильной автоматизации.
В мае мы запустили новый тренинг "Автоматизатор мобильных приложений", который дает все необходимые навыки для самостоятельной настройки полного стека автоматизации с нуля.
Курс состоял из пяти тем. И сейчас в нем добавился новый урок, Continious Integration.
Одни из частых заблуждений тестировщиков заключаются в том, что дефекты нужно искать после того как закончена реализация продукта или его части, а аналитика — «священная корова», которая не может ошибаться. Но это отнюдь не так, и тестировщики не должны бояться брать под сомнения адекватность требований.
В данном докладе мы детальнее рассмотрим:
почему упущенные проблемы на этапе построения требований к продукту гораздо серьезнее в перспективе для пользователя и сложнее в исправлении, чем таковые на более поздних этапах;
о том, как не допустить подобного негативного явления в своей практике;
а также о том, как устранять последствия, если ситуация уже зашла далеко.
В качестве примеров будут представлены несколько кейсов, как тестировщик мог сделать жизнь пользователям проще на основе опыта тестирования интеграции.
Доклад будет интересен всем, кто сомневается в необходимости тестирования требований, а также тем, кто знает, что нужно изменить, но не может определиться, как реализовать на практике.
Когда восемнадцать лет назад я проходил свой первый курс по тестированию, я узнал, что типичный тест-проект состоит из тест-стратегии, тест-плана, тест-сценариев, выполнения тест-кейсов и отчетности о результатах. Еще мне говорили, что тестирование – это профессия, и для хорошего тестирования нужны профессиональные тестировщики.
Однако иногда вы оказываетесь в ситуации, когда это не лучший способ тестировать. В этой статье я описываю проект, в котором тестирование проводилось иначе, без профессиональных тестировщиков. Теперь я знаю, что некоторые называют такой подход «охотой на баги», и я убежден, что в этой конкретной ситуации охота на баги – лучший выход.
Как показать заказчику, что согласованного времени не хватает на тестирование? Что поможет не пропустить ни одного бага? Эти проблемы мы решили в марте. Что же нам помогло?
Нашими спасателями стали тест-анализ, планирование и прозрачная отчетность! Надеемся, что наша статья поможет вам обойти грабли, на которые наступили мы.
1. Внедряем прозрачную отчетность
На проекте по тестированию мобильного приложения возникла путаница с тестовой документацией, а именно с тест-кейсами и чек-листами. Проблема заключалась в том, что заказчика вообще не интересовала наша документация, и он не спешил согласовывать правильность составленных чек-листов и тест-кейсов. Совершенно не выделялось время как на написание и актуализацию документов, так и на смоук и регрессионное тестирование перед релизами; они выполнялись лишь частично в редкие свободные моменты. Такая ситуация длилась долгое время и привела к тому, что на продуктиве начали сыпаться критические и блокирующие дефекты. Соответственно, у целевой аудитории нарастало раздражение при пользовании продуктом.
Прошло довольно много времени с момента нашейпоследней статьи об эффективной Selenium-инфраструктуре. Если вы находитесь в самом начале непростого пути Selenium — советую ознакомиться с нашими статьями про масштабируемый Selenium (часть I, часть II), Selenoid — универсальный инструмент для автоматизации тестов в браузерах (раз, два), Selenium под Windows (ссылка). Если вам больше нравятся мотивирующие рассказы — посмотрите видео моего доклада про масштабируемый Selenium на SeleniumConf Berlin 2017.
С момента публикации последней статьи в нашем сообществе произошло много интересного. Сегодня я хочу рассказать о самых важных возможностях, добавленных в наши инструменты за последние месяцы.
Если долго ведешь блог, то одним из забавных результатов становится то, что люди начинают воспринимать тебя как эксперта. Так это или не так в моем случае – вам судить. В любом случае ко мне обращаются за советами по поводу карьеры, а также спрашивают, знаю ли я, куда движется отрасль. Отвечать на первую часть я здесь не буду – нет такого понятия, как общие советы по карьере, а делиться вопросами, которые мне задавали, и моими ответами мне неловко.
В этой статье я поделюсь своими мыслями на тему «куда движется отрасль». Вы все равно увидите в ней скрытые карьерные советы.
Последний и самый короткий месяц зимы выдался необычайно насыщенным новаторскими подходами и свежими решениями в автотестировании. Сегодняшнее повествование целиком и полностью посвящено автоматизации, и для этого есть множество причин:
автоматизация — это высшее благо при проведении регрессионного тестирования!
автоматизация помогает исключить человеческий фактор, а значит минимизировать ошибки!
все, что может быть автоматизировано, должно быть автоматизировано!
А теперь с удовольствием и гордостью представляем на ваш суд каждое достижение, успешно реализованное нами в феврале.
Затем задумайтесь о том, как люди участвуют в тест-автоматизации в зависимости от того, где они в этой модели находятся. Изначально я пометила части диаграммы как доступ, навыки и мотивацию:
