Разное

Управление командой тестировщиков: Тестирование ПО. Уровень 2. Управление командой тестировщиков.

Содержание

Тестировщик в команде, или команда тестировщиков? — управление

Если я правильно понял, вопрос, есть 2 варианта:

  1. Выделенный тестировщик для каждой из команд.
  2. Отдельный QA отдел с динамически распределяемой нагрузкой.

ИМХО 2-й вариант оптимальнее.
а). Если Вася уйдёт в отпуск / заболеет, его заменит Петя, который также знаком с данной функциональностью. В случае выделенного ресурса такой замены не произойдёт, потому что Петя не знаком с функцональностью продукта Васи.
б). В случае временной низкой загрузки на проекте Пети, ему вполне могут скинуть задачи Васи, у которого сейчас как раз запара. В случае выделенного ресурса, Петя для Васи будет бесполезен: его обучение отнимет время, а пока Петя вкурит функциональность продукта, запара успеет закончиться.
в). Если Вася увольняется, остальной отдел сможет взять эту нагрузку до тех пор, пока не найдут ему замену. Эффективность будет снижена, но ничего фатального не произойдёт. В случае выделенного ресурса, эффективность тестирования будет снижена значительно. Более того, не исключён вариант, что Коля, которого возьмут вместо Васи, посчитает решение Васи полным бредом и начнёт писать всё с нуля, что повлечёт дополнительные трудозатраты.
г). Если продукты связны между собой, возникает потребность тестирования интеграции. Абсолютно не проблема в случае отдела. Есть тикет, есть исполнитель. В случае выделенного ресурса, возникнет вопрос, кому это тестировать: никто не захочет брать на себя лишнюю работу, которая с его продуктом напрямую никак не связана.
е). В случае введения автоматизации, отдел сделает это сравнительно легко: 2 человека берут задачи 3-х, 3-й, наиболее компетентный, разворачивает окружение и пишет автотесты. В случае выделенного ресурса, всё не так просто. Каждый из тестировщиков вынужден будет тратить значительный % времени на описанные выше задачи, что неминуемо приведёт к падению качества тестирования в целом. Как минимум до тех пор, пока автотесты не начнут приносить пользу.
ж). Если продукты связаны, они вполне могут быть похожи. Напрашивается создание общего тестового фреймворка. В случае отдела — не проблема. QA Lead берёт на себя / делегирует роль Test Architect. В случае выделенного ресурса, TA столкнётся с лишними проблемами типа “зачем делать так, если оно написано эдак и работает”.

Плюсы 1-го подхода: сниженные затраты времени / денег на роль QA Lead. Но эта разница легко перекроется с лихвой, когда прилетит любой из 6-ти перечисленных выше раскладов.

Как организовать работу QA. Один практически примененный способ / Хабр

Предыстория

Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?

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

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

По правде говоря, придя в этот проект и за несколько дней оглядевшись по сторонам, я, как и моя коллега, поначалу немного впала в ступор. Не потому что я не знала, что делать. Скорее, я не знала как грамотно себя вклинить в сложившиеся здесь устои. Команда разработчиков замечательно существовала без тестировщиков. Они использовали канбан, принципы continuous delivery, бесстрашно, спокойно и уверенно деплоили на production почти каждый день, даже по пятницам. А все потому, что у них было прекрасное покрытие автотестами. Пожалуй, лучшее, что я когда-либо встречала. Ревьюя пулл реквесты друг друга, они не стеснялись подсказывать друг другу каких еще автотестов добавить. Автор текущего изменения сам деплоил свою работу на production, а значит, полностью сам нес ответственность за свою работу. И он ее нес, несмотря на то, что на проекте появилась я … и перед деплоем неплохо было бы услышать и мое мнение.

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

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

Организация работы QA Инженера

Задаем нужные вопросы

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

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

Первый вопрос. Что из себя представляет структура организации, а именно кто над кем стоит и кто за что отвечает?

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

Второй вопрос. Компания ввела в проект QA Engineer, каковы их ожидания относительно меня, какие цели они преследовали открывая эту позицию?

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

На этом первая часть дискуссии закончилась.

Обсуждаем план действий

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

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

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

Формируем QA Strategy

1. Введение в Quality Assurance

Напомните/впервые познакомьте с термином Quality Assurance. Поверьте, у вас в команде полно людей, которые очень смутно представляют себе, что это такое. Совсем общие определения можно позаимствовать из википедии. Тактично обозначьте, что присутствие команды QA на проект не означает, что вся ответственность за качество работы теперь перекладывается только на них:

Testing is a part of QA. It allows us to determine the level of quality of the feature(s) that we are assessing.

It is not the sole responsibility of testers to carry out QA. The entire team can and should contribute to ensure a high level of quality of the products and services being delivered.

2. Введение в QA Strategy

Подготовьте к тому, о чем дальше люди будут читать.

The Testing Strategy is an evolving document detailing the processes and way we are going to ensure the quality of our product going forward.

Озвучьте контент. Это может быть как просто оглавление, так и более тезисные предложения. Здесь упомяните о существовании Подхода к тестированию (Test Approach), Процессов тестирования (Test Process), Стратегия создания автотестов (Test Automation Strategy) и необходимости Тест плана (Test Plan).

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

3. Test Approach

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

Классика жанра и хорошо работающие подходы – это «действующий на опережение» (proactive) и «основанный на рисках» (risk-based).

We will be adopting a proactive and risk-based testing approach.

Proactive — This means that the test design process is initiated as early as possible in order to find and fix the defects before the build is created.

