CVDX

Товарищи QA-специалисты, Здравствуйте!

Нужна помощь тому, кто еще ничего не знает в QA.) То есть мне.

 

Ситуация: в нашей небольшой компании требуется организовать QA, мобильная разработка, делаем казуальные игры для Android и iOS.

 

Вопросы:

1) ааа что мне делать??77

 

1) Как организовать QA в целом

Шаг №1: не соглашаться с фразой "Руководитель QA несет ответственнсть за качество выпускаемого продукта". На вас упадут все чужие шишки, а продукт сольется, а вы виноваты...

Много, написанное в статье, отчасти верно. Но настораживают фразы:

 

"Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!"

 

"Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных" - после этой фразы читать статью закончил ;-)))

 

Я б к такому безапелляционному менеджеру относился, мня-мня , с осторожностью. Кажется, есть нехватка менторского начала и саппортивити. Сорян за иностранщину.

Конспкекты у меня есть конечно)) по ним и готовлюсь)))

 

Вот по поводу этого "не указаны названия и ограничения для двух исходных чисел, не указана формула расчета премии." - Сергей что вы имели в виду? Если можно на простом примере.

 

 

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

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

В вашем же примере текст кейса упомянуты два поля, в которые вы должны ввести два числа и непонятно как и почему получить третье. Это плохой стиль написания тест кейса в реальной жизни. А тем более, в учебном примере. На двоечку.

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

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

Логика ясна? Вопросы, замечания?

 

 

 

И еще мини-вопросик, пишу я скажем тест кейс и допустим я предполагаю, что пользователь ввел неправильное значение в поле или вообще не ввел, соответственно по логике вещей ожидаемый результат должен показать ошибку. Но как мне узнать об этом, должна ли вообще вылетать ошибка или как узнать какое именно сообщение об ошибке должно вылетать (ps: я же не девелопер и не знаю что там закодили)? Или я могу просто логически подумать и написать скажем "ОШИБКА ВВОДА. ВВЕДИТЕ КОРРЕКТНОЕ ЗНАЧЕНИЕ"?

1. Если есть требования, вы узнаете там.

2. Если их нет, узнаете у компетентного в данном вопросе лица (другой тестировщик, программист, бизнес-аналитик, менеджер проекта, заказчик и т.д.)

3. Если их нет, предполагаете по вашему опыту работы с PC, WEB, Mobile приложениями или устройствами и т.д. и т.п. 

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

 

В любом случае (№№3. 4), главное придумать рациональное объяснение, суметь обосновать свое мнение преподавателю или интервью?э?ру, или программисту, или даже заказчику или манагеру проекта.

Интересная позиция — «мне лень читать статью, в которой есть пример, поэтому скопируйте мне оттуда пример».

Только вот такие статьи обычно и пишут по опыту типовых ошибок и чтобы можно было давать отсылку к статье, а не писать 100500 новичкам каждый раз одно и то же.

 

И вопрос был не конкретный, а "дайте пример любого тест-кейса". Это вообще вопрос из серии "мне даже Савина впадлу прочитать, сделайте все за меня", потому что там тоже, внезапно, есть примеры =)

Ну и если человек хочет, не читая теории, сделать магическим образом практику, и ленится гуглить — то тестировщиком ему не стоит становиться, иначе мир окажется слишком жесток. Хотя вам то как раз пофиг на профессию (пока), а что взять со студента, "мне бы лабу сдать и забыть как страшный сон"

 

 

Скажите, пожалуйста, по какой причине вы пишете это мне, а не автору темы 

elshaarawy

? Я-то тут каким боком?

А мне еще к началу января преподу отвечать теорию по тестам, вот это жестко будет ))) Тут хоть практика - поинтереснее))

 

Это подразумевает наличие учебника или конспекта лекций. Что-то из этого у вас есть или некий аналог?

 

ID ТЕСТ КЕЙСА - 46426
ТЕСТ КЕЙС - СЛОЖИТЬ 2 ЧИСЛА
ШАГИ - 1) запустить приложение калькулятор   2) нажать первое поле для ввода   3) ввести цифру 1500   
4) нажать во второе поле для ввода   5) ввести цифру 5000   6) нажать кнопочку "посчитать примию"
Ожидаемый рез-тат - алерт должен показать 6500

 

Ну, на 3 потянет. Вроде все, что надо, есть. Но написано по-русски безграмотно и совсем непрофессионально.

