Home

Автор: Ирина Соколова, Senior QA Engineer, qualsolife.ru

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

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

Автор: Артём Сапегин
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi
Оригинал статьи
Перевод: Ольга Алифанова

В Министерстве тестирования я принадлежу к очень небольшой группе. Я участвую в независимых митапах, даже если они мне не близки, я делаю доклады, если меня приглашают (но меня не приглашают), и я тихо сижу в канале exploratory-testing в их Слаке. Сегодня я вдохновилась статьей Джамала Тодда в этом канале.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей вы столкнетесь с выдуманным, но реалистичным сценарием использования контрактного тестирования с Pact и Pactflow.

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

Этот распределенный подход к разработке ПО имеет ряд существенных преимуществ, особенно в плане гибкости и масштабируемости:

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

Помимо этих, есть и другие плюсы. Однако этот подход к разработке несет и проблемы, особенно в интеграции и end-to-end тестировании. Чтобы пристальнее взглянуть на эти проблемы и пути их решения, возьмем для примера приложение, состоящие из нескольких неплотно связанных компонентов.

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

Автор оригинала: Vladimir Khorikov

Автор: Eran Kinsbruner
Перевод: Татьяна Рыжова, тренер курса Английский для тестировщиков

Перед тем, как познакомиться с эффективной стратегией непрерывного тестирования, следует разобраться в том, что есть такое “непрерывное тестирование”? Ниже - определение, которое мне особенно импонирует:

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

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

Автор: Боков Максим
Оригинальная публикация

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

Автор: Лобанов Святослав (Менеджер бета-тестирования IVI.ru)

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

Меня зовут Святослав, в IVI я отвечаю за бета-тестирование. Хочу рассказать вам про то, как пользователи могут сделать мир лучше.

У нас в компании есть практика random coffee: сотрудники разных отделов получают приглашение и встречаются в офисе или в Slack, заваривают себе капучино или ванильный макиато и рассказывают друг другу, чем они занимаются. Так мы создаём взаимосвязи и делимся знаниями. И на таких встречах, услышав про бета-тестирование, мне часто задают вопросы: «В смысле? Как? Почему?» Так за многими выпитыми чашками кофе и родился подробный рассказ о нашей работе, про которую, оказывается, не знает никто, кроме нашего клуба бета-тестировщиков и сотрудников тех. отдела. Усаживайтесь поудобнее, наливайте чай, кофе, смузи или апероль шприц.

Автор: Адам Найт (Adam Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор Нина Агеева – тренер курса “Первый Онлайн ИНститут Тестировщиков”  (ПОИНТ).

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

Бытует мнение, что исследовательское тестирование – удел молодых специалистов, якобы думать там совсем не нужно, тыкай себе хаотично всё подряд – авось и баги найдутся. Ан нет. Исследовательское тестирование – это целая наука со своими методологиями и техниками.

Давайте обратимся к теории, что же такое исследовательское тестирование? Что значит “мы исследуем”? Исследовать – значит изучать, знакомиться, смотреть на продукт и на то, как он будет реагировать на ваши действия.

Исследовательское тестирование – это одновременное создание тестов, их прохождение и корректировка в зависимости от поведения вашего  продукта.