Котаны - я теперь так буду обращаться к своим воображаемым читателям - тут такое дело, гайда по тестированию безопасности пока буксует из-за моих сбоев целеполагания, но я нашла отличную статью и собираюсь ее вам вкратце пересказать. Кто хорош в английском, то вот вам она. А кто не очень - то вэлкам, буду рассказывать.
Короче, название у статьи малость провокационное: "Тестеры - нам пора убраться из обеспечения качества". Что за фигня?! - подумают тестеры. Но давайте по порядку.
Осенью 2008 попал автор статьи на конференцию и, в том числе, на лекции "Testing lies" (я не могу подобрать адекватный перевод вне контекста). И краем уха услышал короткий диалог одного из докладчиков с парой людей:
- Ты в QA?
- Да.
- А ты имеешь доступ к изменения исходного кода программ, которые вы тестите?
- Оу, нет. Вообще-то нет.
- Интересно. Тогда как вы можете обеспечивать качество?
Короче, такая штука. Как мы можем обеспечивать качество, не имея доступа к бюджету (планированию всего цикла разработки), коду, заказчику? Тут автор припоминает, что в 1996 Сэм Каннер говорил о том, что роль именно обеспечения качества в компании лежит на менеджменте и CEO (аналог гендира). Я бы еще добавила продакшн менеджера, но вероятно он входит в понятие просто "менеджмента". И на прошлой моей работе было именно так - хотя начальник часто и во всеуслышание заявлял о том, что мол это тестеры решают выходить на прод или нет, но по сути решал это один человек - PM. Это он знал все риски и мог взвесить что именно обойдется нам дороже - выпуск с багом или простой. Но что же тогда остается тестерам? А вот Quallity Assistance! Мы - ассистенты, помощники в обеспечении качества. Мы, кажется, лучше остальных отделов знаем продукт. Как со стороны пользователя, так и со стороны (но конечно менее полно) разработчиков. Таким образом мы не обеспечиваем качество, но мы помогаем непосредственно тем людям, которые его обеспечивают.
Аналогичным образом Джеймс Бах отмечает, что мы вовсе не гейткиперы качества. Мы отвечаем за качество не больше, чем любой другой отдел. Он вспоминает, что когда только пришел в Apple, то был одержим идеей, что именно он отвечает за качество: "Позже я понял, что такая позиция была ужасно обидна для остальной команды, потому что ее подтекст был таков: "Только я беспокоюсь о качестве, а вы, ребята, нет". Разработчики создают качество, они позволяют ему прийти. Без них не будет ничего и вы получите нулевое качество {нихрена, короче, не получите}. Так что это очень обидно и когда вы говорите, что именно вы обеспечиваете качество, то оскорбляете их до такой степени, что они не хотят с вами работать".
Дальше автор вспоминает еще одну конфу (STAR East Conference в Орландо) и как много раз его спрашивали другие тестеры как они могут заставить {на самом деле слова "заставить в тексте нет, но я не знаю как по-другому передать смысл} программистов применять "лучшие практики"; как они могут влиять на менеджеров, чтобы те делали свою работу лучше; как навязать модель или процесс разработчикам. На одном из докладов тестеры жаловались на качество требований, которые они получают от заказчиков (более того, все они делали ошибку, говоря "требований", в то время, как подразумевали именно "документы с требованиями" {ТЗ, я так понимаю - суть тут в том, что жаловались не на само ТЗ, а требования в нем}. Более того, один парень сказал, что они собираются вообще взять на себя работу по написанию требований. В ответ на их запросы {вопросы/заявления} самый helpful {"полезный" вообще-то, но helpful это настолько полезный, насколько он вообще может быть полезным, всеобъемлюще полезный} совет, который может дать автор, это то, что предприятия с такими проблемами не подходящее место для работы квалифицированных тестировщиков.
Мы не мозги проекта. И мы даже не можем контролировать этот "мозг". Наша роль состоит в том, что бы быть дополнительными сверхчувствительными органами восприятия. Мы - это дополнительные глаза, уши, носы, пальцы и вкусовые рецепторы для программистов и менеджеров. Мы - расширение для их чувств. В идеале мы - как сверхчувствительные и хорошо откаллиброванные инструменты - микроскопы, телескопы, суперчувствительные микрофоны, штангенциркули, масс-спектрометры. Бомбо-обнаружительные детекторы. (И эта идея про инструменты принадлежит Сэму Каннеру). Мы помогаем программистам и менеджерам слышать, видеть и осязать что-то в ограниченное время, потому что из-за особенностей своего мышления, необходимого им для работы, они не могут сами услышать/увидеть/почувствовать это.
Если вы действительно хотите улучшить качество кода - станьте программистом. Я стал - пишет автор. Я уверяю вас, что если вы сделаете то же, то очень быстро поймете насколько сложна, скромна {в том смысле, что хрен ее кто видит - humbling - непритязательный, скромный, уничтожительный} и огромна работа действительно хорошего программиста - потому что, как и все инструменты, компьютер увеличивает вашу некомпетенцию настолько быстро, насколько быстро он увеличивает свою компетенцию (короче, вы тупеете тем быстрее, чем развиваются технологии - за ними трудно угнаться). Хотите управлять проектом - станьте менеджером. Им автор тоже стал и, судя по всему, отличным. Но попробуйте - и очень скоро вы сделаете открытие, что качество - величина, зависящая от многих людей, и что ваши стандарты качества намного менее ценны, чем стандарты качества тех, кто пользуется вашим продуктом и платит за него. Станьте продакшн менеджером и вы практически сразу осознаете, что решение о выпуске продукта невозможно принять, исходя только из технических задач без учета бизнесс-процессов и что такое баланс между стоимостью починки багов и расходами на устранение их возможных последствий.
Так что тому, кто никогда не были ни программистом, ни PM'ом, бесполезняк ныть автору, что он ничего не понимает в качестве. Хуже нытья могут быть только советы от людей, которые никогда не делали подобную работу. И в обоих случаях (когда был и программистом, и PM'ом) автор хотел получать от тестеров лишь информацию. Как программист - о проблемах в коде, как они были найдены, как должно быть и как воспроизвести их чтобы отдебажить и исправить. Как PM автор хотел бы знать какую информацию тестеры собрали о продукте и как они конфигурируют, управляют, получают и оценивают продукт. Я хотел знать как наш продукт работает в условиях, отличных от обычных условий использования; о внутренних противоречиях; как продукт работает в сравнении с другими подобными продуктами с рынка - лучше он или хуже и в чем.
Итак, вы хотите влиять и на качество, и на команду. Хотите знать, как влиять на программистов в положительном ключе?
Короче, название у статьи малость провокационное: "Тестеры - нам пора убраться из обеспечения качества". Что за фигня?! - подумают тестеры. Но давайте по порядку.
Осенью 2008 попал автор статьи на конференцию и, в том числе, на лекции "Testing lies" (я не могу подобрать адекватный перевод вне контекста). И краем уха услышал короткий диалог одного из докладчиков с парой людей:
- Ты в QA?
- Да.
- А ты имеешь доступ к изменения исходного кода программ, которые вы тестите?
- Оу, нет. Вообще-то нет.
- Интересно. Тогда как вы можете обеспечивать качество?
Короче, такая штука. Как мы можем обеспечивать качество, не имея доступа к бюджету (планированию всего цикла разработки), коду, заказчику? Тут автор припоминает, что в 1996 Сэм Каннер говорил о том, что роль именно обеспечения качества в компании лежит на менеджменте и CEO (аналог гендира). Я бы еще добавила продакшн менеджера, но вероятно он входит в понятие просто "менеджмента". И на прошлой моей работе было именно так - хотя начальник часто и во всеуслышание заявлял о том, что мол это тестеры решают выходить на прод или нет, но по сути решал это один человек - PM. Это он знал все риски и мог взвесить что именно обойдется нам дороже - выпуск с багом или простой. Но что же тогда остается тестерам? А вот Quallity Assistance! Мы - ассистенты, помощники в обеспечении качества. Мы, кажется, лучше остальных отделов знаем продукт. Как со стороны пользователя, так и со стороны (но конечно менее полно) разработчиков. Таким образом мы не обеспечиваем качество, но мы помогаем непосредственно тем людям, которые его обеспечивают.
Аналогичным образом Джеймс Бах отмечает, что мы вовсе не гейткиперы качества. Мы отвечаем за качество не больше, чем любой другой отдел. Он вспоминает, что когда только пришел в Apple, то был одержим идеей, что именно он отвечает за качество: "Позже я понял, что такая позиция была ужасно обидна для остальной команды, потому что ее подтекст был таков: "Только я беспокоюсь о качестве, а вы, ребята, нет". Разработчики создают качество, они позволяют ему прийти. Без них не будет ничего и вы получите нулевое качество {нихрена, короче, не получите}. Так что это очень обидно и когда вы говорите, что именно вы обеспечиваете качество, то оскорбляете их до такой степени, что они не хотят с вами работать".
Дальше автор вспоминает еще одну конфу (STAR East Conference в Орландо) и как много раз его спрашивали другие тестеры как они могут заставить {на самом деле слова "заставить в тексте нет, но я не знаю как по-другому передать смысл} программистов применять "лучшие практики"; как они могут влиять на менеджеров, чтобы те делали свою работу лучше; как навязать модель или процесс разработчикам. На одном из докладов тестеры жаловались на качество требований, которые они получают от заказчиков (более того, все они делали ошибку, говоря "требований", в то время, как подразумевали именно "документы с требованиями" {ТЗ, я так понимаю - суть тут в том, что жаловались не на само ТЗ, а требования в нем}. Более того, один парень сказал, что они собираются вообще взять на себя работу по написанию требований. В ответ на их запросы {вопросы/заявления} самый helpful {"полезный" вообще-то, но helpful это настолько полезный, насколько он вообще может быть полезным, всеобъемлюще полезный} совет, который может дать автор, это то, что предприятия с такими проблемами не подходящее место для работы квалифицированных тестировщиков.
Мы не мозги проекта. И мы даже не можем контролировать этот "мозг". Наша роль состоит в том, что бы быть дополнительными сверхчувствительными органами восприятия. Мы - это дополнительные глаза, уши, носы, пальцы и вкусовые рецепторы для программистов и менеджеров. Мы - расширение для их чувств. В идеале мы - как сверхчувствительные и хорошо откаллиброванные инструменты - микроскопы, телескопы, суперчувствительные микрофоны, штангенциркули, масс-спектрометры. Бомбо-обнаружительные детекторы. (И эта идея про инструменты принадлежит Сэму Каннеру). Мы помогаем программистам и менеджерам слышать, видеть и осязать что-то в ограниченное время, потому что из-за особенностей своего мышления, необходимого им для работы, они не могут сами услышать/увидеть/почувствовать это.
Если вы действительно хотите улучшить качество кода - станьте программистом. Я стал - пишет автор. Я уверяю вас, что если вы сделаете то же, то очень быстро поймете насколько сложна, скромна {в том смысле, что хрен ее кто видит - humbling - непритязательный, скромный, уничтожительный} и огромна работа действительно хорошего программиста - потому что, как и все инструменты, компьютер увеличивает вашу некомпетенцию настолько быстро, насколько быстро он увеличивает свою компетенцию (короче, вы тупеете тем быстрее, чем развиваются технологии - за ними трудно угнаться). Хотите управлять проектом - станьте менеджером. Им автор тоже стал и, судя по всему, отличным. Но попробуйте - и очень скоро вы сделаете открытие, что качество - величина, зависящая от многих людей, и что ваши стандарты качества намного менее ценны, чем стандарты качества тех, кто пользуется вашим продуктом и платит за него. Станьте продакшн менеджером и вы практически сразу осознаете, что решение о выпуске продукта невозможно принять, исходя только из технических задач без учета бизнесс-процессов и что такое баланс между стоимостью починки багов и расходами на устранение их возможных последствий.
Так что тому, кто никогда не были ни программистом, ни PM'ом, бесполезняк ныть автору, что он ничего не понимает в качестве. Хуже нытья могут быть только советы от людей, которые никогда не делали подобную работу. И в обоих случаях (когда был и программистом, и PM'ом) автор хотел получать от тестеров лишь информацию. Как программист - о проблемах в коде, как они были найдены, как должно быть и как воспроизвести их чтобы отдебажить и исправить. Как PM автор хотел бы знать какую информацию тестеры собрали о продукте и как они конфигурируют, управляют, получают и оценивают продукт. Я хотел знать как наш продукт работает в условиях, отличных от обычных условий использования; о внутренних противоречиях; как продукт работает в сравнении с другими подобными продуктами с рынка - лучше он или хуже и в чем.
Итак, вы хотите влиять и на качество, и на команду. Хотите знать, как влиять на программистов в положительном ключе?
- Говорите программистам, что ваша цель - помочь им лучше делать свою работу. Вы не должны работать воплощением стыда, порицании или зла - не думаю, что мы даже должны шутить об этом, потому что это реально не смешно. От себя добавлю, что действительно считаю плохой и неконструктивной практику изображать из себя чью-либо совесть. Мы просто диагностируем проблемы, а не обвиняем кого-либо в их наличии;
- Мы часто выступаем в роли гонцов с плохими вестями. Давайте признаем это и постараемся приносить их с состраданием и пониманием;
- Мы тоже можем ошибаться - поэтому надо относиться к собственным суждениям с долей скепсиса;
- Сфокусируйтесь на исследовании продукта, а не на подтверждении уже известных о нем вещей;
- Сообщайте то, что узнали подобным образом;
- Пытайтесь понять как работает продукт на всех уровнях, которые вы в состоянии понять, от сложных к простым. Оцените сложность продукта так, что бы когда вас посетит безрассудная идея про починку какого-нибудь простого бага, вы бы имели возможность остановиться и подумать;
- Интересуйтесь тем, что делают программисты и, по возможности, код и как он работает;
- Никогда не говорите программистам как они должны делать свою работу. Если вы все-таки считаете, что это ваша обязанность, подумайте вот о чем: Как бы вы себя чувствовали, если бы программисты указывали вам что и как вам проверять?
Хотите знать, как лучше взаимодействовать с менеджерами?
- Предоставьте им нужную информацию для обоснованных решений и позвольте им самим принимать решения;
- Поймите, что менеджеры руководствуются не только техническими аспектами, но должны учитывать еще и бизнесс-процессы {к примеру, починка мелкого бага может обойтись дороже, чем релиз с ним - по техническим аспектам баг конечно есть, но бизнес-процессы позволяют жить с ним и наоборот};
- Знайте, что продукт не должен соответствовать именно вашим представлениям о стандартах качества;
- Ни программисты, ни менеджеры не сделают вас счастливыми. Но вы можете сказать им что вам для этого нужно. Особенно обратите внимание на:
- Задачи, которые замедляют тестирование. Они чертовски важны, потому что помогают багам окопаться глубже и основательнее. Поэтому рассказывайте не только о багах, но и задачах, которые тормозят процесс тестирования;
- Предоставляйте отчеты о том, сколько времени вы тратите на задачи;
- Обратите внимание на то, сколько вы на самом деле тратите времени непосредственно на тестирование и сколько еще - на настройки окружения, исследование багов, собрания;
- Покажите менеджерам, что самые важные найденные баги были обнаружены не в бездумных повторениях обычных кейсов, а исследовательским тестированием;
- Попросите помочь с автоматизацией {не уверена в точной передаче смысла, но с учетом предыдущего пункта важно, чтобы рутинное тестирование было действительно автоматизировано, что бы мы могли больше времени уделять исследовательскому тестированию};
- Донесите плюсы и минусы автоматизации;
- Помогите людям понять разницу между проверками и тестированием и ценность каждого из этих понятий;
- Работайте, что бы показать, что ваше дело - именно квалифицированная разведка продукта {разведчики мы еще те, саперы блин} и помогите менеджерам понять как мы на самом деле находим проблемы {на свою голову в том числе};
- Помогите команде избежать опасного заблуждения: разработка ПО это не линейный, но органический процесс {имеется ввиду - системный, взаимозависимый, сложный};
- На самом деле у нас не "тестовая фаза", а "фаза исправлений" {not "testing phase, but "fixing phase" мы не просто тестируем, мы потом еще и проверяем, что все работает после починок};
- Когда у вас просят разрешения на выпуск продукта - просто вежливо дайте отчет о тестировании, а решение о выпуске предоставьте тому, чье решение действительно важно - заказчику.
Хотите пользоваться уважением команды?
- Будьте двигателем проекта, а не его тормозом. Вы - поставщик информации, а не инфорсер {жаргонное амер.: член гангстерской банды, функцией которого является принуждение к выполнению ее требований или приведение в исполнение ее приговоров};
- Перестаньте пытаться присвоить качество себе и поймите, что все члены в команде обеспечивают его так же, как и вы;
- Осознайте, что ваша роль - мыслить критически - помогите программистам и менеджерам предотвратить самообман и начните с того, чтобы перестать обманывать себя;
- Разнообразьте свои умения, команду и тактику. Как говорит Карл Вейн: "Если вы хотите понять что-то сложное - вы должны усложнить себя" {чтобы найти баг - будь багом!, ы};
- Улучшайте навыки критического мышления {хотя бы вот на русском и еще ссылки тут}
- Найдите хорошего учителя - мол, интернет, если шо, вам в помощь;
- Не становитесь товаром. Сертификация означает трату денег на то, что бы стать такими неразличимым в толпе таких же людей. Будьте уникальными {"make your own mark" - создайте свой стандарт, что ли};
- Сосредоточьтесь на создании собственных mind skills (мышленческих навыков, брр}, которые вы сможете адаптировать под любой процесс;
- Делитесь тем, что вы изучили {чем и занимаюсь :)}.
Короче, тестеры, пора нам перестать тянуть одеяло с качеством только на себя. Будьте лучшими, насколько сможете, тестировщиками, опытными исследователями, а не подражателями программистов или менеджеров.
Фух. Там в статье есть еще ссылки на интересные материалы, но пока я выдохлась - и так огромный материал получился :)
