Помимо обычных вещей, таких как ориентированность на детали, знание сценариев и глубокое понимание предметной области, на мой взгляд, может сделать вас выдающимся тестировщиком программного обеспечения, особенно если программное обеспечение нацелено на подготовленные профессионалы в узких областях. Некоторыми примерами могут быть программа, которая отслеживает частоту сердечных сокращений пациентов, или программа, которая взаимодействует с автономными мобильными роботами в зоне боевых действий и т. Д. Вариант использования обученного медицинского специалиста, вероятно, будет отличаться от тех, кто этого не делает.

Считаете ли вы, что тестирование важно или что-то просто необходимо сделать? Вы в настоящее время пишете тесты для своего собственного кода? Когда вы пишете тесты, вам трудно думать о новых тестах? Когда вы смотрите на чужой код, можете ли вы увидеть ошибки, которые там есть? Можете ли вы определить, действительно ли набор тестов, с полным покрытием или без него, проверяет полный диапазон возможных путей и поведения? Вы хотите узнать о тестировании больше, чем вы уже знаете? Готовы ли вы, чтобы вас втайне презирали и, возможно, боялись те, кто просто терпит испытания и не принимает их? Какой твой любимый цвет: зеленый или красный? (Подсказка: правильный ответ - зеленый!)

Чтобы продолжить отличный ответ Г.В.Ллосы.

1 Терпение

Вы должны обладать почти бесконечным терпением, потому что многое из того, что вы будете делать, невероятно расстраивает сломан), а также невероятно скучно. Предполагая, что у приложений есть параметры и состояния, вы будете в основном повторять одну и ту же последовательность событий снова и снова.

2 Тщательно

Одна из особенностей разработчиков заключается в том, что они обычно (надеюсь) тестируют свои собственные вещи. прежде, чем они его вернут. В большинстве случаев это означает, что приложение, вероятно, работает в (или) нормальном случае. Однако обычно это происходит на машине разработчиков, и они обычно используют один и тот же тестовый пример снова и снова. Ваша работа - протестировать огромное количество совершенно нормальных кажущихся тестовых случаев, а затем проверить все крайние случаи, а затем проверьте все неприемлемые случаи. Затем, если приложение находится в разных состояниях, вам может потребоваться еще раз проверить все эти вещи с кажущейся несвязанной разницей (IE изменил цветовую схему на вашем калькуляторе, и теперь кнопка «+» не работает).

3 Организовано

Вы должны иметь возможность делать заметки о каждом своем движении. Нет ничего более разочаровывающего, чем когда кто-то сообщает об ошибке и не знает, как это произошло или как ее воспроизвести. Воспроизводимые проблемы в 1000 раз легче решить, потому что их можно проследить. Сложные приложения с множеством переплетающихся состояний и экранов очень затрудняют исправление неясных ошибок, если только программисты не знают, как сгенерировать ошибку в первую очередь.

4 Творчество / сочувствие

Программисты, как правило, опытные пользователи . И компьютеров в целом, и их программы в частности. Они знают, что файловые функции обычно находятся в меню файлов, и что кнопки нужно нажать только один раз, а затем вы ждете. Пользователи не знают об этом . Это не ваша работа - предполагать, что пользователи глупы, потому что это не так, но у них нет той подготовки, которую вы имеете. Поэтому вам нужно понимать, о чем они думают, а затем нажимать кнопку в 100 раз как можно быстрее. Во многих приложениях это дает 100 результатов, что обычно ПЛОХО.

Я знал о приложении, в котором инструкции были нажимать «Shift-Enter», и я нажимал L-Shift вместо R-Shift. Он взорвался. Обычные пользователи будут печатать одной рукой, поэтому они на 99,9% будут использовать L-Shift, никому не приходило в голову привязать и другую смену. Вот почему вам тоже нужно творчество. Вам нужно уметь приспособиться к нескольким различным ролям и спросить себя, как они будут использовать программное обеспечение. Затем злоупотребляйте каждой частью этого варианта использования.

