29 августа в Минске прошла вторая полномасштабная конференция, посвященная автоматизированному и ручному тестированию, менеджменту команд и эффективному взаимодействию участников процесса разработки ПО, организованная сообществом автоматизаторов и сочувствующих COMAQA.BY при деятельной поддержке очень и очень многих небезразличных людей.
На мероприятии с докладами выступили активисты сообщества, ключевые специалисты ведущих IT-компаний Беларуси.
На конференции было представлено 15 докладов, разбитых на два потока и круглый стол, посвященный ряду наболевших вопросов тестирования ПО.
Темы прочитанных докладов:
«Принцип открытого кимоно как инструмент мотивации», … Антон Семенченко, COMAQA.BY,
«Внедрение автоматизации на проекте с действующим …» Вадим Зубович, COMAQA.BY,
“Codeception + PHP for QA Automation” Евгений Борисик, COMAQA.BY,
У многих тестировщиков, а также и у многих менеджеров, при звуке слов "автоматизация тестирования" в мозгу возникает идиллическая картинка в стиле научно-фантастических романов: роботы выполняют рутинную и тяжёлую работу, а человек занимается интеллектуальным или творческим трудом.
Но это никакая не фантастика, это вполне реально и достижимо!
Да, можно освободить тестировщиков от выполнения некоторых типовых задач, переложив эту работу на плечи роботов. Таких рутинных действий тестировщик совершает больше, чем кажется на первый взгляд. Автоматизировать можно не только собственно выполнение тестов, но и подготовку тестового стенда, генерацию тестовых данных большого объёма или высокой сложности, помощь в проверке результатов, полученных при ручном тестировании (сравнение текстов, картинок), создание отчётов или иных документов.
Однако нельзя просто пойти и купить робота, который начнёт немедленно приносить вам пользу. Можно либо взять "универсального" робота и обучить его, либо взять конструктор и собрать узкоспециализированный автомат для решения ваших конкретных задач.
Процесс внедрения автоматизации – это как раз и есть процесс создания или обучения роботов.
Внедрение автоматизации затрагивает многие стороны процесса разработки. Это отнюдь не чисто инженерная задача, требующая только владения инструментами автоматизации и навыками программирования.
Прежде чем перейти к технической части, необходимо выбрать оптимальную стратегию внедрения и дальнейшего развития автоматизированных тестов. Нужно скоординировать работы по автоматизациями с деятельностью специалистов по ручному тестированию, потому что предстоит провести отбор тестов для автоматизации, а может быть и переработку этих тестов. Предстоит также согласовать свои действия с разработчиками, а может быть даже договориться о специальных доработках тестируемого приложения для более удобной автоматизации.
Ну и конечно без инженеров в этом деле не обойтись. Правильно выбрать средства автоматизации, интегрировать с инструментами групповой работы (баг-трекер, сервер непрерывной интеграции, системы отчётности) – при решении этих технических задач талант инженера-автоматизатора может раскрыться в полной мере.
Но главная опасность подстерегает впереди – рано или поздно станет ясно, насколько оправданным и экономически целесообразным оказалось внедрение автоматизации в тестирование. Нужно будет оценить достигнутые результаты и принять новые решения относительно дальнейшего развития систем автоматизации.
Чтобы научить вас правильно планировать процесс внедрения автоматизации, успешно решать технические задачи и адекватно оценивать текущее состояние процесса
мы разработали новый тренинг, особенность которого заключается в том, что его ведут два тренера – "менеджер" и "инженер".
Это позволит вам увидеть проблемы, которые возникают при внедрении автоматизации тестирования, с двух разных (можно даже сказать противоположных) точек зрения.
Тренинг будет полезен всем, кто внедряет с нуля или улучшает текущие подходы к организации автоматизированного тестирования: тест-менеджерам, специалистам по автоматизации и тест-дизайнерам, взаимодействующим с группой автоматизации.
"Младших тестировщиков производительности" не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности.
(с) Скотт Барбер (aka The Perf Guy)
В тестировании компьютерных программ есть "общедоступная" область функционального тестирования, куда доступ открыт всем желающим, и есть целый ряд областей с достаточно высоким "порогом входа", и тестирование производительности находится в их числе.
Для этого вида тестирования требуется хорошее владение оружием, его голыми руками не возьмёшь. Во-первых, нужно само оружие -- тестирование производительности обязательно требует умения пользоваться специальными инструментами. Во-вторых, нужно тщательно изучить соперника -- необходимо хорошее понимание протоколов взаимодействия тестируемой программы с внешним миром и её внутренней физической и логической архитектуры. Ну и конечно же нужно владеть приёмами -- знать какую нагрузку и как подать на тестируемое приложение, и на что смотреть, чтобы выявить проблемы с производительностью.
На тренинге мы будем учиться обращаться с этим оружием:
познакомимся с инструментами, предназначенными для генерации нагрузки и для мониторинга различных характеристик производительности,
освоим способы использования этих инструментов для генерации нагрузки различного вида,
изучим типовые архитектурные шаблоны построения приложений и связанные с этим источники потенциальных проблем с производительностью,
рассмотрим способы выявления проблем с производительностью на основе анализа результатов мониторинга.
Для практических демонстраций и для выполнения домашних заданий будет использоваться инструмент JMeter.
Подскажите активный форум, который посвящен темам "юнит тесты, разработка через тестирование (TDD, ATDD), использование моков и стабов, обсуждение книг по юнит тестам (The Art Of Unit Testing & co)" и так далее.