• Позитивный тест кейс, как?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Ох уж эти "протестируй все"...
    Без спецификации вы не можете тестировать. У вас нет т.н "оракула". Оракул в тестировании это то как вы определите, что наблюдаемое поведение приложения является багом. Может это ошибка, что логин может иметь до 50 символов, может быть должно быть допустимо до 256. Не имея спецификации, как я считаю, можно проверять не изменило ли приложение своего поведения между двумя релизами, тогда вашим "оракулом" будет поведение предыдущей версии программы. И то, вы не знаете может это не регресс, а прогресс.

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

    Грамматические ошибки это негативное качество. Репортить конечно. Тут у вас хоть будет на что сослаться, есть Правила Русского Языка ;-).

    Вот это видео посмотрите, доходчиво обьяснено про классы эквивалентноси и граничные значения.
    Разработка тест кейсов по методике Pair wise. Ники...

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

    По плану тестирования (навскидку, подробности додумаете сами):
    Общее:
    • Нужно проверить все статичные ссылки. Можно написать для этого автоматизацию.
    • Проверить грамматику и содержание (что в тексты не закопипастили по ошибке ерунду)
    Функциoнальные области я бы разделил на категории, например:
    1. Управление учетной записью
      1. Регистрация
      2. Вход
      3. Смена пароля
      4. Восстановление пароля.
      5. Удаление

    2. Управление списками дел
      1. Добавление (списка или задачи)
      2. Просмотр
      3. Удаление
      4. Изменение


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

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