Памятка тестировщика

Решения, основанные  на моем опыте работы в тестировании.

Подсказки и памятки о том, какие вещи нужно помнить в тестировании:

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

2. Обязательно проверять граничные значения для ключевых объектов.

В случае, если максимальное количество проверить невозможно — заявлять поддержку только того, что протестировано.

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

Пример фейла: Так, в одном из продуктов была заявлена поддержка SPN, в то время как SPN поддерживался только локально, однако это не было отражено в документации для пользователя.

 

 

Конспект книги Карла Виргеса «Разработка требований к программному обеспечению»

Черновики мыслей,  основанные на прочтения статьи Карла Виргеса «Разработка требований к программному обеспечению»

Статья в процессе дработки.

Основные мысли из главы 1

Концепции БА:

  1. Образ и границы проекта определены ясно
  2.  Требования к продукту будут регулярно обновляться и согласовываться не реже 1 раза в неделю
  3. Требования будут фиксироваться письменно
  4. Требования будут уточняться исходя из отчетов конкретных пользователей
  5. Информация доносится до разработчиков четкой и ясной, отсутствует двусмысленность
  6. процесс внесения изменений в требования четко оговорен
  7. график не нарушается внесением изменений в требования, при внесении дополнительных фич, какие-то другие фичи удаляются для того, чтобы поддержать график и работоспособность проекта
  8.  объяснять заказчикам, какой функционал нужен их клиентам для того, чтобы помочь заказчику принести максимальный бизнес-профит
  9. Аналитик на проекте не меняется либо люди, которых я подбираю для проекта, придерживаются одного подхода и передают требования и пожелания заказчика другим коллегам в сжатые сроки для того, чтобы люди не распылялись на перечитывание когда, кучи переписок, аудиозаписей и воспоминаний разговоров в коридоре.

Требования разделяются на 3 уровня ( стр. 27) 

  1. Бизнес-требования
  2. Требования пользователей
  3. Функциональные требования

trebovaniya

Разработка требований для продукта(стр.33)

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

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

Управление требованиями для продукта

Спеку нужно согласовать с пользователями и с разработчиками

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

Характеристики отдельных положений спецификации превосходных требований (стр. 42)

  1. полнота
  2. корректность
  3. осуществимость
  4. необходимость
  5. назначение приоритетов
  6. недвусмысленность
  7. проверяемость

Характеристики спецификации требований (стр. 44)

  1. полнота
  2. согласованность
  3. способность к модификации
  4. трассируемость

Глава2. Требования с точки зрения клиента (46-26)

Глава 3. Хорошие приемы создания требований (-41)

Начинать, представляя конечную цель

Недавно перечитывала книгу стивена Кови «7 навыков высокоэффективных людей».

Один из навыков «Начинать, представляя конечную цель» напомнил мне о том, что пора скорректировать планы на ближайшие 5-10 лет.  Я пыталась ответить на вопрос, зачем я хочу пойти в бизнес-анализ, что я буду там делать, насколько полезна будет моя деятельность для меня самой и для общества.

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

 

Конфликтогены

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

Автор приводил несколько примеров этих слов.

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

Слова

«Я тебя сейчас у*ью, иди на *уй»

«ну и что! »

«и что дальше! »

«что ты хочешь»

«ты чего не поднимаешь трубку»

«ты хочешь ту бумажку повесить?» в контексте диалога …

Интонации

грубые

Жесты

 

 

 

 

 

 

 

 

Высокомерие

высокомерие

Высокомерное поведение — это ловушка, в которую попадают многие люди. Зачастую о высокомерии мы вспоминаем лишь тогда, когда попадаем в сложную для нас ситуацию.

Примеры высокомерия:

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

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

na-ravnyh

 

Что делать? — Часто спрашиваю я себя.

Сейчас в голову приходят такие мысли:

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

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

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

Когда я встречаю другого человека, я радуюсь, потому что он — Божье творение :), и напоминаю себе о том, что к каждому человеку нужно относиться уважительно.

