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