Вступление

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

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

Итак, после осознания навязчивого желания хотя бы немного да освоить это таинственное ремесло, каждый задает абсолютно логичный вопрос — «С чего же мне начать»? Ответов может быть множество — к услугам новичков скринкасты, книги, курсы, онлайн-обучение, форумы и прочее, и прочее. Учи-нехочу. И так как никакой общепринятой системы самообучения программированию не существует, можно смотреть и читать все без разбору, дни напролет. При желании, в чтении можно захлебнуться, однако для уверенного продвижения по лестнице знаний необходимо четко и эффективно расходовать свое время и силы, и если не знать с чего начать и куда двигаться — вы попросту забредете в дремучий лес, по которому можно блуждать неделями, пока, наконец, вы не выйдете на верную тропинку. Если выйдете вообще — велик шанс, что вам попросту все это дело быстро надоест.

Ответ на топик «Распространенные ошибки при составлении баг-репортов».

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.

    - Google выше ранжирует сайты, которые загружаются быстрее.
    - Если на eBay или Amazone увеличить время загрузки страниц на 9% они теряют 1% прибыли.
    - Сделать свой сайт быстрее, чтобы сэкономить на клиентском трафике и на числе обращений к серверу.

.htaccess — наш герой

Профессионалы знают, что такое htaccess.
Тем кто собираются уйти с народ.ру на php-хостинг только предстоит узнать, что это такое.
Те кто только что установил свои первые jooml'у или wordpress срочно должны узнать о нашем герое — htaccess

Зачем нам .htaccess ?

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

Или другой пример. Скажем ваш ресурс начинает набирать популярность, но переезжать на выделенный сервер ещё рано, а мощностей VPS уже не хватает. Вас очень может выручить htaccess.

А ещё htaccess может решить некоторые вопросы с безопасностью вашего сайта.

А ещё…

Инспекция кода — это хорошо. Мы используем эту технику в своих проектах не так давно — около трех месяцев, — однако положительные результаты налицо. Мы уже рассказывали на Хабре о внедрении инспекций в процесс разработки, о документообороте при инспекциях, рассказывали о том, как можно оптимизировать процесс инспектирования с помощью инструмента Code Collaborator. Сегодня мы хотим подвести итоги и представить результаты, которых нам удалось достичь за время инспектирования. Поехали!..

Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

• Нет, тут есть ошибка -> сами гады -> а может все не так и плохо -> ппц -> ладно, давай выкручиваться

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

• Как узнать каждое состояние и предугадать следующее?
• Как помочь выйти себе и собеседнику из цепочки?
• Что не делать, чтобы не усугубить ситуацию?

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

Какой человек не любит халявы? Практически все ее просто обожают, и я не исключение. Вдохновленный статьей «Взломать Wi-Fi за 10 часов» я достал из недр харда BT5, скачанный ранее, и записал его на болванку. Результат не заставил себя ждать, и первый пароль был получен на следующее утро. И понеслась…

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

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

Пролог

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

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

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

Продолжаем разговор.

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

mtikhon в своей статье «Легкий способ пройти тестирование» прекрасно дополнил тот список «внешними» проблемами, влияющими на результат тестирования. Внешними – в том смысле, что они зарождаются не в отделе тестирования, а в прочих подразделениях, а еще чаще – где-то на стыках подразделений, при взаимодействии отделов. (Я понимаю, что не всегда под тестирование формально выделен специальный отдел. Но это косметическая разница, сути не меняет: тут речь скорее о разделении ролей)
mtikhon’у слегка попеняли в комментариях, что список проблем изложен, а легкий способ их обойти – нет. Он, в свою очередь, уже справедливо отметил, что «способы как правило разнятся очень сильно». Вот на этой мысли я и хочу потоптаться чуть подробней.

Пожалуй, пойду прямо по тем же пунктам.

Недавно начала вести курсы по основам тестирования, и так получилось, что группа собралась из одних программистов. И каково же было мое удивление, когда люди, задействованные в разработке программного обеспечения, ничего не знают о тестировании. Умные ребята, продвинутые программисты, хорошо разбирающиеся в своей предметной области, ничего не знают о том, как тестировать ими же написанное программное обеспечение.
Несмотря на то, что тестрование существует уже давно, это еще молодое развивающееся направление, про которое зачастую мало что знают, за пределами отдела тестирования. И тогда я задумалась, почему люди идут работать тестировщиками, или наоборот не идут. Движут ли ими какие-то предубеждения и мифы. Как-то на глаза попалась статья Майка Брауна (Mike Brown) про 5 мифов в тестировании, переводом которой хочу с вами поделиться:

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

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

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

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

