Emile_Rottmayer
Ученик
Всех приветствую, в данной теме будет разобрано для чего нужен отдел тестировщиков.
Начнем с того для чего нужно тестирование:
Тестирование необходимо потому, что все мы совершаем ошибки. Некоторые из них могут быть незначительными, в то время как другие – иметь самые разрушительные последствия. Все, что производится человеком, может содержать ошибки (так уж мы, люди, устроены). Именно поэтому любой продукт нуждается в проверке – тестировании, прежде чем его можно будет эффективно и безопасно использовать.
Он сам придумывает сценарий тестирования и сам его осуществляет. Тестировщик моделирует различные ситуации, которые могут возникнуть в процессе использования предмета тестирования, чтобы разработчики смогли исправить обнаруженные ошибки. Таким образом он удостоверяется в надежности продукта с технической и пользовательской точки зрения. Итогом его работы является максимально подробный отчет о проведенном тестировании, в котором должен быть указан анализ и причины возникших проблем.
Разобрались зачем нужно тестирование, дальше разберемся что было бы если тестирования не существовало вообще:
Вы создали проект, не проводили никакого alpha testing'a Поставили проект на vds подключили авто-донат, mysql, сообщаете об открытии проекта, снимаете пароль с сервера, онлайн достигает 1000 человек и сервер выключается.
Согласитесь, ситуация не из самых приятных?
Вот еще одна ситуация: Вы все же успешно открылись, у вас динамический онлайн в 800-900 человек, деньги идут с авто-доната, но все же вы стали замечать что их недостаточно или все же игроки покупают мало игровой валюты. После того как вы запустили отладку вы находите ряд недочетов с проверками которыми игроки активно пользовались и получали игровую валюту совершенно бесплатно.
Мы все говорим про тестировщиков, но не знаем расшифровки этого термина..
Тестировщик — это специалист, который занимается тестированием проекта целью выявления ошибок в его работе и их последующего исправления. Основная задача — найти в программе, приложении, игре или другом продукте все возможные ошибки и проблемы. Он разрабатывает методы тестирования, в частности, в ряде случаев он может использовать систему автоматизации тестирования для проведения одно и того же процесса с различными настройками.
Зачастую тестировщик это многофункциональное понятие, которое имеет один смысл, а на самом деле их два:
QA (сокращённо от «Quality Assurance», что с английского переводится, как «обеспечение качества») это превентивный процесс, гарантирующий, что все необходимые техники, процедуры, стандарты и методологии соблюдаются в процессе разработки продукта для предоставления результата без дефектов.
QC (сокращенно от «Quality Control», что с английского переводится, как «контроль качества») означает процесс проверки качества, который обеспечивает соответствие продукта ранее установленным требованиям. Проще говоря, это процесс, который обеспечивает ожидаемое качество продукта.
В центре внимания QA будет процесс предотвращения дефектов разрабатываемого продукта, в то время как QC будет сосредоточен на конечном качестве продукта и устранении недостатков.
Хорошо, ввели разделение понятий, теперь можно будет сокращать.
У вас возникает логический вопрос: как и кого где брать этих тестировщиков??
Отвечаю на ваш вопрос:
QA: можно найти на самом лучшем великолепном портале p-i, хотя их можно пересчитать по пальцам. Они будут руководить всей системой тестирования да и вообще могут забрать руководство над QC себе.
QC:это ваши потенциальные игроки, которые отыграли некоторое время на beta testing'e или на открытом проекте. Вообщем которые более-менее знают игровой мод.
Теперь затронем тему когда стоит вводить тех самых тестировщиков:
Существует такая модель тестирования V-образная: очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.
Хорошо, мы знаем когда вводить тестировщиков, теперь разберемся с методами тестирования:
• По доступу к коду и архитектуре приложения:
o Метод белого ящика — доступ к коду есть.
o Метод чёрного ящика — доступа к коду нет.
o Метод серого ящика — к части кода доступ есть, к части — нет.
Вы увидели метод белого ящика и сразу задались вопросом, а что, мы будем давать полный код тестировщику? ("Я вот боюсь давать чтоб он ничего не украл")
Так, подождите, не переживайте раньше времени, полный доступ получат не все, а 1 от силы 2 человека т.е получат белый ящик, остальные будут работать по закрытому черному ящику.
Например для полной отладки и анализа проекта сотруднику QA нужно предоставить либо модульно код (блочно) или все же предоставить его полностью.
QC: только закрытый, черный ящик, обычным игрокам серый/белый ящик не нужен. А то накрадут еще себе виртов.
Вообще, по доверию и по работе стоит давать белый ящик. Никогда нельзя просто с лету дать и сказать: вот тебе все карты в руки, чини, смотри, отлаживай.
Это лишь малая часть того что можно рассказать. Если будет интересно то напишу еще пару мануалов или уроков, не знаю как это назвать.
Всем счастья, здоровья, денег, любви.
Начнем с того для чего нужно тестирование:
Тестирование необходимо потому, что все мы совершаем ошибки. Некоторые из них могут быть незначительными, в то время как другие – иметь самые разрушительные последствия. Все, что производится человеком, может содержать ошибки (так уж мы, люди, устроены). Именно поэтому любой продукт нуждается в проверке – тестировании, прежде чем его можно будет эффективно и безопасно использовать.
Он сам придумывает сценарий тестирования и сам его осуществляет. Тестировщик моделирует различные ситуации, которые могут возникнуть в процессе использования предмета тестирования, чтобы разработчики смогли исправить обнаруженные ошибки. Таким образом он удостоверяется в надежности продукта с технической и пользовательской точки зрения. Итогом его работы является максимально подробный отчет о проведенном тестировании, в котором должен быть указан анализ и причины возникших проблем.
Разобрались зачем нужно тестирование, дальше разберемся что было бы если тестирования не существовало вообще:
Вы создали проект, не проводили никакого alpha testing'a Поставили проект на vds подключили авто-донат, mysql, сообщаете об открытии проекта, снимаете пароль с сервера, онлайн достигает 1000 человек и сервер выключается.
Стадия начала тестирования программы в целом специалистами-тестировщиками, обычно не разработчиками программного продукта, но, как правило, внутри организации или сообществе разрабатывающих продукт. Также это может быть стадия добавления новых функциональных возможностей. Программы на данной стадии могут применяться только для ознакомления с будущими возможностями.
Вот еще одна ситуация: Вы все же успешно открылись, у вас динамический онлайн в 800-900 человек, деньги идут с авто-доната, но все же вы стали замечать что их недостаточно или все же игроки покупают мало игровой валюты. После того как вы запустили отладку вы находите ряд недочетов с проверками которыми игроки активно пользовались и получали игровую валюту совершенно бесплатно.
Мы все говорим про тестировщиков, но не знаем расшифровки этого термина..
Тестировщик — это специалист, который занимается тестированием проекта целью выявления ошибок в его работе и их последующего исправления. Основная задача — найти в программе, приложении, игре или другом продукте все возможные ошибки и проблемы. Он разрабатывает методы тестирования, в частности, в ряде случаев он может использовать систему автоматизации тестирования для проведения одно и того же процесса с различными настройками.
Зачастую тестировщик это многофункциональное понятие, которое имеет один смысл, а на самом деле их два:
QA (сокращённо от «Quality Assurance», что с английского переводится, как «обеспечение качества») это превентивный процесс, гарантирующий, что все необходимые техники, процедуры, стандарты и методологии соблюдаются в процессе разработки продукта для предоставления результата без дефектов.
QC (сокращенно от «Quality Control», что с английского переводится, как «контроль качества») означает процесс проверки качества, который обеспечивает соответствие продукта ранее установленным требованиям. Проще говоря, это процесс, который обеспечивает ожидаемое качество продукта.
В центре внимания QA будет процесс предотвращения дефектов разрабатываемого продукта, в то время как QC будет сосредоточен на конечном качестве продукта и устранении недостатков.
Хорошо, ввели разделение понятий, теперь можно будет сокращать.
У вас возникает логический вопрос: как и кого где брать этих тестировщиков??
Отвечаю на ваш вопрос:
QA: можно найти на самом лучшем великолепном портале p-i, хотя их можно пересчитать по пальцам. Они будут руководить всей системой тестирования да и вообще могут забрать руководство над QC себе.
QC:это ваши потенциальные игроки, которые отыграли некоторое время на beta testing'e или на открытом проекте. Вообщем которые более-менее знают игровой мод.
Теперь затронем тему когда стоит вводить тех самых тестировщиков:
Существует такая модель тестирования V-образная: очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.
Чтобы видеть скрытое содержание Зарегистрируйтесь на форуме!
Хорошо, мы знаем когда вводить тестировщиков, теперь разберемся с методами тестирования:
• По доступу к коду и архитектуре приложения:
o Метод белого ящика — доступ к коду есть.
o Метод чёрного ящика — доступа к коду нет.
o Метод серого ящика — к части кода доступ есть, к части — нет.
Вы увидели метод белого ящика и сразу задались вопросом, а что, мы будем давать полный код тестировщику? ("Я вот боюсь давать чтоб он ничего не украл")
Так, подождите, не переживайте раньше времени, полный доступ получат не все, а 1 от силы 2 человека т.е получат белый ящик, остальные будут работать по закрытому черному ящику.
Например для полной отладки и анализа проекта сотруднику QA нужно предоставить либо модульно код (блочно) или все же предоставить его полностью.
QC: только закрытый, черный ящик, обычным игрокам серый/белый ящик не нужен. А то накрадут еще себе виртов.
Вообще, по доверию и по работе стоит давать белый ящик. Никогда нельзя просто с лету дать и сказать: вот тебе все карты в руки, чини, смотри, отлаживай.
Это лишь малая часть того что можно рассказать. Если будет интересно то напишу еще пару мануалов или уроков, не знаю как это назвать.
Всем счастья, здоровья, денег, любви.