Есть желание понять, каким образом можно внедрить систему тестирования в процесс выпуска ПО.
На текущее время это выглядит примерно так:
— реализуется продукт;
— пишется методика испытаний продукта;
— проводятся испытания, по результатам которых ПО отправляется в "архив".
Разработка методики, сопутствующих документов и проведение испытаний может выполняться дольше, чем разработка ПО.
По любому изменению ПО последние 2 пункта повторяются.
В самом ПО по сути ничего "космического" нет, да и проверки обычно ничего толком не проверяют, все делается в угоду ГОСТам и прочей лабуде.
Писать тесты к ПО можно самостоятельно, лично для себя, обеспечения качества продукта и избавления себя от хаоса в дальнейшем развитии проекта.
Но — было бы здорово эти тесты подвести под испытания. Проблема — испытания проводит некий человек по методике и следит за реакцией ПО, проверяет скриншоты и прочее — все действия ручные. Тесты же могут выполняться вообще молча, выдав в результате банальное "ок". Получается, что никто не понимает, что же мы там эдакого натестировали и действительно ли все "ок".
Есть ли какие практики использования тестирования в таких случаях?
Основная проблема — в ручном тестировании человек все видит и может поручиться за то, что ПО действительно работает в рамках, описанных методикой.
При автоматическом тестировании же происходит "магия".
В BDD тесты являются сценариями использования программы с проверкой состояния, так что результатом там будет не ОК, а как раз все сценарии и проверенные состояния, примерно выглядит так
Здравствуйте, avpavlov, Вы писали:
A>В BDD тесты являются сценариями использования программы с проверкой состояния, так что результатом там будет не ОК, а как раз все сценарии и проверенные состояния, примерно выглядит так
Для проверяющего это будет то же самое "ок" в виде кучи текста.
Кто проверит, что тесты написаны должным образом и действительно что-то проверяют, а не просто генерируют текстовые отчеты?
В настоящее время для проведения испытаний проверяющему достаточно уметь читать и быть внимательным.
В случае же использования тестов кто-то должен взять на себя ответственность за их качество, полноту и достаточность, что они действительно гарантируют появление на выходе продукта, который удовлетворяет требованиям к тем же тестам. Какие есть практики? Программист пишет ПО, QA занимаются его ковырянием и поиском багов. А кто в итоге отвечает за тесты?
Здравствуйте, lexer_lx, Вы писали:
_>Кто проверит, что тесты написаны должным образом и действительно что-то проверяют, а не просто генерируют текстовые отчеты?
Вы какую проблему хотите решить? Свою или проверяющего?
Если свою, то не нужно пытаться подстроиться под бюрократию. Даже если получится, гемороя будет в разы больше. Не говоря уже о том, что объяснить зачем это им нужно будет тот еще челенж (по опыту знаю). Делайте то, что принесет пользу вам и вашей команде.
Если чужую, то ответьте себе на такой вопрос: "а это действительно для них проблема?".
Здравствуйте, Vlad_SP, Вы писали:
V_S>а зачем вообще решать чужую проблему?
Есть такая потребность у людей.
Сам от нее страдаю. В последнее время значительно меньше.
Здравствуйте, Aikin, Вы писали:
V_S>>а зачем вообще решать чужую проблему? A>Есть такая потребность у людей.
Кстати, не было бы такой потребности -- не существовало бы форумов.
Здравствуйте, lexer_lx,
_> Тесты же могут выполняться вообще молча, выдав в результате банальное "ок". Получается, что никто не понимает, что же мы там эдакого натестировали и действительно ли все "ок". _>Есть ли какие практики использования тестирования в таких случаях? _>Основная проблема — в ручном тестировании человек все видит и может поручиться за то, что ПО действительно работает в рамках, описанных методикой. _>При автоматическом тестировании же происходит "магия".
Дык, эта.... А что мешает в ПиМИ отписать методику тестирования вашего ПО с помощью автоматических тестов?
Написать нечто типа "Проверка на соответствие пункту XXX ТУ проводится с помощью тестовой программы YYY.exe версии ... сборки ... контрольная сумма ... следующим образом:
[тут описание методики проверки автоматическим тестом]
Результат проверки считается удовлетворительным, если ... [тут описать положительный исход теста — например, вывод тестовой программы YYY.exe содержит текстовую строку "OK", ну или что там требуется?]"
А этот самый некий человек выполняет тестирование и интерпретацию результатов строго по ПиМИ.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Дык, эта.... А что мешает в ПиМИ отписать методику тестирования вашего ПО с помощью автоматических тестов?
V_S>Написать нечто типа "Проверка на соответствие пункту XXX ТУ проводится с помощью тестовой программы YYY.exe версии ... сборки ... контрольная сумма ... следующим образом: V_S>[тут описание методики проверки автоматическим тестом] V_S>Результат проверки считается удовлетворительным, если ... [тут описать положительный исход теста — например, вывод тестовой программы YYY.exe содержит текстовую строку "OK", ну или что там требуется?]"
V_S>А этот самый некий человек выполняет тестирование и интерпретацию результатов строго по ПиМИ.
Тогда нужно будет проводить испытания тестов — что они действительно тестируют. Писать методику, и так далее.
ха, так это ключевой вопрос: что они действительно тестируют?
И если опираться на первоначальное сообщение: _> да и проверки обычно ничего толком не проверяют, все делается в угоду ГОСТам и прочей лабуде.
то и получается, что разруха отнюдь не в клозетах... Нет?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Написать нечто типа "Проверка на соответствие пункту XXX ТУ проводится с помощью тестовой программы YYY.exe версии ... сборки ... контрольная сумма ... следующим образом: V_S>[тут описание методики проверки автоматическим тестом] V_S>Результат проверки считается удовлетворительным, если ... [тут описать положительный исход теста — например, вывод тестовой программы YYY.exe содержит текстовую строку "OK", ну или что там требуется?]"
Без согласования никто эту строчку не добавит. Т.е. это все не отменяет вопроса
В случае же использования тестов кто-то должен взять на себя ответственность за их качество, полноту и достаточность, что они действительно гарантируют появление на выходе продукта, который удовлетворяет требованиям к тем же тестам
На данный момент ответственность берет "некий человек", который прогоняет тесты "по методике и следит за реакцией ПО".
Хотя мысль, согласен, правильная. Нужно включать такую строчку к документы. Вопрос как? У меня такого опыта нет совсем. Vlad_SP, может что подскажешь?
Хмм... Ну-с, что касается "ответственности за их качество, полноту и достаточность", то это сфера ответственности QA специалиста в команде, а в более широком смысле — PM-а. А базироваться эта "полнота и достаточность" должна, разумеется, на требованиях к ПО. (Да чего я тебе-то это объясняю?... Твоих-то постов я почитал достаточно...) Разумеется, код самих автоматических тестов должен разрабатывать программист, но вот методику испытаний, наборы входных и выходных (эталонных) данных должен разрабатывать QA спец и/или бизнес-аналитик.
Согласовать ПиМИ с Заказчиком, по моему опыту, ни разу не проблема. Заказчик успешно согласует ПиМИ даже с упоминанием автоматических средств, при условии, что эти средства действительно тестируют то и так, как это Заказчику нужно. Другое дело, что в том, что тестируется то и так, как нужно, должны быть уверены и QA и аналитик и PM, а вот это упирается в полноту и достоверность требований.... А вот с этим проблемы наблюдаются, увы, регулярно....
Здравствуйте, Vlad_SP, Вы писали:
V_S>Хмм... Ну-с, что касается "ответственности за их качество, полноту и достаточность", то это сфера ответственности QA специалиста в команде, а в более широком смысле — PM-а. А базироваться эта "полнота и достаточность" должна, разумеется, на требованиях к ПО. (Да чего я тебе-то это объясняю?... Твоих-то постов я почитал достаточно...) Разумеется, код самих автоматических тестов должен разрабатывать программист, но вот методику испытаний, наборы входных и выходных (эталонных) данных должен разрабатывать QA спец и/или бизнес-аналитик.
Да, теорию я знаю. Примерно представляю как это делается на практике. В нашей, постсоветской приктике. Так вот, мне кажется, проще и дешевле посадить человека на приемочное тестирование, чем утверждать автоматизированное.
Люди, которые утверждают и подписывают план тестирования разбираются в бизнесс процессах, поэтому понимают, с большего, что написано в плане. А вот в IT они разбираются слабо и "протолкнуть" им автотесты, ИМХО, будет сложно. Это чисто мои чувства. Опыта в этой области у меня нет.
V_S>Согласовать ПиМИ с Заказчиком, по моему опыту, ни разу не проблема. Заказчик успешно согласует ПиМИ даже с упоминанием автоматических средств, при условии, что эти средства действительно тестируют то и так, как это Заказчику нужно. Другое дело, что в том, что тестируется то и так, как нужно, должны быть уверены и QA и аналитик и PM, а вот это упирается в полноту и достоверность требований.... А вот с этим проблемы наблюдаются, увы, регулярно....
У меня другой опыт. Заказчик успешно согласует любую фигню, лишь бы она выглядела значительно. Полнота и достоверность его мало интересует.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Хмм... Ну-с, что касается "ответственности за их качество, полноту и достаточность", то это сфера ответственности QA специалиста в команде, а в более широком смысле — PM-а. А базироваться эта "полнота и достаточность" должна, разумеется, на требованиях к ПО. (Да чего я тебе-то это объясняю?... Твоих-то постов я почитал достаточно...) Разумеется, код самих автоматических тестов должен разрабатывать программист, но вот методику испытаний, наборы входных и выходных (эталонных) данных должен разрабатывать QA спец и/или бизнес-аналитик.
V_S>Согласовать ПиМИ с Заказчиком, по моему опыту, ни разу не проблема. Заказчик успешно согласует ПиМИ даже с упоминанием автоматических средств, при условии, что эти средства действительно тестируют то и так, как это Заказчику нужно. Другое дело, что в том, что тестируется то и так, как нужно, должны быть уверены и QA и аналитик и PM, а вот это упирается в полноту и достоверность требований.... А вот с этим проблемы наблюдаются, увы, регулярно....
Ключевое слово здесь:
"Если чужую, то ответьте себе на такой вопрос: "а это действительно для них проблема?"."
Постсоветская практика =) QA нет, PM нет, человек, принимающий решения на верховном уровне ПО воспринимает на уровне Фортрана.
Упростить для себя процесс вряд-ли удастся.
По крайней мере я вынес для себя, что понимание процесса тестирования, его пользы и необходимости, гарантии качества продукта должно быть у людей, стоящих у руля.
А пока будем проверять, что чекбоксы квадратные, а баттоны прямоугольные. Проблем то ведь нет. И потихоньку внедрять тесты самостоятельно =)
Насколько я понял, это ответ мне.
_>Ключевое слово здесь: _> "Если чужую, то ответьте себе на такой вопрос: "а это действительно для них проблема?"."
_>По крайней мере я вынес для себя, что понимание процесса тестирования, его пользы и необходимости, гарантии качества продукта должно быть у людей, стоящих у руля.
Не обязательно. "Польза и необходимость" для "людей, стоящих у руля" может ничего не иметь общего с качеством продукта. Например, есть смысл в выпуске "практически безбажного" приложения и зарабатывания денег на правке багов и сапорте. Сравните с написанием идеального приложения без багов за короткий срок. Доход в первом случае существенно выше. И таких вариантов куча.
_>А пока будем проверять, что чекбоксы квадратные, а баттоны прямоугольные. Проблем то ведь нет.
Проблемы
_>И потихоньку внедрять тесты самостоятельно =)
Только если эти тесты будут помогать конкретно ВАМ.
Тут, кстати, можно себе ответить на такой вопрос: а вы сами заинтересованы, чтобы приложение получилось качественное (не много багов), поддерживаемое (изменения в логике или правка бага не требует месяцы времени) и за относительно короткий срок. Ведь есть своя выгода в сидении на знакомом проекте, в котором ты все знаешь и можешь фиксить баги даже левой ногой.
Хотя, я могу предугадать ответ. Раз появились мысли по улучшению и вы задали вопрос на форуме, то вам не все равно и вы хотите что-то изменить. Удачи вам! Это дело не из простых, но именно так мы чему-то учимся!
Здравствуйте, lexer_lx, Вы писали:
_>Здравствуйте, Vlad_SP, Вы писали: V_S>>А этот самый некий человек выполняет тестирование и интерпретацию результатов строго по ПиМИ. _>Тогда нужно будет проводить испытания тестов — что они действительно тестируют. Писать методику, и так далее.
Для этого тоже существуют практики:
1) Код-ревью автотестов
2) Перекрестные проверки в тестах
3) Мутационное тестирование, при котором вы целенаправленно вносите правки в тестируемую систему и проверяете, что тесты это отлавливают
4) Дополнительные метрики оценки покрытия системы
ты знаешь, it depends. Как показывает мой опыт, автоматизированное тестирование оправдывается в двух случаях (как минимум, т.е. список вряд ли исчерпывающий):
а) серийный выпуск,
б) испытания софта на очень больших объемах данных, когда ручная обработка результатов испытаний становится сильно трудоемкой.
Нетрудно заметить, что и в том, и в другом случае автоматизированное тестирование приходит на смену большому объему ручного труда. Ну и плюс исключаются ошибки "человеческого фактора" (типа тестер в конце рабочего дня тупо забыл протестировать по какому-нибудь пункту ПиМИ...)
Здравствуйте, Aikin, Вы писали:
A>Хотя, я могу предугадать ответ. Раз появились мысли по улучшению и вы задали вопрос на форуме, то вам не все равно и вы хотите что-то изменить. Удачи вам! Это дело не из простых, но именно так мы чему-то учимся!
Шлялся в новогодние праздники по форуму, нашел свое старое сообщение, отпишусь о результатах, может для статистики сгодятся.
А результаты таковы: ушел в другую контору, с удовольствием там работаю и наряду с кодингом пишу всевозможные виды тестов, чего и всем желаю.
С Новым Годом!
