И почему работа QA — инженерная, а не кликающая вручную в браузере.
Существует множество дискуссий о ежедневной разработке программного обеспечения, которые мы проводим в наших командах, компаниях или в Интернете. Иногда мы обсуждаем, что будет сделано для конкретной функции, а иногда когда назначить встречу с клиентом для уточнения.
Иногда соглашение является естественным результатом. Мы просто держим друг друга в курсе. Но человек, иногда это может быть война. Например, когда мы говорим о Git-стратегии, мы следим за тем, чтобы в комнате не было ножей или любого другого потенциального оружия.
Стратегия обеспечения качества — еще одна тема, за которую мы благодарны тому, что наша работа стала более удаленной, чем раньше. Теперь мы можем высказывать свое мнение, не рискуя судьбой Робеспьера.
В большинстве случаев есть договоренность о том, что нам нужно: уникальные тестовые данные, инструмент для мокинга, продакшн-бэкапы и автоматизация с пайплайнами. Все хорошо, пока мы не вернемся к основному вопросу.
Но как насчет стратегии обеспечения качества, которую так трудно обсуждать? Ну, следите за обновлениями.
Some more technical articles: 1. Generics in Go: Viva la Revolution! 2. Practical SOLID in Golang: Single Responsability Principle 3. Practical SOLID in Golang: Open/Closed Principle 4. Practical DDD in Golang: Value Object 5. Practical DDD in Golang: Entity 6. Practical DDD in Golang: Aggregate 7. Practical DDD in Golang: Repository 8. ...
Самое простое правило из всех
Проверка вручную не является исключительной обязанностью инженера по обеспечению качества. Тестирование вручную не является исключительной обязанностью инженера по контролю качества.
Ох, это было легко написать. Никто не пострадал? Хорошо. Так что я могу продолжать. Что означают эти два предложения? (Конечно, если есть еще кто-то, кто их не понимает.)
Итак, другими словами:
Ручное тестирование должно выполняться в равной степени всеми членами команды, в которую входят разработчики программного обеспечения с любым опытом: Frontend, Backend и DevOps.
Ручное тестирование, наверное, самая скучная работа во Вселенной (а если вселенных несколько, я их включаю). Если вы со мной не согласны, что ж, мой блог, мои правила.
Исторически сложилось так, что многие компании в прошлом рассматривали позицию QA как место, где кто-то может вручную смоделировать то, что реальные пользователи будут делать с нашим программным обеспечением. Некоторые компании до сих пор так думают.
Некоторые инструменты автоматизации тестирования уже были на рынке в начале 90-х, но настоящий прорыв произошел с фреймворками автоматизации тестирования в 2000-х. Сегодня трудно представить разработку программного обеспечения без автоматизации тестирования. По крайней мере, для меня это беспроигрышный вариант.
Тем не менее, даже с автоматизацией тестирования, я имею в виду не только модульные тесты, но и всю Тестовую пирамиду, многие компании рассматривают ее как подработку QA-инженеров. Мы просто забываем эту часть Инженера.
И при этом мы теряем многие преимущества качества нашего программного обеспечения. Позвольте мне назвать некоторые из них.
Что мы получаем от этого?
Распределив обязанности по ручному тестированию на всех членов команды, мы можем сначала увидеть падение производительности.
На первый взгляд кажется, что мы даем какую-то однообразную и бессмысленную работу высокооплачиваемому классу работников, что для них это может быть пустой тратой времени. Ведь скучно это делать, не так ли?
Но это только вершина. И вот почему.
Никто лучше нас не разбирается в нашем программном обеспечении
На планете нет никого, кто разбирается в программном обеспечении лучше, чем его разработчик. Это делает любого разработчика идеальным кандидатом на то, чтобы найти лазейку в своем коде.
Когда мы тестируем программное обеспечение, которое мы разработали в последние месяцы, мы понимаем, как оно работает за кулисами. Можно подумать о неудавшемся деле.
Мы можем выполнять тесты, которые не только входят в критерии приемки, но и все те, которые связаны с новой функцией, которая, как мы подозреваем, может быть затронута. И вот здесь эта потеря времени смягчается преимуществом совместной ответственности за ручное тестирование.
Разделенная ответственность за ручное тестирование приводит к тому, что мы раньше обнаруживаем ошибки, которые обязательно появятся позже, вероятно, в продакшене, где их срочность заставляет нас быстро менять контекст нашей работы.
Самое эффективное тестирование — это автоматизация тестирования.
Единственный способ добиться долгосрочной стабильности кода — это автоматизация тестирования, которая включает множество функциональных тестов, тестов компонентов, тестов пользовательского интерфейса и так далее.
Если мы возложим все ручное тестирование на плечи инженеров по контролю качества, кто должен нести ответственность за написание всех этих тестов?
Во многих случаях определенные автоматизированные тесты относятся к технологии, которую мы выбираем как разработчики программного обеспечения (например, модульные тесты или контрактные тесты). Но иногда нам нужно предоставить другие типы тестов, которые относятся к технологиям и платформам, о которых мы не знаем.
И именно поэтому ответственность QA-инженера заключается в написании таких автоматизированных тестов. Эти автоматические тесты будут выполняться каждый следующий раз в наших пайплайнах и гарантируют, что программное обеспечение поддерживает определенный уровень стабильности и ничего не ломается после доставки новой функции.
Здесь мы снова уменьшаем потенциальную трату времени. С каждым новым автоматическим тестом наше ручное тестирование приложения сводится к чистой проверке работоспособности в промежуточных или предварительных средах во время регулярных выпусков.
Вся команда получает право собственности
Когда QA распределяется по всей команде, это неизбежно повышает осведомленность всех членов команды об их важности в создании и доставке стабильного приложения.
И наоборот, когда один вид работы привязан к одному человеку, а в большинстве команд есть не более одного QA-инженера, мы неосознанно попадаем в ловушку перекладывания всей ответственности на этого человека.
Это не редкий случай. К сожалению, мне приходилось видеть невнимательность разработчиков программного обеспечения к конечному результату качества кода. Не то чтобы им было все равно (ну, может быть, некоторым из них было все равно), но подстраховка заставляла их чувствовать себя исключительно ответственными за написание кода любого качества и ничего больше.
Но с таким подходом мы снова даем понять нашим разработчикам программного обеспечения, что они являются последней линией обороны. Если что-то не освещается должным образом, вся команда берет на себя ответственность за решение проблемы. И вся команда должна обсудить, как избежать подобных инцидентов в будущем.
Вся команда лучше знакомится с приложением
Когда мы тестируем функцию и при этом обязательно тестируем функции, разработанные другими, мы также получаем представление о разрабатываемой новой функции, чтобы мы могли в дальнейшем создавать образ проекта.
Неизбежно, что мы не можем участвовать в разработке всех функций нашего проекта. Принуждение всех к тестированию функций, разработанных другими, дает большему количеству людей возможность узнать о новых функциях и связать их с другими, созданными ими в прошлом.
Ключевым моментом здесь является понимание того, что единственное правило для этого состоит в том, что каждый тестирует только те функции, которые он не создал. Это могут быть функции, о которых они знают и которые они запланировали (это было бы идеально), но физически не участвуют в кодировании, чтобы избежать предвзятости тестирования.
Кроме того, это делает команду сильнее, когда кто-то уходит в отпуск, особенно если это QA-инженер. Я видел во многих ситуациях, когда люди бегали, как безголовые цыплята, когда они прыгали на сеансы ручного тестирования, потому что их QA-инженер уехал в отпуск.
Заключение
Наличие большего количества людей, ответственных за ручное тестирование, не отнимает время у наших самых высокооплачиваемых сотрудников, но обеспечивает большую стабильность кода, автоматизацию тестирования, владение знаниями и обмен ими.
Поэтому мне особо нечего вам сказать на эту тему, но пожалуй:
GIVEN I am a DEV member of the team (FE, BE or QA) WHEN I finish with my current ticket on the board AND I can see on the board some tickets in ready for testing status THEN I take the first ticket in ready for testing status to execute manual testing. GIVEN I am a DEV member of the team (FE, BE or QA) WHEN I finish with my current ticket on the board AND I can not see on the board some tickets in ready for testing status THEN I take the first ticket from to do belonging to technology of my choice.
