Лига тестировщиков
133 поста
•
2 984 подписчика
Все проблемы IT-компаний
Когда надо найти виновного во всех бедах, но всех кого можно обвинить сидят с тобой за столом.
Показать полностью
1
QA Girls (facepalm)
Я Senior QA в большой аутсорсной конторе, пришла в индустрию потому что мне всегда нравилось делать мир правильнее, лучше и багфри. Но оказывается моя профессия это прибыльно и к нам идут только ради наживы:
Пол года в тестировании или взгляд с колоколенки
Почти год назад я спрашивал мнения у вас, ребята, по поводу профессии тестировщика. Было много дельных советов, и не очень, но все они были полезны в коей-то мере. И вот, я уже ровно 7 месяцев как тестировщик. Возможно, что кому-то будет полезен пост. Вероятно, что именно ты задумываешься о том, чтобы начать строить карьеру в тестировании, но пока обременён другими заботами. Я постараюсь максимально простым языком поделиться своим скромным опытом, и возможно, повлиять на твоё решение в вопросе "хочу ли я быть тестировщиком?".В общем, заваривай чайку, хватай печенюги и усаживайся поудобнее. А я беру бокал креплёного и начинаю.
Преамбула.
Войти в Ай-Ти или хлопоты "входа"
Немного цифр. После окончания универа по профилю "Энергетика" я уже окончательно для себя решил, что хочу быть тестировщиком. У меня всегда была тяга к тому, чтобы всё, чем я пользуюсь было идеальным + большое увлечение компами и еже с ними. Небольшой опыт кодинга (говно-кодинга) в конце 10-11 класса школы и первых курсов универа, но со временем всё забылось. После получения заветной корочки и месяца беспросветных кутежей, я составил резюме и начал шерстить вакансии на хх. И вот, первый отклик. Мне выслали тестовое задание, с ним я к сожалению не справился. Как говорится, первый блин комом. Затем почти один за одним были еще 3 ответа к моим откликам. Каждая компания высылала тестовое задание, которые я уже успешно выполнил и впереди у меня состоялись 3 первых в моей жизни собеседования. Первые два я успешно провалил, а на третьем, уже имея некоторый опыт в общении с HR и тестировщиками, успешно его прошел. Спустя приблизительно неделю в один жаркий летний день мне позвонили и сообщили, что с 1 сентября я выхожу на работу. Это была моя маленькая победа. К слову, я даже рад, что в предыдущие места меня не взяли, но об этом дальше.
Ах да, цифры, подытожим - 4 отклика, 4 тестовых задания, 3 собеседования, 1 успешное, затраченное время около 3 недель.
Испытательный срок или оклад за обучение
После оффера (успешного прохождения собеседования и приглашения на работу) я начал усиленно готовиться, читал блоги, смотрел видео, впитывал и вкушал опыт других, бывалых тестировщиков. Первые два месяца я приходил на работу и изучал документацию по продукту, который мне предстояло тестировать, смотрел видео-уроки (записывали их тестировщики из компании). Очень круто, что для лёгкого входа новичков был весь необходимый материал, это очень помогло. В течение месяца я каждый день изучал новое, а два раза в неделю общался с менеджером разработки (член команды, который ставит задачи, общается с заказчиками и вообще, занимается многими организационными вопросами + защищает нас от других команд, которые хотят скинуть свои косяки на нас), рассказывал ему, что нового узнал, отвечал на его вопросы. Честно, я ощущал себя идиотом, который нифига не понимал, но очень хотел и старался вникнуть в процесс. Какие-то непонятные названия, странные слова Agile, Scrum, МР, ПМ, Тим-лид и прочие, уже кажутся такими простыми и примитивными, но тогда, будучи совсем зелёным, я их до конца не мог сложить воедино. Первые три месяца пролетели быстро, но их я запомню на всю жизнь - это самое болезненное время, когда много, просто невероятно МНОГО информации, которую нужно усвоить и научиться использовать.
И вот, наступил декабрь. К этому моменту я успешно прошёл испытательный срок. У нас была даже некая балльная система, по которой по всем критериям у меня было 5/5, что не могло не радовать + положительный отзыв МРа. И в декабре, когда я уже неплохо освоился, состоялась ретроспектива. Ретроспектива - это некое собрание, когда команда обсуждает предыдущий квартал, какие были проблемы, находит пути их решения, подводит итоги и строит планы на следующий квартал. Цель - стать лучше. Одна из задач - разрешить предыдущие проблемы. И на этой ретроспективе я понял, что эта команда та самая, с которой можно свернуть горы и сделать наш продукт очень крутым. Я много читал историй, когда коллектив, мягко говоря - хрень, но в моём случае все более, чем круто сложилось. Ребята, зная, что я совсем зеленый, легко отвечали на все мои самые глупые вопросы, чем я старался не злоупотреблять.
Пошло-поехало
Прошло ровно пол года, как почувствовал, понял, осознал (как это не назови), что тестирование - это моё. Именно спустя пол года я понял, что то, чем я занимаюсь - это призвание. Естественно, что бывают косяки, не тестируемые задачи и прочие грустны вещи, но целая картинка позитивна!
Результат работы
Спустя 7 месяцев я научился и освоил некоторые инструменты и приобрёл скиллы, а именно:
PostgreSQL (СУБД) на уровне, который нужен тестировщику (анализ связей в БД, типов данных, запросы для тестирования и выборки данных);
Консольку Linux для просмотра логов, кода на тестовых стендах, правки "на горячую", всякие curl и прочие мелочи;
Различные техники тест-дизайна;
Буквально в последний месяц начал писать автотесты в связке Ruby+Selenium Webdriver+(всякие гемы аля Browsermob-proxy);
Написание документации (тест-планы, тест-кейсы, чек-листы и пр.);
Ну и всякие мелочи из разряда "деплоить ветку на тестовый стенд", "проверить наличие задач в ветке".
Вывод и скромный совет
Хотел бы обратиться к тебе, читатель. Если ты прочитал до этого места, то тебе в принципе интересно всё о тестировании, даже бредни джуна. Запомни одно - если чувствуешь, что это твоё - "не тормози сни..." не распыляйся и занимайся этим. Тестировщики - это ценные сотрудники, они отвечают за качество продукта, а следовательно экономят деньги заказчикам и делают конечных пользователей чуточку счастливее.
Задавай свои вопросы в комментарии и я с удовольствием отвечу на них.
P.S: Под понятием "тестировщик" я объединил и, непосредственно тестировщиков, и QA, и QC, не будите занудство и не проявляйте проф. деформации :) peace.
Показать полностью
Запуск Selenium-тестов в Docker
Весьма полезный доклад о запуске тестов в Docker и использовании Selenoid.
Первый митап RamQA
Раз уж у нас есть QA-сообщество, вдруг кому будет интересно, а на блог компании Рамблер Вы не подписаны ;D
зы: слово "митап" мне тоже не нравится, но раз уж повелось так называть, то чего уж.
Оригинал статьи: https://habrahabr.ru/company/rambler-co/blog/311050/
29 сентября c 19:00 до 22:00 пройдёт наш первый митап по тестированию и обеспечению качества разработки. В этот раз мы поговорим про автоматизацию мобилок, автоматизацию управления и об устройстве тестирования в одной известной компании.
На встрече мы услышим 3 доклада.
Анастасия Асеева | Альфа Лаборатория, руководитель проектов по автоматизации тестирования и Devops-евангелист.
«Почему мы выбрали appium для автоматизации тестирования mobile приложений?»
«Я расскажу о исследовании, которое мы провели, для того чтобы выбрать платформу для построения системы автоматизации тестирования iOS и Android приложений. В докладе будут обозначены критерии выбора и результаты пилота, а также с какими основными проблемами мы столкнулись при разработке ядра фреймворка.»
Мария Прыткова | Rambler&Co, руководитель группы тестирования LiveJournal.
«Автоматизация управления тестированием с помощью Google Docs.»
«Полезная информация для тех, кому надоела рутина, отчеты, слежка за тестерами и беспорядок в Jira.»
Александр Кочин | CarPrice, Руководитель QA
«Как тестируют в CarPrice»
«Рассказ про принятую методику тестирования в CarPrice, тестовую инфраструктуру и автоматизацию.»
Ссылку на регистрацию добавить, видимо, не получится, ругается пикабушечка на нее, можно кликнуть в оригинале на Хабре, если заинтересовало.
Показать полностью
DevOps для тестировщиков
Оригинал тут https://habrahabr.ru/company/luxoft/blog/310998/
История вопроса
В этой статье я хочу обсудить внедрение методологии DevOps с точки зрения тестирования и тестировщика. «Движение DevOps» (лучшего названия пока нет) развивается стремительно. Скорость внедрения новшеств в этой методологии, как и многие другие перемены, которые происходят в этой отрасли, очень высокая. При этом до сих пор нет четко сформулированного названия самого движения.
В зависимости от структуры вашей команды, от того, с кем вы разговариваете, методология DevOps может представлять собой как решение проблемы, так и самостоятельную цель. На некоторых предприятиях цель заключается в переходе к цифровым технологиям, и методология DevOps является частью общего подхода к обеспечению регулярного и высококачественного развертывания. Именно в этом смысле я рассматриваю DevOps в данной статье. Однако при реализации маркетинга технологий и услуг, связанных с методологией DevOps, эта цель может быть не совсем понятной. Проблема изменения культуры (или изменения поведения), требуемого для достижения успеха, зачастую недооценивается. Другое предположение, от которого я отталкиваюсь, заключается в том, что для тестировщиков, работающих в рамках методологии DevOps и находящихся под ее влиянием, эта методология является новинкой.
Я построил эту статью как введение в методологию DevOps для таких тестировщиков, а также как обсуждение ее влияния на методы тестирования. Если Вы являетесь опытным специалистом-практиком, использующим методологию DevOps, эта статья вам также может быть полезна. Если же Вы не являетесь тестировщиком, вы, по крайней мере, взглянете на вопрос с точки зрения тестировщика.
Для непосвященного читателя: что такое методология DevOps?
Простыми словами: DevOps — это понятие, обозначающее группу разработки и группу эксплуатации систем, которые более тесно сотрудничают между собой. В так называемом конвейере развертывания (от исходного программного кода до эксплуатации в производственной среде) разработчики автоматизируют какие-либо действия группы эксплуатации. Группа эксплуатации имеет возможность отслеживать действия разработчиков и оказывать на них некоторое влияние. При этом цель заключается в ускорении развертывания и внедрения программного обеспечения. Объединение группы эксплуатации (Ops) и разработчиков (Dev) (фактически в виде команды, использующей методы Agile) позволяет реализовать подход, который можно назвать «эксплуатация, основанная на методах Agile» (Agile Operations).
Очевидный результат успешного внедрения методологии DevOps заключается в сокращении количества времени, которое необходимо на то, чтобы изменение программного обеспечения прошло все стадии от идеи до эксплуатации в производственной среде. Когда разработчик говорит, что изменение программного обеспечения «сделано», переход к использованию этого изменения в производственной среде выполняется с помощью всеобъемлющей автоматизации. Автоматизированные средства и процессы используются при конфигурировании системы, в процессе сборки, при тестировании, развертывании в тестовой, промежуточной и производственной среде, при проведении мониторинга после завершения развертывания, при оценке и эксплуатации.
Итак, DevOps — это просто инструменты?
С одной стороны, цель методологии DevOps заключается в ликвидации узких мест в конвейере развертывания за счет использования автоматизации. Но автоматизацией многостадийных процессов все равно необходимо управлять. Многие автоматизированные процессы на самом деле не являются автономными — они не могут выполняться без вмешательства человека (для выполнения технического обслуживания и обработки нестандартных ситуаций). Полностью автоматизированный процесс DevOps не имеет смысла без учета влияния человеческого фактора. Несмотря на то что средства автоматизации выполняют много черновой работы, именно люди, управляющие процессом, обеспечивают его успешное (или неуспешное) выполнение.
Итак, DevOps — это просто разработчики (Dev) и группа эксплуатации (Ops), тесно сотрудничающие с использованием средств автоматизации?
Нет, опять неверно. Передача управления между автоматизированными процессами часто включает в себя другие процессы — обычно тестирование того или иного рода. Автоматизированные тесты создаются разработчиками и тестировщиками. Результаты этих тестов нацелены на предоставление достаточной информации, необходимой для выполнения других процессов или, что бывает чаще, необходимой людям, которые выполняют переход от одной стадии конвейера к другой. Тестировщики и разработчики, которые осуществляют тестирование, обеспечивают успешное и надежное выполнение процесса DevOps.
Голова кругом! И что же все-таки означает DevOps? Это прогрессирующая новейшая дисциплина. Данный вопрос детально рассмотрен в статье «What Is DevOps?», которая появилась за несколько недель до написания данной статьи. Как вы уже поняли, определение понятия DevOps еще не сформулировано окончательно. Возможно, никогда и не будет.
Что это значит для тестировщиков? Это значит, что до сих пор не существует «единственно верного пути» и что ваша роль в режиме DevOps, который постоянно развивается (а каждый режим постоянно развивается), еще окончательно не установлена. Существуют два момента, которые вы можете реализовывать:
1) обращать внимание на болевые точки и прилагать усилия к тому, чтобы уменьшить степень их негативного влияния;
2) выявлять возможности, которые позволяют оптимизировать процесс DevOps.
Если и существует единственная мантра, которая наилучшим образом описывает движение к методологии DevOps, то она звучит так: «Если это неприятно, делайте это чаще». Это может показаться похожим на клише, однако я буду пользоваться этим выражением в качестве контекста для внедрения и совершенствования практических навыков по тестированию с использованием методологии DevOps.
Если это неприятно, делайте это чаще
Трудности или неприятные ощущения, которые мы испытываем при выполнении определенной работы, влияют на нас отрицательно. Если нам не нравится какое-либо задание, то мы стремимся отложить его. Когда же мы, наконец, принимаемся за это неприятное дело — становится еще невыносимее. Визит к стоматологу, уборка в гараже, интеграция программного обеспечения, тестирование и т. д. Опыт говорит о том, что чем реже мы выполняем такие задания, тем неприятнее их выполнение. Мартин Фаулер (Martin Fowler) предложил три причины того, почему частое (или даже непрерывное) выполнение определенных заданий уменьшает неприятные ощущения.
Первая причина заключается в том, что большие и сложные задания трудно планировать, ими трудно управлять и их трудно контролировать. Разбиение больших заданий на несколько маленьких позволяет облегчить их выполнение и снизить степень риска, а если что-то пойдет не так, будет проще все вернуть в прежнее состояние. Вторая причина – многие задания (и тестирование в этом плане представляет собой наилучший пример) обеспечивают возможность обратной связи. Эта обратная связь, если она поступает на ранней стадии и достаточно часто, позволяет быстро реагировать на возникающие проблемы, прежде чем будет впустую потрачено время. И третья причина: если мы осуществляем какую-либо деятельность чаще, мы лучше справляемся с ней. Мы учимся делать эту работу эффективно. Кроме того, мы находим возможности автоматизировать ее тем или иным способом.
С точки зрения тестировщика эта мантра вынуждает более серьезно подходить к понятию автоматизации при осуществлении процесса тестирования. Если производится ручное вмешательство (обычно между автоматизированными стадиями в процессе DevOps), то оно должно рассматриваться как болевая точка: узкие места, причины задержек и потенциально ненадежные и склонные к появлению ошибок аспекты процесса.
Ручное тестирование неприятно. Да, вам может доставлять удовольствие проводить исследовательское тестирование, вы можете считать, что только вы как человек сможете обнаружить те заковыристые ошибки, которые автоматика никогда не найдет, что только вам как тестировщику можно доверять, чтобы не допустить катастрофу.
Вас как тестировщика может беспокоить, будет ли работа по тестированию выполнена надлежащим образом, если она поручается разработчикам или автоматизированным средствам. Если это для вас неприятно, делайте это чаще.
Тесты, автоматизация и доверие
Ведется много споров вокруг значения, например, проверок и тестирования, и вокруг того, насколько мы можем полагаться на тестировщиков, на проверки и на автоматизированные средства (The New Model and Testing v Checking).
Я не говорю, что мы должны полностью полагаться на автоматизированные проверки. Нам понадобится применить более сложный подход. Однако мы можем для целей этой статьи, по крайней мере, разделить тесты и деятельность по осуществлению тестирования на четыре компонента:
1) проверки, которые могут быть автоматизированы разработчиками в составе покомпонентных проверок и процессов непрерывной интеграции;
2) проверки, которые можно автоматизировать (обычно силами системных тестировщиков) для выполнения транзакций на уровне API, линий связи или всей системы;
3) тесты, включающие проверки совместимости и позволяющие продемонстрировать совместимость с браузерами, операционными системами и платформами;
4) тесты, которые может выполнить только человек.
В данной статье могу лишь сделать предположение, как осуществить такое разделение — каждая среда имеет свои особенности. Наиболее подходящий вопрос для данной статьи – как тестировщику «освободить себя» от поздних ручных проверок? Ранее я писал об исключении поздних ручных проверок. Это требует предусмотрительности и доверия.
Необходимо сконцентрировать внимание на следующих моментах:
1. Если это возможно, ручные проверки, которые могут быть выполнены на уровне компонентов, должны быть возложены на разработчиков. Как тестировщик, вы можете предложить выполнить эти тесты во время сеансов парной или коллективной работы. Вы можете написать их сами и включить их в режим непрерывной интеграции.
2. Для тестирования пользовательского интерфейса и комплексного тестирования может потребоваться использование автоматизированных средств. Такое тестирование следует свести к минимуму, так как оно долго выполняется, является нестабильным и часто требует обслуживания. Подумайте о том, нужно ли его выполнять при каждой проверке программного кода или можно отложить для использования только на крупных, менее частых релизах.
3. Какие неавтоматизируемые тесты можно выполнять на компонентах, которые еще не интегрированы в предвыпускную версию? Можно ли выполнять ручное тестирование в сеансах парной работы с разработчиками? Существуют ли альтернативы такому тестированию? Может ли помочь работа с архивными документами, прототипирование с использованием подхода BDD? Можно ли выполнять проверки пользовательского интерфейса на макетах или каркасных конструкциях?
4. Какие проверки необходимо выполнять только вручную в отличие от проверок, которые требуется оставить для регрессионного тестирования (они являются кандидатами для автоматизированного тестирования)?
Выше я упомянул о доверии. Другой вопрос заключается в том, как надежно тестировать систему, если не будет позднего ручного тестирования. Представьте себе среду, в которой все тестирование осуществляется автоматизированными средствами. Поверите ли вы, что разработчики надлежащим образом выполнят тестирование? Смещение забот о тестировании влево должно развеять ваши сомнения. Если вы как тестировщик действуете, как следопыт: для того чтобы идентифицировать и оценить риски, выбрать тесты и обеспечить, чтобы они были встроены в процессы разработки и автоматизации, то ваши опасения могут быть сведены к минимуму.
Естественно, вы должны перестать считать себя охранником качества, последним рубежом обороны, единственным человеком, которому не все равно. Вам приходится больше думать, как провидец, определитель рисков, управляющий рисками, следопыт, координатор и инструктор или наставник.
Практика, мониторинг и совершенствование
При всем желании если перестать полагаться на поздние ручные проверки, ошибки все же могут быть. Когда программное обеспечение выпускается в производство, обнаруживаются проблемы. Одной из ключевых дисциплин методологии DevOps с точки зрения эксплуатации является более глубокий мониторинг.
Мониторинг на каждом уровне — от компонентов и простых транзакций в приложениях до интеграции и обмена сообщениями и, конечно, самой инфраструктуры. Одна из целей мониторинга заключается в том, чтобы формировать сообщения об отказах до того, как пользователи испытают на себе их последствия. Это довольно амбициозное утверждение, но оно определяет конечную цель.
Когда проблемы встречаются в производственной среде, то задача заключается в том, чтобы использовать аналитическую информацию, полученную при выполнении мониторинга для того, чтобы не только отследить причину и устранить ее, но и для уточнения процесса тестирования (автоматизированного или ручного) и снижения вероятности возникновения подобных проблем в будущем. Роль тестирования и аналитической информации в функционировании всего конвейера определяется и обсуждается в статье «Thinking Big: Introducing Test Analytics».
Можно назвать автоматизированное тестирование процесса DevOps мониторингом. Когда мониторинг объединен с производственной средой, можно сказать, что мониторинг на протяжении всего процесса DevOps с заходом в производство расширяет сферу применения тестирования. Таким образом, методология DevOps не уменьшает роль тестировщиков.
Заключение
Недавно меня спросили: «В каком случае не следует пытаться применять методологию DevOps в организации?». Это хороший вопрос. Думаю в его основе лежит опасение, должна ли методология DevOps стать нормой и должны ли тестировщики обратить на это внимание. Мой ответ прост.
Почему бы вам не сделать так, чтобы разработчики и специалисты по эксплуатации разговаривали друг с другом? Почему бы вам не начать получать более надежные сборки и развертывания в тестовой и производственной среде? Почему бы вам не использовать лучшие технологии для более точного, эффективного и информативного конвейера? Методология DevOps является хорошим делом, однако не всегда легко достичь требуемого уровня ее использования. Не говоря уже о том, что она требует изменения культуры, а это не так просто.
С точки зрения тестировщика, методология DevOps оказывает влияние в большей степени на ранних стадиях проектов, вынуждает более серьезно задумываться об автоматизации тестирования, предоставления информации и принятия решений. Тестировщикам следует стремиться к использованию методологии DevOps, так как она дает возможности для выполнения действий в упреждающем режиме, получения более широких полномочий и уважения в проектной команде.
Показать полностью