Зачем я это пишу? Я не хочу быть высокомерной.
Но не всегда замечаю это за собой. Чтобы вовремя распознать эту проблему и остановить ее развитие, просто чтобы стать лучше, я  пишу эти строки.

Если моя статья поможет вам хотя бы задуматься о том, чтобы сделать мир чуточку добрее, значит, я написала ее не зря.

 

7 шагов к командной работе в тестировании

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

Слайдшоу.

 

Подробно

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

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

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

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

slide1-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

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

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

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

slide2-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

 

ШАГ 1

Одна из проблем в разработке нового проекта  — непонятно что и как тестировать.

slide3-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

Часто случается, что программист с тех. лидом уже сделали какую-то фичу. Фича переходит в тестирование в сокращенном варианте.
На примере ниже — это заголовок с небольшим указанием, что может пригодиться для тестирования 🙂

slide4-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

slide5-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide6-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide7-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

Решая эту задачу и основываясь на своем жизненном опыте, я нашла вот такие решения:
Внедрение новых практик — одной из которых, будет, к примеру, ежедневный синк программистов и тестировщиков( личная встреча или звонок)  на 30 минут -1 час для того, чтобы задать все имеющиеся вопросы и получить на них ответы.  В том числе такие синки позволяют создать дополнительные action items или подзадачи и мини-собрания для того, чтобы глубже уточнить некоторые другие вопросы и не занимать время всех присутствующих.

По результатам общения правилом хорошего тона считается отправлять самари — выжимку основных тем обсуждения. В случае для ежедневных собраний, если темы не объемные — достаточно просто на рабочей доске      ( jira, tfs … )  создать несколько подзадач и назначить исполнителей.

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

Немного о Team rules
Вот например памятка о том,  какого алгоритма было бы хорошо придерживаться, высылая предложения клиенту.

Proposal emails
All our proposal e-mails should correspond to the following structure:
1)Business case. How the fix/feature affects business logic.
2)Technical description of the fix/feature: What a cause of the issue? How the feature should work from technical point of view?
3)Ways to fix/implement. Analyze merits and demerits of every suggested method.
4)Conclusion: what we would prefer and why.

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

2.  тестировщик-программист.
Когда и как решать вопросы по новым фичам. Переводить неясную задачу на программиста или организовать несколько кратких синков в течение дня в удобное для всех время и т.д.

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

slide8-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya


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

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

Несколько лет назад у меня был замечательный опыт работы с программистами, которые много лет работали на одном проекте. У них была наработанная база сценариев, как сконфигурировать какое-либо оборудование с картинками и пошаговыми инструкциями для тестировщиков.  Кроме того, когда они делали технически сложный фикс, который описывал изменения в коде, и который сложно представлялось как протестировать, они не ленились подробно расписывать тестовые сценарии для тестировщиков прямо в задаче. Некоторые из этих сценариев были очень типовыми, их можно было добавлять в тест-план для повторного тестирования.
slide9-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

ШАГ 2

slide10-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

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

slide11-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide12-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

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

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

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

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

Желательно в спринте не заполнять все 100% времени команды, т.к. всегда могут  быть непредвиденные случаи или срочные задачи.

 

slide13-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

slide14-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

ШАГ 3
slide15-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

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

slide16-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide17-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

ШАГ 4
slide18-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

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

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

slide19-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

ШАГ 5
slide20-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

В случае, когда нужно подстраиваться под сложившиеся  шаблоны, я предлагаю свои решения, но если они не устраивают лида, или не подходят под проект, предпочитаю пересмотреть свои убеждения в сторону согласованности.
Желательно договариваться о едином стиле написания тестов, чтобы потом можно было проходить чужие тесты как свои. Это даже можно вынести в блок своей внутренней вики Team rules.
Ниже я представила свои заметки по написанию тестов:

slide21-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide22-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide23-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide24-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

ШАГ 6

slide25-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

slide26-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

