Псевдогуру

Вы не пишете на нескольких языках программирования, вы на них какаете засранцы 

Ты тестировщик ты должен уметь всё

Уже после создания опроса понял, что название темы дает двойственное понимание. Посему решил, что опишу оба варианта:
1. Совмещение позиции QA специалиста с какими то другими обязанностями
2. Необходимость большой базы знаний для качественного тестирования ПО

Итак, поехали по 1-му пункту:
Совмещение обязанностей, наверное, бесит абсолютно всех QA-специалистов(QAS). Если вы кроме тестирования занимаетесь программированием или администрированием сети, либо круче этого, вы - офис менеджер, то бросьте вы эту затею. Профессия тестировщика одна из тех, которым не пойдет «в плюс» совмещение позиций. Ведь вы профессионально тестируете софт, т.е. вы имеете деструктивное мышление, это вам не поможет не в обслуживании сети или офиса, а при разработке ПО будет всячески мешать, хоть и в некоторых случаях и помогать тоже.
При всем этом я вполне допускаю вариант тестировщика:

1. Выясняющего и пишущего постановку бизнес требований
2. Внедряющего ПО
3. В роли похожей на «Product owner» в Scrum
4. IT-консультанта

Почему?

1. Я уже много раз писал, что еще в начале проекта на этапе сбора требований нужно подключать QAS. А при должном опыте работы общения с заказчиками, такая задача вполне по плечу тестировщику. Если не верите, то у меня и Ромы был личный опыт.
2. Об этом я тоже давно пишу, что тестировщик лучше всех знает как установить и использовать софт. Не редкие случаи, когда тестировщик знает работу всего продукта лучше любого из разработчиков. Это объясняется тем, что QAS обычно работает со всем функционалом сразу. Кроме этого сборку и установку ПО каждый нормальный тестировщик обязан автоматизировать и в этом случае у него при внедрении все карты на руках :)
   
3. Этот пункт, что-то вытекающее из 1-го пункта, в довесок просто плотное общение с заказчиком
4. В принципе этот пункт я оставил напоследок, поскольку все скорее будет зависеть от самого человека, нежели от профессии, но я бы подчеркнул, что для QAS это не противоречивая должность

При этом нужно понимать, что тестирование программного обеспечения для компании является очень дорогим удовольствием. Содержать целую QA команду, не всегда является оптимальным по стоимости решением. Поэтому некую проверку продукта(релиза, проекта и т.д.) выполняют разные специалисты, еще чаще сами программисты.

Теперь по 2-му пункту:
База знаний QAS немногим уступает, а в идеале и вовсе должна быть больше базы разработчика. Кроме фундаментальных типов тестирования и инструментария к нему, тестировщик должен знать бизнес логику, архитектуру и наиболее рискованные участки софта. Знание всего вышеперечисленного уже является не малым багажом знаний.
Почему же я написал, что в идеале QAS должен знать больше самого разработчика? Я уже писал здесь, о том, какие знания разработчика должен иметь тестировщик и чем он должен владеть для меня в идеале.
Я понимаю, что в больших командах тестирования специалисты в большей мере узко специализированы и мое видение может показаться неправильным и не фундаментальным. Но я пока не имел опыта работы в действительно огромной команде тестирования и являюсь приверженцем, того что QAS должен быть универсально подкован во всех видах и типах тестирования.
Наверное, хватит! Извините за небольшой сумбур в описании. Получился 1 из примеров когда хотелось рассказать многое но не клеилось. Комментарии опять же приветствуются.

P.S. Обратно создал опрос на следующую интересующую тему. Выбирайте, срок почти тот же - 10 дней.

О необходимости знаний в программировании для QA