Risk-based — This means that we will organize our testing efforts in a way that reduces the level of product risk when the system ships. According to the ISTQB syllabus «Risk-based testing is the idea that we can organize our testing efforts in a way that reduces the residual level of product risk when the system ships. Risk-based testing uses risk to prioritize and emphasize the appropriate tests during test execution, but it’s about more than that. Risk-based testing starts early in the project, identifying risks to system quality and using that knowledge of risk to guide testing planning, specification, preparation and execution. Risk-based testing involves both mitigations — testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects — and contingency — testing to identify workarounds to make the defects that do get past us less painful. Risk-based testing also involves measuring how well we are doing at finding and removing defects in critical areas»

Когда мы говорим про опережение, мы, в первую очередь, должны говорит о контроле качества спецификации требований. Менеджеры, которые составляют спецификации элементов очередного цикла разработки, в большинстве своем мыслят как простые пользователи системы, в то время как логика мыслей разработчиков существует в другом измерении. Во-первых, не раз я видела такое, что разработчик, читая спецификацию, не может перевести ее на язык программирования. Например, не может сопоставить упомянутого в спецификации пользователя с существующими в системе ролями/правами доступа. В итоге он может подобрать наиболее подходящую, по его личному мнению, роль, которая окажется не той и придется возвращать функциональность в работу позже и терять время; либо задать вопрос менеджеру, который, быть может, ушел в отпуск и снова терять время в ожидании. QA Engineer это та замечательная прослойка между заточенным на пользователя менеджером и технически мыслящим разработчиком, особенно, если QA Engineer не пренебрегает бело ящичным тестированием. Именно мы способны понять менеджеров и перевести их мысли разработчикам. Вовремя.

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

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

4. Test Process

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

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

We will use the test process outlined in the Foundation level ISTQB syllabus: Test Planning and Control, Test Analysis and Design, Test Implementation and Execution, Evaluating Exit Criteria and Reporting, and Test Closure Activities.

5. Responsibilities

Обозначьте свои и чужие обязанности на поприще повышения качества продукта. Донесите свою миссию.

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

Во-вторых, разъясните и уясните направление своего постоянного развития. QA Инженер — главный эксперт по функциональности продукта: знает, как и что работает, способен объяснить, как и что нужно тестировать. Он – человек, который предугадает эксплуатационное поведение заказчика, а значит, не позволит развиться серьезным проблемам.

В-третьих, обозначьте способ взаимодействия с менеджерами и разработчиками. Например, остановитесь на Three amigos agile approach

Collaboration between Business, Development and QA

a. Business — What problem are we trying to solve?

b. Development — How might we build a solution to solve that problem?

c. Testing — What about this, what could possibly happen

6. Testing Levels and QA Automation Strategy

На сегодня этот раздел у меня стал отдельным самодостаточным документом. Но на уровне организации зарождающегося QA процесса в команде, обозначьте какие виды тестирования кто будет исполнять. Что будет выполняться вручную, что автоматизироваться и по какому принципу. Кто за какие автотесты отвечает.

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

7. Feature workflow

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

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

Например, мой вариант такой

The workflow below details the process that we will adopt internally.

1. Get story before planning session

2. Create a checklist according to acceptance criteria and the description

3. Note unclear details/questions

4. Clarify questions on planning

5. Update the checklist

6. Highlight any dependencies and how you’re going to overcome them

7. When the story is in Review check if acceptance criteria are covered by autotests

8. Encourage developer to cover all acceptance criteria with autotests or do it yourself

9. When the story is ready for testing perform manual testing using the checklist

10. Create bugs for the story if they exist and return the item to development

11. When bugs are fixed perform manual testing using the checklist again

12. Check if all autotests are passed

13. Create a task for implementing additional integration autotests if it is needed

14. Move story in QA Passed state

8. Test Plan

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

На данном проекте мой Тест План — это набор чеклистов для каждой Story. При имеющемся уровне автоматизации пока этого достаточно.

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

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

Как работать с документом

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

Прописывая каждое предложение, хорошо бы задумываться над вопросами: «Я, действительно, хочу так работать?», «Я, действительно, буду воплощать это в жизнь на проекте?»

Если оба ответа положительны, уверенно печатать дальше.

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

Если один из ответов – из ряда «Пока не знаю», пусть пока живет на ваших страницах.

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

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

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

Спасибо!

Качество — ответственность команды. Наш QA опыт / Блог компании Miro / Хабр

Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).

Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.

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

С чего начался эксперимент

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

Уход тестировщика в отпуск — отдельная история. Ему нужно заранее найти кого-то из тестеров, кто готов взять его задачи в дополнение к своим, договориться, погрузить в задачи. Одновременно уйти в отпуск двум тестерам — непозволительная роскошь.

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

История первая: бесконечное перекидывание задачи

Есть я и разработчик. У каждого свои задачи. Разработчик закончил одну из задач и отдал её мне на тестирование. Так как у этой задачи приоритет выше, чем у моих текущих, — я переключаюсь на неё. Нахожу баги, завожу всё в Jira и отдаю обратно разработчику на доработку.

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

В итоге, общее время работы над задачей увеличивается в несколько раз, вслед за этим увеличивается Time to market, а это критично для нас как для продуктовой компании. Причин увеличения времени работы над задачей несколько:

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

История вторая: растущая очередь задач

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

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

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

Вывод из обеих историй одинаковый — команды слишком сильно зависят от тестировщика:

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

Давайте увеличим штат тестировщиков?

