Доброго времени суток:)
В рамках подготовки к собеседованию и вдохновившись картинкой «Как тестировать карандаш» решил нарисовать свою, только дело пойдет о чашке.
Есть у кого какие замечания по доработке или исправлению?:)
вполне прилично. Только исследуемый предмет тогда уж не чашка, а чашка с блюдцем. И добавить: хорошо ли стоит блюдце на чашке (для чая как функция заваривания), как чашка размещается на блюдце в перевернутом состоянии, удобно ли пить жидкость из чашки (достаточен ли диаметр каемки)...
Сколько интересных вопросов можно задать на собеседование. А тут все про чашки и карандаши.
Самый адекватный ответ. ИМХО
А: Дайте мне документации к этой чашки:)
Б: Документации нет.
А: А чем у вас занимаются аналитики?
Б: А у нас их нет. У нас все мастера (программеры) делают.
А: Но на основании чего-то они это делали? Есть какие-то требования?
Б: Да.
А: А можете мне их предоставить?!
Б: Но про это знает Вася, но он очень занят...
А: А от меня чего хотите? Чашку вам протестировать?!
Б: Да.
А: Тоесть вы заказчик? Хорошо. А чего вы ожидаете от этой чашки?!
И т.д и т.п.
На такие вопросы, надо задавать вопросы.
А не сразу описывать, как вы будете тестировать чашку или что-то еще .
Это покажет, что вы думающий человек, который понимает процессы. А не «лопата», которая копает от забора до обеда.
И что вы хотите понять, что именно вы будете тестировать и зачем. Представте что вместо чашки, вам сказали описать как вы будете тестировать синхрофазотрон.
Надеюсь намёк понятен:))
А уже позвали на собеседование? )
Учите теорию. То что Вы нарисовали дает ясное понимание того что у Вас проблемы с теорией.
Тестовая документация так не оформляется. Если у Вас спросят про карандаш на собеседовании, то они явно ждут не этого ))
Ктонить пояснит мне смысл данных оторванных от софта и жизни заданий ?
Абстрактне мислення.
Софт різний буває, те що тестувальник тестував веб, а тепер зможе тестувати мобайл/десктоп і т.д. — не факт. Часто, дальше свого болота людина не може вийти. Зустрічав таке
А вміння в любому об’єкті побачити суб’єкт тестування і провести над ним всі необхідні дії в правильному порядку, гарантують те, що в кандидата не виникатиме проблем при виборі стратегії, отриманні пріорітетів від замовника, документуванню роботи і т.д. не залежно від потреб на проекті та напрямку софта, який розробляється/буде розроблятися.
Головне не обмежуватися заїзженими олівцями/чашками і тд, стратегії по тестуванню яких описані 100500 разів, і зазубрені джунами/мідлами на пам’ять. Можна генерувати чимало інших об’єктів з повсякденного користування.
Абстрактне мислення.Сколько люков на заправках для автобусов с шариками в Лос-Анджелесе?
Софт різний буває, те що тестувальник тестував веб, а тепер зможе тестувати мобайл/десктоп і т.д. — не факт.Так спросите: А если вам надо будет протестировать мобайл?
А вміння в любому об’єкті побачити суб’єкт тестування і провести над ним всі необхідні дії в правильному порядкуСубъект тестирования — это собственно тестировщик.
Стоит привязаться к тестовой документации. Хотя бы попробовать.
По нагенерированному:
— не раздражает ли цвет — это как раз юзабилити при чем критерий нечеткий «раздражать» — кого-то раздражает белый текст на черном фоне консоли, а кого-то зеленый, а кого-то — черный на белом и т. д.
— не облазят ли надписи/рисунки после кипятка — а кто сказал что у нас чашка для горячих напитков? Это тоже не UI, а HW при чем в сторону sustainability/reliability/stress etc. testing.
Что не возьми — сложно поддается тестированию. Построено на субъективизме слишком. В стресс-тестинг лучше бы посудомоечную машину заложили (с указанным диапазоном температур воды/вохдуха и продолжительности, характеристик воды, характеристик материала, которые будут взаимодействовать с чашкой).
Нагрузочное тестирование для чашки — это не налить много воды. Это организовать корпоратив с поеданием тортиков на N людей (N не из головы берем, а из спецификации) и вот этой одной чашкой.
Надо идти и много читать. Или на проект кофе варить — тестировщики в кофе поинте направят...
Вы у Портнова учились? Сочувствую. У вас буквально семь функциональных тестов. Больше ничего не придумывается?
Вот как программист тестировал карандаш habrahabr.ru/post/193902
Питання до Вашого опису негативного тестування: Наскільки я розумію, негативне тестування це тестування, при якому перевіряються різні випадки неправильної роботи користувача з продуктом. У Вашому випадку ніяких критичних ситуацій не описано.Налити рідину різної температури — що у тут неправильного? Цілком хороший приклад positive testing. І чому у третьому тесті Ви написали «вдарити не сильно»? Треба спробувати її розбити!=) Буде прекрасний приклад negative testing=) і взагалі я б на Вашому місці придумала якісь більш оригінальні приклади негативного тестування. А взагалі, хороша у Вас ілюстрація. Схожа на «Тестирование карандаша» Михаила Портнова. Успіху Вам!
Наскільки я розумію, негативне тестування це тестування, при якому перевіряються різні випадки неправильної роботи користувача з продуктом.Невірно розумієте.
Що означає
неправильної роботи користувача з продуктом.?
В стилі вашого формулювання, це скоріше «різні випадки поведінки програмного забезпечення при введені користувачем невірних/невалідних даних»
Maxim Ermakov
Андрей Сазонов
Taras Voloshenko
Grez
Oleg Antonov
Bogdan Shyiak
Сергей Свистунов
Viktor Kryvyziuk
Елена Дрон
Mariana Kotsko
11 комментариев
Добавить комментарий Подписаться на комментарииОтписаться от комментариев