В каком то из постов я уже касался такой темы, что для меня лично, идеальный QA это прежде всего тот, кто указывает на ошибки, еще посмотрев на изменения в коде. При этом я не исключаю ни ручного, ни еще какого либо тестирования. Как показывает всеобщая практика 70-80% багов находятся в процессе именно ручного тестирования. Все должно быть в совокупности.Теперь начнем рассуждать по делу с самого начала... Все так или иначе столкнулись или столкнуться с тем временем, когда нужно набирать людей в свой QA отдел. Лично я приверженец того, что если человек решил заняться тестированием ПО "серьезно", то ему естественно нужен некий базис. В моем понимании базиса, QA должен иметь как минимум IT образование, причем я имею в виду не только высшее образование, это может быть и просто опыт работы без всякого "диплома". Скажу честно, что человека без IT прошлого на роль QA, я не стану даже рассматривать. Я знаю, что есть множество примеров, когда люди без "образования" тестировали продукты лучше специалистов. Но на этот факт надо смотреть по другому: ведь QA не занимается постоянным ручным тестированием в надежде найти ошибку, кроме этого он должен писать автоматизированные тесты, понимать хотя бы архитектурную суть софта и многое другое. А вот брать и учить даже этому, человека совсем не просвещенному в этих вопросах я не хочу и не буду. Мне жалко и свое время и свои нервы.Пойдем дальше. Автоматизированные тесты как бы к ним не относились... это тоже программный код, который в любом случае будет иметь свою логику и архитектуру. При этом написанные тесты придется усиленно поддерживать. Еще на данном этапе будут необходимы хотя бы минимальные знания программирования. Еще дальше. Всем опытным QA когда то приходилось тестировать задачи которые очень тяжело воспроизвести. В таких случаях тоже могут понадобиться те самые знания программирования. Т.е. смотрим в исходный код и смотрим где что могло вывалиться или сработать не корректно. Теперь о том, что было еще в начале. К примеру у меня уже давно стало привычкой еще до начала тестирования смотреть в изменения в коде для того, чтобы понять что, как и где изменилось и на что это может повлиять. Мой опыт показывает, что это как минимум не мешает общему процессу тестирования. Описал не все свои доводы, но постарался написать хотя бы общие.

О читабельности кода

Недавно стал задумываться о том, какого хрена молодые разработчики (особенно студенты) сильно не гадуют почему нужно переменные, методы, классы, интерфейсы и т.д. и т.п. называть нормальными именами( как их принято называть жаваподобными именами). Каждый раз называют любимыми x, y, i и т.д. В чем заключается собственно барьер?
Школа. Проблема на мой взгляд кроется даже не в увиневере, а в школе. Итак вспоминаем школу урок математики. Приводится какая то задача и там же как было принято какие то неизвестные величины, тобишь переменные всегда называются x и y. Далее идет огромное дерево решений с использованием этих имен. При этом это является нормальным для всех, читабельным решением.
Универ. Такая же фигня после этого наблюдается и в универе когда препод говорит мол называем прибыль x, себестоимость a, цена b. И давайте мол решение автоматизируем и напишем x = b - a; и все счастливы. А на первый вопрос как во всем этом разобраться советует писать комментарии. Вот и настает полная фигня и бардак в коде. А это извините меня 10 лет в школе(грубо говоря) и 5 лет(в универе) впихивание таковой культуры.
Естественно на первые грабли такие товарищи наступают очень быстро, при первом же коммите ну или чуть позже, если конечно человек устроился на работу в команде)). По правде я когда то видел целые группы разработчиков у которых x и y-ки забиты в проекте и сопровождаются не менее большими комментариями. Это уже полный ахтунг.
Помню случай когда студенты спорили друг с другом на то, кто пишет труднее и в чьем коде трудней разобраться и это на самом деле для них являлось просто офигительным решением. Смешно конечно, но это было на самом деле.
Лекарство. Самый лучший пример по извлечению таких вредных привычек у такого товарища наверное просто заставить переписать его собственный код под новую логику. Там и выходят все отрицательные стороны его подхода и человек начинает понимать собственные ошибки. Если не понимает, то писец... Лучше сменить порфессию, либо работать одному.
P.S. Мысль возникла после того, как увидел автоматически сгенеренный скрипт от TestComplete(кто видел, тот наверное поймет). Такое впечатление что его писали именно такие товарищи о которых
писалось выше...
Хотелось бы подчеркнуть что тоном хорошего кода является не только название переменных конечно, но как то это зацепило так что не судите строго:)