Добрый день дамы и господа!

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

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

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

Мы c камрадом eagleson провели не претендуя на научность небольшой опрос «Чего не хватает и что мешает тестировщикам ПО?» и были не на шутку заинтересованы лидерами голосования, в числе который оказался, например, такой вариант ответа как «Понимание целей и задач процесса тестирования» за который проголосовало около 50% респондентов.

То есть, 50% респондентов (выборка не большая, 500 человек, по ссылке все результаты голосования и все варианты опроса) считаю, что тестировщики с которыми они работают не вникают в цели и задачи процесса тестирования?

Мы решили обсудить эту тему и пригласили записать небольшой подкаст нашего коллегу из Харькова Глеба Рыбалко.

Мы с eagleson работали в тестировании каждый лет по 7-8, а Глеб Рыбалко и сейчас работает в области тестирования и обеспечения качества уже около 6-ти лет. Он успел поработать в Харькове, Львове и Днепропетровске. За это время прошел долгий путь от младшего инженера тестировщика до руководителя нескольких групп тестирования на большом проекте в крупнейшей украинской IT компании.

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

Тестировщики и правда не понимают целей и задач тестирования ПО?

Мы продолжаем говорить со специалистами в области тестирования ПО, чтобы разобраться в вопросе «Что случилось с тестировщиками?»

В теме продолжают разбираться Слава Панкратов (case) и Саша Орлов (eagleson) — в славном боевом прошлом специалисты и руководители команд по тестированию.

Напомним, что мы провели небольшой опрос на сайте www.it4business.ru к которому присоединились наши коллеги из сообщества www.happy-pm.com и сообщество Стратоплан.Ру в Фесбуке из которого узнали, что половина опрошенных считает проблемой тестировщиков ПО непонимание целей и задач тестирования ПО.

Мы уже записали и опубликовали на Хабре небольшой подкаст с Глебом Рыбалко, который работает в тестировании более 6 лет.

Сегодня мы пригласили побеседовать на эту тему Алексея Лянгузова: 11 лет в тестировании, tech lead команды тестирования в Oracle, до этого работал в TogetherSoft и Borland, со-основатель сообщества тестировщиков Санкт-Петербурга.

Причины, которые, как нам показалось, могут пояснить, почему 50% опрошенных, солидарны в своей позиции: «Тестировщики не понимают целей и задач тестирования».

1. Мы не говорим, что и как мы делаем: недостаток визибилити и прозрачности нашей работы для других членов команды или соседних рабочих групп и отделов.
2. Мы не можем банально посчитать в цифрах эффективность наших решений и показать результаты нашей работы.
3. Мы не готовы честно провести анализ полученных результатов и сказать «Да, я провтыкал и ошибся».
4. Мы закапываемся в работу и забываем, что «пилу надо точить»: книги, вебинары, публикации, тренинги – всего этого в нашей отрасли сейчас навалом.
5. Мы не смотрим шире своих рабочих задач: многие из нас тестировщиков «стажировались» в группе разработки за последний год? Не барское дело, понятно.
6. Мы не делимся опытом и наработками с другими группами: аналитики, программисты, менеджеры, наконец! А у нас есть что сказать: тестировщики — это пользователь номер 1 любого программного продукта. И только они знают готов ли он к запуску или нет.

Конечно, есть еще одна, банальная причина того, что тестировщиков ПО не воспринимают, как специалистов, которые понимают, что и зачем они делают. Даже не причина, а источник проблем — мы сами.

Нас справедливо упрекнули в том, что мы сгущаем краски: и опрос мы сделали неправильный, и обидели тестировщиков понапрасну, и предложить ничего не предложили, что самое главное!

Мы просто делаем все последовательно. Есть проблема? Надо собрать мнения — собрали, предложили их вам обсудить. Если есть проблема, то, наверняка, есть и решение — и мы нашли людей, которые готовы поделиться с нами опытом своих побед проблем в тестировании, которые мы нашли.

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

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

Мы запланировали еще одну интересную онлайн-встречу, чтобы окончательно закрыть тему и доказать, что если проблема решаема, то она решаема не одним способом!

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

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

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

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

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

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

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