Коллеги, всем привет!! На связи TEST IT! 
И сегодня с Вами снова я, сменная ведущая Киселева Ольга. Конечно, наша рубрика ушла в отпуск на какое-то время, но надо же когда-то отдыхать, правда?
И вот, мы решили вернуться! Сегодня у нас вопрос из группы в ВК
Попробую ответить на него, хотя не совсем понимаю слово "методики". В тестировании вообще мало устоявшихся выражений и такое словосочетание я почти не встречаю.
Но если мы оглянемся немного назад, на свою учебу в ВУЗ-е, то поймем, что методика - это фактически тест-план, а что мы будем делать, чтобы что-то протестировать, какие виды тестирования применять, какие дополнительные инструменты итд.
Ну чтож, если вопрос идет о своей работе, то я и расскажу немного о конкретном примере.
У разработчиков есть любимый принцип "Тесты проходят? Значит, все хорошо!". Поэтому, когда где-то внезапно всплывает баг, "нету теста = нет проблем". Его надо локализовать (что делают вообще все тестировщики), а потом пойти в тот модуль, который сломался и написать автотест. Или проверить уже существующие, есть среди них такой или нет. Как только наш тест сломался - можно идти к разработчикам.
Часто такие ситуации встречаются на других работах? Я думаю, не очень
Именно по этому, увы и ах, "серебрянной пули" нет. То, что использую в своей работе я, далеко не факт, что пригодится кому-то еще.
Да и вообще, можно назвать это методикой тестирования? Наверное, нет. Это скорее постфактум. Если багу нашел - сделай то-то и то-то.
Если брать конкретную задачу, то тоже - смотря какая задача.
Если надо сделать новую фичу, то анализируем требования, используя методогию (?) под названием тестирование документации. Далее используем классы эквивалентности, граничные значения, диаграмму состояний и переходов, все, что угодно, для того, чтобы написать тест-кейсы, которые будут проверять данную фичу. Потом мы пишем автотесты на них. Ну и когда фича сделана, проверяем, что:
а) автотесты не падают;
б) функциональность работает (смотрим вручную);
А если задача - провести регрессию? Включаем мозг
Прикидываем, что надо проверить ручками, что не покрыто тестами и проверяем. Смотрим на задачи из релиза и прикидываем, как они могли повлиять на те модули, которые напрямую не затрагивают. И проверяем. А еще протыкиваем пользовательский интерфейс, вдруг что-то отвалилось?
Честно говоря, не совсем понятна подоплека вопроса. Вопрос от новичка, который никогда не занимался тестированием и не знает что учить? Учи тест-дизайн, всегда пригодится!
Вопрос от человека, который занимает только ручным тестированием и всегда по одному и тому же сценарию? Хочется посмотреть, как это делают другие и что-то исправить у себя? А надо ли что-то менять? Никогда не стоит вносить изменения просто потому, что так делают в другом месте.
Если хотите что-то улучшать, то должна быть четкая цель. Или хотя бы понимание, а что не нравится в конкретном процессе. И если единственное, что не нравится - это скука, то надо искать не новые техники, а новый взгляд на уже существующие практики. Покопать в сторону геймификации и вдохнуть новую жизнь в уже существующий процесс.
А если интересует, как решать конкретную задачу, потому что мыслей вообще нет - то уточните, что это вообще за задача. Потому что для разных задачек - разный подход.
За сим откланиваюсь. До встречи, ребята!
Мы ждем ваших писем - пишите на sprosi.testera@gmail.com, задавайте вопросы, рассказывайте истории, грустные и не очень, делитесь опытом - мы рады всем!
Пока, увидимся через неделю (надеюсь)!
И сегодня с Вами снова я, сменная ведущая Киселева Ольга. Конечно, наша рубрика ушла в отпуск на какое-то время, но надо же когда-то отдыхать, правда?
И вот, мы решили вернуться! Сегодня у нас вопрос из группы в ВК
Кто нибудь может поделиться или рассказать, какие методики тестирования вы используете в своей работе? как вы выбираете методику тестирования для своей конкретной задачи?!
Попробую ответить на него, хотя не совсем понимаю слово "методики". В тестировании вообще мало устоявшихся выражений и такое словосочетание я почти не встречаю.
Но если мы оглянемся немного назад, на свою учебу в ВУЗ-е, то поймем, что методика - это фактически тест-план, а что мы будем делать, чтобы что-то протестировать, какие виды тестирования применять, какие дополнительные инструменты итд.
Ну чтож, если вопрос идет о своей работе, то я и расскажу немного о конкретном примере.
У разработчиков есть любимый принцип "Тесты проходят? Значит, все хорошо!". Поэтому, когда где-то внезапно всплывает баг, "нету теста = нет проблем". Его надо локализовать (что делают вообще все тестировщики), а потом пойти в тот модуль, который сломался и написать автотест. Или проверить уже существующие, есть среди них такой или нет. Как только наш тест сломался - можно идти к разработчикам.
Часто такие ситуации встречаются на других работах? Я думаю, не очень
Именно по этому, увы и ах, "серебрянной пули" нет. То, что использую в своей работе я, далеко не факт, что пригодится кому-то еще.
Да и вообще, можно назвать это методикой тестирования? Наверное, нет. Это скорее постфактум. Если багу нашел - сделай то-то и то-то.
Если брать конкретную задачу, то тоже - смотря какая задача.
Если надо сделать новую фичу, то анализируем требования, используя методогию (?) под названием тестирование документации. Далее используем классы эквивалентности, граничные значения, диаграмму состояний и переходов, все, что угодно, для того, чтобы написать тест-кейсы, которые будут проверять данную фичу. Потом мы пишем автотесты на них. Ну и когда фича сделана, проверяем, что:
а) автотесты не падают;
б) функциональность работает (смотрим вручную);
А если задача - провести регрессию? Включаем мозг
Прикидываем, что надо проверить ручками, что не покрыто тестами и проверяем. Смотрим на задачи из релиза и прикидываем, как они могли повлиять на те модули, которые напрямую не затрагивают. И проверяем. А еще протыкиваем пользовательский интерфейс, вдруг что-то отвалилось?
Честно говоря, не совсем понятна подоплека вопроса. Вопрос от новичка, который никогда не занимался тестированием и не знает что учить? Учи тест-дизайн, всегда пригодится!
Вопрос от человека, который занимает только ручным тестированием и всегда по одному и тому же сценарию? Хочется посмотреть, как это делают другие и что-то исправить у себя? А надо ли что-то менять? Никогда не стоит вносить изменения просто потому, что так делают в другом месте.
Если хотите что-то улучшать, то должна быть четкая цель. Или хотя бы понимание, а что не нравится в конкретном процессе. И если единственное, что не нравится - это скука, то надо искать не новые техники, а новый взгляд на уже существующие практики. Покопать в сторону геймификации и вдохнуть новую жизнь в уже существующий процесс.
А если интересует, как решать конкретную задачу, потому что мыслей вообще нет - то уточните, что это вообще за задача. Потому что для разных задачек - разный подход.
За сим откланиваюсь. До встречи, ребята!
Мы ждем ваших писем - пишите на sprosi.testera@gmail.com, задавайте вопросы, рассказывайте истории, грустные и не очень, делитесь опытом - мы рады всем!
Пока, увидимся через неделю (надеюсь)!
Комментариев нет:
Отправить комментарий