Самая очевидная мысль — увеличить штат тестировщиков. Это будет работать, но только до определённого момента: количество задач будет постоянно расти, а бесконечно увеличивать количество тестировщиков невозможно — в какой-то момент это станет дорого и неэффективно. На тему проблем “ресурсного мышления” (не можете решить проблему? Наймите ещё одного сотрудника) хорошо написал Фёдор Овчинников, CEO Dodo Pizza.

Гораздо эффективнее сохранить скорость и качество разработки в рамках текущих ресурсов. Поэтому мы решили запустить эксперимент, который поможет командам создавать функционал сразу с учётом всех рисков и пограничных ситуаций. Назвали его Transform tester to QA, потому что он про трансформацию одной из ролей в команде: от monkey-тестировщика, выявляющего ошибки за разработчиком, к QA-инженеру, осознанно обеспечивающему качество на всех этапах процесса разработки.

Давайте улучшим процессы в разработке

Цели эксперимента:

  • Снять зависимость команды от тестировщиков, но без потери качества и сроков.
  • Повысить уровень обеспечения качества QA-инженерами в командах.

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

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

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

  1. Презентация постановки.
  2. Техническое решение и тестовый сценарий.
  3. Разработка и проверка.
  4. Релиз.

Постановка задачи

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

Техническое решение

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

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

Вот пример некоторых блоков из технического решения:

Описание задачи

Добавляются ли в систему новые сущности или подходы?

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

Меняется ли взаимодействие серверов в рамках кластера? Добавляются ли новые кластерные роли?

Меняется ли модель данных?

Для сервера речь идет об объектах и моделях.

Если модель данных сложная, можно представить её в виде UML-диаграммы, либо в виде текстового описания.

Изменяется ли взаимодействие между клиентом и сервером?

Описание изменений. Если это API, то можно ли его будет отдать внешним пользователям? Не забыть про обработку ошибок — т.е. указать правильные reason.

Тестовый сценарий

Параллельно с этим разработчик или QA составляют тестовый сценарий, в котором учитываются все возможные места возникновения проблем. Если это делает разработчик, он обязательно отдаёт сценарий на проверку QA, который проверяет его на полноту и достаточность. Если сценарий составляет QA — разработчик должен подтвердить, что понимает, как можно выполнить каждый из его пунктов. Команда также оценивает сценарий на корректность.

Для составления и хранения сценариев мы используем HipTest.

Разработка и проверка

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

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

Релиз готового функционала

Это финальный этап. Здесь от команды могут потребоваться пред\пост-релизные действия, например, включение нового функционала для бета-пользователей.

Документация и инструменты

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

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

Результаты эксперимента

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

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

При этом среднее время работы над задачами уменьшилось всего на 2%: до старта эксперимента оно составляло 12 часов 40 минут, после — 12 часов 25 минут. Значит мы смогли сохранить текущую скорость работы над задачами.

В итоге, в нашей команде теперь нет жёсткой зависимости от QA. Если я заболею или уйду в отпуск — команда продолжит работу без потери в скорости и качестве.

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

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

О чём стоит помнить перед началом эксперимента

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

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

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

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

Взаимодействие тестировщика с командой: что нужно знать?

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

3 признака эффективной коммуникации:

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

Это идеальный вариант. Но в реальной жизни тестировщики могут сталкиваться с ситуацией, когда:

  • Не всегда ясно, где найти тестовые данные;
  • Один и тот же вопрос повторно задается разными людьми;
  • Многократно создается описание одного и того же дефекта.

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

Общение с разработчиками

Поддерживайте личное общение

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

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

Пишите понятно

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

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

При описании дефекта можно пользоваться принципом «Что? Где? Когда?». Например:

  • Что: аварийное завершение работы приложения.
  • Где: на странице с полем выбора кода мобильного оператора.
  • Когда: при выборе следующих стран: Молдова, Перу, Австралия.

Указывайте фактический и ожидаемый результат.

  • Фактический результат: Приложение аварийно завершает работу.
  • Ожидаемый результат: Страна выбрана.

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

Критикуйте конструктивно или совсем не критикуйте

Есть мнение, что разработчики «недолюбливают» тестировщиков, мстят им за каждый обнаруженный баг или, наоборот, жалуются на злорадствующих QA-инженеров, которые считают своим личным достижением лишний раз указать разработчику на ошибку в коде.

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

Коммуникация внутри команды

Узнайте лучше своих коллег

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

Обсуждайте свои открытия и новости в коллективе

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

Делитесь тестовыми данными

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

Последняя по счету, но не по важности рекомендация:

Говорите на одном языке

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

Обучение на курсах — ваш первый опыт работы с командой!

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

Кстати, статистика QA Academy говорит, что те группы, которые продолжают общаться после окончания курсов, делятся в skype-чате опытом прохождения собеседований, находят работу быстрее тех, кто такое общение прекращает.

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

Лучшие системы управления тестированием 2019

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



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

Мы проанализировали проверенные временем и новые системы управления тестированием, которые сейчас популярны на рынке. Выбрали функции, которые должны быть в идеальной Test Management System, сравнили возможности продуктов и изучили отзывы пользователей.

Как итог, перед вами список инструментов, один из которых точно подойдёт вашей команде.

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

Что мы хотим от системы управления тестированием?

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

  • Удобная установка и поддержка.
  • Создание и управление проектами.
  • Создание пользователей и ролей пользователей.
  • Удобная интеграция с автоматическими тестами.
  • Создание тест-плана.
  • Создание тест-кейса.
  • Прогон тест-кейса.
  • Понятная система отчётности.
  • Встроенная система баг-трекинга.
  • Возможность интеграции с другими инструментами.

