Тестирование IT-систем *

«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»

Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?

Тогда прошу под кат!

Дорогой_хабрахабр_прости_пожалуйста_но_какой_тестировщик_не_проверит_эту_ может_и_бесполезную_штуку_в_блоге_по_тестированию?



Для придания посту минимальной информационной ценности, добавлю:
тестирование «неправильного» поведения пользователя называется негативным тестированием.

     «Милая „Наталья“, я вам пишу, чего же… » Нет, не такое вступление должно быть для монолога в стиле Роберта Пирсига. Такое обращение оставим для диалога в комментариях.

Книгу Дзен и искусство ухода за мотоциклом я рекомендую всем, кому важно качество, особенно тем, кто близок к тестированию!

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

Вопрос эффективности и рациональности я ставлю во главу угла, поэтому вопрос быть или не быть практике тестирования нужно обсуждать не в этом разделе. Кому не нужно тестирование и кто хочет сделать это самостоятельно силами разработчиков — могут не читать далее :) или все-же взвесить аргументы:
1. Профессия тестировщика не нуждается в обосновании, жизнь доказала потребность :)
2. Независимое тестирование позволяет выполнять работу для нескольких подразделений, продуктов или проектов.
3. Сложные виды тестирования требуют организационной формы для закупки инструмента, который будет использован (и амортизирован) для нескольких подразделений, продуктов или проектов.
4. Тестирование на этапе приемки в корпорациях выполняется для большого спектра продуктов или технологий.
5. Тестирование длительных жизненных циклов требует взаимозаменяемости участников и групповой (не только персональной) компетенции, например, тесты сопровождаемых систем со стороны заказчика или организации внедрения или сопровождения.

Disclimer: универсальных рецептов не бывает, автор исходит из опыта создания и развития практики тестирования в крупных ИТ-компаниях и не претендует на истину во всех инстанциях :)

В апреле этого года в Казани пройдёт 9-я конференция SQA Days. На ней, как и всегда, соберутся ведущие умы, гуру и эксперты в области тестирования. Её участниками, как и всегда, будут наиболее активные представители сферы контроля качества. На ней, как и всегда, каждый получит желаемое: тонны информации, века консолидированного опыта, террабайты мотивашечек.

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

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

Но если присмотреться внимательнее, то под видимостью продуктивного сотрудничества зачастую скрывается абсолютное непонимание разработчиков: «зачем эти тестеры вообще нужны??». Это непонимание нередко является взаимным, и несмотря на кажущуюся миролюбивость, оставляет в совместной работе лишь видимость продуктивности.

В качестве предисловия скажу, что я пришла в Иннову чуть больше года назад, моей задачей было «сделать тестирование в компании». Мой отдел тестирования состоит из двух групп: группа тестирования веб-приложений и группа тестирования игровых приложений. Такое разделение сложилось потому, что у этих направлений разные задачи и разные требования к сотрудникам.

Дальше рассказ будет про направление игрового тестирования. Это рассказ про моих ребят, про наши процессы, про нашу организацию работы. Приглашаю на словесную экскурсию.

Стоит ли вообще браться за JMeter

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

Составление сценария

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

Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.

Но я думаю, что одна из главных причин заключается в том, что люди не знают, с чего начать. Вот прочитал я статью про юнит-тесты, понравилось; решил, что надо бы когда-нибудь попробовать. Но что дальше? С чего начать? Как придумывать все эти требования, как называть тест-методы?

В последнее время набирает популярность тенденция превращать юнит-тесты в BDD-спецификации, то есть говорится о том, что хороший юнит-тест должен не тестировать что-то, а описывать поведение программы. Но как описать это чёртово поведение; откуда брать вдохновение, чтобы придумать названия для всех этих тест-кейсов?

Об этом и пойдёт речь:

Я работаю в автоматизации тестирования уже более пяти лет. Более всего я работал с ОС Windows. Мы пишем скрипты на Borland SilkTest. Я знаком и с другими средами разработки автоматизированных тестов, такими как QTP и TestComplete – у каждого продукта есть свои достоинства, но, к сожалению, и свои недостатки. Возникают проблемы, которые очень сложно решить «не выходя из системы»*

Вместо вступления

В первую очередь хочется отметить, что QA и тестирование в России идут довольно близко и разницы между ними очень мало, именно поэтому я обобщил эти термины.
В этой статье я бы хотел поделиться общими моментами процесса собеседования, как со стороны собеседоваемого, так и со стороны собеседующего. Тут приведен взгляд сразу с двух сторон. Так же хотелось бы сделать особый упор на техническую сторону данного процесса, так как, как правило, именно она и является решающей при выборе кандидата. Мне понравился вот этот топик, поэтому хотелось бы кое-что к нему добавить и увести в сторонy QA.
Сразу хочу отметить, что это лишь личные наблюдения и просто хотелось бы, чтобы процесс ревью был более понятен обоим сторонам. Везде своя специфика, но все равно можно выделить некоторые моменты. Все далее можно отнести к начинающему или уже имеющему опыт специалисту, но никак не к эксперту.

Один из самых частых ответов на вопрос «Почему я не пишу юнит-тесты» — это вопрос «А кто напишет тесты для моих тестов? Где гарантия, что в моих тестах тоже не будет ошибки?», что свидетельствует о серьёзном недопонимании сути юнит-тестов.

Цель этой заметки — коротко и чётко зафиксировать этот момент, чтобы больше не возникало разногласий.

Итак, юнит-тест — это

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

