Каков наилучший способ помочь вашему тестеру?

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

и наш тестер фактически находится в другой стране, поэтому обычно мы общаемся только через мгновенные сообщения или электронную почту. обычно я стараюсь проводить как можно больше тестов «белого ящика», но иногда из-за плотного графика мне нужно обрабатывать несколько вещей одновременно, и в этом случае я довольно ленив после пост-тестирования ... :(

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

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

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

Итак, мой вопрос, есть ли у вас хорошие советы или лучший способ, чтобы мы могли помочь нашему тестировщику лучше находить больше ошибок?

Спасибо

11.12.2008 02:33:09
6 ОТВЕТОВ
РЕШЕНИЕ

Похоже, вы уже делаете две важные вещи:

  1. У вас есть все, чтобы найти свои недостатки. (Хотя не похоже, что вы работаете с какими-либо автоматизированными модульными тестами, которые могут помочь в этой области)
  2. Оценка обратной связи, которую вы получаете от тестирования.

Две дополнительные вещи я бы порекомендовал.

  1. Вы оба должны получить четкое определение того, что нужно сделать.
  2. Обеспечить завершенную функциональность на регулярной основе.

Это немного баланс между:

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

B. Регулярный выпуск с добавленной функциональностью.

3
11.12.2008 02:59:52
Я использую mod_perl, работающий в UNIX с сервером Apache, недавно я попытался найти инфраструктуру TDD, чтобы я мог автоматизировать тестирование, но пока не сделал этого.
melaos 11.12.2008 05:33:37

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

  1. Полностью работоспособный
  2. Решает основные проблемы, такие как плохой ввод

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

4
11.12.2008 02:40:24
Спасибо за предложение не тратить время тестеров. Я видел так много выпусков, которые даже не установились, поэтому мне было стыдно быть частью команды разработчиков. QA предназначен для проверки работающей системы, прежде чем клиент увидит ее.
Adam Liss 11.12.2008 02:50:00
У меня действительно были проблемы такого типа, когда я имел дело со старым пакетом vb6, так как большинство машин, на которых я тестировал это приложение, раньше, мы обнаруживали ошибки только тогда, когда клиенты устанавливали на новые машины, что приводило в замешательство моменты. :(
melaos 19.12.2008 02:45:16

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

Я стараюсь помочь нашим тестировщикам:

  1. Сообщая им, что я изменил, и какие другие части системы могут быть затронуты,

  2. Убедившись, что они понимают требования клиентов, чтобы они знали, как система должна работать,

  3. Запрашивать отзывы об их субъективных наблюдениях (это слишком сложно ...; это занимает слишком много времени ...; экран ужасен, потому что ....), и

  4. Поощряя их находить творческие способы сломать систему после того, как они убедились, что она работает так, как она должна для «ожидаемых» вводов.

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

Помните, что проверка состоит из двух частей:

  1. Система должна делать то, что должна, и

  2. Он не должен делать то, что не должен делать!

Удачи!

3
11.12.2008 02:45:33

Не лучше ли в некоторых случаях НЕ помогать тестеру? Собираетесь ли вы присутствовать, чтобы помочь всем пользователям, когда они запускают вашу программу?

-1
11.12.2008 04:34:07
можешь уточнить? причина, по которой я хочу сделать его более эффективным, заключается в том, что у меня есть только один ограниченный тестер, и ей иногда приходится жонглировать между проектами.
melaos 11.12.2008 05:29:40
@milesgroman: Я думаю, что «помощь» означает «эффективнее находить проблемы», а не «помогает понять и использовать систему». ОП ищет эффективное тестирование, а не более быстрое обучение.
Adam Liss 12.12.2008 03:16:06

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

Например, если у вас есть приложение hello world, если вы нажмете кнопку, на которой на ярлыке написано «hello», вы точно скажете, что текст метки кнопки Click будет «Hello».

У нас также есть наши разработчики, которые передают мне свои документированные тесты UNIT, а затем я просто делаю тесты шире, чем они. Это отличная помощь. Наши модульные тесты всегда ответят на эти четыре основных вопроса, КТО, КОГДА И КАК. Кто сделал изменения. Что было изменено. Как это работает сейчас. Когда это было изменено.

Также здорово быть быстрым, отвечая на вопросы и предоставляя всю информацию тестеру заранее. Я ненавижу, когда разработчики дают мне приложение и просто говорят: «Вот и ты готов к тестированию». Это худший из возможных сценариев, потому что я понятия не имею, что это такое и как оно вообще должно функционировать.

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

2
8.07.2014 16:28:22
ну, обычно я пытаюсь поймать те очевидные, что эта функция производит этот тип теста, но это скользкие ситуации, когда все идет не так, как ошибки типа плана, которые, как я надеялся, тестер может помочь мне найти.
melaos 11.12.2008 05:35:15
Вы никогда не сможете поймать все, для чего мы здесь. если вы даете всю информацию, необходимую для успеха, вы помогаете своему тестеру наилучшим образом.
Ironsides 11.12.2008 16:05:57
когда вы упоминаете о прохождении модульного теста для вас, вы имеете в виду, как в документах обо всех модульных тестах, выполненных разработчиком? это подразумевало бы наличие документации для начала. если так, как это должно выглядеть?
melaos 19.12.2008 02:46:54
да, мы очень документально настроены здесь. Лучше всего иметь то, что мы называем «счастливым путем». В основном, если это работает отлично, это - то, как это работает. Тестер должен придумать все остальное.
Ironsides 7.01.2009 20:08:34

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

2
11.12.2008 04:52:58