Здравствуйте,
меня заинтересовала тема тестирования, но в интернете ничего структурированного нет.
Мне интересно, как устроено тестирование в компаниях.
Непонятно что за чем должно идти.
В моем понимании это так:
1) Выходит документация, ее анализируют.
2) На основе пункта 1 составляют тест-кейсы.
3) По тест-кейсам пишут реальный код (а может и не пишут, судя по статьям по тестированию, которые походят больше на статьи о менеджменте).
И еще: какие техники обычно используют тестировщики?
У меня после прочтения книг и статей такое ощущение, что они сами не знают, что будут делать, но им важно, чтобы их взяли на работу, где собственно им и предъявят, что надо делать.
dollar, я разработчик, пишу код, начал рвзработку по TDD. Все понятно, но захотел понять, чем занимаются тестировщики. И тут пошло поехало. Один менеджмент и надежды.
Георгий, тогда вам эта тема в целом не нужна. Достаточно аккуратно писать код и тестировать каждый маленький кусочек кода, чтобы просто быть уверенным в нем. То есть не писать "в слепую", вот и всё. Методологию можно применять только тогда, когда у вас штат ленивых программистов, которые не заинтересованы в качестве и работоспособности кода, и вы хотите их дисциплинировать.
А отдельный тестировщик обычно тестирует уже готовый продукт (на разных стадиях готовности). Там дальше уже целая наука, как проводится тестирование, если это профессиональный тестировщик.
Как чаще всего устроен процесс тестирование в маленьких / средних продуктовых компаниях:
1. Пилится фича разработчиками.
2. Отправляется на ревью коллег.
3. После ревью приходит тестировщик и по своим тест-кейсам прогоняет ветку с фичей. Чаще всего это смоук-тест и соответствие фичи необходимым требованиям. Если это какая-то большая / глобальная фича, то здесь уже идёт в бой регрессионное тестирование.
Вообще, во всех компаниях процессы разные, это действительно может быть разработка TDD, который вы описали, а может быть тестировщик сидит и в своей голове придумывает тест-кейсы и лежат они у него где-то в блокноте.
Поэтому отчасти ощущение непонимания своей задачи даже уместно в этом случае на начальном этапе.
Георгий,
в крупных (очень) тоже бывает не сильно далеко процесс убегает
регрессионные тесты могут писать автоматизаторы или сами разработчики
тестировщик же проверяет задачу по тому, что она должна работать так, как указано в Defenition of Done или русским языком -- так как ожидается в описании задачи, по идее нужно проверить похожие/рядом стоящие кейсы, еще по идее сам разработчик должен отдать оттестированную им задачу, но по факту QA видит работу несколько в инном свете, тк в отличие от разработчика -- он не видит кишки и значит не знает деталей, а значит работает несколько в другом контексте и находит не соответствия, которые разработчику тяжело углядеть (особенно который не умеет в QA)...
Спецификация и тест-кейсы на основе документации, а не полевой работы -- признаки довольно крутого процесса работы разработки и QA, не видел таких еще (но я в крупных мало где работал).
А если тест-кейсы на основе User story в виде BDD описаний -- божественно :)
Получается, поприще тестеров это некие мнимые общие подходы, которые вообще не общие. Кто на что горазд, тем и занимается.
А значит есть куда стремиться в области унификации и стандартизации подходов.
Георгий, Важны не подходы, а информация которую тестировщик предоставляет проекту. Артефакт (~"осязаямый продукт") тестировщика - информация. Это надо усвоить. А все остальное второстепенно.
Георгий, нет, тестовые сценарии это вспомогательный инструмент.
Ими пользуются для воспроизводимости, и повторяемости, и приблизительной оценки покрытия. Как список покупок - можно им пользоваться можно нет, важно чтобы на столе было что поесть в конце концов.
Я имею ввиду информацию о дефектах в продукте. Нашел дефекты, сообщил - молодец. Не нашел или не сообщил - их найдут пользователи.
Менеджерам важны эти тесткейсы, но тесткейсы это не тесты, надо это понимать.
(https://www.satisfice.com/download/test-cases-are-...
Людям нужна иллюзия контроля, а иллюзия контроля есть только тогда когда есть цифры. Я тоже регулярно снимаю статистику, чтобы определить "горячие точки" на которые нужно в первую очередь обратить вниманием, но я не делаю из цифр культа, и не подменяю ими цель. (См.Закон Гудхарта
Ваш продукт - найденная информация по дефектам. Для тестировщика, я считаю, есть единственная важная цифра - количество заведенных качественных и уникальных репортов за единицу времени. Качественный репорт, это тот который возьмут в работу и будут чинить, не завернут по любой другой причине, например из-за невоспроизводимости или беспорядочного описания.
Можно иметь дофига тестовых сценариев, в специальных дорогих программах для управления тестовыми сценариями, штаб тестировщиков, менеджера тестирования, автоматизацию тестирования. Но если в конце концов дефекты не выявляются или не чинятся (кстати довести выявленный дефект до его действительной починки, как я считаю тоже обязанность тестировщика, хотя тут некоторые могут быть со мной не согласны) - все впустую.
Вот у нас на проекте, с меня требуют увеличения количества автоматизированных тестов. Потом хотят, чтобы они все были зелеными, и все такое в этом духе. Но не это главная работа тестировщика-автоматизатора. Работа тестировщика-автоматизатора - с выявлять дефекты (в данном случае с помощью системы автоматизации).
Т.е. само собой разумеется, я хочу увеличивать покрытие, я хочу меньше false negative, я хочу качественный логгинг, потому что это упрощает мне анализ сбоя, и выявление дефекта (или он в продукте или он в тесте). Автоматизация добавляет своей сложности. Автоматизация может выдавать трудновоспроизводимые сбои. Сидишь, копаешься. Окупаются эти трудозатраты только за счет обьема.
Да все эти книги, сертификации, это попытка систематизировать работу тестировщика, чтобы о ней было удобнее разговаривать, сравнивать, считать, оценивать. Книги и сертификации хорошо продаются. Полезных книг о тестировании очень мало, они есть, но их мало. И в этих книгах, тех которые хорошие, описываются не методологии, не готовые рецепты, а парадигмы. Каким "видением" нужно наделить тестировщика чтобы он был хорошим тестировщиком.
Alexej Simakov, вы занимаетесь как юнит-тестированием, так и инструментами автоматизации, как Selenium? Или, может, совмещаете их?
Что еще интересно, так это тестировщики пишут обычно свои тесты автоматизации в виде отдельных независимых программ или встраивают тесты в исходный код, над которым работают разработчики.
Например, я могу написать на селениуме тесты, проверяющие веб-приложение, не встраивая код в сам продукт или могу использовать, например, JUnit + Selenium и все написать в папке отведенной для тестов.
Георгий, у нас не веб-приложение, и инструмент для UI тестирования свой. У нас он встроен в приложение. Но это не очень хорошо. Лучше когда приложение и инструмент разделены. Таким образом приложение физически не сможет повлиять на инструмент тестирования. Ну кроме случая когда приложение негативно влияет на операционную систему а это в свою очередь влияет на инструмент тестирования.
Представим вы из юнит теста запускаете приложение, запускаете браузер, запускаете тесты selenium, потом все сворачиваете.. На машине разработчика все так возможно будет работать. А как вы будете тестировать приложение если оно уже собраное, и в облаке/на сервере? Можно устроить так чтобы разрабатывать и прогонять тесты локально через JUnit. А при сборке тесты бы выгружались и их можно было запускать с любой машины. Придется всего лишь отвязать механизм запуска приложения от тестов. Т.е. всю процедуру подготовки приложения для теста. Тут надо подумать кто, когда, где и для чего будет пользоваться этими тестами. Тестировать ли продакшн? Да, конечно тестировать. Именно это то что будет видеть конечный пользователь. Это же классика, на машине разработчика все работает, а после сборки и деплоя "внезапно" приложение дохнет. Кто-то там какие-то конфиги забыл закоммитить, видите-ли.
Георгий еще вот пример из жизни: когда инструмент тестирования является частью приложения - если приложение сломано так что вообще ничего не запускается, то тесты вообще не отработают. И у нас к сожалению так. А если инструмент смотрит на приложение снаружи, он просто покажет все тесты красными.
Простой
Простой
