какой настрой должен быть у тестировщика
Семь правил тестировщика
«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»
Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?
Тогда прошу под кат!
Свою карьеру тестировщика я начал в одной небольшой фирме, занимающейся тестированием самолетного ПО. Там было только автоматизированное тестирование, все процессы были уже построены, в общем — не сильно сложная работа. Мне показали основы написания кода на Visual Basic, показали как запускать тесты, и отправили в дальнее плавание.
Затем моё студенчество закончилось, захотелось больше интересной работы, и я перешел в другую компанию на должность простого ручного тестировщика. Тут нужно сделать небольшое отступление — в небольших кампаниях/отделах тестировщик порой выполняет целую кучу задач, не связанных напрямую с тестированием. Например, развертывание тестовой среды, ведение нескольких веток продукта в сорс контроле, саппорт выпущенных продуктов и т.д. Я попал именно в такую ситуацию.
Поначалу все было хорошо — мы делали свой 1 проект, я все делал руками, и у меня еще оставалась куча свободного времени.
Но постепенно проектов становилось все больше, программисты постоянно фиксили баги, нужно было накатывать билды чуть ли не каждый час. В какой-то момент я заметил, что на собственно тестирование я трачу лишь 40% времени. Остальное время занимают какие-то левые активности. Тогда я понял первое простое правило:
1. Если ты тестировщик, то можно и нужно автоматизировать не только тестирование
Именно тогда я сделал простую табличку в Excel, и отметил все задачи, на которые тратилось время. И нашел то, что выжирало больше всего времени — банальная выкладка билдов (обновление файлов, екзешников и т.д.). Вечером дома я зарылся в яндекс, и нашел, как убрать эту активность в 0. Я посмотрел синтаксис билдов на нашем билд-сервере, и сделал автоматическую выкладку всего этого хозяйства. После этого я привязал запуск билда к check-in’у в сорс контроле, и обрадовался жизни — у меня опять появилось свободное время! Тогда же я понял второе простое правило:
2. Автоматизируй то, что даст наибольший выигрыш по времени
Постепенно проекты росли, и появились системы, расположенные на нескольких серверах. И, о ужас, — конфиги разработчиков не работали на серверах! А программисты почему-то(!) не хотели их править. Я опять полез ковыряться в билд-машине, и обнаружил, что конфиги можно легко менять на этапе сборки. Тогда я понял третье простое правило:
3. Полностью изучи работу билд-машины
Примерно тогда же в моем распоряжении появилась первая виртуальная ферма на Hyper-V. Через пару месяцев я уже не представлял себе, как жил до этого. Настолько легко и просто оказалось поднимать тестовые стенды! Отсюда четвертое простое правило:
4. Подними сервер виртуализации
В то время компания очень сильно выросла, и внезапно оказалось, что для простого заведения учетки в домене нужно писать заявку админам с обоснованием и подтверждениями. Какое-то время мы терпели, а потом я сделал свой тестовый домен. Через месяц я понял, что не только сервер виртуализации был необходим. Отсюда пятое простое правило:
5. Сделай, наконец, свой тестовый домен
Когда я поднимал тестовый домен, то обнаружил на сервере забавную вещь — Power Shell. Как оказалось, кучу вещей можно сделать без интерфейса — заводить пользователей, настраивать IIS, делать правила в файрволе, устанавливать сервисы и т.д. Кроме того я узнал, что это можно делать не только на своей машине!
И если какую-то задачу на удаленной машине нужно будет сделать больше трёх раз, я всегда пишу скрипт — экономия времени огромна.
В общем, шестое простое правило:
6. Разберись с PowerShell/cmd/bash
В какой-то момент я осознал, что даже не приступив к автоматизации тестирования, я автоматизировал все остальное!
Тогда я взялся делать свой первый огромный(как мне тогда казалось) проект по автоматизированному тестированию одной огромной монструозной бизнес-функции. Делал я его долго, мучительно, но все-таки сотворил. Вот только там было столько костылей, неявных зависимостей, хардкода и прочего добра, что как-либо поддерживать это создание воспаленного ума оказалось невозможным. Именно тогда я понял, почему эти умные программисты допускают столько косяков… Но это была не последняя монструозная система в моем исполнении — их было еще много. В общем, самое главное седьмое правило:
7. Хочешь автоматизировать? Учись правильно программировать! Прочитай книги по архитектуре программ
Именно тут проявила себя цитата, вынесенная в эпиграф. Только сделав несколько ужасных проектов, обломав кучу зубов на поддержке своих творений, я начал понимать то, что написали эти умные дядьки в своих книгах. Только тотальная нехватка времени и тупизна работы по копированию файликов из одного место в другое толкнули меня на путь автоматизации. Только полностью влившись в команду разработки я начал писать относительно нормальный код.
А потом я втянулся. И следующие несколько книжек в плане на прочтение — о программировании. Причем я не буду переходить в программисты, это не моё. Ну а программирующим тестировщиком я уже стал.
И главное, не нужно бояться автоматизации. Это не всегда огромные труды, которые могут принести мифическую прибыль в будущем. Посмотри вокруг! Что-то можно сделать мышкой? С вероятностью в 95% это можно заскриптовать. Ты выполняешь ручные операции уже в пятнадцатый раз? Значит заскриптовать их нужно было еще вчера.
И еще одно пожелание. Научился сам, просвети своих коллег — согласитесь, интереснее работать с людьми, которые делают красивые, сложные проекты, а не ходят в грязном свитере и страдают от своей работы.
Желаю интересных багов, хороших проектов и дружных коллег-программистов!
Чек-лист подготовки к собеседованию на позицию ручного web-тестировщика
Самые популярные вопросы:
Какие методики тестирования Вы знаете?
модульная/компонентная: проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по отдельности;
интеграционная: предназначена для проверки связи между компонентами, а также взаимодействия с различными частями системы.
системная: высокоуровневая проверка функционала всей программы или системы в целом.
приемочная: проводится на этапе сдачи готового продукта заказчику.
Именно в этом порядке программное обеспечение подвергается испытанием.
Расскажите про виды тестирования?
Все виды тестирования программного обеспечения, можно условно разделить на следующие группы:
связанные с изменениями, то есть после исправления бага/дефекта необходимо повторное тестирование, с целью убедиться, что внесенные изменения действительно решили проблему.
Что такое нагрузочное тестирование и чем отличается от стресс тестированием?
Какие бывают подходы тестирования?
Всё зависит от доступа к коду программного обеспечения.
Что такое чек-лист и как его оформлять?
Литературы по тестированию множество и вам всё не перечитать, это и не нужно! Выбирайте книгу более современную и тоньше.
Что такое web приложение? Однозначно, это клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому не избежать вопросов про сетевые протоколы взаимодействия. Могут быть общие вопросы:
Какие интернет протоколы Вам известны?
На собеседование достаточно будет рассказать про основные протоколы, углубляться в эту тему не следует. Наиболее известные протоколы:
HTTP (Hyper Text Transfer Protocol)
FTP (File Transfer Protocol)
POP3 (Post Office Protocol)
SMTP (Simple Mail Transfer Protocol)
Но основная часть вопросов будет про http и https:
Расскажите какие между ними различие?
http — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.
https — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности.
Как же ответить на вопрос «в чем отличия?», ответ кроется в их определении, а именно: https не является отдельным протоколом передачи данных, а представляет собой расширение протокола http с надстройкой шифрования; передаваемые по протоколу http данные не защищены, https обеспечивает конфиденциальность информации путем ее шифрования.
Какие Вам известны методы протокола http, расскажите вкратце о каждом?
HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса.
Метода GET в HTTP используется для получения информации от сервера. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
Метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
Метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
Метод PUT заменяет все текущие представления ресурса данными запроса.
Метод DELETE удаляет указанный ресурс.
Метод CONNECT преобразует существующее соединение в тоннель.
Метод OPTIONS используется для получения параметров текущего HTTP соединения.
Метод TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.
Метод PATCH используется для частичного изменения ресурса.
Отвечая на этот вопрос можете перечислить только основные методы.
Расскажите о структуре http-запроса и ответа?
Не пугайтесь этого вопроса, здесь следует упомянуть только про основные части http запроса: строка запроса, заголовки, тело сообщения. Нужно обратить внимание, что между заголовками и телом сообщения находится пустая строка (в качестве разделителя), она представляет собой символ перевода строки. При получении ответного запроса от сервера, тело сообщения обычно представляет собой содержимое веб-страницы.
Для расширения кругозора рекомендую прояснить понятия «Транспортный уровень», «Уровень сети интернет», «Канальный уровень».
Основы Web-программирования
Веб-приложение — клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому вопросы на собеседовании по этой теме обязательно будут!
Почему не открывается гиперссылка?
При ответе на вопрос необходимо уточнить, что у пользователя устойчивое интернет соединение. Даны следующие вводные: пользователь заходит на популярный ресурс с новостями, нажимает на «Срочная новость!», но страница не открывается. Самый простой способ разобраться в причине, это воспользоваться браузерной консолью. Открыли консоль, выбрали элемент с гиперссылкой, и анализируем какой веб-адрес указан. Самая популярная ошибка, которую находят тестировщики, это неверно указанный веб-адрес.
Почему не соответствует цвет кнопки дизайну?
Посмотреть цвет кнопки можно аналогичным способом через браузерную панель, и сравнить кодировки цвета.
Расскажите про браузерную консоль.
Панель Elements показывает разметку страницы точно так же, как она рендерится в браузере, так же можно посмотреть, как бы выглядела открытая страница на каком-нибудь девайсе с другим расширением экрана.
Панель Network. Основная функция данной вкладки – запись сетевого журнала. Она дает представление о запрашиваемых и загружаемых ресурсах в режиме реального времени.
Панель Performance. Данная вкладка используется при необходимости полного обзора затраченного времени.
Панель Memory. Данная панель дает возможность профилировать время исполнения и использование памяти веб приложением или страницей, таким образом помогая понять где именно тратится много ресурсов и как можно оптимизировать код.
Панель Application. Предназначена для исследования загруженных элементов.
Если у вас есть основы знаний HTML, CSS, JS это будет огромным плюсом, хотя бы следует развиваться в этом направлении, чтобы стать хорошим специалистом!
Что же именно входит в основы?
А что же с API?
Сложность тестирования API (программный интерфейс приложения) заключается в отсутствии пользовательского интерфейса. Поэтому нужно настроить с необходимым набором параметров среду тестирующую API, а затем проанализировать результаты теста. Какие же вопросы могут таиться:
Чем отличается REST от SOAP протокола?
REST — это архитектурный стиль. SOAP — это формат обмена сообщениям, имеет веб-сервис WSDL с прописанными методами, которые можно удаленно вызывать.
REST работает только по HTTP/HTTPS, SOAP с любым протоколом прикладного уровня: SMPT, FTP, HTTP, HTTPS, POP3.
REST более простой, гибкий и быстрый, SOAP типизированный, но в некоторых случаях лучше визуализируется за счет применения им синтаксиса похожего на HTML разметку.
Какой формат передачи информации используется в SOAP, а какой в REST?
REST использует Json и XML, SOAP только XML.
Какие инструменты вы знаете для тестирования API?
Отвечая на этот вопрос, опирайтесь на свой опыт. Список самых популярных инструментов: SoapUI, Postman, REST-Assured, Fiddler, Karate, JMeter.
Информации по API в свободном доступе огромное количество, поэтому вы сможете разобраться в этом разделе.
Как быть с автоматизацией?
Во многих компаниях активно используется автоматическое тестирование. Часто разбором результатов прогонов и анализом занимаются ручники. Поэтому нужно иметь небольшое представление, как строится процесс автоматизации и какие инструменты используются.
Если раньше в работе сталкивались с автоматизацией, то расскажите подробнее какой использовался технический стек, как происходил разбор тестов, и какой был алгоритм действий, если автотест падал с ошибкой.
Большим плюсом будет опыт работы с GIT и с базами данных.
Как работать тестировщику: выстраиваем планирование, общаемся с командой разработки и проверяем сайты на безопасность
Мы собрали митап, где трое экспертов по QA рассказали, о чем тестировщику нужно говорить с командой разработки, какими инструментами пользоваться для планирования и тестирования, а также что нужно учесть, чтобы сделать сайты безопасными. Внутри есть видео и текстовая выжимка по каждому докладу.
Современные паттерны тестирования
Рассказывает директор по развитию бизнеса в IT-компании @BSL_Dev и ex-руководитель отдела обеспечения качества Redmadrobot Марина Куликова @Marishunya_QA.
Коротко в чем суть.
Бывает, что в командах разработки забывают о принципе раннего тестирования. Существует миф, что тестирование продукта должно проходить в конце спринта или разработки. При такой организации процесса проекта могут возникать ошибки (как процессные, так и технические).
Чтобы такого не случалось, тестирование продукта должно быть в самом начале разработки. Кроме того, тестовые активности должны идти параллельно с ней. Это помогает тестировщикам оповещать команду о рисках заранее и давать обратную связь на каждом этапе, начиная от анализа требований до финальных релизных отчетов и поддержки.
Основная цель тестирования — своевременно оповещать команду о реальном состоянии системы или продукта
Основные точки опоры для построения тестирования
Анализ требований или технического задания.
Инфраструктура — важно настроить окружение, выбрать целевые устройства, какие тестовые данные потребуются.
Процесс коммуникации — нужно договориться, в каком формате мы выстраиваем обратную связь с командой (например, делаем отчеты о тестировании в Jira).
Разбираемся, как именно организовываем тестирование: какие виды тестирования, на каких этапах применяем, как распределяем ресурсы, планирование и так далее.
Уделяем время написанию отчетности и договариваемся, какая отчетность и в каком виде нужна.
Постоянно внедряем улучшения и анализируем изменения.
О чем тестировщик должен сообщать команде
Что нужно автоматизировать. В процессе коммуникации с разработчиками и менеджерами тестировщику нужно определить и рассказать, какие тесты должны быть автоматизированы и на каком уровне.
Как оптимизировать работу. Нужно делать постоянную оптимизацию тестов, чтобы они затрачивали меньше времени. Задача тестировщика — минимизировать время выполнения тестов, оптимизировать фича тесты и регресс. Это нужно, для того чтобы быстро получать информацию о состоянии продукта.
Обеспечить полезные метрики для бизнеса. Например, количество багов на продакшене, количество активностей, как двигается процесс написания документации, время, затраченное на тестирование и т.д. Такие метрики будут сигнализировать, всё ли у проекта хорошо. Кроме того, с помощью них тестировщик может показать результаты работы всей команды. Но стоит помнить, что не стоит закапываться в метриках, а нужно использовать скорее их как опорные точки. Ведь, помимо метрик, есть и другие системы отчетности.
Напоминать о новых инструментах. Важно говорить об инструментах тестирования, потому что сейчас они постоянно меняются. Стоит постоянно мониторить, как изменяются инструменты, и добавлять себе самые лучшие.
Тестирование — это как круговая оборона. Весь продукт «охранять» очень сложно, поэтому тестировщики создают «датчики» (некие красные флажки), которые в нужный момент сообщают: alarm! И подобные «датчики» — это метрики, а также автотесты, различные приемы и т.д. Задача команды тестирования выстроить многослойную систему защиты, состоящую из нужных «датчиков». Также стоит помнить, что помимо того, что QA тестирует, команда ещё сообщает реальное состояние системы, где все окей, где начинает «рваться», а где все плохо и нужно срочно исправлять.
Как тестировщику обеспечивать обратную связь для команды
С помощью парного тестирования или программирования. Автоматизацию тестирования полезно делать при поддержке разработчиков. На этом этапе должно происходить взаимное ревью, это помогает тестировщику глубже узнать систему и уже на этом этапе обнаружить какие-то проблемы.
С помощью Code Reviews. Это не совсем работа тестировщика, но в проекте через Code Reviews можно получить обратную связь. Например, если у нас фича автоматизации типовая, и она долго ревьюится на разных проектах, то нужно выяснить причину.
Через модульные тесты (Unit tests).
С помощью автоматизированных интеграционных тестов (Automated Integration Test).
С помощью автоматизированных Acceptance Tests. Эту активность можно разделить с продакт-менеджерами.
По возможности следует автоматизировать Regression Test.
Постоянный Exploratory Testing.
Обратная связь от пользователей или бизнес-юзеров.
Постоянное UAT-тестирование + DEMO-сессии.
Через что тестировщик может организовать обратную связь с командой
С помощью работы с дефектами (багами) — нужно определить формат их заведения и оповещения о них, например, делать это в Jira или другом удобном инструменте. Разработчикам не всегда хватает информации в дефекте, чтобы приступить к фиксу, поэтому иногда требуется дополнительная коммуникация с багрепортером.
Организовать коммуникацию по сборкам и состояниям тестовых сред. Это понадобится, если вдруг с ними что-то пойдет не так или они задерживаются.
Кросс-обучение внутри тестирования. Все специалисты разные, они могут учиться друг у друга, поэтому важно иногда собираться и обсуждать результаты работы и делиться лайфхаками и знаниями продукта. Это некий knowledge transfer.
Тест-документация — собирать отчетность по фичам, сборкам и по приемке. Для составления отчетности поможет изучение ГОСТов: в них описаны градации дефектов, как с ними быть и так далее. Для проектов, связанных с государственным подрядом, поможет изучение ГОСТ 34.603-92.
Как тестировщикам работать с Google-таблицами (и зачем)
Руководитель отдела тестирования Redmadrobot Саша Строкин собрал собственные Google-таблицы, с помощью которых он выстраивает работу, начиная от планирования и заканчивая аналитикой для тестировщиков.
На нескольких примерах Саша рассказал об инструментах и формулах, которые он использует в работе.
Google-таблицы при планировании — подготовка к процессу тестирования
В тестировании есть четыре главных процесса:
Планирование — подготовка к самим работам по тестированию,
Test development — крафтинг артефактов, разработка сценариев тестирования,
Test execution — само выполнение тестирования,
Test analysis — оценка результатов тестирования, выделение процессов, которые нужно улучшать или, наоборот, не стоит менять.
Планирование в Google-таблицах — это инструмент, необходимый в первую очередь для лидов, чтобы вовремя подключать и отключать нужных людей, проводить ротации, отслеживать нагрузку сотрудников.
Чтобы облегчить процесс планирования, в Sheets можно создать вкладку Dictionary, где описываются все существующие проекты для работы, список участников, роль инженера на проекте и так далее.
Стоит отметить, что Google Sheet позволяет добавлять отдельные срезы, если мы говорим про фильтрацию данных, ее можно делать как на уровне всей таблицы, так и по отдельным критериям. Например, если нажать на вкладку с указанием определенного проекта, то увидим, сколько инженеров на данный момент в нём задействовано и процент их загрузки.
Интеграция Google-таблиц с Jira
Интеграция Excel c рабочим инструментом большинства команд разработки и тестирования — Jira — возможна через специальный плагин — Jira Cloud of Sheets.
C помощью этого плагина можно «вытаскивать» любые данные из бэклога Jira по тому же фильтру, по которому обычно тестировщики фильтруют дефекты, только с переводом не на графическое изображение, а на JQL.
На примере Саша показал, как решил проверить все свои дефекты и собрать на этом фоне статистику. За время работы над проектом в общей сложности было заведено 1500 дефектов и по ним была сформирована статистика. Можно посмотреть, например, какие из них обладают уровнем приоритетности. Также можно в виде графиков формировать статистику по практически любым показателям.
Кроме того, с помощью плагина можно выгрузить статистику по отдельным проектам и посмотреть статистику по нему. Можно проанализировать, как проекты обрастают дефектами в динамике и увидеть, что, например, в июне и июле на проекте было заведено больше всего багов.
Для формирования такой статистики нужно воспользоваться вкладкой MounthStat (она вытягивает данные о дате создания из общей выгрузки, где мы можем выбрать дату создания дефекта). С помощью функции Trim даты можно рассортировать по месяцам.
Тестирование и безопасность web-сайтов для начинающих тестировщиков
Рассказала и показала QA-инженер Redmadrobot Вика Бегенчева @vikusti.
Основные уловки мошенников, как они могут навредить пользователям или системам:
С помощью cookies
Вика рассказала, что такое cookies на примере интернет-магазина. Допустим, мы открываем браузер, заходим на сайт и кладем в корзину печеньки, которые нам понравились. Если мы закроем окно браузера, а затем откроем заново, то вся информация про начавшиеся покупки сохранится. Это происходит с помощью cookies — различной информации о пользователе, которая хранится в браузере локально.
Эта информация нужна для удобства пользователя, чтобы сайт «запоминал» определенные данные и нам не приходилось постоянно их указывать. Cookies бывают двух видов: временные (cookies-сессии) и постоянные. Cookies-сессии хранятся определенное ограниченное время и могут меняться, когда пользователь перелогинился. Постоянные сookies хранятся всегда, пока вы их не сотрете.
Как хакеры могут использовать cookies
Хакер может «угнать» ваши cookies и с помощью этого «доказать» системе, что он — это вы. Тогда он сможет переиспользовать их и продолжить сессию. Это происходит так:
Через протоколы: HTTP и HTTPS
Копаясь на просторах интернета, мы до сих пор можем попадать на сайты, о небезопасности которых нас предупреждает браузер.
Почему так? Потому что браузер умный, и он считает ненадежным сайты, в которых происходит соединение по HTTP, а не HTTPS. В протоколе HTTPS есть последняя буква S, это значит, что добавляются повышенные требования к безопасности. В этом протоколе при общении браузера с сервером по протоколу https добавляется сертификат безопасности: если хакер попробует перехватить такие запросы, он получит лишь набор символов и не сможет их расшифровать.
Подбор пароля — Brute force
Это атака перебора — мошенник может знать логин и с помощью специального скрипта подбирать пароль. Обычно подбор пароля с помощью скрипта занимает около 10 часов.
Как проверять сайты на безопасность
Посмотреть, как устроена безопасность хранения cookies: открываем «Инспектор» в браузере, заходим в вкладку application и видим свои cookies для сайта. Для проверки безопасности нужно обратить внимание на столбцы под названием httpOnly и secure. Если галочки стоят, то на сайте предусмотрена защита от угона cookies.
Нужно проверять, чтобы все запросы шли через протокол HTTPS. Например, работаем с сайтом диванынадом.ру. Нужно убрать букву S из протокола и проверить, можно ли зайти только по ссылке с HTTP. Если да, то это плохо, мошенник может создать такую ссылку и перехватывать запросы пользователей. Чтобы этого избежать, нужно создать редирект — автоматически перебрасывать пользователей на безопасную страницу.
При введении логина/пароля нужно использовать ограничение на количество неправильных попыток, а также использовать таймаут, например, после трех неудачных попыток введения пароля попробовать ввести пароль в четвертый раз можно лишь через час. Это поможет избежать взлома с помощью автоматического подбора паролей.
Вика написала отдельную статью, где подробно рассказала про все пункты и дала еще больше советов для начинающих тестировщиков.
Полезные ссылки
Telegram-канал «Google Таблицы»: много информации о фишках Google Sheets;
YouTube STM Solutions: видеоуроки Google Docs, Google Sheets, Google Apps Script;
Jira Cloud for Sheets: плагин для интеграции Google Sheets с основным рабочим инструментом большинства команд — Jira;
owasp.org: некоммерческий фонд, который работает над повышением уровня безопасности ПО;
hackthebox.eu: тренировочная онлайн-платформа, на которой можно проверить навыки тестирования в сфере безопасности сайтов;
xss-game.appspot.com: тренировочная игра для обнаружения и устранения ошибок XSS.
Кстати, мы ищем QA-специалистов в команду, залетайте посмотреть.