А еще есть человеческая высокомерность, чувство всесильности, когда один человек что-то знает, а другой нет. Иногда люди, которые владеют информацией, этим пользуются и пытаются таким образом показать свою значимость. Что тут говорить, — незнающим коллегам в такой ситуации нелегко.
На новом проекте ситуация может доходить до того, что коллеги объединяются и начинают жаловаться на то, что человек ничего не знает, с ним невозможно работать, потому что он задает много вопросов. Тут хочется задать вопрос: может быть, дело не в том, что человек глупый, а в том, как организован процесс, и как сам человек понял свое место в этом процессе? На эту ситуацию  у каждого будет свое видение.

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

Как получить нужную информацию в короткие сроки?
На слайде несколько примеров того, что помогало мне.

slide27-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya
Еще Стивен Кови писал, что обучая других, человек обучается сам. Кроме того, вклад в другого человека, поможет в будущем передать ему задачи, которые сейчас приходится делать самому. А чтобы эти вложения были долгосрочными, и  человек не ушел, важно постоянно уточнять уровень его доверия руководителю и компании, а также общее самочувствие человека в команде.

slide28-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

На практике, человек, который делится чем-то новым по проекту: какой то новой утилитой, чтобы процесс был легче, или новыми знаниями, которые можно применить здесь и сейчас, — непроизвольно заслуживает уважение и доверие всей команды.

slide29-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

ШАГ 7slide30-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

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

slide31-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

slide32-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

 

ИТОГ
slide33-7-shagov-k-uluchsheniyu-vzaimodejstviya-v-komande-testirovaniya

 

Полезная памятка по личной эффективности

Общие подходы

1. Важно понимать, что больше ошибок совершают те, кто больше всех на них концентрируется. Поэтому мне нужно концентрироваться на удачном результате.

2.  Делать подробное описание, что есть в каждом конкретном бэкапе при сохранении каких-либо данных! Не лениться делать это сразу, потому что потом очень сложно понять, что находится внутри каждого из таких пакетов.

3.  Применять по максимуму Технику ТутИСейчас (Техника ТИС). Т.е. если нужно решить какую-то проблему, и ее можно решить за 5-15 минут, лучше сделать это сейчас, т.к. дальше будет сложнее.

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

5. Чаще задавать себе вопрос «Как я делаю это сейчас? Как я могу сделать это лучше?»  — это помогает усовершенствовать любой повторяющийся процесс

 

Результаты опроса тестировщиков и менеджеров на тему взаимодействия в команде тестирования

Привет. В марте 2015 года мной проводился опрос на тему взаимодействия в команде тестирования. Около 30 респондентов из Беларуси и России, работающих в области тестирования, согласились поделиться своим опытом и знаниями.

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

Ответы представлены в формате Excel.

Ответы руководителя команды тестирования (Responses)

Ответы Специалиста по тестированию (Responses)

Как повысить продуктивность команды тестирования. Что говорят менеджеры, а что тестировщики

Привет, друзья.
Выкладываю доклад с SQAdays 17, отражающий взгляды менеджеров и тестировщиков на то, как повысить продуктивность команды тестирования.

А какие способы повышения продуктивности команды знаете вы? Какие из них были самыми эффективными? Ждем ваших ответов в комментариях.


Видео с конференции

Доклад Анастасии Симанович на конференции SQA Days-17, 29-30 мая 2015, Минск

www.sqadays.com

Как создать хорошую команду тестирования

Не так давно на сайте проводился опрос на тему взаимодействия в команде тестирования.
Спасибо всем, кто принял участие и поделился своим мнением!
Были получены очень разнообразные ответы. Коллективный ум — это верный способ решения насущных проблем.
Ответы были сопоставлены. Наиболее яркие из них представлены на нашем сайте.
Что QA менеджер говорит о том, как создать хорошую команду тестирования.
qa-manager-good-team
А вот, что об этом думает тестировщик
qa-engineer-good-team
И менеджер и тестировщик во многом сходятся во мнении о хорошей команде тестирования
qa-eng-manager-good-team1
qa-eng-manager-good-team2
qa-eng-manager-good-team3

А какой вы видите хорошую команду тестирования? Напишите об этом в комментариях.