Одни из частых заблуждений тестировщиков заключаются в том, что дефекты нужно искать после того как закончена реализация продукта или его части, а аналитика — «священная корова», которая не может ошибаться. Но это отнюдь не так, и тестировщики не должны бояться брать под сомнения адекватность требований.
В данном докладе мы детальнее рассмотрим:
почему упущенные проблемы на этапе построения требований к продукту гораздо серьезнее в перспективе для пользователя и сложнее в исправлении, чем таковые на более поздних этапах;
о том, как не допустить подобного негативного явления в своей практике;
а также о том, как устранять последствия, если ситуация уже зашла далеко.
В качестве примеров будут представлены несколько кейсов, как тестировщик мог сделать жизнь пользователям проще на основе опыта тестирования интеграции.
Доклад будет интересен всем, кто сомневается в необходимости тестирования требований, а также тем, кто знает, что нужно изменить, но не может определиться, как реализовать на практике.
Когда восемнадцать лет назад я проходил свой первый курс по тестированию, я узнал, что типичный тест-проект состоит из тест-стратегии, тест-плана, тест-сценариев, выполнения тест-кейсов и отчетности о результатах. Еще мне говорили, что тестирование – это профессия, и для хорошего тестирования нужны профессиональные тестировщики.
Однако иногда вы оказываетесь в ситуации, когда это не лучший способ тестировать. В этой статье я описываю проект, в котором тестирование проводилось иначе, без профессиональных тестировщиков. Теперь я знаю, что некоторые называют такой подход «охотой на баги», и я убежден, что в этой конкретной ситуации охота на баги – лучший выход.
Как показать заказчику, что согласованного времени не хватает на тестирование? Что поможет не пропустить ни одного бага? Эти проблемы мы решили в марте. Что же нам помогло?
Нашими спасателями стали тест-анализ, планирование и прозрачная отчетность! Надеемся, что наша статья поможет вам обойти грабли, на которые наступили мы.
1. Внедряем прозрачную отчетность
На проекте по тестированию мобильного приложения возникла путаница с тестовой документацией, а именно с тест-кейсами и чек-листами. Проблема заключалась в том, что заказчика вообще не интересовала наша документация, и он не спешил согласовывать правильность составленных чек-листов и тест-кейсов. Совершенно не выделялось время как на написание и актуализацию документов, так и на смоук и регрессионное тестирование перед релизами; они выполнялись лишь частично в редкие свободные моменты. Такая ситуация длилась долгое время и привела к тому, что на продуктиве начали сыпаться критические и блокирующие дефекты. Соответственно, у целевой аудитории нарастало раздражение при пользовании продуктом.
Прошло довольно много времени с момента нашейпоследней статьи об эффективной Selenium-инфраструктуре. Если вы находитесь в самом начале непростого пути Selenium — советую ознакомиться с нашими статьями про масштабируемый Selenium (часть I, часть II), Selenoid — универсальный инструмент для автоматизации тестов в браузерах (раз, два), Selenium под Windows (ссылка). Если вам больше нравятся мотивирующие рассказы — посмотрите видео моего доклада про масштабируемый Selenium на SeleniumConf Berlin 2017.
С момента публикации последней статьи в нашем сообществе произошло много интересного. Сегодня я хочу рассказать о самых важных возможностях, добавленных в наши инструменты за последние месяцы.
Если долго ведешь блог, то одним из забавных результатов становится то, что люди начинают воспринимать тебя как эксперта. Так это или не так в моем случае – вам судить. В любом случае ко мне обращаются за советами по поводу карьеры, а также спрашивают, знаю ли я, куда движется отрасль. Отвечать на первую часть я здесь не буду – нет такого понятия, как общие советы по карьере, а делиться вопросами, которые мне задавали, и моими ответами мне неловко.
В этой статье я поделюсь своими мыслями на тему «куда движется отрасль». Вы все равно увидите в ней скрытые карьерные советы.
Последний и самый короткий месяц зимы выдался необычайно насыщенным новаторскими подходами и свежими решениями в автотестировании. Сегодняшнее повествование целиком и полностью посвящено автоматизации, и для этого есть множество причин:
автоматизация — это высшее благо при проведении регрессионного тестирования!
автоматизация помогает исключить человеческий фактор, а значит минимизировать ошибки!
все, что может быть автоматизировано, должно быть автоматизировано!
А теперь с удовольствием и гордостью представляем на ваш суд каждое достижение, успешно реализованное нами в феврале.
Затем задумайтесь о том, как люди участвуют в тест-автоматизации в зависимости от того, где они в этой модели находятся. Изначально я пометила части диаграммы как доступ, навыки и мотивацию:
Все приложения можно условно разделить на «спринтеров» и «марафонцев». Спринтеров запускают редко и ненадолго — например, интернет-банк для проведения разовых операций. Марафонцы же включены у своих пользователей постоянно: текстовые редакторы, бухгалтерские программы, системы документооборота и т.д.
Если ваш продукт — марафонец, то вам просто необходимо тестирование надёжности (aka reliability testing). В рамках такого тестирования мы проверяем, как продукт ведёт себя при длительном использовании, не наблюдается ли утечек памяти, не растут ли используемые ресурсы, не возникают ли непредвиденные ошибки.
В своём докладе Олег расскажет, как проводить автоматизированное тестирование надёжности веб-приложений при помощи Selenium Web Driver.
По итогам этого доклада вы узнаете:
Какие критичные ошибки «марафонцев» можно пропустить, не уделяя достаточно внимания тестированию надёжности
Что такое утечки памяти, и почему растёт память браузера при длительном использовании продукта
Почему автоматизация тестирования — наиболее оправданное решение для тестирования надёжности
С чего начать автоматизацию reliability тестов, и как это лучше всего сделать.
Доклад будет полезен всем, кто занят тестированием регулярно и подолгу используемых программных продуктов.
Это письменная версия моего выступления на официальной конференции по Selenium в Берлине. Если вы предпочитаете посмотреть доклад, он доступен здесь: Selenium YouTube channel.
Как ваши коллеги вкладываются в автоматизацию?
Кто участвует в дизайне, разработке и поддержке наборов тестов?
Что произойдет, если люди в вашей команде изменят свой вклад в автоматизацию?
— Итак, поступило новое дело: в нашем распоряжении 10 дней для поиска места тестировщика в Scrum разработке. Необходимо понять, что же это такое Scrum, что входит в это понятие, кто вовлечен в этот процесс, и что именно необходимо делать тестировщику.
— Шеф, так что же такое Scrum?
— Все элементарно, коллега. Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в установленные небольшие промежутки времени предоставлять заказчику (конечному пользователю) наделенное наибольшим приоритетом работающее ПО с новыми возможностями.
— И из чего состоит этот процесс?
— Из принципов, скоупа задач, определенных при планировании, и ограниченных (четко оговоренных и определенных) сроков. Учитывается и то, что качество не должно пострадать из-за скорости или установленных временных рамок.
— Шеф, и с чего начнем?
— А начнем с того, что рассмотрим наиболее простую и понятную схему для Scrum процесса: двухнедельная итерация (10 рабочих дней). При этом мы имеем определенно важный спринт, сплоченную команду разработки и тестирования, минимум документации, четкие требования к проекту и лаконичное описание требуемых разрабатываемых фич.
— И где же в этой схеме место тестировщика?
— А в этом нам предстоит разобраться, коллега!)
