Little_CJIOH

Изучить программирование?

ну зачем плохому то учите =)

Это не плохое. Это ограниченно применимое решение череватое некоторыми граблями.
Ну и нельзя человека научить тому чему он не хочет учится, а так глядишь, try catch освоит.

Банально же кликаете по первому элементу и ловите эксцепшен. Поймали NoElementException или как он там называется - клацайте по второму.

Интеграционное - это когда вы тестируете взаимодействие 2-х и более компонент.
E2E - это когда вы тестируете всю систему насквозь.

Как квадрат - частный случай прямоугольника, так E2E частный случай интеграционного тестирования. то есть, любой E2E тест интеграционный. Но не любой интеграционный E2E

google - это такая поисковая система, которая легко находит типовые ответы на типовые вопросы.
Коммитить - делать коммит
Мерджить - делать мердж
Новая сборка - сборка с самым свежим временем сборки

Самый популярный джира-тикет
https://jira.atlassi.../JRASERVER-1330

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

ЗЫЖ лично я сначала пишу фактический

7. Этот вопрос очень меня волнует. Я нашел много сайтов с различными методологиями и моделями тестированиями, но практически нигде в них не упоминаются примеры, в каких проектах на практике используются данные модели. Например, я слышал, что Ватерфолл применяют в крупных военных и медицинских проектах. А где могут применяться другие модели?

Есть такой видосик rise and fall of waterfall. И есть такая статья http://www.maxkir.co...uction_RUS.html

8. При изучении тест-планов я часто нахожу термин "направления тестирования". Приведите, пожалуйста, пример.

Приведите пример, мы скажем что имеется ввиду

9. Скажите, я правильно понимаю, что юзер-стори это атрибут современных гибких методологий разработки?

Это артефакт, формализованное описание проблемы пользователя, которую надо решить

10. Входит ли Матрица соответствования требований в тест-дизайн?

Неизвестно. В таком виде это вопрос вида входит ли немыслимая чушь в неведомую хрень.

11. В одном источнике я наткнулся на разделение тестовой документации на внешнюю и внутреннюю. Скажите, какие между ними отличия? Я правильно понимаю, что внутреняя - это та, которая создается и используется только для команды тестирования: тогда как внешняя - это та, которой пользуются также менеджмент и владельцы продукта?

отличие в ответе на вопрос для кого она.

12. В дополнение к пункту 11: скажите, тест.сценарий - это отдельный документ? Я так понимаю, это что-то похожее на тест-план?

Да, может быть.
Примерно как план развития региона похож на маршрутную карту мусоровоза.

13. И последнее. Скажите пожалуйста, как на собеседованиях обычно проверяют уровень английского? Это что-то на подобие знаменитых вопросов в духе "Tell me about yourself", или, например, рассказать про какую-то из техник тест-дизайна на инглише?

Проводят собеседование на английском. Проводят просто беседу на английском. Предлагают пройти тест.

Надеюсь, я задал не слишком много вопросов.

Можете просчитать корреляцию подробности ответов с номером вопроса. Она есть и явная :)
ну и форум отказался принять сообщение с таким количеством цитат

1. Истинное значение терминов "регистрация", "аутентификация" и "авторизация". Если с регистрацией все понятно, то вот с последними двумя терминами все более сложно - т.е. я как бы понимаю значение вообще, но на примере объяснить не могу. Может, вы можете объяснить на примере, скажем, входа на сайт или транзакцию через банк. карту и терминал?

Аутентификация - это процесс подтверждения что именно вы и есть вася пупкин. А авторизация - это набор прав, которые вы, как вася пупкин имеете

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

Если верификация - это проверка, что вы делаете нечто так как нужно, то валидация - это проверка, что вы делаете то что нужно.

3. Парное тестирование (Pairwise testing). При изучении техник тестирования, эта осталась для меня загадкой.

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

4. При изучении уровней тестинга, я часто натыкаюсь на такой момент, что одни авторы включают в уровни операционное и приемочное тестирование (т.е. модульное-интеграционное-системное-операционное-приемочное), а другие - нет. Кто же из них прав?

Каждый уровень тестирования решает свою задачу. Если у вас отсутствует приемка продукта, то вам очевидно не нужно приемочное тестирование.

5. В дополнение к пункту 4: многие источники, раскрывая виды тестирования по объекту, делят их на функциональные и не функциональные, причем одни авторы включают в функциональный тестинг также тестирование безопасности, GUI, и тестинг взаимодействия; в то время как другие авторы не включают эти виды в фунциональный тестинг.

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

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

Вы понимаете неправильно. Это несвязанные фасеты, хотя и может показаться что уж юнит то тестирование обязательно white box. но это иллюзия.

Короче. Если контора не выгоняет сопливящих сотрудников работать из дома или на 100% оплачиваемый больничный - вы с этим ничего не сделаете.
Взывать к людям бесполезно, выходить на больничный невыгодно.

Заводить 100500 задач в джире на каждый баг тоже такой себе вариант.

 

Почему? Она ровно для этого создана.
Вам нужно поставить 100500 задач на исправление разработчикам и потом проверить, что они выполнены. вы либо создаете  список и работаете по ему, либо создаете тикеты и процессите их.

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

Алексей, а почему на два уровня вверх?))

Потому, что именно там сообщение MissLeman

Вы хотите очень правильную вещь, но этот документ должен быть частью ТЗ и мэинтейнится аналитиком.
Попытка содержать своё отдельное описание будет приводить к тому, что оно постоянно будет расходится с действительностью, как и сказал Спок.

Статью не читал специально. Мой ответ - ВСЕ.

Извините, вы overqualified, боимся вам у нас будет скучно.