Зачем она нужна?

Решить задачу создания единой системы для работы со всей документацией проекта можно несколькими способами:

  • Самый дешёвый способ — не заморачиваться и выбрать Google Docs для матрицы трассируемости, а дефекты вести в open-source баг-трекере.
  • Другой способ — использовать одну из популярных TMS’ок, интегрированную с баг-трекером компании.
  • Next-level способ — выбрать Test Management System, исходя из специфики проектов, объемов задач, типов документации и используемых видов тестирования.

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

Популярные системы управления тестированием

  • Test Link
  • Test IT
  • Zephyr
  • qTest
  • PractiTest
  • TestLodge
  • TestRail
  • Qase
  • Tematoo
  • Test Collab
  • HP ALM
  • Testuff
  • XQual

Давайте рассмотрим выбранные инструменты более пристально.

1. TestLink

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

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

Код проекта часто обновляется и дополняется.

Возможности:

  • Управление требованиями
  • Спецификация — определение тест кейсов путём группировки в разные наборы тестов
  • Назначение выполнения тест сьютов на уровне сборки
  • Централизованное управление пользователями и ролями
  • Кастомизация настраиваемых пользователем полей

Ссылка на код (GitHub)
Ссылка на скачивание

2. Test IT

Test IT — TMS, которую создают тестировщики для тестировщиков. Этот инструмент отличает продуманный и понятный интерфейс. Внутри системы можно создавать проекты и вести для каждого структурированную библиотеку тестовых случаев и чек-листов, часто повторяющиеся операции выделяются в общие шаги. Инструмент гибкий — в каждом проекте создаются дополнительные пользовательские атрибуты, распределяются роли и права, что упрощает настройку TMS под процессы вашей компании. Test IT помогает руководителям групп тестирования равномерно распределять нагрузку между тестировщиками и контролировать исполнение работ с помощью пользовательских запросов и отчётов.

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

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

Возможности:

  • Управление тест-планами, тест-кейсами и чек-листами
  • Общие шаги для повторяющихся действий
  • Автоматическое распределение тестов на QA инженеров
  • Интеграция автоматических тестов с помощью API
  • Аналитика как по автоматическим, так и по ручным тестам
  • Ролевая модель и персонализация
  • Геймификация
  • Двусторонняя интеграция с JIRA
  • Импорт из других систем управления тестированием

Бесплатная пробная версия: Открытая демо-версия на сайте
Ссылка на скачивание

3. Zephyr

Zephyr — это плагин для всем известной JIRA, который интегрирует тестирование в проектный цикл, позволяя вам отслеживать качество программного обеспечения и принимать решения в стиле go / no-go. Тест кейсы могут создаваться, выполняться и трекаться так же, как и любые другие задачи в JIRA. Для более оптимальной фиксации процесса тестирования есть интеграция с инструментами управления качеством, автоматизации, непрерывной интеграции и аналитики.

Кроме того, у продукта быстро отвечающая тех поддержка.

Возможности:

  • Ссылка на user stories, задачи, требования, дефекты
  • Конфигурации деплоя: в облаке, на сервере, в дата-центре
  • Расширенная информация на дашбордах аналитики и DevOps
  • Интеграция с JIRA, Confluence, Selenium, Jenkins и Bamboo

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

4. qTest

Инструмент полезный не только тестировщикам, но и всей команде. Интерфейс qTest нативно понятен, мануалы просты в освоении. Это позволяет быстро и эффективно создавать, организовывать и управлять тест кейсами.

Разработчики нескромно заявляют, что их инструмент управления тестами №1

Согласно анализу рынка, qTest является одним из самых быстрорастущих решений для управления тестированием среди команд Agile Development.

Возможности:

  • Планирование тестов
  • Создание и управление требованиями
  • Интуитивный drag-n-drop интерфейс
  • Комплексная матрица трассируемости
  • Наглядные отчёты с подробными графиками
  • Интеграция со сторонними инструментами баг-трекинга
  • Детальный контроль доступа пользователей
  • Облачный инструмент интеграции с JIRA

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

5. PractiTest

PractiTest — это комплексное средство управления тестами. Оно обеспечивает полную наглядность процесса тестирования и более глубокое понимание результатов тестирования. Этот инструмент поможет организовать тест сьюты в соответствии с вашими циклами и спринтами. Тестовые наборы можно формировать по различным критериям, таким как компоненты, версии или типы. Тул заточен на Agile тестирование, регрессионное тестирование, тестирование микросервисов и DevOps.

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

Возможности:

  • Лёгкое добавление тестов новых фич в регрессионное тестирование
  • Группировка тестов на основе микросервисов, которые они охватывают, даже кросс-сервисные
  • Различное отображение информации для разных групп пользователей
  • Дашборды в реальном времени показывают состояние тестов, прогонов на этапах разработки и при деплое на продакшн
  • Интеграция с JIRA, Redmine, Jenkins, GitLab и Slack

Бесплатная пробная версия: 14 дней
Ссылка на скачивание

6. TestLodge

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

Возможности:

  • Базовый набор создания, редактирования тест плана и тест сьютов
  • Нативный интерфейс
  • Интеграция с JIRA, Redmine, Trello, Asana, GitHub и YouTrack

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

7. TestRail

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

Возможности:

  • Отслеживание состояния и результатов отдельного теста
  • Сравнение результатов нескольких тестов, конфигураций и этапов
  • Отслеживание рабочей нагрузки команды для корректировки задач и ресурсов
  • Развёрнутые отчёты и метрики
  • Широкие возможности настройки, облачные или локальные варианты установки
  • Интеграция с JIRA, Redmine, YouTrack, GitHub, Jenkins, Selenium и Visual Studio
  • Удобный REST API

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

