Чухаю в затылке

Ответить мне конечно никто не ответит... Но оформить вопрос надо. Была на собеседовании и меня просили про проверку окна логина. Ну ввода корректных/некорректных данных, валидация емейла, вот это все. Мало того что я затупила как обычно на собеседовании (это был полный позор, могу представить что девушка обо мне подумала), вспомнила только вечером что именно от меня хотели, так вот еще вопрос возник. Я на наш проект пришла год назад, у нас сертификат от PCI DSS и это автоматом означает что формы у нас провалидированы от и до. Мне не нужно было этим заниматься и я в курсе что валидатор у нас прикручен, отчасти это объясняет мой тупняк (привет, самооправдания!). Но вот вопрос - разве в современном мире программирования программер не прикрутит валидатор автоматом? Тогда какой смысл в подобном тесте? Или я слишком хорошего мнения о людях и их отношении к работе?

Про тестирование карандашей/чашек/столов

Ну вы все наверное в курсе как часто на собеседовании тестировщикам предлагают протестировать пуговицу, карандаш, моржовый хрен и прочие белые тапочки. Может кому-то и нравится постоянно в  окружающем мире выискивать "баги" и генерить кейсы направо и налево, но я тестировщик ленивый, не любящий лишних телодвижений без необходимости. К слову, это помогает не тратить энергию, а направлять ее на действительно важные вещи (напомните мне об этом, когда меня снова занесет на тестировании безопасности). Попробую пояснить. Вот вам предложили протестировать ручку. О, давайте-давайте щас выпишем все, до чего можно доебаться у ручки! Итак:
1. Определимся с типом - шариковая, гелевая, чернильная?
2. Определимся с материалом корпуса и если он не монолитный - то и с материалами частей
3. С внешними параметрами (вес/размеры/цвет)
4. Цвет чернил
5. Стержень и его составляющие
6. Ширина мазка
7. Течет ли паста/чернила/гель
8. На каких поверхностях она будет писать (опробовать стопиццот, никак не меньше!)
9. При каком угле наклона перестает писать?
10. С какого этажа ее можно скинуть безболезненно для корпуса
11. С какого - еще можно собрать
12. Водостойки ли чернила? Не исчезают ли они через 5 минут?
13. При каком атмосферном давлении из нее еще не вытекают все чернила? А при каком трещит корпус?
И еще много аналогичных вопросов. В то время как на реальный (не избыточный, с ненужными тратами времени и ресурсов) тест ручки вам понадобится не больше минуты. Вам дали ее в руки, вы покрутили, расписали - всё! "Но я же..50 тест-кейсов...". А зачем? Ручка, которую вам дали протестровать - самая обычная офисная. Её функция - удовлетворять нужды офисного работника. Какое значение для нее имеют параметры водостойкости, угол наклона при письме, ее прочность (если максимум с чего она падает - это стол, а если это херндацатый этаж - то кто пойдет ее искать)? Никакого практического. То, что респондент способен сгенерить громадное кол-во кейсов говорит только о его отличной фантазии, но никак не о его скилах тестера. Другое дело, что вопрос с "протестированием предмета" позволяет хорошо увидеть - собеседуемый действительно разбирается и любит свое дело, или просто думает, что придумав и выполнив много тестов он формально прикроет свою пятую точку от анальных кар в случае фейла. Такой сугубо формальный подход мне кажется у тестировщика избыточным, как и само тестирование ручки/карандаша). Мораль: старайтесь не формально выполнить данное вам задание, а пораскинуть мозгами над ним. 

Простые истины

Как у админов "нечего делать - делай бэкапы", так у тестировщиков: "нечего делать - делай тесты". У нас конечно довольно редко бывает "нечего делать", но я вас уверяю - лишних проверок не бывает) Решила прогнать пару контрольных - оказалось, сторонний партнер у себя сделал изменения, а нам не сказал. "Сова нашла хвост!"

Прекрасного принесла

"Зато много девушек среди QA (тестирование), где не нужно решать творческие технические задачи и много думать."
Оставлю без комментариев.

Как оно работает?!

