sophe's comments

The market is bad. Since getting laid off in March, I've applied to 185 jobs. I'm a director, 25 years, and I can only work remotely.

What's new this time around is: + Nobody at target companies will respond to questions (via email or linkedin) + At least 50% of application forms require desired salary (seriously who does this for a director or VP role?); I've dropped my limit by 50k + Radio silence from companies. most never even send a rejection. Very few applications get to screenings. + For some openings, I write some test code up front top demonstrate my interest, and still no bites.

I suspect that TA teams are getting blown up by the traffic, but... for leadership roles, I would expect more careful handling.

The hardest part is planning what you are going to write; that is, identifying the most important of the possible things to test. The writing itself should be fairly straightforward.

Can't stand those "starers". Always looking.

The worst kind of tech debt is test debt: the huge body of unidentified and undiscussed tests that never get considered. On an "agile" team where there are no test specialists, and the emphasis is on CI/CD with fully automated tests, those tests are confirmational: these tests verify that the code works as expected, and they have to run fast. If you have an SDET, then their work is most likely focused on tooling to improve the efficiency of the dev team, and not to exploring and learning about the applications to drive quality. This is delivering "working code" with eyes closed and fingers crossed, and this test debt hangs like the Sword of Damocles above your company's customers.

The role of test specialists is to try and make the unknown unknowns a little less unknown. If you have decided that it's finally time to hire a test specialist, then you have that huge test debt PLUS immediate pressure to focus on new features.

I've been working in software in San Francisco since 2001: i wear shorts and a collared shirt every day. I never have to interact with clients, though. I wear long pants when I interview for new jobs ;)

The class of tool you are looking for is a Test Case Management tool (TCM). The basic model of a TCM is a db for holding atomic test cases. Most TCMs let you collect test cases into "test runs", which is a set of test cases to be executed in a context. Test runs can typically be organized into some kind of project bucket (e.g., "drop 11" or "release foo").

TCMs usually support tagging of test cases, so you could for example tag some test cases as "smoke test" and collect them into a smoke test run.

TCMs usually support the manual execution of test cases: the tester works from a "test run" and sets status of that test cases instance to pass/fail/etc. Depending on the state of your test automation, you can also do the same status setting for an automated "test run". Some TCMs support the automatic updating of a test case instance via APIs triggered by integration with test frameworks.

Some TCMs support integrations with bug trackers, for example with Jira. This means you could create a virtuous circle of automated test execution, test run status updating, and bug creation for failed tests, depending on the maturity of your test automation infrastructure and your TCM and bug tracker tool choices.

My current preference is for Testrail (http://www.gurock.com/testrail/) over TestLink.

But here's the deal: a TCM is a far better tool than Word or Excel in tracking test cases or test execution, but TCMs come with gotchas. Any QA or test effort is a dynamic process that should evolve over time. It's easy to put way too much emphasis on the TCM as the goal of your test work, but it's just a tool that supports a process. Don't use a TCM as your strategic test planning tool, because it's a software product written by external teams according to their own crazy software development realities and definitions of process and quality. Figure out what you need to focus on, what your workflow should be, and use a TCM as a tool that helps you right now, and drop it if you find yourself changing your work patterns to suit the tool.

Location: San Francisco, CA

Remote: OK

Willing to relocate: no

Technologies: python, UIs, APIs, DBs, test automation tools

Résumé/CV: https://www.linkedin.com/in/dereksisson/

Email: [email protected]

I'm an experienced technical quality assurance manager and test automation architect: I manage teams, define test strategy, build test frameworks, write code daily.

See if your 4-year college offers continuing education classes: you don't typically need to go through an acceptance process to get into those classes. After a couple of semesters, see about matriculating over to the undergrad program. The process for applying as an existing student is different than for incoming freshman. This is how I got into college in 1986.

Armor by John Steakley