Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

Аннотация

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

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

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

Я не берусь давать четкие определения видам тестирования в этой статье. Об интерпретации терминов, используемых для названия видов, речь пойдет в третьей части. Связано это разделение с объемом информации.

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

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

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

У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей:

• командный дух и атмосфера в командах — удобство процессов важнее сложившихся годами правил и привычек;
• автоматизация рутины важнее задавливания массой;
• быстрое принятие решений важнее консилиумов, коллегий, долгих совещаний;
• доверие к людям, возможность учиться (и ошибаться!) важнее централизации управления;
• открытость для всех (от высшего руководства до конкретного участника проекта) и вовлеченность важнее сиюминутной экономии времени и видимости согласия;
• демократия в обсуждении вопросов, но диктатура в претворении решений в жизнь;
• необходимый минимум правил, но требовательность при их исполнении;
• когда все думают одинаково — никто не думает;
• «мужик сказал — мужик сделал», все несут ответственность за свои решения.

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

Вдохновленный этим топиком, приобрел UniFi AP. Как потом выяснилось, для нормальной работы, точке доступа был необходим софт, который устанавливался на PC. С помощью этого софта (контроллера) можно настраивать и управлять UniFi точками, подключенными к локальной сети. Если компьютер на котором установлен контроллер выключить, то через некоторое время девайсы перестают работать. В данном случае, у меня был один UniFi Ap и смысл в этом контроллере пропадал. Поэтому решено было установить на него Ubiquiti AirOS для работы в Stand Alone режиме.

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

Лучшие порталы с открытыми шаблонами сайтов

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

Решил поделиться c ссылками, которые использую для своего сборника портативного софта:

www.no-install.com

www.pegtop.net
www.robloach.net/project/portableapplications
portableapps.com
www.richskills.com
www.portablefreeware.com/all.php
unattended.org.ua/portable-soft
alexwild.ru/index.php?do=cat&category=portable_soft
softarchive.net/category/portable
softray.net/index.php?option=com_content&task=category§ionid=4&id=83&Itemid=58
portablebox.net

U3:
software.u3.com
software.u3.com/SoftwareCentral.aspx

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

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

В соседней теме попросили рассказать о нюансах работы с зарубежными клиентами для ИП/ООО. Для физических лиц работа с нерезидентами ничем не отличается работы с резидентами.
Это скорее даже не статья, а заметка/памятка, но возможно кому-нибудь будет хоть немного полезна.

Регистрация счета

Предположим что вы закончили регистрацию ИП/ООО и открыли рублёвый расчетный счет.
Для того чтобы работать с валютой нужно открыть еще один расчетный счет — валютный. Это просто.
При открытии валютного счета вам создадут дополнительно технический транзитный счет. Его реквизиты и нужно сообщать заказчику.

Здесь мы встречаем потенциальный косяк номер раз: как и в случае с рублевым счетом нужно уведомить налоговую в недельный срок (штраф — 5000 рублей [1]). Затем не забыть уведомить и своё отделение ПФР в тот же срок, иначе опять же штраф, но уже меньше — 2000. Если вы зарегистрированы в ФСС, то нужно не забыть так же и их, всё аналогично случаю с ПФР. [2]

ООО нужно уведомить ПФР и ФСС только если есть работники. ИП — обязательно ПФР, но если есть или были работники, то и ФСС.

Некоторые госслужбы «не шарят» и пытаются оштрафовать если не уведомили о транзитном счете. Это противозаконно и легко решает даже в досудебном порядке, не говоря уже о суде. Заявлять нужно только об обычном счете, о транзитном — не нужно.

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

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

Сразу скажу, что получение денег на пластиковую карту без уплаты налогов может вылиться в серьезные проблемы (про ответственность написано в конце топика). Объяснения, что деньги «от бабушки внучку на мороженное» при суммах больше 10К$ в год уже не прокатывают, особенно если в реквизитах «бабушки» будет стоять что-то вроде «GMBH Star Development» Вероятность того, что возьмут за задницу достаточно высокая и поэтому лучше не рисковать и делать все по Закону, тем более, что ничего сложного в этом нет

Последние изменения на free-lance.ru создали большое недовольство в среде фрилансеров.
Многие озвучили намерение уйти на другие биржи. Довольно часто звучал вопрос «Как мне вернуть деньги за PRO-аккаунт?»
Правила сайта free-lance.ru гласят, что начисленные на счет средства не возвращаются.

Однако, как показывает практика, вернуть деньги можно.

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

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

Новость не обошла стороной даже популярные издания вроде Lenta.ru.

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

Спустя сутки мы получили ответы от генерального директора free-lance.ru

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

Все дела сделаны и теперь есть время черкануть пару строк об автоматизации тестирования…

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

Грубо говоря, проблема в том, что в браузере работает javascript, а на сервере его нет. Нужно либо писать интерпретатор js на одном из серверных языков (jParser и jTokenizer), либо ставить на сервер браузер, посылать в него запросы и вытаскивать итоговое dom-дерево.

В древности в таких случаях мы строили свой велосипед: на отдельной машине запускали браузер, в нем js, который постоянно стучался на сервер и получал от него задания (джобы), сам сайт грузился в iframe, а скрипт извне отправлял dom-дерево ифрейма обратно на сервер.

Сейчас появились более продвинутые средства — xulrunner (crowbar) и watir. Первый — безголовый firefox. У crowbar есть даже ff-плагин для визуального выделения нужных данных, который генерит специальный парсер-js-код, однако там не поддерживаются cookies, а допиливать неохота. Watir позиционируется разработчиками как средство отладки, но мы будем его использовать по прямому назначению и в качестве примера вытащим какие-нибудь данные с сайта travelocity.com.

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

Почему бы не избежать этих неприятностей, прогнав нагрузочный тест?

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

Под катом рассказываю, как с нуля организовать незамысловатый нагрузочный тест сайта при помощи Apache JMeter.

Большинство людей не умеют писать unit-тесты. И даже те, кто применяет модульные тесты в ежедневной разработке, зачастую признают, что получившиеся тесты иногда не очень эффективны по определенным причинам. К этой категории людей я могу отнести и себя. В первую очередь, такой «причиной» является некоторая появляющаяся «инертность» кода, заключающаяся в том, что если требуется немного изменить какой-то ключевой алгоритм, добавить пару строчек кода, то при этом «падают» ~100 модульных тестов и приходится тратить продолжительное время на то чтобы заставить их работать вновь. Итак, приступим к «хорошим рекомендациям» при написании автоматических модульных тестов. Нет, я не буду капитаном очевидностью, в очередной раз описывая популярный стиль написания тестов под названием AAA (Arange-Act-Assert). Зато попытаюсь объяснить, чем отличается Mock от Stub-а и что далеко не все тестовые объекты — «моки».

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

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

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