Основной недостаток с профессиональной точки зрения: не указаны названия и ограничения для двух исходных чисел, не указана формула расчета премии.

 

 

2) нажать первое поле для ввода   3) ввести цифру 1500   
4) нажать во второе поле для ввода   5) ввести цифру 5000   6) нажать кнопочку "посчитать примию"

 

Я бы сделал примерно так (единовременная премия без привязки к временному периоду):

2. Кликнуть на поле ввода "Оклад".

3. Ввести величину оклада "40000" в рублях РФ.

4. Кликнуть на поле ввода "Премиальный коэффициент".

5. Ввести величину премиального коэффициента "52" в процентах от оклада.

6. Нажать кнопку "Расчет премии".

 

Ож. рез: Во всплывающем окне должна быть отображена сумма рассчитанной премии (Оклад*Премиальный коэффициент/100) "20800" в рублях РФ.

 

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

 

Ps: За слово "примия" я бы вам двойку влепил моментально. Чудовищное неуважение к родному языку. Ладно, это лирика.

Как я вижу тест кейс. Вот пример.

1. Название тесткейса 2. Шаги 3. Ожидаемый рез-тат. 4. Рез-тат тест - PASS/FAIL (но это поле я так понимаю надо писать только когда физически сам  тест сделаешь. Если просто тест-кейс делаешь без тестирования, то это поле не надо вообще писать)

 

верно

но вы уж наконец напишите нам всем пару примерчиков этих тестов уже! ;-)))

И еще я читаю вот тут на сайте одном про предварительные шаги. Это я так понимаю, например - включить комп, запустить само приложение. Верно? Или это надо писать в пункт 2. Шаги? Ивзините за столько вопросов, я прочитал много уже материалов, просто на разных сайтах по-разному пишут и кому верить.

 

 

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

 

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

Очевидно, что тут и компьютер включен, и интернет есть, и скорость интернет приемлемая. Про это писать в даном контексте нет смысла. Это должно было быть протестировано на предварительном этапе. Или подразумевается как само собой разумеющееся.

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

 

Все просто. Вы, лично вы, являетесь пользователем калькулятора, а не кто-то другой эфемерный непонятный юзверь из сферической вселенной.

Вы решаете, какие функции калькултяора вам нужны. Например, функция 1, 2, 3, 4 и т.д., а еще =, а так же +. а так же -, а так же /, а так же нажатие клавиши Enter

Или только 2, *, =

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

То есть, зная количество тестируемых функций, вы сможете посчитать минимальное количество тестов:

мин. Кол-во позитивных тестов = Кол-во тестируемхы функций.

мин. Кол-во негативных тестов = Кол-во тестируемых функций (есл иконечно равно ;-))

Общее миним. количество тестов = мин. Кол-во позитивных тестов + мин. Кол-во негативных тестов.

Про большее количество тестов попробуете догадаться сами?

Вообще по правилам, нужно писать все возможные варианты? Ну например, как вы написали - деление 4 на 2, деление 3 на 4, деление 1 на 3 и все варианнты? Или достаточно написать скажем 4 делить на 2, 6 делить на 3 и больше для деления хватит?

 

 

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

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

То есть, 4/2=2

3/4=0.75

1/3=0.3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333

И т.д.

Уф, проще записать так: 0.3(3). Или 0.(3)?

 

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

Главное тут - почувствовать разницу между тестами или данными для теста. Если вы способны это понять, значит вы сможете протестировать программу более полно.

Есть такое важное понятие как класс эквивалентности. На примере деления все тесты (или данные) 4/2, 9/3, 10/5 обладают одним общим свойством - результат деления это целое число (кстати, делитель и делимое тоже целые). Поэтому для такой проверки можно описать один тест кейс или использовать лишь одну единицу данных джля теста.

Так же и 3/4=0.75; 1/4=0.25; В результате деления целых чисел трехзначная дробь.

 А вот 2.96/8=0.37 это другой класс эквивалентности, потому что мы делим нецелое число на целое. А получаем тоже трезначную дробь.

Если у вас мало времени, стоит сделать лишь одну проверку 2.96/8=0.37, а 3/4=0.75; 1/4=0.25 не делать, потому что первая проверка некий надкласс над двумя следующими.

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

То есть смысл тест кейса это найти все возможные варианты, которые может сделать юзер, верно?

 

 