С одной стороны, сейчас много курсов в этой области, которые проводятся на базе портала Software-Testing.Ru, УЦ Luxoft, EPAM Systems и т.д.
С другой стороны, начинающему тестировщику далеко не всегда нужны курсы. Если вы ещё не знаете, в каком направлении развиваться, какие области интересны, какие знания хочется получать – то о каких курсах идёт речь? А комплексного ВУЗовского образования для тестировщиков в СНГ пока что нет… В итоге, многие люди не могут быстро «влиться» в профессию, найти направление для развития и понять, «что и как надо изучать для быстрого старта?».

Поэтому, я составила инструкцию для начинающих тестировщиков или людей, которые только выбрали себе эту область деятельности, и снабдила её максимумом ссылок, чтобы информацию не приходилось собирать по крупицам. Надеюсь, что эта инструкция поможет Вам в выбранном начинании.

Итак, 7 шагов от чайника к тестировщику.

Вот и первая жертва корпорации Oracle. Любители continuous integration сервера Hudson недавно наблюдали неприятную историю переезда Hudson c серверов управляемых Oracle'ом. Oracle так просто не сдался. Разработчики признали, что право на название «Hudson» принадлежит Oracle и, чтобы не было проблем в будущем, решили переименовать проект. Предложенное название — Jenkins

В последнее время развелось очень много различных AJAX-приложений. По сути автоматизация тестирования такого приложения не отличается от автоматизации тестирования обычного WEB-приложения, но есть несколько тонкостей. Одна из тонкостей — это как раз ожидание завершения всех AJAX-запросов. Например, если отметка некого checkbox'а на странице вызывает обновление какого-нибудь select'a по AJAX-запросу, то тест, который сразу после отметки выбирает конкретный option, свалится, т.к. этого option'a там не будет. А всё потому, что сам тест выполняется намного быстрее чем AJAX-запрос на обновление списка.

В данном случае у автоматизатора есть несколько выходов.

Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, цель которого – локализация ошибок в работе программного обеспечения.

Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.

Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

В последнее время наблюдается интересная тенденция — зарождение и развитие оффлайновых сообществ тестировщиков на пост-советском пространстве (конечно, есть сообщества в Индии, Великобритании и других странах, но, в силу своей удаленности, они в данной заметке не рассматриваются). Похоже, маховик раскручивается в обратную сторону, люди возвращаются из бескрайних просторов Интернета в оффлайн, и это определенно дает положительные результаты.

Данной статьей хотелось бы начать небольшой цикл о сообществах тестировщиков.
Мы думаем, что участие во встречах будет полезно не только людям, тестирующим программы, но и представителям многих других ИТ-профессий. Как показывает практика, самые интересные и злободневные вопросы обсуждаются на встречах тогда, когда на них присутствуют программисты, аналитики, технические писатели. Ведь тестирование не является самодостаточным процессом, его задача — предоставлять информацию остальным участникам проекта. Поэтому мы всегда рады, когда к нам приходят представители других профессий и будем еще больше рады, если кто-нибудь захочет выступить с докладом.

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

Области применения, цели и задачи тестирования ПО разнообразны, поэтому тестирование оценивается и объясняется по-разному. Иногда и самим тестировщикам бывает сложно объяснить, что такое тестирование ПО 'as is'. Возникает путаница.

Для распутывания этой путаницы Алексей Баранцев (практик, тренер и консалтер в тестировании ПО; выходец из Института системного программирования Российской академии наук) предваряет свои тренинги по тестированию вводным видео про основные положения тестирования.

Мне кажется, что в этом докладе лектор смог наиболее адекватно и взвешенно объяснить «что такое тестирование» с точки зрения ученого и программиста. Странно, что этот текст еще не появлялся на хабре.

Привожу здесь сжатый пересказ этого доклада. В конце текста есть линки на полную версию, а также на упомянутое видео.

Все более-менее сложные программные системы содержат ошибки (если и не собственные, то наведённые используемыми библиотеками или по причине неточного осознания поведенческих парадигм используемых фреймворков).
Часто, для тестирования системы на этапе разработки используются Unit-тесты.

Так программист может контролировать поведение системы на контрольных точках и пограничных значениях.
Часто именно неверная отработка пограничных значений приводит к проблемам. И опытные программисты это знают и учитывают при проектировании Unit-тестов.

Удобство Unit-тестов ещё и в том, что изменяя код вы ожидаете получить предсказуемые результаты и провести полностью автоматическое тестирование по имеющимся сценариям, чтобы быстро выявить наведённые изменениями неприятности.

Например, вы пишите код для работы на Intel и PPC, разрабатываете его на Intel, но учитываете порядок байтов. Потом прогоняете свои Unit-тесты, чтобы сравнить выходные данные с эталоном и обнаруживаете расхождения — понятно, где-то забыли байты перевернуть — исправляете — всё в порядке.

Однако, любой пользователь всегда несёт в себе элемент случайности.

Опытный программист сочетает в себе талант качественного тестировщика и может отловить много ошибок до выхода программы в свет.

Если программа делает больше чем печать «Hello World!», то скрытые ошибки в любом случае остаются.
Это могут быть ошибки и в логике в том числе.

Программа компилируется, все Warning'и устранены… но иногда что-то идёт не так… у пользователя (который живёт далеко в домике на островке в тихом океане — приехать к нему и пощупать нет возможности). Программист прокликал и протестировал со своей стороны всё что мог, но ошибки не нашёл. Что же делать?