;
Виктория Слинявчук
Манифест Agile-тестировщика. Часть 2
26.05.2017 2779
Другие статьи автора
Пирамида автоматизации
Распространенные ошибки начинающих тестировщиков
Как научиться учиться. Часть 2
Как научиться учиться. Часть 1
7 принципов тестирования. Часть 1
7 принципов тестирования. Часть 2
7 принципов тестирования. Часть 3
Манифест Agile-тестировщика. Часть 1
Оружие математического поражения
Шерстяная Фуфайка на карте мира
Последние статьи в блоге
Как оценивать работу тестировщиков по науке
Учебный центр IBS получил сертификат ГОСТ Р ИСО 9001-2015
Совет по развитию сертификации ИТ-специалистов при АПКИТ аккредитовал «Платформу сертификации IBS»
Java-сертификация: IBS в сравнении с Oracle
Исследование IBS: число новых ИТ-решений в реестре ПО выросло в 2023 году более чем на треть
6 суперспособностей Fullstack-тестировщиков, которые напоминают навыки животных
5 мифов о системных аналитиках
Методология 12 факторов: как успешно разрабатывать облачные приложения
Баги, которые стали фичами
Шаблоны облачного проектирования
продолжим разбираться с "Манифестом тестировщика", который составили Саманта Лэинг и Карен Гривз.
Следующий принцип:
We value building the best system over breaking the system.
Мы больше ценим разработку лучшей системы, чем попытки ее сломать.
В связи с этим принципом вспоминается старый анекдот.
Приходит тестировщик на собеседование.
Заходит в комнату, ему указывают на стул и говорят: "Садитесь, пожалуйста!"
Тестировщик садится - и стул под ним немедленно ломается.
"Вы приняты!".
Анекдот хоть и забавный, но не совсем соответствует реальности. Хотя существует такое распространенное представление, что тестировщики занимаются исключительно разрушительной деятельностью, в этом только доля правды.
В самом деле, многие, кто выбрали эту профессию, любят что-то ломать и от души радуются, когда находят дефекты Да, тестировщик может играть роль злонамеренного пользователя и пытаться что-то испортить, но это лишь один из аспектов нашей работы.
Позитивное тестирование не менее (а то и более) важно, чем негативное. Порой тестировщики, особенно начинающие, слишком увлекаются сложными негативными тестами: а что если ввести 15 цифр после запятой? а что если ввести строку из 5000 символов? а что если отправить сообщение со всеми спецсимволами вместе, вроде такого: "~!@#$%^&*()_+{}:;'`"?><[]"? Всё это очень увлекательно, но в то же время не стоит забывать о главной цели - создать продукт, несущий некую ценность и выполняющий свои функции как следует. Поэтому простые позитивные тесты, приближенные к реальным действиям пользователям, всё-таки приоритетнее.
We value team responsibility for quality over tester's responsibility.
Мы больше ценим командную ответственность за качество, чем ответственность тестировщика.
Вообще говоря, ответственность всей команды за качество - один из основополагающих принципов Agile.
Но многие ли чувствуют эту коллективную ответственность? Когда возникают сложности, как поступаете вы и другие люди в вашей команде - доказываете, что виноват кто-то другой, или думаете: "А что я мог(ла) бы сделать, чтобы это предотвратить или исправить?".
Если обнаруживается проблема с качеством, винят ли в этом исключительно тестировщиков или же команда разделяет ответственность?
Собственно, тестировщики не могут улучшить качество, роль тестирования - определить уровень качества и проинформировать о нем заинтересованных лиц. Улучшение качества возможно только совместными усилиями всей команды.
Итак Следующий принцип:
We value building the best system over breaking the system.
Мы больше ценим разработку лучшей системы, чем попытки ее сломать.
В связи с этим принципом вспоминается старый анекдот.
Приходит тестировщик на собеседование.
Заходит в комнату, ему указывают на стул и говорят: "Садитесь, пожалуйста!"
Тестировщик садится - и стул под ним немедленно ломается.
"Вы приняты!".
Анекдот хоть и забавный, но не совсем соответствует реальности. Хотя существует такое распространенное представление, что тестировщики занимаются исключительно разрушительной деятельностью, в этом только доля правды.
В самом деле, многие, кто выбрали эту профессию, любят что-то ломать и от души радуются, когда находят дефекты Да, тестировщик может играть роль злонамеренного пользователя и пытаться что-то испортить, но это лишь один из аспектов нашей работы.
Позитивное тестирование не менее (а то и более) важно, чем негативное. Порой тестировщики, особенно начинающие, слишком увлекаются сложными негативными тестами: а что если ввести 15 цифр после запятой? а что если ввести строку из 5000 символов? а что если отправить сообщение со всеми спецсимволами вместе, вроде такого: "~!@#$%^&*()_+{}:;'`"?><[]"? Всё это очень увлекательно, но в то же время не стоит забывать о главной цели - создать продукт, несущий некую ценность и выполняющий свои функции как следует. Поэтому простые позитивные тесты, приближенные к реальным действиям пользователям, всё-таки приоритетнее.
We value team responsibility for quality over tester's responsibility.
Мы больше ценим командную ответственность за качество, чем ответственность тестировщика.
Вообще говоря, ответственность всей команды за качество - один из основополагающих принципов Agile.
Но многие ли чувствуют эту коллективную ответственность? Когда возникают сложности, как поступаете вы и другие люди в вашей команде - доказываете, что виноват кто-то другой, или думаете: "А что я мог(ла) бы сделать, чтобы это предотвратить или исправить?".
Если обнаруживается проблема с качеством, винят ли в этом исключительно тестировщиков или же команда разделяет ответственность?
Собственно, тестировщики не могут улучшить качество, роль тестирования - определить уровень качества и проинформировать о нем заинтересованных лиц. Улучшение качества возможно только совместными усилиями всей команды.
Курсы по тестированию ПО.
Расскажи друзьям:
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!