8. Qase

Qase это недавно появившийся продукт, который можно нормально использовать в работе. Облачная TMS, которая поможет вашей команде повысить производительность и организовать удобный флоу тестирования программного обеспечения.

Возможности:

  • Тестовый репозиторий: выстраивание тестов в логические группы
  • Составление шагов для кейсов, установка приоритета и серьёзности
  • Запуск тестовых прогоны с трекингом времени по каждому тест кейсу
  • Хранение документации по проекту
  • Автоматическое заведение дефектов в интегрированные трекеры
  • Интеграция с JIRA, Redmine, YouTrack и Slack
  • Объединение результатов автотестов с REST API

Бесплатно для небольших компаний
Ссылка на скачивание

9. Tematoo

Эта облачная TMS от TestLink не так разрекламирована, но не уступает по своей функциональности более дорогим аналогам. Инструмент предоставляет лаконичную инфраструктуру, позволяя быстро приступить к тестированию продукта. А бесплатный план поддержки небольших команд позволяет проводить пилотные реализации проекта бесплатно. Tematoo может быть интегрирован со многими баг-трекерами, даже облачными.

Возможности:

  • Формирование тест сьютов по билдам и типам
  • Описание тест кейса по шагам, с возможностью прикрепить скриншот
  • Статус отдельных тестов, наборов и общий статус сборки
  • Аналитические отчёты и общий метрики по тест плану
  • Для платного плана: свой баг-трекер

Бесплатно: для команды из 1-5 человек
Ссылка на скачивание

10. Test Collab

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

Test Collab можно настроить в облаке или в вашей инфраструктуре, тут всё достаточно гибко.

Возможности:

  • Группировка тест кейсов по этапам или билдам
  • Управление требованиями
  • Переиспользование тестов
  • Настройка спринтов
  • Отчёты по результатам тестов
  • Комментирование тест кейсов
  • Интеграция с JIRA, Redmine, Bugzilla, Asana, Trello, YouTrack, GitHub

Бесплатно: 200 тест кейсов, 400 выполненных прогонов
Бесплатная пробная версия: 14 дней
Ссылка на скачивание

11. HP ALM

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

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

Возможности:

  • Общий доступ к библиотекам требований и ресурсов
  • Подробные сведения о коде, тестировании, управлении рисками и их оценке, а также о соответствии требованиям
  • Быстрый доступ к показателям, например к данным о неустранённых дефектах
  • Быстрая настройка лабораторной среды для устранения ошибок конфигурации в средах Agile
  • Создание требований и отслеживание их выполнения на всех этапах жизненного цикла приложения
  • Аналитика на любой вкус и цвет: гибко настраиваемые отчёты
  • Интеграция с 50+ инструментами

Бесплатная пробная версия: 60 дней
Ссылка на скачивание

12. Testuff

Testuff — это мощная веб-платформа управления тестированием, которая позволяет легко проектировать, выполнять и управлять неограниченным количеством тестов. Тул можно настроить под любой формат тестирования: от популярной гибкой методологии и TDD, до White-Box или Black-Box; Top-Down или Bottom-Up.

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

Возможности:

  • Два доступных клиента — Web и Desktop
  • Планирование цикла тестирования с использованием нескольких тестовых окружений
  • Разграничение по ролям пользователей
  • Встроенный захват экрана в виде скриншота или видео
  • Подключение результатов автоматизированных тестов по API
  • Интеграция с JIRA, Trello, Redmine, Bugzilla, YouTrack, Selenium, GitHub, Visual Studio

Бесплатная пробная версия: 30 дней
Ссылка на скачивание

13. XQual

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

Возможности:

  • Расширенная настройка шагов тест кейса
  • Переиспользование тестов
  • Матрица трассируемости
  • Настройка тестовой лаборатории: hardware, software, тестовое окружение
  • Продвинутое логирование действий (даже удалённых тестов)
  • Настраиваемая аналитика
  • Встроенный захват экрана
  • Интеграция с JIRA, Redmine, MySQL, Oracle, Apache, Skype
  • Интеграция с 5 различными интерфейсами для ручного тестирования
  • Интеграция с почти 70 тулами автоматизации: Selenium, QTP / UFT, JMeter, Ranorex, TestComplete, JUnit, NUnit, TestPartner, Sahi, NeoLoad, QF-Test, RobotFramework, Sikuli, SoapUi, Squish, TestNg, TestOptimal и многие другие

Бесплатно: для команды из 4-10 человек, 200 тестов
Ссылка на скачивание

Понравился пост? Не забудьте поделиться им!

И помните, мы стоим между багами и клиентом! 🙂

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

7 этапов эволюции тестирования в компании / Хабр

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

Статья изначально писалась для журнала CIS, но думаю будет интересна и пользователям Хабра.

Итак, стадии.

  1. Нет тестировщика. Его функции выполняет сам разработчик или менеджер.
  2. Тестировщики появляются, но тестируют проекты только на стадии завершения.
  3. Тестировщики проверяют все задачи разработчиков на предмет соответствия результата изначальной постановке задачи.
  4. Тестировщики занимаются тест-дизайном.
  5. Внедряется система управления тестированием.
  6. Появляется автоматизация тестирования.
  7. Усложняется иерархия, появляются новые роли в команде тестирования.

Теперь о каждой стадии подробнее.