Я этим вопросом задаюсь каждый раз, как попадаю на новое место работы. И толком никто не может объяснить. Потому что представьте себе вопрос: "Как работает твоя дыхательная система?". "Чувак, я просто вдыхаю и выдыхаю!" - ответит пользователь продукта. А теперь представьте, что вы спрашиваете об этом нос. А теперь - легкие (при этом еще круто, если удастся задать вопрос именно легким, а не выуживать инфу отдельно у бронхов, альвеол, реснитчатого эпителия и т.д.). А добавим еще видение со стороны кровеносной системы. Вот так я собираю информацию от разных составляющих проекта. В прошлый раз на то, чтобы постичь принцип работы приложения, у меня ушел год (я умолчу о серверных нюансах, они так и остались чем-то абстрактным). А тестеры, которые остались там работать, так до закрытия проекта и не знали всей картины. Что не мешало им в общем выпустить, а потом сопровождать проект в течение двух лет. Иногда от понимания факта, что всем в общем насрать на уровень осведомленности тестеров о проекте, у меня опускаются руки. Добавим сюда еще отнюдь не повышающий самооценку процесс задавания вопросов программистам в стиле: "А что это за эксепшн вот в этой строчечке?", который, помимо всего прочего, может быть воспринят как личное оскорбление. Чтобы научиться задавать нормальные вопросы, нужен определенный уровень осведомленности, а выглядеть идиотом тоже мало кому хочется. Короче, по всему получается, что лучше не знать и тыкать так, со стороны пользователя. Но каждый раз, получая ошибки на проде, я убеждаюсь, что это абсолютно не так. Многих из них удалось бы избежать, знай я раньше как работает тот или иной компонент и их связки. И в эти моменты мне хочется бегать и трясти всех за любые места чтобы мне только показали все и сразу. Но увы, это тоже невозможно. Нельзя за пару месяцев, влившись в рабочий проект (и чем он старше, тем дольше), полностью построить в голове принцип его жизнеобеспечения. По крайней мере, если у вас это получилось - я за вас искренне рада. А пока я ползу дальше ковряться в собственных белых пятнах. 

Testers: Get Out of the Quality Assurance Business

Котаны - я теперь так буду обращаться к своим воображаемым читателям - тут такое дело, гайда по тестированию безопасности пока буксует из-за моих сбоев целеполагания, но я нашла отличную статью и собираюсь ее вам вкратце пересказать. Кто хорош в английском, то вот вам она. А кто не очень - то вэлкам, буду рассказывать.
Короче, название у статьи малость провокационное: "Тестеры - нам пора убраться из обеспечения качества". Что за фигня?! - подумают тестеры. Но давайте по порядку.
Осенью 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 (мышленческих навыков, брр}, которые вы сможете адаптировать под любой процесс;
• Делитесь тем, что вы изучили {чем и занимаюсь :)}.

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

Фух. Там в статье есть еще ссылки на интересные материалы, но пока я выдохлась - и так огромный материал получился :) 

Планы

Я обещалась сделать тему по тестированию безопасности сайтов по прочтении гайда от QWASP'а, но я все еще в процессе. Что бы начать излагать хотя бы отдельные главы мне нужно дочитать хотя бы первый раз целиком до конца и это движется, но медленно. Тупо переводить дело гиблое, я застряну сразу, а вот начать вольный пересказ - вполне по силам имхо. Осилила уже половину и в скором времени надеюсь уже начать излагать по кусочкам. Не переключайтесь, у меня обширный дополнительный материал :)

В идеальном мире: мифология тестирования

Чем хороший специалист отличается от плохого? Почему платные клиники по большей части бесполезны? Чем так смешит фраза: "Вы не даете нам тестировать!" - читайте в рубрике "монологи о профессионализме".
 Итак, тут я делала акцент на том факте, что тестирование - это не столько поиск багов. Задача тестировщика в бОльшей степени состоит как раз в понимании этой простой истины, и только потом уже - в ее реализации. Хотя на практике все происходит наоборот, т.к. нельзя натянуть теорию на голое место. Теория - это концентрированный опыт, а концентрат в голом виде либо бесполезен, либо вообще опасен, его нужно добавлять во что-то, нужна основа. И этим "что-то" служит практика тестирования, опыт проверок, изучение процесса и анализ повторяющихся ситуаций. Нельзя просто так взять, почитать теорию и думать, что знаешь как это устроено. Сдача на сертификат, как и любой экзамен, часто дает ложноположительный результат: признаками положительного служит тот факт, что человек рассказывает теорию (повторяет слова), а отрицательным фактом является то, что он не понимает сути этих слов. И надежного и унифицированного способа выяснить это понимание не существует. Все мы помним зубрил, которым незаслуженно ставили "отлично", но последствия ложного оценивания на единичных экзаменах (не все преподаватели любят зубрил) не так губительны, как выдача сертификата специалисту, который на самом деле не является таковым. Хотя конечно несмертельно, тем более с учетом того факта, что работодатель может довольно быстро проверить насколько знания теории соответствуют умениям (зазубрены они или есть понимание применения).
