В данной статье поделюсь своим опытом обучения на программиста в домашних условиях. Расскажу как на мой взгляд лучше готовиться к обучению, как строить план обучения и поделюсь своими философскими мыслями касательно обучения и не только.

В каких случаях стоит использовать абстрактный класс, а в каких — интерфейс? Давайте разбираться, в чем между ними разница.

Вторая часть подборки материалов от QA для начинающих специалистов (и не только). Под катом квалификационные требования, практические пособия и классика книг по тестированию.

Когда-то давно я мечтал стать программистом. Еще со средних класов школы начал ездить на олимпиады по программированию, писал игровые моды и просто нереально кайфовал от того, что делал. Начинал еще с Turbo Pascal, потом С, потом скриптовые языки, в универе математическое моделирование на С++ и matlab. Только в универе пришлось на теор.физике тусоваться, ибо не прошел по балах на программирование, но да ладно. Спустя 3 года я все таки решил кинуть физику, так как просто не видел денег в этой сфере в своей стране, и получил все таки первую долгожданном ИТ. Это была серверная разработка на Python.

С тех пор прошло уже 6 лет. Не могу сказать, что я сверх нерд и мое мнение авторитетное - но какой-то опыт в своей сфере все таки имею. Повидать успел с десяток различных компаний - от крупнейших в СНГ и крупных на диком западе, до мелких стартапов ( не думайте, что я во всех них успел поработать - это тема отдельная). Это печально...

Я часто работаю с клиентами, которые либо только начинают, либо пытаются развивать свои навыки в автоматизации тестирования, и чаще всего все они совершают одни и те же фатальные ошибки.

Хотя они могут понимать основы автоматизации тестирования, они по-прежнему считают ценность скриптовых тестов экономией времени за счет автоматического выполнения сценариев, а не вручную. Они считают, что если автоматизированные сценарии выполняются быстрее, чем это могут сделать люди, то наибольший выигрыш в эффективности должен быть достигнут за счет автоматизации самых длительных тестов.

И если бы время исполнения было единственным временем для оценки, они были бы правы.

Но время выполнения теста — это всего лишь одна проблема, связанная со временем. Вам также нужно подумать о времени, необходимом для написания автоматизированных тестов, и о времени, которое вам нужно, чтобы научиться писать тесты.

Команды добиваются успеха чаще, когда они перерабатывают большие тесты в меньшие, более короткие. Вот как вы можете извлечь выгоду из этой не интуитивной идеи.

 Оставьте время для обучения

Малыши учатся балансировать, прежде чем они смогут встать. Они стоят перед тем, как научатся ходить. Программисты пишут «Hello world» каждый раз, когда изучают новый язык программирования.

Команды, обучающиеся автоматизации, могут проходить через несколько кривых обучения одновременно: язык программирования, концепции программирования, инструмент или фреймворк автоматизации тестирования, управление исходным кодом и совместная работа над программным проектом.

К старту курса по Fullstack-разработке на Python показываем, как работают регулярные выражения, на примере их движка с визуализацией, которую вы видите на КДПВ. Под катом подробности и код.

Иногда ваше тестовое окружение не готово к изоляции от внешних сервисов. Более того, тестовый фреймворк не готов тоже. Но наступает момент, когда вы понимаете, что это нужно изменить и размышляете, как  наиболее плавно перейти на моки. В этой статье я хочу рассказать о нескольких вариантах организации мокирования веб-сервисов в подобном случае, о том, как связать это с автоматизацией тестирования и о нашем опыте внедрения Mockserver в стек инструментов компании.

Продолжаем тему оформления документов по ГОСТам, начатую в статье «Оформляем приложения по ГОСТ 7.32 в MS Word и не только». На этот раз рассматриваем подходы к автоматизации форматирования больших текстов (более 500 страниц) в редакторе MS Word. Предлагаемые подходы применимы также в других редакторах, использующих стили, в частности, LibreOffice Writer.

Привет! Меня зовут Андрей Небольсин, я Старший Тестировщик на проекте Сбер МегаМаркет. Мой опыт в QA-сфере относительно небольшой, тем не менее я думаю, что у меня есть, чем поделиться :-)

Всем привет! Меня зовут Иван и я Head of QA Automation в Skyeng. Я регулярно занимаюсь обучением Manual QA и менторством начинающих QA Automation (далее – QAA) и часто слышу от падаванов вопрос: «А как же мне, собственно, стать QAA?»

Вопрос многогранный. В статье хочу поделиться мыслями на этот счет. Так что присаживайтесь поудобнее, чаек и конфетки при прочтении приветствуются! Также советую захватить валерьянку — некоторым она понадобится при чтении третьего раздела.

Представим, что я Manual QA: каждый день занимаюсь ручным тестированием, пишу тест-кейсы, хожу на планирование, ревьюю требования и тестирую задачи. 

Однажды приходит осознание, что нужно расти. Но куда?

Большое количество модулей Maven замедляет сборку проекта и время прогона тестов. Для того, чтобы сохранить многомодульную структуру проекта и быстро прогонять тесты, мы в Wrike написали новый инструмент — Maven Modules Merger, который сократил время некоторых сборок с 50 до 12 минут. В статье подробно расскажу о том, с какими проблемами нам помог справиться Maven Modules Merger и поделюсь подробностями его создания.

Привет, Хабр! Меня зовут Михаил, я SDET-специалист компании SimbirSoft. Я занимаюсь автоматизацией тестирования, в основном это работа с WEB и REST API, но на последнем проекте применял SOAP. Мне приходилось работать с сообщениями этого протокола, а именно:

— выполнять проверку наличия обязательных атрибутов и тегов SOAP сообщений;

— сравнивать содержание различных сообщений;

— вносить изменения или генерировать новые сообщения для исходящих запросов.

В своей статье я поделюсь несколькими способами работы с XML-документами. Материал будет полезен тем, кто впервые сталкивается  в работе из кода с подобными документами на Java.

В разработке программного обеспечения все меняется с невероятной скоростью — в том числе инструменты, которые мы используем. Это происходит в результате совершенствования аппаратной части, инфраструктурных сред. Иногда старые инструменты плохо адаптируются к реалиям, поэтому они в конечном итоге исчезают, и на замену им приходят новые утилиты.

"Все новое — лучше, чем старое" — девиз, который не всегда применим для утилит в Linux. Но все же исключения есть.

В статье под катом разработчик Хосе Висенте Нуньес* рассказывает о нескольких устаревших инструментах, которые вы, возможно, все еще используете. А также о том, чем их можно заменить. Автор объясняет, почему вам следует переключиться на эти улучшенные альтернативы, которые обеспечивают ту же — а в некоторых случаях даже большую — функциональность. Список составлен в произвольном порядке.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Благодаря проведению нефункционального тестирования мы улучшаем пользовательский опыт и охватываем проверками те области продукта, которые не были покрыты с помощью функционального тестирования. Одинаково важно проверить, и как система работает, и убедиться в ее функциональности. Одним из видов нефункционального тестирования является тестирование производительности, которое используется для проверки масштабируемости, стабильности характеристик и скорости работы тестируемого приложения.

Когда я работал над своей курсовой про то, как передавать С++ исключения из ядра ОС пользовательским программам, я изучал, как работают исключения в С++ и в этом мне очень помогла эта серия статей с Хабра. Теперь я хочу дополнить некоторые мометны, которые недостают в этой серии статей.