В конечном счете, это лишь некоторые из необходимых навыков. Но, как вы заметили, все эти навыки полезно иметь в любом случае, поэтому их развитие никогда не бывает плохим.

Ура.

Связь - это ключ. Важно знать, как написать эффективный отчет об ошибке.

Очистить заголовок

Минимальные поддающиеся количественной оценке шаги для воспроизведения проблемы

Рисунки

Ожидаемые и наблюдаемые результаты (мне нравится, когда я не получаю ожидаемых результатов !!!!)

Это отличная статья по этому поводу:

http://itscommonsensestupid.blogspot.com/2008/07/tips-to-write-good-bug-report.html

Простая вещь - «Думай негативно»

Всегда ломай что-нибудь во благо

Вы действительно не можете знать, станете ли вы хорошим тестером программного обеспечения, пока не станете им. Нет одного отношения, одного опыта, одного набора навыков, которые определяют QAer.

Это не что иное, как быть хорошим разработчиком. Вы можете себе представить, что станете хорошим специалистом, потому что испробовали множество вещей, разработанных разработчиками. Но пока вы этого не сделаете, никогда не узнаете.

Спросите себя, почему вы хотите поменяться ролями? Что привлекает вас в роли QA?

Если вы думаете, что это будет проще, или вы думаете, что у вас будет более короткий рабочий день, или вы думаете, что вам будут платить больше, или вы думаете, что все будут любить вас - тогда роль QA может не для вас.

Если вы подумываете о переходе на QA, потому что вы были менее чем успешны как разработчик - тогда роль QA может быть не для вас.

Или все может сработать, вы никогда не узнаете! Я знаю людей в QA, которые пришли из самых разных слоев общества.

Как было предложено, найдите себя в проекте (бесплатном или оплачиваемом), в котором вы можете выполнять эту роль. Тогда и только тогда вы узнаете, нравится ли вам это, и у вас это хорошо получается.

Удачи!

Вы можете попробовать протестировать проект с открытым исходным кодом: они появляются на всех стадиях разработки (зрелые или незрелые), а также должны иметь спецификации. Это даст вам возможность работать над реальным проектом с настоящими разработчиками, тестировщиками, системой отслеживания ошибок и т. Д.

Лучший способ определить, насколько вы хороший тестировщик:

1) Методичен ли вы. Можете ли вы каждый раз повторять одни и те же шаги с небольшими различиями, чтобы использовать разные логические пути.

2) Вы очень внимательны к анализу.

Любой из них хорош, оба хороши.

Я согласен с другими, которые говорят: «любит ломать вещи».

Также разнообразие фонов хорошо для тестовой команды. Бывшие разработчики часто помогают команде приступить к автоматизации, бывшие сотрудники службы поддержки клиентов могут быть яростными защитниками права пользователя на удобный пользовательский интерфейс и т. Д.

Статья Тестировщики и разработчики думают по-разному , Брета Петтихорда, противопоставляет образы и черты характера, которые полезны в каждой роли. Например, в нем подробно рассматриваются такие темы:

• Хорошие тестировщики
  • Эмпирические
  • Наблюдаемые
  • Скептики
• Хорошие разработчики
  • Теоретический
  • Как это устроено
  • Верующие

Вот заметки из Cem Kaner Testing Computer Software , касающиеся некоторых атрибутов и навыков, полезных для тестировщика :

• Целостность и приверженность качеству
• Эмпирическая система отсчета против теоретической. Тесты как миниатюрные эксперименты.
• Образование
• Некоторые основы программирования. Полезно, но не обязательно.
• Опыт использования многих компьютеров и множества программных пакетов
• Знание комбинаторики. Сколько тестовых примеров требуется для полной оценки того или иного аспекта программы?
• Отличное устное и письменное общение.
• Хорошее умение угадывать ошибки.
• Быстрые навыки абстракции.
• Хорошо разбираются в головоломках.
• Очень сознательно эффективности.
• Способен совмещать многие задачи.
• Хорош в планировании
• Внимательный наблюдатель, пациент, уделяет внимание деталям.
• Ролевая игра воображения.
• Может читать и писать спецификации.