А
Саша, а можешь немного раскрыть последний тезис, что нужен переход от черного ящика к серому или белому?
Про это я могу немного рассказать. но это моё личное понимание и отношение, все строго ИМХО :)
На мой взгляд, "классическое" тестирование, когда разработчик сделал- отдал тестировщику на тестирование, это был зачастую тот самый черный ящик, особенно там, где разработка и тестирование это разные команды, мячик перекидывался от одних другим.
Что это подразумевает- есть требования, разработчик по ним что-то сделал, это получило тестирование и по этим же требованиям проверило. Возможности узнать как оно там внутри работает практически небыло. все на догадках.
У нас сейчас (у нас = в моей команде) это серый ящик, т.к. тестирование и разработка это одна команда, в обсуждении участвуют все, понимаение того. как это реализовано есть у всех, на любом этапе можно уточнить ньюансы и подробности. За счет этого находится много edge кейсов и неожиданных сценариев, Допустим, в код мы не лезем, но алгоритмически мы понимаем что и как работает. В каких-то моментах это позволяет нам серьёзно сократить тестирование- если ым знаем, что во всех 90 случаях тыкания кнопки в разных местах системы вызывается одна и та же функция, то мы вместо проверки всех 90 кнопок проверяем одну конкретную функцию. И наоборот, кнопка может выглядеть одинаково. но по факту в глубине работают совершенно разный код, со своими условиями и так далее.
Совсем белый ящик- это когда есть возможность тестировать ещё и код ко всему прочему, мы пока так не умеем, про это скорее Олег может рассказать. Мы пока ограничиваемся тем, что планируем тестирование до этапа разработки, если есть понимание того. как будет реализовано, договаривамеся, что мы будем покрывать юнит тестами. Чем тоже сокращаем себе ручное тестирование, плюс это позволяет нам писать меньше Е2Е тестов.
На мой взгляд, "классическое" тестирование, когда разработчик сделал- отдал тестировщику на тестирование, это был зачастую тот самый черный ящик, особенно там, где разработка и тестирование это разные команды, мячик перекидывался от одних другим.
Что это подразумевает- есть требования, разработчик по ним что-то сделал, это получило тестирование и по этим же требованиям проверило. Возможности узнать как оно там внутри работает практически небыло. все на догадках.
У нас сейчас (у нас = в моей команде) это серый ящик, т.к. тестирование и разработка это одна команда, в обсуждении участвуют все, понимаение того. как это реализовано есть у всех, на любом этапе можно уточнить ньюансы и подробности. За счет этого находится много edge кейсов и неожиданных сценариев, Допустим, в код мы не лезем, но алгоритмически мы понимаем что и как работает. В каких-то моментах это позволяет нам серьёзно сократить тестирование- если ым знаем, что во всех 90 случаях тыкания кнопки в разных местах системы вызывается одна и та же функция, то мы вместо проверки всех 90 кнопок проверяем одну конкретную функцию. И наоборот, кнопка может выглядеть одинаково. но по факту в глубине работают совершенно разный код, со своими условиями и так далее.
Совсем белый ящик- это когда есть возможность тестировать ещё и код ко всему прочему, мы пока так не умеем, про это скорее Олег может рассказать. Мы пока ограничиваемся тем, что планируем тестирование до этапа разработки, если есть понимание того. как будет реализовано, договаривамеся, что мы будем покрывать юнит тестами. Чем тоже сокращаем себе ручное тестирование, плюс это позволяет нам писать меньше Е2Е тестов.