Нет. Задача (смысл) тест кейса в том, чтобы описать один тест.

Если вы хотите описать все возможные варианты (если это физически выполнимо), тогда вам надо написать целый набор тест кейсов. 

Для одного теста может быть использована 1 единица данных или несколько разных данных для тестирования одной операции (деление 4 на 2, деление 3 на 4, деление 1 на 3, деление на ноль и т.д. и т.п.).

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

Это вы сами решаете, как оптимально сосотавить набор тестов и охватить наиболее важные проверки и результаты.

Деление на ноль, умножение на -1, сложение отриц чисел это исключительные ситуации (edge cases), которые тестировать надо, но это не основные проверки.

 

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

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

 

 

Ps: дааа, было время в ВУЗе, мог только по чужому примеру или методичке передрать свой вариант, а теперь, как и все, предложил бы сначала самому подумать. А тогда смог бы? ;-) Кстати, мы вот в подростковом клубе ведем занятия. Один из приемов - предварительный (развед.) опрос с целью выяснить начальный уровень знаний и навыков кадет.

 

 

Вы, кстати, на кого и где учитесь? В колледже информатика что ли?

 

 

http://www.protestin...g/testcase.html

Готовлюсь к собеседованию и вот в списке вопросов есть такой: Как представляете себе процесс «правильный» QA? У кого-то есть мысли по поводу того, что конкретно тут имеется в виду?

 

 

Привет, Ольга. Очевидно, вы начинаете свою деятельность в тестировании ПО. Значит, вам следует понимать, что опытный специалист на собеседовании это знает быстро осознает.

Поэтому, хотелось бы сразу дать совет: будьте честны с собой и с другими, не пытайтесь представить из себя то, что вы не представляете.

На мой взгляд, в вашем положении нужно внимательно почитать, уметь рассказать (а еще лучше, усвоить да понять) вот об этом, указав источники информации:

 

1. https://ru.wikipedia...ечение_качества

 

2. https://ru.wikipedia...ого_обеспечения

 

3. http://en.wikipedia....ality_assurance

Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality

SQA encompasses the entire software development process, which includes processes such as requirements definition, software design, coding, source code control,code reviews, software configuration management, testing, release management.

 

 

 

4. http://www.quizful.n...iew/qa/qa-vs-qc

 

Говоря другими словами, Quality Assurance гарантирует, что процесс поставлен правильно и дает предсказуемый результат, в то время как Quality Control гарантирует, что продукт удовлетворяет указанному набору требований.

 

 

ИМХО:

  - Процесс обеспечения качества (QA) организуется руководителем (менеджером) проекта вместе с руководителем разработки и руководителем тестирования.

  - Процесс контроля качества (QC) организуется руководителем тестирования.

  - Тестировщики (разработчики и исполнители тестов и пр.) непосредственно обеспечивают контроль качества.

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

 

 

 

Ps:

  - Самое главное: вы должны усвоить, заучить, уверовать в то, что тестировщики не отвечают за качество продукта (ПО). За качество продукта отвечает менеджмент проекта и/или разработчики (кодеры/девелоперы/программисты).

  - Если потенциальный работодатель заявляет, что QA это ответственность тестеров, уходите (если можете :-) )!

Кем Канер вам в помощь (на него можно и нужно ссылаться): "Quality flows from the top, not from QA". Под qa имеется в виду группа тестирования. Цитата со страницы 347 книги "Testing Computer Software", Cem Kaner, Jack Falk, Hung Quoc Nguyen, 1999, ISBN 0-471-35846-0

Или нужно проверять еще какие нибудь произвольные значения? Или еще что либо?

Я бы проверил крайние значения, которые противоречат друг другу. Например, рост 178, размер одежды 40, размер обуви 38.
Это негативный тест.

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

Какое-то решение этого задания есть тут:
http://www.protestin...n_practice.html

Вероятно, тот, кто дал такое задание, не поленился почитать этот источник. Поэтому стоит не плагиатом заниматься, а разобраться и добавить свои идеи по образу и подобию.

Тест-кейс №1:
1)Тип обращения - Консультация
2)Контактное лицо - Иванов Иван Иваныч
3)Контактный телефон - +790800000000
...

Тест-кейс №2:
1)Тип обращения - Проведение тестирования
2)Контактное лицо - Иван I
3)Контактный телефон: 312-22-000

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

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

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