Home

Автор: Ян Яап Каннегитер (Jan Jaap Cannegieter)

Оригинал статьи: http://www.testingcircus.com/the-way-to-involve-stakeholders-in-testing/

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

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

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

Автор: Эми Филлипс (Amy Phillips)

Оригинал статьи: http://www.testingcircus.com/how-a-lone-tester-can-build-an-efficient-test-process-despite-the-challenges/

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

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

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

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

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

Оригинальная публикация: http://quality-lab.ru/investigation_held_by_testers_or_testers_role_in_scrum/

— Итак, поступило новое дело: в нашем распоряжении 10 дней для поиска места тестировщика в Scrum разработке. Необходимо понять, что же это такое Scrum, что входит в это понятие, кто вовлечен в этот процесс, и что именно необходимо делать тестировщику.

— Шеф, так что же такое Scrum?
— Все элементарно, коллега. Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в установленные небольшие промежутки времени предоставлять заказчику (конечному пользователю) наделенное наибольшим приоритетом работающее ПО с новыми возможностями.
— И из чего состоит этот процесс?
— Из принципов, скоупа задач, определенных при планировании, и ограниченных (четко оговоренных и определенных) сроков. Учитывается и то, что качество не должно пострадать из-за скорости или установленных временных рамок.
— Шеф, и с чего начнем?
— А начнем с того, что рассмотрим наиболее простую и понятную схему для Scrum процесса: двухнедельная итерация (10 рабочих дней). При этом мы имеем определенно важный спринт, сплоченную команду разработки и тестирования, минимум документации, четкие требования к проекту и лаконичное описание требуемых разрабатываемых фич.
— И где же в этой схеме место тестировщика?
— А в этом нам предстоит разобраться, коллега!)

Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2018/01/31/good-gherkin-scenario-titles/

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

Золотое правило Gherkin гласит:

"Обращайтесь с читателями так, как вы хотели бы, чтобы обращались с вами. Пишите Gherkin так, что люди, не знающие фичу, поймут, о чем это".

Хороший Gherkin (как и любой язык, основанный на specification-by-example) неразрывно связан с созданием хороших заголовков для поведенческих сценариев. Заголовок – это лицо сценария: он резюмирует суть поведения. Хорошие заголовки серьезно облегчают сотрудничество в команде, а плохие – затрудняют его. Но что же делает заголовок "хорошим"? Вот несколько неплохих советов.

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2018/03/four-and-more-questions/

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

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

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

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

Оригинальная публикация: http://quality-lab.ru/what_we_learn_from_mistakes_and_why_making_mistakes_is_a_good_thing/

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

Баг, там баг!

Однажды я заблокировала продакшн-релиз… Это вполне себе обычное дело в практике тестировщика. В том случае, когда ты работаешь недавно, блокировка релизов – дело более опытных коллег. Но что делать, если твои старшие товарищи в отпуске, а на продакшн-версию может попасть «поехавшая верстка»?

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

Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2017/10/08/bdd-101-manual-testing/

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

Философия разработки через реализацию поведения ставит во главу угла автоматизацию: спеки поведения должна превратиться в автоматизированные тесты. Однако BDD вполне может включать в себя и ручное тестирование. У ручного тестирования есть свое место и свои задачи, даже в BDD. Помните, поведенческие сценарии – это в первую очередь поведенческие спецификации, и их ценность выходит за рамки тестирования/автоматизации. Любой сценарий можно прогнать как ручной тест. Следовательно, встают вопросы, в каких случаях пользоваться ручным подходом, и как с ним управляться.

Оригинальная публикация: https://www.testdetective.com/2018/05/code-review-for-testers.html

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

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

И хотя код-ревью и запросы на включение кода (pull requests) хорошо известны разработчикам, эти понятия все еще остаются не до конца понятны тестировщикам. В большинстве scrum команд, в которых мне приходилось работать, инженеры-тестировщики по умолчанию не принимали участия в процессе просмотра запросов на изменение кода. Самое время изменить подобное мышление тестировщиков (и команд!). В этой статье я бы хотел рассмотреть код-ревью с позиции тестировщика и обозначить его преимущества для тестировщиков и scrum команд.

Оригинальная публикация: http://blog.tentamen.eu/oracle-exercise-on-real-example/

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

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

Дисклеймер: здесь не идёт речи о каком-то новомодном фреймворке для тестирования. Это статья об искусстве тестирования в чистом виде.

Вы еще здесь после прочтения дисклеймера? Отлично!

Оракулы – это принципы или механизмы, благодаря которым мы распознаем проблему.

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

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

Итак, начнем.

Миграция данных – перенос данных на новый ресурс/окружение.

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

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