Что пишут в блогах

Подписаться

Онлайн-тренинги

Очные тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Другие виды тестирования
Разумное парное тестирование
05.02.2019 00:00

Авторы: Оля Фазулзянова, тестировщик Контур.Экстерна и Оля Изюрьева, тестировщик Контур.Биллинга и организатор курса тестировщиков.

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

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

В методологии XP есть практика — парное программирование. Во многих источниках написано о массе его преимуществ: высоком качестве кода, взаимозаменяемости разработчиков и т. д.

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

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

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

Любая практика — всего лишь инструмент. Мы не хотим забивать гвозди микроскопом, поэтому всегда отталкиваемся от задачи. Давайте рассмотрим те задачи, для которых релевантно использование практики «парное тестирование».

Подробнее...
 
Фаззинг или тестирование мусорными данными // Максим Бакиров
18.01.2019 00:00

Публикуем запись доклада Максима Бакирова "Фаззинг или тестирование мусорными данными" с прошедшего в Новосибирске QA DevDay.

Стоит отметить, что Макс пишет на С++ и его доклад очень близок к unit-тестированию. Однако, даже если тема вам не близка, посмотрите видео для развлечения. Наши гости единогласно заметили, что за фаззингом будущее.

Обсудить в форуме

 
SQA Days-24: релизное и регрессионное тестирование
11.01.2019 00:00

Публикуем подборку докладов с конференции SQA Days 24, посвященную аспектам тестирования в процессе регресса и предрелизной подготовки.

  1. Не все так плохо. Выстраиваем регрессионное тестирование на проекте где нет документации – Даниил Майстренко, Performance Lab (Москва).
  2. Эффективность применения матрицы критичности-сложности для регрессионного тестирования – Алексей Кузнецов, Performance Lab (Москва).
  3. Запускать или нет? Как убедиться что мобильное приложение готово к публикации – Юлия Чистова, REDMADROBOT (Москва).
Подробнее...
 
Видеозапись доклада Владимира Полякова "Особенности тестирования ПО в предметной области Life Sciences"
17.10.2018 12:03

Доклад Владимира Полякова "Особенности тестирования ПО в предметной области Life Sciences" с прошедшей конференции COMAQA Spring 2018.

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

Также мы увидим, что для работы в области Life Sciences не требуется высшего биологического образования.

Обсудить в форуме

 
Как сократить сроки регрессионного тестирования с 3 до 1 дня?
20.09.2018 14:12

Автор: Елена Шамхалова

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

Регрессионное тестирование – это набор тестов, направленных на обнаружение дефектов в уже протестированных частях приложения.

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

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

Подробнее...
 
Тестирование SAP: особенности и инструменты
19.09.2018 14:52

В трансляцию блогов регулярно добавляются новые блоги. Их количество уже давно перевалило за отметку 100. Ну а мы продолжаем знакомить Вас с новыми блогами.

Блог компании «Аплана» — http://aplana.ru/infocenter/corpblog

Немного о нас:

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

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

Публикуем одну из первых статей блога.

Подробнее...
 
Введение в исследовательское тестирование
18.09.2018 13:22

Автор: Марсель Гелен (Marcel Gehlen)

Оригинал статьи

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

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

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

Это настоящая кроличья нора – статьи ведут на другие статьи, а те, в свою очередь, на еще большее количество источников. Приятного чтения!

Подробнее...
 
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
30.07.2018 11:43

Оригинальная публикация: http://habr.com/post/358142/

Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта

О чём это всё

Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.

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

Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?

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

Подробнее...
 
Lean-тестирование: теория и практика
27.02.2018 00:00

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: http://testerkiwi.blogspot.ru/2016/02/lean-testing-in-theory-and-practice.html#more

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

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

Мое любимое определение тестирования дал Кем Кейнер: «Тестирование – это эмпирическое исследование, которое проводится с целью предоставить заинтересованным лицам информацию о продукте или сервисе, который тестировался».

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

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

«Ценность любой практики зависит от контекста» и «внутри контекста есть хорошие практики, но лучших не существует». Любая проблема тестирования уникальна. Наш подход к этой проблеме, следовательно, тоже уникален. Выяснить как можно больше и передать другим свое понимание проблемы жизненно необходимо для эффективного тестирования. Чем гибче инструмент или процесс, тем выше количество контекстов, в котором я могу его использовать.

Подробнее...
 
7 правил хорошего тона при написании Unit-тестов
13.02.2018 00:00

Оригинальная публикация: https://habrahabr.ru/company/wrike/blog/337188/

“Хорошими манерами обладает тот,
кто наименьшее количество людей
ставит в неловкое положение.”
Дж. Свифт

Привет, коллеги! Сегодня я бы хотел поговорить о Unit-тестировании и некоторых “правилах” при их написании. Конечно, они неформальные и не обязательны к выполнению, но при их соблюдении всем будет приятно и легко читать и поддерживать тесты, которые вы написали. Мы в Wrike видели достаточно Unit-тестов, чтобы понять основные проблемы, которые возникают при их написании и поддержке, и сформулировать несколько правил для их предотвращения.

1. Unit-тесты нужно писать. Да, как бы банально это не звучало, но писать их нужно. Каждый кусок логики приложения должен быть протестирован, чтобы в будущем избежать проблем. А они могут возникнуть при изменении логики, рефакторинге, или даже при обновлении версии зависимых библиотек. И чем больше покрытие кода тестами, тем быстрее проблема будет обнаружена и исправлена.

2. Это правило очень актуально для тех, кого заставляют покрывать код тестами, и оно звучит так: Тесты — это тоже код, и относиться к нему нужно как к рабочему коду. Это касается и нейминга переменных, и форматирования кода внутри теста, и, особенно, названий тестовых методов. Конечно, написание адекватного имени переменной занимает немного больше времени и ударов по клавиатуре, чем “int i = 0;”, но это повышает читабельность тестов и легкость их поддержки.

Угадайте, что проверяет упавший тестовый метод?)

Подробнее...
 



Страница 1 из 3