Testing in Agile: roles merge but don't disappear

-
With "Agile methodologies" currently gaining more and more ground, there's a little bit of anxiety, especially among Software Testers, about "Roles merge" idea. Let me comfort you - roles do merge, but they do not disappear. Let's have a look at this in a little bit more details - first, let's discuss why roles do and should merge in Agile projects, then why they will never disappear.


Why roles merge

An agile team is typically is a cross-functional team having a shared goal (well, at least in theory). For instance, this goal may be to paint a room, prepare a party, write the best ever software or anything else. This means that there will be a situation where one needs to step in and help others do their job.



A very great example of it was a truly agile and cross-functional team of criminals trying to rob a Casino in the movie "Ocean's Eleven". It consists of criminals with various primary skills, but when necessary, one is abandoning his primary skill and doing something he is not specialized in.

Thus nature of any project in a complex and ever-changing environment - you will have to adjust your plan to conform to real life. In software developer terms, when QA specialist struggles with testing some functionality, Development specialist may help or do some other test related work. Similarly, if all developers got flu (shit happens), somebody will have to proceed with implementing the functionality. There's no time to wait, a value should be delivered no matter what, and the team should do it's best to help this happen.

Naturally, team members are widening their skills in adjacent areas becoming more general specialist, merging roles. This also is a great tool of decreasing project "Bus factor"

Why roles don't disappear

Still, one can't be very good at everything. It is hardly possible to be great front-end and back-end developer or be both good at writing and testing software. Each skill requires some time to grow. Skill exercised most will always be better developed than others.

Look at "Ocean's Eleven" again. Each of the team members is particularly good at somethings. In a similar fashion, your team will require somebody particularly good in front-end, database development and testing. Naturally, those who have particularly good skills in something will spend more time on exercising their skill, both because it lets us get value faster and because they just like doing their kind of things more. Roles will never disappear entirely, just be less prominent.

So what should I do?

Well, first of all, identify the primary skill you want to have. Choose whatever you like. Be good at it. Try to be best at it. Second, learn something outside your comfort zone. Make curiosity your habit.

And a small disclaimer - fact, that roles will not disappear doesn't mean demand for all roles will stay the same. It is possible that for particular role demand is going down, so try to have other options (secondary skill may be helpful here).

Comments

Post a Comment

Popular posts from this blog

Test automation framework architecture. Part 2.1 - Layered architecture example

-
Image
Let's consider an example of what Layered (Tiered) architecture may look like for a test automation framework. As a system under test, we're going to use this simple and neat "Todo list" application. First, let's do a brief analysis of the application. From my brief exploration I came up with the following checklist: Area/Group Things to check Comments Todos CRUD 1 Create item Basic scenario, UI-level case 1.1 Create an item with the same name The case is not valid. There's no validation for that - nothing to check really. 1.2 Create an item with an empty/not valid/malicious name While it would be a nice thing to test manually, from test automation standpoint I would expect this to be filtered on service or repository level, so either integration or unit test . 2 Mark item complete Basic scenario, UI-level case 2.1 Un-mark item complete Basic scenario, UI-level case 3 Delete item Basic scenario, UI-level case 3.1 Delete item
Read more

Test automation framework architecture. Part 2 - Layered architecture

-
Image
Probably the most popular architecture pattern used for test automation frameworks (TAF) is layered architecture. This pattern is so well known that on job interviews for some companies when they ask you about TAF architecture you are supposed to describe this one. If you don't - they think you know nothing about the architecture altogether. I suggest you first read a brilliant description of the pattern at the O'Reilly web page , cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution. Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer , business-layer and core layer , but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above). The rough
Read more

Efficient test automation - Secret #1 | Test Club

-
Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more