«Это должно быть сделано еще вчера», «Протестируйте как-нибудь быстренько», «Время от начала разработки до выкладки на продакшн должно быть минимальным, а если возможно — еще меньше» — наверное, многим знакомы подобные цитаты. И покуда мы (тестировщики) — одно из последних звеньев в цепочке разработки, именно нам чаще всего приходится балансировать между скоростью выхода фич и их качеством.
В данной статье хочу поделиться тем, как мы в нашей компании применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваются тестировщики при использовании данной методологии и как мы с этими трудностями справляемся.
Пара слов о себе: я тестировщик, имела опыт работы в проектах разного масштаба, была единственным тестировщиком на проекте и работала в командах, в которых использовались разные подходы и методологии. По моему опыту, работать по Lean Startup — это круто, но тут есть и подводные камни для тестирования, о которых неплохо знать заранее.
Для начала стоит немного рассказать о том, чем занимается наша компания. Туту.ру — сервис по онлайн-покупке ж/д, авиа- и автобусных билетов, туров и других вещей, связанных с путешествиями. Один из наших проектов — "Туры" — еще в стадии активного развития, он очень динамичен, функциональность быстро меняется. Наши PO (продукт-оунеры) практикуют Lean Startup, и в частности мы проводим очень много экспериментов.
Тестирование – это очень широкая область. У вас не будет свода правил насчет того, как именно должна тестироваться определенная система. Однако вы всегда можете выявить какие-то способы и уловки, которые в большинстве случаев, если не всегда, сработают. Все они приведут к тому, что вы будете лучше знать тестируемую систему, а это жизненно важно в тестировании. Порядок нижеследующих советов – это порядок, в котором вы должны действовать, чтобы лучше познакомиться с ПО.
Покопайтесь в нем
Это самый важный совет. Начиная тестировать, НЕ ищите спецификации и требования. Все, что вам нужно знать –это базовую идею о том, что система предположительно должна уметь делать. Как она это делает, мы сейчас выясним.
Это дает вам возможность посмотреть на систему глазами нового пользователя. Суть совета в том, что большинство пользователей смотрят в инструкцию, как чем-то пользоваться, только если не могут разобраться самостоятельно. Если пользователю трудно разобраться в вашей системе, обратите внимание на ее удобство использования.
На этом шаге вы должны выяснить многое о том, как система работает, какова ее основная функциональность, и каким образом можно с этой функциональностью общаться.
Во время тестирования веб-приложения нужно обращать внимание на нижеперечисленные пункты. Этот чеклист применим практически к любому типу веб-приложений в зависимости от бизнес-требований.
Чек-лист для тестирования веб-приложений состоит из:
Тестирования удобства использования.
Функционального тестирования.
Тестирования совместимости.
Тестирования баз данных.
Тестирования безопасности.
Тестирования производительности.
Теперь давайте рассмотрим каждый пункт по отдельности.
Исследовательское тестирование — термин, применяемый в противопоставление сценарному подходу к тестированию. Думаю, нет нужды говорить, насколько потрясающих результатов можно достичь, совмещая оба этих подхода, но чаще всего у нас просто не хватает времени на развернутый анализ и полноценное проектирование тестов.
Именно поэтому наиболее удачным решением может оказаться выбор исследовательского тестирования в моно-варианте. Поскольку сам термин «исследование» подразумевает индивидуальную заинтересованность и вовлеченность в процесс, мы все сразу же задумываемся о подводных камнях данного подхода.
Конечно, говоря о тестировании, нельзя не упомянуть распространенные ошибки самих тестировщиков. Есть такой психологический момент: если не обозначены рамки, то начинает казаться, что можно делать всё, что угодно. И этот процесс будет называться тестированием. Многие начинающие тестировщики совершенно необоснованно думают, что «исследовательское» тестирование позволяет не соблюдать основные принципы тестирования.
Для выступления на конференции COMAQA Birthday 2016, посвященной двухлетию сообщества, были отобраны доклады на самые актуальные темы тестирования: об опыте применения автоматизации и последних тенденциях в этой области, тестировании мобильных приложений, тестировании требований и об использовании пирамиды тестирования Коэна через призму калькулятора ROI.
Если вам не удалось лично присутствовать на мероприятии или посмотреть прямую трансляцию, вам будет интересно узнать, как все проходило. Ниже записи докладов, прозвучавших на конференции:
Марта Веренчикова: Автоматизация Canvas: сложно, но возможно
Роман Сорока: ScreenPlay Design Patterns for QA Automation
Вадим Зубович: Как находить ненаходимое: возможности CSS и XPATH локаторов
Владислав Романенко: Эвристики, мнемоники и другие греческие слова в исследовательском тестировании мобильных приложений
Никита Сысков: Работа с бизнес-требованиями на стадии выхода продукта
Антон Семенченко: Пирамида Тестирования через призму ROI калькулятора и прочая геометрия
Наши партнеры и коллеги, Слава Панкратов и Александр Орлов (Стратоплан), на этой неделе устраивают Большую Распродажу всех материалов Школы менеджеров, потому что Годовой программы Школы менеджеров в таком формате, как она существовала до сих пор, больше не будет.
В распродажу входят записи 22 курсов, 3 конференций, 3 справочников. В штуках это 435 видео, суммарно на 368 часов (приблизительно) контента об управлении людьми / проектами, ведении переговоров, о переходе в позицию менеджера начального и среднего уровней плюс дополнительные материалы на другие полезные темы.
Стоимость оригинальных материалов сложно подсчитать, поскольку это архив курсов за несколько лет работы и некоторые программы больше не проводятся, тем не менее каждый из них стоил от $180 до $700 за курс.
В рамках Ликвидации Склада 2017 все материалы продаются за $350 / 19 980 руб. / 9 540 грн.
Последний раз подобное мероприятие проводилось в 2013 году. Кто упустил возможность в тот раз, сейчас могут наверстать упущенное и получить гораздо больше.
Предложение действует до пятницы, 10 марта 18.00 MSK.
Тестирование клиент-серверных мобильных приложений - пожалуй, одна из наиболее сложных задач в отрасли. К проблемам фрагментации девайсов и ОС добавляются проблемы со связью и возможные баги на самом сервере. В таких условиях нужно тестировать каждую из областей изолировано, чтобы проблемы с приложением не мешали и не замедляли проверку клиент-серверного протокола. Поэтому тестировщикам часто необходимо перехватывать запросы от приложения к серверу, а зачастую и подменять их. Для этого стоит научиться пользоваться инструментами перехвата трафика.
В качестве такого инструмента отлично подходит Charles Proxy Server, который создаёт на машине тестировщика прокси, через который можно пускать запросы, в том числе и от смартфона. Проще всего его использовать, конечно, с эмулятором, однако это возможно далеко не всегда. Поэтому мы сделали небольшой обучающий ролик, в котором показано, как настроить работу прокси с минимальными усилиями.
Этот ролик является частью курса "Тестирование мобильных приложений", следующая группа которого стартует уже через неделю. Если вас заинтересовал этот тренинг - можете почитать отзывы или записаться на участие. Больше роликов, посвящённых тестированию мобильных приложений, вы можете увидеть на канале в Youtube
Насколько детальным должно быть исследовательское тестирование?
Я наткнулась на этот вопрос в темах Cambridge Lean Coffee, которые Джеймс Томас собирает в своем блоге. Этот вопрос я слышу достаточно часто, и регулярно использую одну и ту же аналогию в моем ответе: маятник тестирования.
Когда тестировщик начинает работать в новой организации – или над новым проектом – то маятник нашего тестирования начинает свое движение. Думайте об этом, как будто вы поднимаете маятник в его наивысшую точку и затем отпускаете его. Вначале он раскачивается от поверхностного тестирования, отражая ограниченные знания о новой для нас ситуации. Когда наш опыт улучшается, углубляется и наше тестирование.
Для начала скажем несколько слов о проекте. Существует сайт букмекерской конторы для принятия ставок онлайн. До начала работ по автоматизации каждый ручной сет регрессионных тестов занимал около двух дней, релизы проводились примерно раз в неделю. Главным ожиданием заказчика от автоматизации было максимально возможное покрытие регресса автотестами, а также ускорение этого процесса.
Забегая вперед, отмечу, что сейчас релизы проходят каждый день или через день, а ручная часть тестов (то, что оказалось невозможно автоматизировать по тем или иным причинам) занимает примерно столько же времени, что и прогон автотестов с просмотром результатов.
Эта статья о том, что беспокоит меня уже довольно давно и продолжает всплывать по ряду причин. Когда я разговариваю с клиентами, вижу дискуссии на ЛинкедИне или StackOverflow, или читаю блог об автоматизации, слишком часто я вижу нечто вроде "как мне решить проблему А при помощи инструмента Б" (где инструмент Б, как правило, Селениум). То, что меня беспокоит – это вопрос "как". У меня дергается глаз, потому что вместо этого "как" мне хочется спросить "зачем". Точнее говоря, "зачем и какого черта это вообще делать"?
Где-то полгода назад я писал про это пост на LinkedIn. Он не изменил мир, я все еще вижу кучу "как" там, где, думается мне, спрашивать надо "зачем". Но, как изящно выражаются на латыни, repetition mater studiorum est (повторение – мать учения).
Я думаю, стоит повторить: задавая вопрос, связанный с автоматизацией, спросите себя "зачем", перед тем , как начинать думать, "как".
