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

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

Решение — под катом.

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

Итак, имеем карандаш:

Знание истории происхождения вещей и их названий, будь то простой карандаш, автомобиль или команда операционной системы, делает их повседневное использование намного интереснее. В этой заметке я постарался разобраться в причинах странного, казалось бы, наименования некоторых программ, используемых в операционной системе Unix и её родственниках: *BSD, Solaris, HP-UX, Linux и т.д.

Перепечатка моей статьи, написанной, в свою очередь, по мотивам страницы What does {some strange unix command name} stand for?

Добрый день!

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

Везде, где я буду говорить про автоматизацию тестирования, речь будет идти про тестирование интерфейса с подключением к внешним ресурсам (БД, файловая система, сервисы и т.п.).

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

На дигге была найдена интересная ссылка (PDF-версия) — описание более, чем 350 команд Линукс (на английском языке). Фактически представляет собой шпаргалку, где команды разбиты на категории. Отмечу, что это не простой список команд, а именно описание с применением. Чтобы не быть голословным приведу несколько примеров.

Поскольку астрологи объявили неделю собеседований, и количество топиков на эту тему удвоилось, я не удержался и составил свой топ ошибок соискателей, но есть еще мысли и по поводу работодателей. У вашего покорного слуги за плечами несколько сотен собеседований, поэтому мои размышления на эту тему, возможно, пригодятся вам при подготовке ко встрече с потенциальным работодателем.
Во время работы над текстом я консультировался с руководителем карьерных сервисов hh.ru marships, чтобы лучше понять взгляд профессиональных рекрутеров. Она помогла с приоритезацией ошибок и добавила пару идей.

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

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

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

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

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

Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.

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

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

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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