Comments 13
Вполне согласен — должен быть конфликт разработчика и тестера — типа спорта — чья возьмет
Всегда поражали тестеры, которые умудрялись находить весьма неочевидные баги — это надо чувствовать
п.1 В коде всегда есть ошибки, а значит есть баги
п.2 Если багов и ошибок не найдено — смотреть п.1
п.2 Если багов и ошибок не найдено — смотреть п.1
1) Любой программист, посмотрев на чужой код, найдёт в нём, как минимум, три ошибки.
2) Ошибкам не всё равно, кто их ищет.
2) Ошибкам не всё равно, кто их ищет.
Я никогда не ставлю себе прямую задачу найти ошибку. Иногда меня просят потестировать какой-то кусок программы, и я знаю какую последовательность действий выполнить чтобы увеличить вероятность выявления ошибки. Чтобы выявить ошибку, нужно понимать, как устроена программа внутренне, как взаимодействуют ее части. Это как тестировать спичечный домик. Можно его сжечь и сказать, что он не огнеустойчив, но это бесполезный тест, если он не является прямым требованием. Но то что спичечный домик можно сжечь ясно и без теста. А требовать от спичечного домика быть огнеустойчивым — безумие. С другой стороны, инженер, понимающий как он собран, будет искать места где неровно стоит спичка, так что зацепив ее можно развалить его полностью. Так вот в моем понимании, хороший тестировщик знает за какую ниточку стоит тянуть, а за какую не стоит. Ему не нужно рисовать матрицы эквивалентных классов, не нужно составлять комбинаторные таблицы. Они у него подвешены на интуиции, он проведет три теста, и скажет — все нормально или найдет проблему. И если он проблемы не выявит, это не значит что ее нет, это значит что за 20 % времени он проверил 80 % приложения. И такой тестировщик ценен. Он добивается приемлемого качества за короткий отрезок времени. Правильный тестировщик напишет очень много разных «тестов для карандаша», отличный тестировщик сделает два-три теста и скажет «окей» или нет. И в этом «окей» будет всё. Это будет уверенность в том, что оно действительно «окей». В свою оценку он вкладывает риск, обусловленный нецелесообразностью полного тестирования, и отвечает за этот риск. Мастер своего дела, не тот кто делает все по учебнику, а тот кто берет на себя обоснованные риски.
Кажется, я могу видеть такого сверхтест-инженера.
Несколько дополнений.
1. Вы переплетаете понятия «знания», «понимание», «интуиция» — на мой взгляд совершенно правильно. Эта смесь – важная составляющая тест-инженера. Хочу лишь призвать Вас не отбрасывать учебники. На каждую из этих тем есть достойная литература.
2. Таблицы и матрицы – не самоцель, а инструменты. Если они полезны, их можно использовать… даже если Вы чертовски хорош, чтобы выстраивать нечто подобное сразу у себя в голове.
3. Полного тестирования, говорят, не существует.
4. Надеюсь, что правильный и отличный не исключают друг друга, а второй идет за первым.
Несколько дополнений.
1. Вы переплетаете понятия «знания», «понимание», «интуиция» — на мой взгляд совершенно правильно. Эта смесь – важная составляющая тест-инженера. Хочу лишь призвать Вас не отбрасывать учебники. На каждую из этих тем есть достойная литература.
2. Таблицы и матрицы – не самоцель, а инструменты. Если они полезны, их можно использовать… даже если Вы чертовски хорош, чтобы выстраивать нечто подобное сразу у себя в голове.
3. Полного тестирования, говорят, не существует.
4. Надеюсь, что правильный и отличный не исключают друг друга, а второй идет за первым.
Спасибо за дополнение, а то мой комментарий прозвучал немного бескомпромиссно.
Мой «кумир» из-за которого я вообще пошел в профессию — James Bach. Послушав его лекции, сложилась картина, что можно стать «ниньзя-тестировщиком» (вот как-то так я себе его представляю). Это не значит конечно, что нужны только такие специалисты, это просто такой продвинутый уровень квалификации, который как мне кажется нарабатывается только опытом. И опытом в конкретном проекте. Но я точно знаю, что есть те кто стремятся стать такими высококлассными тестировщиками, а есть те кто предпочитают оставаться «обычными». А может быть опыт тоже такая штука что нарабатывается он всеми а усваивают его не все. Я пока не понял как это работает. Почему одни стремятся стать лучше а потом еще лучше, а другие остаются на своем уровне навыка и не страдают.
Мой «кумир» из-за которого я вообще пошел в профессию — James Bach. Послушав его лекции, сложилась картина, что можно стать «ниньзя-тестировщиком» (вот как-то так я себе его представляю). Это не значит конечно, что нужны только такие специалисты, это просто такой продвинутый уровень квалификации, который как мне кажется нарабатывается только опытом. И опытом в конкретном проекте. Но я точно знаю, что есть те кто стремятся стать такими высококлассными тестировщиками, а есть те кто предпочитают оставаться «обычными». А может быть опыт тоже такая штука что нарабатывается он всеми а усваивают его не все. Я пока не понял как это работает. Почему одни стремятся стать лучше а потом еще лучше, а другие остаются на своем уровне навыка и не страдают.
начните с аксиомы – программа содержит ошибки (кстати, это верно для большинства программ), и далее тестируйте так, чтобы найти их столько, сколько это вообще возможно, будто это Ваш последний день (в тестировании).
Лучше не найти как можно больше, а пропустить как можно меньше приоритетных для пользователя багов.
Очень хорошо про это написала NatalyaRukol в своей статье.
Спасибо за комментарий.
Мне кажется, что здесь не совсем справедливо говорить о «лучше – хуже». Что касается психологического аспекта, установка «пропустить как можно меньше» уступает по своей силе установке «найти как можно больше». Похоже, что именно так считают авторы, и я с ними согласен. С формулировкой «найти как можно больше» все не просто. С формулировкой «пропустить как можно меньше» все еще сложнее. Как нам разобраться с этим? Автор указанной Вами статьи отвечает на этот вопрос (который, по существу, является вопросом эффективности). Чем меньше ошибок пропущено, тем эффективнее. А как мне разобраться с количеством? Откуда я могу узнать много пропущено ошибок или не много? То есть, я хочу сказать, что определение количества пропущенных ошибок требует дополнительной активности, оно не является само по себе. А второй ответ: чем меньше недовольства клиентом выражено, тем эффективнее. Но ведь этот показатель и является отличным способом (конечно же, одним из) разобраться, какое количество ошибок пропущено. Кто-нибудь направьте меня, если я запутался.
И снова, с точки зрения психологии (каким бы громким не было это слово) авторы, на мой взгляд, достаточно убедительны. Важно еще и то, что в переведенном мной отрывке не упоминается такой активности как погоня за отчетами об ошибках. Автор же указанной Вами статья такой параметр вводит.
Поэтому считаю, что темы двух текстов несколько отличаются.
В попытке найти лаконичный ответ на Ваш комментарий, снова сошлюсь на указанную Вами статью и скажу:
Существует поиск ошибок, который не имеет ничего общего с тестированием. Но здесь отсутствует утверждение, что не существует процесса поиска ошибок как важной части процесса тестирования. Нам нужны дополнительные детали.
Считаю, что автор указанной Вами статьи утрирует, неестественно разводя примеры по разным сторонам. Это отличная модель на первых порах обучения, но от нее следует двигаться далее туда, где все не так однозначно.
Мне кажется, что здесь не совсем справедливо говорить о «лучше – хуже». Что касается психологического аспекта, установка «пропустить как можно меньше» уступает по своей силе установке «найти как можно больше». Похоже, что именно так считают авторы, и я с ними согласен. С формулировкой «найти как можно больше» все не просто. С формулировкой «пропустить как можно меньше» все еще сложнее. Как нам разобраться с этим? Автор указанной Вами статьи отвечает на этот вопрос (который, по существу, является вопросом эффективности). Чем меньше ошибок пропущено, тем эффективнее. А как мне разобраться с количеством? Откуда я могу узнать много пропущено ошибок или не много? То есть, я хочу сказать, что определение количества пропущенных ошибок требует дополнительной активности, оно не является само по себе. А второй ответ: чем меньше недовольства клиентом выражено, тем эффективнее. Но ведь этот показатель и является отличным способом (конечно же, одним из) разобраться, какое количество ошибок пропущено. Кто-нибудь направьте меня, если я запутался.
И снова, с точки зрения психологии (каким бы громким не было это слово) авторы, на мой взгляд, достаточно убедительны. Важно еще и то, что в переведенном мной отрывке не упоминается такой активности как погоня за отчетами об ошибках. Автор же указанной Вами статья такой параметр вводит.
Поэтому считаю, что темы двух текстов несколько отличаются.
В попытке найти лаконичный ответ на Ваш комментарий, снова сошлюсь на указанную Вами статью и скажу:
Существует поиск ошибок, который не имеет ничего общего с тестированием. Но здесь отсутствует утверждение, что не существует процесса поиска ошибок как важной части процесса тестирования. Нам нужны дополнительные детали.
Считаю, что автор указанной Вами статьи утрирует, неестественно разводя примеры по разным сторонам. Это отличная модель на первых порах обучения, но от нее следует двигаться далее туда, где все не так однозначно.
Я когда-то работал QA и вполне согласен, ошибки были и будут всегда, qa инженер должен найти их чтобы их количество стремилось к нулю. Иногда чтобы найти проблему достаточно просто посмотреть на код как бы сказать с другой стороны)
"На другой руке" (англ. Идиома on the other hand) переводится как "с другой стороны".
А так, спасибо за актуальный перевод полезного отрывка из книги!
Sign up to leave a comment.
Психология тестирования (конечно же, не исчерпывающая). Личный перевод из книги «Искусство тестирования» Г. Майерса