Home

Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять?

В рамках курса мы создали специальный «бажный» сайт для тестирования. Внедрили туда 20 разных по типу ошибок. Чтобы их найти, придется применять разные техники и инструменты:

— Собрать логи.

— Проверить консоль JS.

— Найти граничные значения.

— Пройтись по туру, отмененному из-за дождя.

— Проверить разные браузеры.

— Убрать ограничение, установленное на клиенте.

— …

Сервер поднят на linux-е, куда у студентов есть доступ на чтение логов. Это позволяет применить полезные в будущем инструменты:

• Putty — снять статистику, последить за логом

• WinSCP — забрать лог с сервера

• Grep — найти нужный стек в логе (linux)

• Cygwin — найти нужный стек в логе (windows)

Еще на курсе будут использоваться:

• Postman — послать POST-запрос на сервер

• Perlclip — сгенерить большую строку текста

Курс запускался в два этапа — год назад вышла первая версия на 4 занятия. Мы рассказывали только то, что не зависит от “веб — не веб, линукс — не линукс” итд. Как искать, локализовывать и оформлять задачи. Материала было много! По отзывам студентов:

Ого, сколько материалов и заданий! Скучать не придется. А текст задания: "Меня обманули и обесчестили, я разворачиваюсь и ухожу." развеселил))

Но курс должен не только веселить, но и учить. Общаясь с ребятами, мы поняли просто “найти и локализовать” неинтересно. Это ведь все умеют, мы занимаемся этим каждый день.

Интересно другое:

— Как понять, кто именно сломался, если системы интегрированы?

— Как доказать подрядчику, что проблема именно на его стороне?

— Что делать, если ошибку уже пропустил?

Или технические штуки, которые пригодятся в дальнейшем:

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

Все это теперь есть! Мы расширили курс, теперь там девять уроков вместо четырех. И 27 домашних задания — чтобы как следует закрепить материал. Приходите к нам, если хотите взглянуть на “обычный” процесс поиска и локализации багов по новому.

Описание курса

Подробное описание с примером видео-лекции

Вышел выпуск рассылки за вторую половину декабря, его содержание доступно по ссылке.

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Друзья, поздравляем вас с чудесным и даже немного волшебным праздником - с Новым годом!

Желаем вам всего самого лучшего в следующем году. Пусть все хорошее, что не успело произойти в 2016-м, обязательно случится в 2017-м. Желаем вам здоровья, удачи, любви и пусть самые близкие всегда будут рядом!

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

С наилучшими пожеланиями, команда Software-Testing.Ru

Версия открытки для печати

Время идет, появляются новые инструменты автоматизации тестирования. Влияет ли это на рабочий процесс? Конечно!

Что делать в таком случае: переписывать тесты с нуля или достаточно только немного подправить их? А как это сделать, ничего не сломав? Сколько времени придется потратить на доработку? Вопросов немало.

Коллеги на конференции QA Fest 2016 рассказали об эволюции автоматизации и поделились своим опытом актуализации автотестов:

Дмитрий Химион - Векторы развития систем автоматизации тестирования

Яков Крамаренко - Укрощаем фреймворки-динозавры используя NSelene

Иван Пашко - Теория Дарвина в тестах. Эволюция Wait-ов

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2016/12/13/testing-without-requirements/

Перевод: Ольга Алифанова

Этот вопрос звучит частенько: что же делать, вот приходишь ты на работу, или на проект, и должен тестировать, а ТРЕБОВАНИЙ НЕТ!

Для некоторых из нас крайне трудно представить себя в подобной ситуации.

Если вы работали только в местах, где тест-кейсы были документированы, а спецификации присутствовали, то сама мысль об этом выглядит для вас дикой.

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

На то есть множество причин – и очень хороших причин, хотя плохие среди них тоже присутствуют.

Но несмотря на причины, возможно, в какой-то момент вы обнаружите себя в этой ситуации и вас попросят протестировать то, для чего нет требований и, возможно, НИКТО не знает, как оно на самом деле должно работать.

Сейчас я объясню, что это вполне посильная задача – и вы не просто справитесь с ней, но справитесь блестяще, и улучшите свой навык тестировщика.

Может ли самый первый релиз продукта быть достаточно хорошо оттестированным, или кучу шишек неизбежно набьёшь уже в продакшене? Конференция по тестированию «Гейзенбаг», которую мы недавно провели в Москве, состоялась в самый первый раз, так что можно было на её наглядном примере и посмотреть. Как она прошла? Возникли ли проблемы? И как вообще должна выглядеть конференция по тестированию, если внутри него существуют подвиды с совершенно разной спецификой, а дело с ним имеют специалисты разного профиля?

Утром 10 декабря в холле «Radisson-Славянской» можно было увидеть не только тестировщиков, но и разработчиков, которые не хотят просто «перекидывать код через стену», а ощущают значимость тестирования. В том же холле, помимо прочего, можно было поиграть в робохоккей — и поскольку в этой игре надо управлять жуками, она смотрелась на «Гейзенбаге» довольно символично.

Развитие - это немаловажная часть нашей жизни. Поэтому после того, как вы нашли свою первую работу в качестве тестировщика, на повестке наверняка появятся вопросы “Что я должен сделать, чтобы остаться востребованным специалистом?” и “Что поможет мне в дальнейшем профессиональном развитии?”

С советами от более опытных коллег вы можете ознакомиться, посмотрев ниже записи докладов с конференции QA Fest 2016.

Роман Белоусов - Как найти первую работу в IT-сфере

Екатерина Шепелева - Секрет успеха: как стать и оставаться востребованным на рынке IT

Игорь Бондаренко - Курсы по QA: как не ошибиться, и как еще научиться тестированию?

Автор: Александр Мешков

Оригинальная публикация

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

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

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

Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Демминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.

Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.

MBI или Model Based Improvement — подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процесcные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.

Но подходят ли нам такие модели для аудитов уже существующих процессов?

По моей практике скажу, что нет!