Стадия 1. Тестирование выполняет разработчик и\или менеджер

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

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

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

Стадия 2. Тестировщик проверяет проект в самом конце

Проверить весь проект на предрелизной стадии — классический метод при работе по модели Waterfall. Проект разделяется на глобальные этапы (иногда весь проект это один этап). На каждом этапе сначала делается софт, а уже потом тестируется. Тестирование уже есть, и это хорошо. Но проблемы тоже есть, и совершенно конкретные.

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

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

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

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

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

Стадия 3. Все задачи проверяются на соответствие результата изначальной задаче

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

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

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

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

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

Стадия 4. Тестировщики занимаются тест-дизайном

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

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

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

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

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

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

Стадия 5. Внедряется система управления тестированием

Далее компания дорастает до необходимости использования специализированных систем для хранения тест-кейсов (чек-листов) и выполнения тестовых прогонов.

Такая система позволяет:

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

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

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

Стадия 6. Автоматизируются регулярные проверки

В процессе длительного развития проектов возникает потребность автоматизировать отдельные проверки. Для этого разработчики и тестировщики пишут автотесты. Разработчики обычно делают unit-тесты, тестировщики — ui-тесты. Начинают с покрытия автотестами позитивных сценариев использования ключевого функционала: авторизации, регистрации, публикации записей и тому подобное.

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

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

Стадия 7. Усложняется иерархия, появляются новые роли

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

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

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

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

Выводы

Мы рассмотрели ключевые стадии эволюции тестирования в компании. Осознанное профессиональное тестирование начинается со стадии тест-дизайна. Тест-дизайн дает устойчивое повышение качества продукта.

Процесс развития тестирования не всегда линейный. Вы можете пропускать, объединять, смешивать определенные этапы или сразу выходить на более высокий уровень. Например, у нас в Qualitica есть система управления тестирования, то есть мы на стадии 5. Сейчас практически одновременно у нас появляются узкие специалисты (новые роли, стадия 7) и автоматизация (стадия 6).

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

Т-тестировщики и их роль в команде

Автор: Роб Ламберт

Ссылка на оригинал статьи: http://thesocialtester.co.uk/t-shaped-testers-and-their-role-in-a-team/

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

Мне никогда не нравился подход, при котором тестировщики отделены от основной команды и подключаются к работе на соответствующие «фазы» тестирования. Я проработал так около восьми лет, и все это время бился над ответами на следующие вопросы:

  • Почему мы так поздно подключились к проекту?
  • Почему в нем так много очевиднейших багов и проблем?
  • Почему продукт не соответствует спецификации?
  • Почему из раза в раз мы гоняем одни и те же кейсы и на этом основании считаем, что продукт готов и тестирование завершено?
  • Почему бы тестировщикам не начать задавать вопросы на более ранних стадиях разработки продукта?
  • Почему такие навыки тестировщика, как тест-дизайн, организационные способности, критическое мышление совсем не ценятся под конец проекта?
  • Почему некоторые тестировщики высоко специализированы — например, тестировщики производительности — но при этом куча прочих тестировщиков просто «гоняет любые функциональные тест-кейсы»?
  • Почему все ноют, что так работать невозможно, но ничегошеньки не делают, чтобы это изменить?

Я могу долго продолжать, я задавал массу таких вопросов.


 

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

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

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

Я считаю, что поиск багов — это всего лишь одна сторона работы тестировщика.

Я не думаю, что ответственность за поиск багов лежит исключительно на тестировщике.

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

Идея, которую я пытаюсь развить — это идея «Людей-Т». Придумал ее не я. Кажется, Тим Браун (CEO компании IDEO) выступил с ней в 1990 году, описывая новый тип работника.

Представьте себе, что буква Т представляет собой навыки человека (или, как мне нравится говорить, его роль). Вертикальная черта в букве Т — это его основная профессиональная область. Если мы говорим о тестировании, то это ключевой навык тестировщика (какой именно — зависит от контекста, и у него могут быть суб-навыки). Горизонтальная черта буквы Т — это способность человека работать в нескольких областях, применяя навыки, отличные от основной специализации.

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

Многие мои коллеги по профессии — Т-тестировщики. Они отличные специалисты, и к тому же привносят в профессию умения из других областей (или же используют свои навыки, чтобы выполнять другие бизнес-задачи).

В стартапах и быстро развивающихся компаниях способность быть «универсальным солдатом» очень выгодна.

Человек, способный «играть несколько ролей», и делать это хорошо — это, очевидно, хороший актив. Даже в более традиционных, структурированных командах можно найти «людей-Т».

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

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

  • Я знаю крутого менеджера по тестированию, который также руководит службой поддержки.
  • Я знаю отличного тестировщика, который также работает product-owner-ом.
  • Я знаю прекрасного тестировщика, который выполняет роль скрам-мастера.
  • Я знаю крутого тестировщика, который также работает над исследованиями рынка.
  • Я знаю классного тестировщика, который собеседует ВСЕХ новых членов команды.
  • Я знаю замечательного тестировщика, который проводит конференции, занимается рекламой, создает собственный продукт, работает над маркетингом, и дает консультации корпоративным клиентам (представляете, какой спектр навыков ему понадобился, чтобы добиться этого?)

Это всего лишь часть примеров. Перечислять таких людей можно бесконечно долго.

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

К сожалению, многие люди (не только тестировщики) жестко ограничены рамками своей роли, несмотря на то, что могут предложить намного больше.

