Monday, June 04, 2018

Is Code the Future of Test

Where I work there is increasing focus on test automation. Recent hiring around the quality assurance area has focused on those who can create and maintain automated tests.

Test automation is about source code. So at least some programming skill and experience is now basically a requirement to be hired into QA. Of course there is still a requirement to be able to do more classic manual testing. That is, going to the website, desktop, or mobile app, executing various flows in person, observing and verifying the result is correct and the user experience is smooth. The way forward seems to be dual-hat in QA. Comfortable both in manual testing and test automation.

This tends to blur a distinction between manual and automated testing. It's all testing. The trend in my observation seems toward eliminate the separate test automation teams, the 3 teams doctrine (dev team, manual test team, test automation team).

It also tends to blur a distinction between developer and tester. Going forward it may become that QA/test automation is generally the entry level position out of tech school. From there, the individual will have the opportunity to demonstrate an ability to write clean, maintainable code that works as part of test automation. That person could if interested be offered an opportunity to switch from QA to development.

So I'd see a scenario something like this where dual-hat QA is capable both in manual testing and test automation. While manually testing a screen on the website, a tester notices a problem. The tester files a bug report in the usual way, reporting steps to reproduce, expected result, actual result, screen shots, logs, etc. While the bug goes into the development team, the tester then creates an automated test to demonstrate the defect on the website. The automated test is reviewed and checked into the repo. A couple days later the development team marks the bug as fixed and ready to verify.

The tester goes back to the screen on the website with the latest build. The defect is observed to now be fixed. The automated test case runs automatically. The automated test switches from red to green, confirming that the issue is now fixed. The defect is closed. The automated test remains in the repo and runs in the overnight regression test run to help ensure the defect does not accidentally reappear in the website.

What of the classic manual tester?
I think the traditional non-coding manual testers will be around for some time. There's plenty of work in that area. They are not yet an endangered species. Not every company has fully embraced dual-hat QA. Anyone who has a job manual testing is probably pretty safe.

Perhaps it will start to be felt in mobility if you lose your job or seek to switch jobs. For example where I work it seems all new QA hiring now requires coding and test automation ability. So by that definition any manual testers here might have a harder time getting hired by today's standards, even though they are good at their jobs and make important contributions to successful product releases. So I suspect QA hiring across tech will increasingly require the ability to fire up Eclipse, Visual Studio, whatever IDE, understand code, and write code.

To the existing manual tester there are some paths forward. Be really good at manual testing. Consider reinvent as a business analyst, product manager, project manager, or into management. Also if possible fire up the tools and learn/relearn to code and embrace test automation.

What is the future of Development?
I think that will also evolve. It's worth its own post. I should think about it some more and may come up with something.

Friday, May 04, 2018

2 Years of C# and .net

Hey, it's been a while. This site is still active. I just don't seem to have much to write about. I still work in software. January 2017 marked 20 years doing this work. It's a pretty good career all in all. The pay and benefits are good.

Back in late 2015 I switched jobs and joined my current employer. It's pretty good here, and it has been a positive change. After RIM ended abruptly in 2014, my previous employer gave me a job when I was out of work in the summer of 2014. I appreciate them for that. It was what I expected and I don't have anything bad to say.

When I joined my current job the initial plan was around factoring out a piece of a large monolithic Java application so that it could be called from a .net client. As things turned out I pretty quickly ended up working on the .net side. There has been a smattering of Java here and there since then but primarily I've been working in .net and C# for a little over two years now.

I'd never done anything in C#, .net, or Visual Studio before. I'd heard some good things about .net but it was new to me. So at this point I have about 4,000 hours in on the Microsoft stack. It does make a difference being at it this long. Still learning and still not quite mastered. 6,000 hours to go I suppose. Though working with it for several thousand hours does make a big difference in proficiency and speed.

The .net stack including ReSharper is really quite good. Really well thought through, powerful, and easy to build applications with. Coming over from years in Java, the whole developer experience from C# to Visual Studio, to the .net libraries, it has been a very positive experience. C# is an excellent programming language. Powerful and well thought through. And LINQ is just incredible, and built right into the language, the intellisense.

Java and Eclipse is a great developer experience too I will add. I'm not going to declare a winner, both approaches are very well done and developer friendly.

I've done a lot of Web stuff with the .net implementation of MVC. And the Microsoft take on MVC with Razor is an excellent implementation. Everything is just there and just works the way you would expect. Microsoft really has worked hard on this and done a great job. I'd never really understood MVC before and now I've seen it done right it is a great approach to the Web. It was a great decision to have MVC right out of the box as a first class Microsoft module, it was very wise differentiator for Microsoft to own the MVC, instead of leaving it to the whims of third party vendors or open source for better or for worse.

Also I've worked more with the SQL Server database the last two years. Mostly Oracle over the years before coming where I am now. I've gained a lot of respect for MSSQL and SQL Server Management Studio. I didn't know much about MSSQL, but I will say it's a great database and does a number of things very well.