почему …QA? что эта аббревиатура означает?
гугл говорит что QA это Quality assurance, но судя из содержания вебинаров мы изучаем тестирование.
QA - это и есть Quality Assurance. Вообще, Вы правы: строго говоря, тестирование правильнее называть Quality Control (QC), т.к. целью тестирования является только исследование уровня качества. А Quality Assurance, это гораздо более обширная область: это весь комплекс мер, направленных на обеспечение качества.
Тем не менее, исторически сложилось, и, за последние лет десять наверное, окончательно прижилось, что QA = тестирование.
2 лайка
Тестирование - это тестирование.
QA - это QA.
Это 2 разных мира. Разница только в объекте: тестирование это из области обнаружения ошибок в коде. Для этого надо иметь код.
Для QA мы отвечаем на вопрос: “Давай посмотрим на процесс разработки ПО и подумаем как сделать его лучше”
Ваш КО =)
3 лайка
Ой, яростно, отчаянно плюсуюсь!
Мне иногда даже стыдно, когда люди исключительно test-minded называют себя QA и дискредитируют эту аббревиатуру.
Недавно одну девушку, которая уже 4 месяца тестирует некое приложение, недавно вышедшее в релиз, спросили: “А для чего, собственно, это приложение? Кто его использует?” Ответ был совершенно замечательный: “Честно говоря, я была так сфокусирована на функциональном тестировании, что у меня не было времени почитать business requirements document, так что я не знаю”!
То есть человек знает как должны создаваться новые записи, сортироваться списки, сохраняться данные и т.п. и это и проверяет. Но как используют это приложение люди, для чего оно им, какие юз кейсы возможны и где, соответственно, могут быть узкие места и что может отсутствовать в тест плане - она не знает.
1 лайк
Требования возможны?
Так, вроде, везде написано что use case - это вариант использования.
Это популярный, но не единственный, формат, в котором задаются бизнес-требования. Он, конечно, основан на взаимодействии пользователя и системы.
Но, между моментом написания use case и моментом тестирования программного продукта лежат этап дизайна и кодирования. Для тестера в этом процессе требования, на основе которых создана тестируемая система, не могут быть возможными. Они 100% определены (изменения вносятся потом в рабочем порядке, конечно) до начала дизайна и кодирования.
1 лайк
PRD там как такового не было, только отдельные user stories на кокретный функционал. А business requirements document, где и описывалось как раз для кого создается приложение, с какой целью, высокоуровневые требования и т.п. у нее почитать времени не было, о чем она честно сообщила. Уж больно длинный! 
Я вообще крайне редко встречаю подробные требования в виде единого документа, даже дискутировали когда-то на этот счет с вице-президентов по продакт менеджменту, который возмущался, что их хотят заставить их писать, а “PRD - это прошлый век, даже в Palm мы сдались и перестали”. Но это отдельная, больная для тестера тема…
Наверное не в одном десятке компаний довелось поработать:flo:
С 7 разными продакт-менеджерами работала на разных проектах so far + с коллегами из разных компаний и hiring managers доводится общаться 
Тот же Palm, Yahoo, Google, Facebook, Cisco - из крупных. Не один десяток наберется, да. Практически все: “Требования?.. Ну что вы, хорошо если хоть коротенькая user story!.. И скриншоты.” Причем многие, говорят, пытались начинать как правильно, создавали PRD, но по ходу развития проекта просто забрасывали его обновление.
Российский опыт я, понятно, в расчет даже не беру, думала в Штатах в этом смысле дело лучше обстоит. Но либо я опоздала лет на десять, а agile и scrum не дают возможность людям тратить достаточное количество времени на обновление подробной документации, либо выборка у меня такая нерепрезентативная.