Если вкратце, несколько лет назад я чуть было не ушел из тестирования — не в последнюю очередь потому, что ответы на вышеперечисленные вопросы так и не были найдены. «Неужели это конец?», — думал я. Как насчет моей квалификации в других областях, моих хобби? Не могу ли я использовать их? На какую работу я могу претендовать с такими навыками? Придется ли мне пройти переобучение? Почему весь спектр моих навыков не ценится в моей работе? И тогда я открыл для себя блогинг, консалтинг, Agile-тренинги, системное мышление, и, в результате — управление человеческими ресурсами, и все встало на свои места… Кхм, я отвлекся от темы.

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

С приходом таких подходов, как Acceptance Test Driven Development, Test Driven Development и многих других появилась нужда в раннем подключении тестировщиков к проекту. К тому же теперь у них не так связаны руки на более поздних стадиях разработки. Любовь к исследованиям, любопытство, новизна — вот что движет тестировщиками. Проверки пройдены — теперь нужно понять, что этот продукт вообще делает, поделиться своими взглядами на возможные риски и неопределенность, поучаствовать в обсуждении пользовательского опыта и маркетинга (заказчиков, конечных пользователей, конкурентов, отрасли в целом), ожиданий от продукта, и много чего еще, что сходу не приходит в голову.

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

Поиск ошибок — наша работа, но это не наша единственная конечная цель. Баги — побочный эффект сбора информации о продукте.

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

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

Мы все еще работаем над балансом ролей и ожиданий, и баланс периодически смещается (как правило, в ответ на колебания рынка).

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

Очевидно, этот подход не ограничен исключительно тестировщиками. Программисты, product-owner-ы, сотрудники службы поддержки, продажники, аккаунт-менеджеры — каждый может стать Т-человеком (как минимум, у каждого есть для этого потенциал).

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

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

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

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

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

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

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

Построение QA-команды с нуля: плюсы и минусы

07 мая 08:38 2019 Вадим Юдович & nbsp

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

Когда дело доходит до привлечения специалистов по тестированию программного обеспечения, начинаешь спрашивать себя: «Как это сделать правильно, когда у меня ничего нет? Как избежать ошибок? » .Чтобы ответить на эти вопросы, мы проконсультировались с нашими QA-специалистами, и они поделились своим опытом сотрудничества с владельцем успешного стартапа.

Что нужно учитывать при построении команды QA: советы экспертов

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

Советы от стартапа . «Определите, когда задача считается выполненной» , — делится Гев, генеральный директор Ucraft.Определите ожидаемый конечный результат проекта. Вы должны знать, какой должна быть выполненная задача. Покажите своей команде, какой цели они должны достичь. Это повысит эффективность каждого действия. Сравните результаты с запланированными потребностями и посмотрите, насколько завершена задача уровня.

Еще один совет от Gev — «назначать подзадачи» каждому конкретному специалисту. Например, разделить обязанности между ручными и автоматическими тестировщиками по каждому тесту.

Еще один — «указать критерии приемки» .Определите для группы тестирования, что ожидается от тестирования, как оно должно проводиться и какой результат будет достигнут. Создайте рамки для тестирования.

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

Команда QA в стартапе должна быть рентабельной . «У новой компании минимальный бюджет и максимум идей и энтузиазма. В общем, у стартапов нет большого капитала. Продажи? Могут быть, но в очень редких случаях. Из-за этого цена является ключевым аспектом для стартапов и их основными ограничениями », — констатирует специалист QATestLab Михаил Гречуха.

Советы менеджерам по маркетингу, как наладить эффективную работу команды QA:

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

Команда QA в стартапе должна быть ориентирована на сценарий использования. «Доставка некачественного программного обеспечения не является основной причиной неудач при запуске. Но потому что они производят продукт, которым никто не пользуется и который никого не интересует », — утверждает менеджер проекта QATestLab .

«Это не означает, что вы должны сосредоточить QA только на том,« какие функции добавить, чтобы доставить удовольствие пользователям »и заставить их покупать ваше программное обеспечение. Также важно тестирование в обычном виде. Всегда нужно держать баланс », — делится Михаил.Он также добавляет по вопросу бюджета: «Вы должны использовать бюджет проекта как свои собственные деньги» .

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

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

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

Шаги по созданию команды QA

Мы проанализировали приведенные выше комментарии наших экспертов и разработали их в виде базовой инструкции по созданию команды QA.

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

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

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

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

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

Препятствия при создании команды QA с нуля

  1. Легче настроить и изменить существующую команду QA, чем создать новую, если у вас уже есть некоторые участники.
  2. Поиск, проверка и собеседование кандидатов занимает много времени, которое можно сэкономить для проекта, работая с уже задействованными специалистами.
  3. Создание новой команды требует установления новых связей и координации между ее членами. Связь между участниками существующей команды более уверенная и стабильная, что ускоряет завершение проекта. Менеджер проекта знает, какой подход применить в уже сформированной команде, в отличие от новой.

Преимущества создания команды QA с нуля

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

Заключительное слово о создании команды QA

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

Узнайте больше из QATestLab

Похожие сообщения:

.

Улучшение навыков управления командой QA

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

Продолжайте учиться
Директор по обеспечению качества KMS Technology Муш Хонда посоветовал руководителям групп постоянно развивать несколько основных областей управления командой. Менеджеры по обеспечению качества должны всегда искать возможности узнавать об изменениях в индустрии тестирования программного обеспечения и применять новые передовые практики. Руководители групп должны быть гибкими в этом отношении, всегда готовы внедрять новые инструменты контроля качества и подходы к тестированию программного обеспечения.Это гарантирует, что их команда будет оставаться на переднем крае процессов контроля качества и использовать наиболее эффективные стратегии.

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

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

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

