Привет, мой первый пост я посвящаю основам по Тестированию на самом верхнем уровне абстракции. Буду писать прямо, как есть, как вижу это я, Кирилл, человек который прошел путь от ручного тестировщика до руководителя целого отдела по тестированию. Путь, как я его называю from Zero to Sub-zero [0]: Используйте подобные сноски в конце для определений 📘 📖
QA vs QC
Я часто слышу вопрос о разнице в позициях Инженера по обеспечению качества (Quality Assurance или QA) и Тестировщиком (Quality Control или QC) даже от людей кто занимается профессиональной разработкой. Что же говорить о других? А им все равно, и это их право.
Людям просто нужны качественные продукты! Менеджеры хотят качественное программное обеспечение (ПО) без багов [1], пользователи хотят качественные приложения, и так далее, а это достигается средствами тестирования [2] не смотря ни на что другое. Но что все это значит? Что есть качество? Все дело в удовлетворенности, вот и все! Мера качества - это счастье конечного пользователя. Однако как достигнуть такого рода абстракции становится настоящим испытанием для всей команды разработки [3].
Качество и риски
Когда идет разработка любого продукта, особенно софта, без тестирования, мы сталкиваемся с рисками [4] и как правило это связанно с потерей денежных средств [5]. Так, компании которые хотят быстро снизить подобные риски просто нанимают Тестировщиков (QC) в надежде контролировать некие метрики вроде количества багов заведенных за релиз, забывая о процессах порождающих эти баги. А ведь это антипатерн.
Agile testing
Описанные проблемы не новы. В нашем распоряжении есть некий успешный опыт к решению подобных задач, назовем их Лучшими практиками (Best practice) [6]. Применительно к разработке и тестированию ПО это гибкие подходы (Agile). Любая из гибких методологий ставит качество на первое место, а точнее встраивает его в продукт. Вспомним знаменитое высказывание Деминга: "Встраивайте качество в продукт вместо того, чтобы пытаться тестировать его позже" [7].
Итак, если мы заботимся в первую очередь о процессе, мы не будем отделять тестировщика и тестирование от разработки. В такой момент говорят о "полнокомандном" подходе и распределении ответственности. Говорят о ролях и в нашем контексте про инженеров кого волнует фокус на тест-дизайне [8] - Quality Assurance Engineers.
Дорога к QA Lead
Как только вы начинаете свой путь как тестировщик, то узнаете о видах тестирования [9] и тестовой документации вроде тест-плана. Далее вы сможете работать с тест-кейзами [10] основанными на техниках тест-дизайна [11]. В какой то момент начнете использовать язык программирования и автоматизировать регрессионный тестовый набор. Вы изучите гибкие процессы, менеджмент ресурсов и к тому времени будете понимать разницу между нахождением и превентированием багов, что сделает из вас руководителя отдела тестирования.
Пролог
Если вам непонятны какие-то термины или вы сомневаетесь в правильном толковании, задайте мне любой вопрос. Подписывайтесь на мой Дзен-канал, чтобы не пропустить продолжение!
[0] Sub-zero - вымышленный игровой персонаж из серии компьютерных игр Mortal Kombat
[1] Баг - несоответствие между фактическим и ожидаемым поведением
[2] Тестирование - исследование продукта путем верификации и валидации на основе требований с целью выявить баги https://smartbear.com/blog/test-and-monitor/verification-and-validation-the-difference/
[3] Команда - дизайнеры, программисты, тестировщики, то есть все люди кто разрабатывает приложения. Также тут интересная игра слов говоря о Настоящем испытании в переводе звучит как True test.
[4] Риск - (a) вероятность того, что случится что-то плохое (by Cambridge dictionary); (b) действие в надежде на счастливый исход (by google dictionary)
[5] (a) 125 миллионные потери в результате краха Марсохода из-за простой математической ошибки http://articles.latimes.com/1999/oct/01/news/mn-17288 (b) Множественные человеческие ошибки приведшие к падению Boeing 737 Max https://www.theverge.com/2019/5/2/18518176/boeing-737-max-crash-problems-human-error-mcas-faa
[6] В данном случае речь о Тестовой пирамиде в качестве Лучшей практики - фреймворке для дизайна тестовых наборов который оптимизирует баланс между скоростью выполнения тестов и уверенностью что приложение работает как предполагалось. https://www.codecademy.com/articles/tdd-testing-pyramid
[7] Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд. 2010 Вильямс. Цитата. Предисловие. Edwards Deming.
[8] Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы) в соответствии с определёнными ранее критериями качества и целями тестирования.
[9] Тестирование Дот Ком. 2007, Роман Савин. Классификация видов тестирования
[10] Тест-кейз - Шаги воспроизведения с одним или несколькими ожидаемыми результатами основанными на требованиях к приложению. Формально: Тестовый сценарий (Test case) используется для определения разных условий и/или входных данных в отношении требований к ожидаемым результатам.
[11] О техниках тест-дизайна я рассказываю на моем Udemy курсе
