Мой природный способ «врубания» в тему происходит через осмысление — это такая познавательная процедура, которая подразумевает постижение действительности более с помощью мышления, нежели эксперимента. И хотя одно другому не противоречит, это уточение важно.
Я же не столько думаю, сколько обдумываю и додумываю. Это очень медленный процесс с неочевидным результатом.
Иногда полезно.
Иногда впустую.
Некоторые делают это эффективно (книги Эдварда де Боно могут помочь), бо мышление — навык, который нужно тренировать.
Некоторые делают это быстро и безо всяких книг, бо природа.
Некоторые вообще не понимают, о чём речь.
Да?!
Блог появился как способ осмысления темы тестирования ПО. Каждая статья — как обобщение какой-то идеи. Или явления. Или что там ещё есть…
В воскресенье (24 мая) аналогичное мероприятие провели Radio QA — здесь тоже планируется серия видео-трансляций в экспериментальном формате.
QA VADIS — КУА ИДЁШЬ — Пилотный выпуск с Алексеем Алёшиным (Middle QA) — HD
Но… мне от всего этого бермуторно, скептично и мизантропно. В чём польза таких «собеседований» в прямом/кривом эфире?
На курсах для начинающих этих самых начинающих, кагбэ, натаскивают на прохождение собеседований (это называется «оказать информационную помощь в трудоустройстве», ага) и на курсы народ ходит именно ради этой помощи, а не для «хочу на протяжении трёх месяцев разобраться с тестированием». И это логично.
Надо заранее обучиться этикету и манерам, которые будут ОЧЕНЬ НУЖНЫ, когда чопорный шофёр-порученец вручит вам приглашение на бранч в саду королевы английской великой Британии завтра в файв-о-клок, сэр, но, кагбэ… сперва надо получить это приглашение (на собеседование).
А их не зовут.
Тот, кто сумеет эту проблему решить дёшево и эффективно — будет торт среди тортов. Но сейчас простого решения нет.
«Стариканы» талдычат о том, что а вот мы просто начинали читать, а вот мы просто ходили на все собеседования сразу, и так набирали жопыт; а вот мы в наше время были счастливы только от того, что смогли найти справочник по мнемокодам Intel 8080 любую шнягу, которую сегодня просто поди и скачай с торрентов, делов-то; вы просто делайте то же самое… И это очень правильный совет, и это очень правильное поведение, и читать сегодня можно бесконечно.
А их не зовут. И уже искрит по проводам.
Поэтому селяне с радостью подбрасывают в небо чепчики своих селянок, встречая новых миссионеров, которые обещают успокоить страждущих и вразумить запутавшихся и направить заблудших по какой-то едино верной дороге… взамен на… всего-то ничего, потом же будет рай земной, айфончик, обеспеченное будуйющее… go к нам, брат, ты чо такой хилый, давай поднимем твои скиллы, мы научим, без балды, никакой теории, только практика, иди, иди, иди к нам, шаг за шагом.
Я тупею. Возраст и Фэйсбук берут своё. Внешне это ещё не заметно, но внутри чувствуется как болезнь.
Пик её пришёлся на 2014-ый, когда было тревожно жить и было важно знать, где прямо сейчас в Киеве опасно, чтобы знать и принимать соответствующие решения. Лента новостей была оооогромной, вперемешку свидетельства, новости, слухи, мнения. Не сразу, но почувствовал эффект «рекомендуемого контента».
А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?
Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.
Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?
Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.
Ну, и чо?
Когда я только выполнял чужие кейсы, это всё было ненужным и абстрактным лайном.
Когда я сам проектировал тесты, да ещё и для какой-то финансовой аппликухи — приходилось знать/понимать точно, какие тесты покрывают прописанные требования (верификационные), а какие тесты покрывают НЕпрописанные требования (валидационные) и соответственно их разделять по разным сборникам тестов. И это всё стало осязаемым и важным.
Ну, как книга. Современные преподаватели сделали для своих студентов 1-го курса видеолекции. Если собрать тексты всех этих выпусков в один массив = кагбэ, да, книга. И оформлена по-современному — её можно читать только в браузере, текст перемежается с видео. Формат противоречив и работает только в определённых условиях.
— (голосом пионера) Приглашаем всех на «Анонс_final», ежегодную конференцию для анонимных анонсистов и финалистов и всех-всех-всех, которых интересует качественный процесс анонса и финализации! Спешите скорее, билеты уже в продаже!
— ПАГАДИТИ! Это же «Selenium Camp», ежегодная конференцию для разработчиков и QA и всех тех, кого интересует качественный процесс разработки и тестирования, которая успешно состоится 21-22 февраля 2020 в Киеве! Что за анонсисты? Какие финализаторы… Спешите скорее, билеты уже в продаже!
— (по телефону из Кишинёва) Да это файл с пресс-релизом так назвали, «Анонс_final». Никто не виноват. Спешите скорее, билеты уже в продаже!
инфраструктура автоматизации тестирования (когда, где и как проводить тесты);
машинное обучение и автоматизация тестирования (предложения, чат-боты, модели);
метрика и мониторинг;
управление тестовыми данными и генерация;
качество кода в автоматизации тестирования (реальные истории);
hardware / роботы / IoT (experience reports).
— ПАГАДИТИ! А где это пройдёт-то?
— Дык, в пресс-релизе не было написано…
— (по телефону из Кишинёва) Да там же, где и всегда: Киев, ул. Вадима Гетьмана, 6, Mercure Congress Hall.
Формат:
2 дня практических докладов от отечественных и иностранных спикеров,
3 параллельных потока,
BOF сессии, где освещаются самые актуальные давно известные темы и вопросы,
Виски-фуршет для неформального общения со всеми теми спикерами и участниками конференции, которые предпочитают коньяк,
40% скидка на билет для тех, кто только переходит от ручного до автоматизированного тестирования (то есть, для начинающих.)
И да, нумерованный список был выбран нарочно 🙂
Среди спикеров обнаружены:
Simon Steward (Selenium Project, UK), Marcus R Merrell (Sauce Labs, USA), Elias Nogueira (Waes, Netherlands), Николай Алименков (XP Injection, Украина), Андрей Солнцев (Codeborne, Estonia), Иван Крутов (Aerokube, Россия), Сергей Пирогов (EPAM, Украина).
Одна из редких конференций, на которые надо поскорее поспешить, бо билеты уже в продаже! Do you feel it?!
Любомир Геревич не знает, кто дядя Боб. Так вот, это один из тех семнадцати чуваков, которые собрались в феврале 2001-го в Snowbird ski resort в Юте для того, чтобы потрындеть о том, как можно было бы обустроить жизнь программистскую.
На этом фото Роберт Мартин третий слева.
К тому времени уже оформилось несколько устойчивых и обоснованных мнений о том, что и как надо было бы делать, чтобы было «правильно», поэтому необходимость в общем словаре уже назрела.
Дальнейшее уже легенда, эпос и сказания, дважды пересказанные и триста раз перевранные. Время вернуться к источникам. И вся книга именно об этом. Продолжить чтение »
На форуме неравнодушных к равнодушию кто-то смелый попросил(а) оценить тест-кейсы первого отжима для гуглопереводчика Google с английского языка на русский.
Откуда-то глухо доносится «Fuck the police comin’ straight from the underground»…
Опиумная кальянная мадам Козятиной.
“We know English! Visa accepted! 24h!”
На кушетке, присосавшись к кальянной трубке, возлежит Менеджер проектов без галстука. В недрах стоящего рядом мягкого кресла утонул пофигистичный к мирскому его коллега, бухгалтер.
Легкая задымленность и маниакальный блеск в глазах говорящего:
— …их стало слишком много! Каждую неделю кто-то спрашивает у меня лично, а получится ли у него стать тестировщиком. Каждый мнит себя уникальным, каждый считает себя подготовленным просто потому, что у него есть «ОГРОМНОЕ ЖЕЛАНИЕ», но он ещё ничего не делал, ничего не пробовал, ни одной книги не прочитал, а если разговор зайдёт про книги, то меня спрашивают, какую конкретно книгу надо прочитать…!
— Дык, скажи им, какую книгу прочитать-то, — из глубин кресла. — у нас даже бухгалтера знают ваши книги. Как их там… Савин, Фолкнер и Нгуен?!
чтобы люди объединились в сообщество, нужны следующие элементы:
Общие враги. Наличие врагов — отличный способ сплотить сообщество. Для «Гринпис» это правило легковыполнимо, но есть ли враг у вас?
Общие цели. Спасение чилийских шахтеров — достойный повод к объединению. Дайте людям почувствовать вовлечённость.
Защита от нападения. Насилие не обязательно. Даже словесная критика может быть расценена как нападение. Вы никогда не видели спортивных фанатов (меломанов, политических сторонников) сплотившихся, чтобы защитить себя от нападения?
Страх. Существует разница между реальным нападением и наличием угрозы. Страх — доказанный способ объединить людей. Иногда страх бывает и позитивный, но чаще это негатив. Позитивно можно использовать страх неудачи, страх позволить другим совершить ошибку. Страх быть обыгранным конкурентом и т.д. …
Разделение на своих и чужих. При наличии чёткого разграничения на своих и чужих люди объединяются плотнее. Пять лондонцев, которые никогда не заговорят друг с другом дома, в лондонской подземке, будут намного общительнее в пекинском метро.
Великие достижения. Достижение чего-то замечательного отлично объединяет группу, особенно если все ощущают себя частью целого. Избрание своего кандидата. Освещение в прессе. Достижение важной вехи. Общие достижения придают людям гордости.
Общий опыт. Один из самых сильных связывающих элементов. Люди охотнее объединяются, если прошли через что-то хорошее или плохое вместе. Участие в мероприятиях, совместная поездка, любой совместный опыт делает людей ближе.
Если в вашем сообществе есть хоть часть этих связующих элементов — можете не беспокоиться.
При сборке pdf в каталоге проекта появляется ряд служебных файлов, содержимое которых меняется от билда к билду. Их даже нет смысла засылать в репозиторий.
Можно сказать Kile, что после закрытия надо удалять все «временные файлы». Но закрывать Kile каждый раз перед тем, как сделать коммит — как-то странно.
Можно добавить все такие файлы в .gitignore Но эти файлы так и лежат в каталоге проекта.
А можно компилировать проект, принудительно создавая всякие такие файлы в отдельном каталоге.
В наше время считается нормой учиться тестированию и при этом НЕ учиться программированию. Но ведь тестирование само по себе не имеет смысла — это подчинённый процесс, придуманный программистами для программирования.
Все «старые» книги про тестирование написаны программистами, которые объясняют тестирование программистам. Майерс, Бейзер, Вайнберг, Йоргенсен — не так уж много их, но что дошло до наших дней, то если не блестит, то поблёскивает.
The main ability of a tester is to have no fear for discuss requirements and asking for
whole picture first,
details.
The main behaviour of a tester is do not rush with any conclusions about software and to always start with
Stop! Explain this software, even if it looks understandable. What are the purposes of this software? Why this functionality is needed? How it should work?
Stop! I need a time for think (analyze this).
Stop! What are the final expectations?
The basic skill of a tester is to imagine (and to write them as scenarios) a chain of situations
where the software is intended to work ‘as expected’ (correct user login),
those that may happen, and should be tolerated by software (wrong user login),
those that should not be tolerated, even if they are possible (wrong data encoding).
Test It Quickly 
А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?
Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.
Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?
Если пример непонятный — нет, ты не идиот, просто давным-давно, в другом мире…
Глава первая, вступательная в зыбкое болото терминов
Верификация — проверка соответствия приложения прописанным требованиям.
Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.
Ну, и чо?
Когда я только выполнял чужие кейсы, это всё было ненужным и абстрактным лайном.
Когда я сам проектировал тесты, да ещё и для какой-то финансовой аппликухи — приходилось знать/понимать точно, какие тесты покрывают прописанные требования (верификационные), а какие тесты покрывают НЕпрописанные требования (валидационные) и соответственно их разделять по разным сборникам тестов. И это всё стало осязаемым и важным.
Продолжить чтение »