Связь критична
Хороший руководитель группы должен уметь эффективно делиться отзывами и идеями с тестировщиками программного обеспечения, а также способствовать прямым обсуждениям статуса команды. Инженер по тестированию программного обеспечения Шарат Бхат объяснил в своем посте для Software Testing Help, что менеджеры по обеспечению качества должны чувствовать себя комфортно, разговаривая с членами команды в неформальной обстановке, поощряя их говорить о сохраняющихся проблемах с командой или о любых других проблемах, которые потенциально могут повлиять на производительность и эффективность .Хотя многие организации участвуют в регулярных групповых встречах, таких как ежедневные схватки или стендапы, важно, чтобы у тестировщиков программного обеспечения была возможность обсудить вопросы конфиденциально, вдали от такой среды. Как заметил Бхат, эта информация может оказаться неоценимой, если есть особая проблема с командой, которая скрывается под поверхностью.

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

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

Статьи по теме:

.

Почему обеспечение качества (QA) важно для любой группы доставки

Сегодня, когда сфера разработки вышла за рамки традиционного программного обеспечения, большинство ИТ-специалистов осознают ценность, которую может принести команда обеспечения качества (QA). Всего несколько лет назад этого не было, так как гораздо меньше компаний занимались проверкой качества. Разработчики нередко спрашивали: «Зачем нам нужна команда QA?» Тем не менее, сегодня такие взгляды встречаются реже. Практика обеспечения качества все еще сильно недооценена во многих организациях.

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

Важность команды QA

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

  1. Команды QA помогают наиболее полно удовлетворить потребности и ожидания клиентов
  2. Они укрепляют доверие клиентов и в конечном итоге побеждают конкурентов, производя более качественный продукт.
  3. Они сокращают расходы за счет обнаружения и исправления проблем и недостатков на ранних этапах разработки.
  4. Они помогают установить и поддерживать высокие стандарты качества и сместить акцент с выявления проблем на их предотвращение.

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

Создание команды QA

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

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

Менеджеры должны работать над раскрытием талантов каждого и учитывать уникальный набор навыков при распределении ролей в команде QA.

Управление командой QA

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

  • Убедитесь, что требования для каждого тестового примера четко определены и понятны членам команды для повышения производительности
  • Установите правила и процессы, которым должны следовать все (вы можете вовлечь в их создание всех членов команды)
  • Регулярно отслеживайте прогресс по всем проектам
  • Поощрение постоянного обучения, совершенствования и поддержки инициатив
  • Обеспечить каждого члена команды инструментами, необходимыми для наиболее эффективной работы
  • Создавайте дружескую атмосферу в коллективе

Сказанное может успешно применяться как к командам, собранным «под одной крышей», так и к удаленным.

Аналитики

QA обычно слышат такие вопросы, как «Есть ли у Google команда QA?» или «Есть ли у Facebook команда QA?» Ответ положительный! Так и должно быть вам. За каждым успешным и высококачественным продуктом стоит команда профессионалов, которые работают над поддержанием и улучшением его стандартов качества и служат своего рода защитой от ошибок и дефектов, чтобы они не попали к пользователям. Инженеры по обеспечению качества помогают разработчикам работать над улучшением программного обеспечения, находя и исправляя всевозможные недостатки.

.

Как создать успешную команду QA — Характеристики отличной группы тестирования программного обеспечения

Что мы подразумеваем под отличной командой тестирования программного обеспечения?

«Команда со звездным игроком — хорошая команда, но команда без такового — отличная команда». — Автор неизвестен.

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

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

Почему одни группы тестирования программного обеспечения терпят неудачу, а другие добиваются успеха?

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

Успех также зависит от лидерских качеств, которыми обладает Test Lead — «Капитан корабля».

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

Успех команды в долгосрочной перспективе не зависит от человека, которого считают «ЗВЕЗДОЙ», а зависит от всех, кто формирует звездные скопления, составляющие отличную команду.

Характеристики отличной группы тестирования программного обеспечения

Начальный этап: Задайте себе следующий вопрос:

Знает ли новый член команды причину, по которой он был выбран в команду?

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

Помогите людям понять проект в более широком контексте, прояснив определение ролей и обязанностей

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

Владение

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

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

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

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

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

Сотрудничество и твердое чувство взаимозависимости в команде ослабят обвинение в поведении и стимулируют возможности для обучения и совершенствования.

Знание опытных игроков в команде

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

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

Мотивация — ключевой фактор

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

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

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

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

Признание

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

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

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

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

Базовая встреча один на один

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

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

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

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

«Не говорите людям, как что-то делать, говорите им, что делать, и позвольте им удивить вас своими результатами.”- Джордж Паттон

Заключение

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

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

«Объединение — это начало, Сохранение вместе — это прогресс, Совместная работа — это успех». — Генри Форд

К тебе!

Что вы думаете из своего опыта? Каковы ваши характеристики для создания успешной команды QA?

Об авторе: Шарат Р. Бхат (Sharath R. Bhat) — инженер по тестированию программного обеспечения в Torry Harris Business Solutions, Бангалор, и имеет более чем трехлетний опыт работы в области тестирования программного обеспечения. Сертифицированный инженер по тестированию ISEB / ISTQB, работал в сферах телекоммуникаций, финансов и здравоохранения.Сферы технической экспертизы включают тестирование веб-приложений, клиент-серверных приложений, хранилищ данных и промежуточного программного обеспечения, созданных с использованием «Kabira».

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

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *