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

Подписаться

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

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

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

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

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

.
Опрос: статистика в тестировании
21.02.2018 11:45

Автор: Евгений Демидов

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

Просим поделиться своим опытом работы со статистикой тестирования в этом опросе (прохождение опроса займет не более 2 минут), из результатов которого мы сможем понять:

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

Более подробную информацию об опросе Вы можете найти в этом топике на форуме.

Ссылка на опрос: https://goo.gl/forms/a8QGMF0tO0PGfoyW2 (прохождение опроса займет не более 2 минут)

Большая благодарность каждому, кто поделится примерами графиков, которые Вы создаете на основании собранных метрик тестирования. Ответ не должен быть максимально развернут или как-то аргументирован. Важно лишь узнать какую статистику собирают и используют на практике другие команды, и какие самые популярные виды графиков, построенные на основании собранных тест данных.

Результаты опроса будут также позже опубликованы на портале.

 
А вы не слишком много времени уделяете тестированию ПО?
20.02.2018 11:19

Оригинальная публикация: http://www.networkworld.com/article/2944686/software/are-you-over-testing-your-software.html

Перевод: Анна Радионова

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

Тестирование релиз-кандидатов отнимает слишком много времени.

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

Но что, если вам не нужно было бы прибегать к помощи сотрудника для проверки определенной версии билда, чтобы минимизировать риски перед деплоем? Вместо него бот сообщал бы команде о готовности билда и кому-то оставалось бы только нажать кнопку деплоя?

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

Подробнее...
 
Давайте жить дружно: как сложные коммуникации на проекте сделать приятными
19.02.2018 00:00

Автор: Анаит Азоян, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/how-to-make-difficult-communications-on-a-project-easier/

А начнем так…

«В одном IT-царстве жила-была себе команда тестировщиков: Алеша Попович, Добрыня Никитич, Любава и Гай Юлий. Были в том царстве и разработчики – Змей Горыныч, Илья Муромец и Тихон. Ну и, конечно же, присутствовал тим-менеджер Царь. Все они, такие разные, творили одно доброе дело и корпели над одним общим заданием: укрепить и облегчить жизнь мирскую и не пропустить ни одного Бага. Объединяло их общее желание и стремление, а посему и решили они – будем работать вместе».

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

  • внедрение в сознание всех сотрудников постулата «общее дело объединяет»;
  • установление дружелюбных, искренних и налаженных коллективных отношений;
  • достижение сплоченности как важного фактора эффективности;
  • понимание того, что любой человек в команде – важное звено;
  • налаживание взаимодействия каждого участника со всеми остальными;
  • учет мотивации каждого конкретного сотрудника в зависимости от его выявленных целей и желаний.
Подробнее...
 
Видеозапись доклада Стаса Косарева с онлайн-конференции для тестировщиков КоТэ
16.02.2018 14:26

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

Стас Косарев "Три лучших инструмента для управления тестами"

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

 
Это не та карта, которую я имел в виду: значение, неточности и таксономия визуальных моделей тестирования, часть 2
15.02.2018 00:00

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

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=14

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

Ветки

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

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

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

Подробнее...
 
QA конференция COMAQA, 10-11 марта, Минск
14.02.2018 16:44

10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.

Спикеры из ведущих IT-компаний Швеции, Германии, Финляндии, Ирландии, России и Беларуси соберутся вместе, чтобы рассказать о своем опыте в тестировании и управлении, поделиться личными практическими “секретами” и наработками.

Организаторы подготовили для вас:

  • 16 докладов в первый день конференции от профессионалов-практиков;
  • Видеотрансляцию докладов (условно платную) для тех, кто захочет присоединиться удаленно;
  • 3 потока мастер-классов во второй день конференции;
  • Обед и кофе-паузы для комфортного общения со спикерами и нетворкинга;
  • Сувениры от организаторов и партнеров конференции.

Полную программу и билеты вы найдете на официальном сайте конференции: http://conference.comaqa.by/

Следите за новостями конференции на странице мероприятия в Facebook

Приходите, знакомьтесь и объединяйтесь! And let's start the party!

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

 
Что делать когда нет времени на тестирование: лайф-хаки и практики
14.02.2018 00:00

Автор: Юлия Бурматова, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/what-to-do-when-there-is-no-time-for-testing/

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

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

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

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

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

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

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

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

Подробнее...
 
Это не та карта, которую я имел в виду: значение, неточности и таксономия визуальных моделей тестирования, часть 1
12.02.2018 00:00

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

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=14

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

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

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

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

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

«Круто!» - думаете вы.

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

Подробнее...
 
Почему тест-кейсы - это не тестирование, как создавать карту для исследовательского тестирования, инструменты автотестов для мобильных приложений: самые интересные новости тестирования за конец января
09.02.2018 15:38

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

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

Подписаться на рассылку можно по ссылке.

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

 
Видеозапись доклада Виктории Юркевич с онлайн-конференции для тестировщиков КоТэ
09.02.2018 10:45

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

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

Как этого избежать?

Доклад Виктории Юркевич "Как избежать ошибок при покрытии мобильных окружений"

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