Но вернемся к основной задаче и важности ее понимания. Во второй половине 70х подход к тестированию заключался именно в поиске как можно большего кол-ва багов и мне кажется, что многие тестировщики так и застряли на этом этапе развития. Поиск багов является побочным продуктом деятельности тестировщика, а его прямой задачей является - я прошу прощения за повторы - полный, развернутый отчет о состоянии проекта. Проверить работоспособность каждой части системы в разных условиях. Может быть так, что с основными "обязанностями" отдельная функция справляется, а в какой-то нестандартной ситуации ведет себя не очень хорошо - и тут опять могут быть градации - от простого неудобства для пользователя, до полного отказа, но в столь нестандартном случае, что он практически невозможен. И вот именно в таких случаях - когда тестировщик в одиночку не может оценить целесообразность починки подобных вещей - нужно не кричать: "Чини его!", а просто донести до команды проблему и принять решение. Кстати, оценка последствий починки или не-починки багов, тоже привилегия тестировщика - именно он, зная систему, с большей точностью способен предсказать как именно окончательное решение повлияет на проект. И так по каждому багу практически :) Разумеется, есть вещи, которые видно сразу - оно сломалось и надо чинить, но в этих случаях вопрос о починке даже не стоит - он и так ясен. При таком подходе конфликта с программистами и споров до хрипоты "Баг или фича?!" не возникает вообще.
Так чем же хороший специалист отличается от плохого? Гибкостью подхода. Умением оперировать не шаблонами, а разными, годными, пластичными шаблонами подходами к проблемам. Не "есть симптом - лечить/чинить, нет - симптома - нет болезни/бага", а "что будет симптомом для данного человека/программы?", "давление в 90/60 может быть нормальным для человека? - да, если он себя при этом прекрасно чувствует" - "у программы ломается интерфейс, если пользователь издевался над ней вводом невалидных данных - баг или пользователь неумный?" и прочие гибкие методологии. Возвращаясь к вопросу о платных клиниках - плохие специалисты, которые получили диплом, просто вызубрив энцикплопедические связки, никогда не смогут подходить к проблеме гибко, а так и будут гонять пациента сдавать анализы и качать головой, вместо того, чтобы подойти к проблеме индивидуально, с анализом бОльшего количества параметров. А наткнуться на такого "специалиста" как в платной, так и в обычной поликлинике, вероятность примерно одинакова. Конечно, это не значит, что в платных клиниках сплошь зубрилы с красными дипломами, это просто замечание, что даже платная клиника не панацея. Найти хорошего врача также трудно, как и любого другого хорошего специалиста.
Ну и к последней части. "Вы не даете нам тестировать!" - почему это смешно. Можете вы представить себе ситуацию, когда, наняв по трезвому и взвешенному размышлению, тестировщиков в команду, им не дают делать свою работу? Да это как купить Porsche с бриллиантовыми стразиками и поставить в гараж потому что "бензин дорогой"! Можно сделать вывод, что если тестировщикам "не дают тестировать", т.е. времени, которое они требуют на проверку билда, то это плохие, негодные тестировщики. Они пытаются не дать оценку проекту, а именно "найти все баги" чтобы прикрыть попу от возможных претензий в последствии. Они живут в идеальном мире, считая себя людьми, которые выносят вердикт "выходить на прод или нет". Но, как я уже говорила, решают это не тестировщики. И ответственность не только на них, так что нет смысла пытаться сначала всю на себя ее перетянуть, а потом думать как бы съехать. Не нужно создавать себе дополнительных сложностей :) Мы живем не в идеальном мире, и это - хорошо!