Learning to code - just learning

I'm reading Cem Kaner's book on Domain testing. Having skimmed though a lot of it, I started again and got stuck with ideas from start of intro.

"Testing is a cognitively complex activity. Developing competence with cognitively complex skills requires mastery of routine tasks and formation of schemas (cognitive maps) that can guide you as you do tasks that require more conscious effort (van Merrienboer, 1997)"

I've dedicated much of my adult life to building these skills and building networks that help me develop these skills. Right now, on my summer vacation I'm putting 20 hours a week for four weeks to a course that teaches one out of hundreds testing techniques - thinking tools. I absolutely love the BBST Domain testing course so far.

Testing is cognitively complex activity. So is coding. But they are different cognitive activities. When I do things, I want to be good - excellent even. With all the effort that learning testing takes, where to find time that coding takes?

The question on my part is really rhetorical. I was forced to take coding classes as part of my MSc studies for computer science. I could do them, but I never felt the urge to do it again or do more of it. Looking back, I wasn't into the things we were supposed to implement and I never felt the same overwhelming feeling of success in a brain-engaged activity that I get with testing, again and again. Recently, I've been giving coding a second chance and with the control of choices learned in testing, it's definitely more fun. But I still don't get the feeling of success that would drive me to depths that testing has.

Creating an algorithm that handles things smartly is somewhat of a boost. But I do that for testing too, to build ideas of what's possible and expectable. I just skip implementing and debugging the idea if I test. I love thinking about the problem and solution, but I lose interest snd have to force myself to complete the details on different layers of logic - the routine tasks of coding. It comforts me a little that I learn while doing, that I see ugly code that just cries to be refactored. That I get reminded that coding is just as much exploration as testing. But it still doesn't give me the feeling that THIS I want, this feeling is totally worth all the effort. It does for some, and I respect their love of code highly. I just feel different.

A lot of the cognitive load on learning coding is like the stuff we now do on the domain testing course. Learning routine ways of doing things that repeat, to free our minds to the non-routine aspects of our work. I notice my routine with coding is off, I need to rely on guides (intellisense) to come up with syntax and I google like crazy to decide what library would already have something useful for my purpose. I don't remember since with choices of time, my practice of coding just isn't on the level I'd like it to be.

With all this, I find the 'testers should code' 'why would a tester not learn to code' a generally upsetting theme. Why should I want to be a mediocre coder when I can be a brilliant tester? Or why should I give up my aims of excellence in testing to learn coding to a level I consider professional?

On my team, most developers suck at testing. I know from a personal experience that the 'can't break own stuff' is mostly just an excuse to avoid work they don't love. As I ask developers to test more, I offer to implement more. Neither gets the things that would make us fully happy, for supposingly greater good.

I just keep wondering if this trend is really smart at all. Let testers learn coding but let them also be non-coders. This direction of emphasis would lead to driving away more good testers. You don't know what you're missing since those who think this is a smart move never paid attention to what the 'business people' do. It's not coding, so it's probably 'less valuable' - as one of my developers put it.

Coding is great. Testing is great. Finding idea-solution-product-market fit and buy-in is great. We need respect for diversity and collaboration more than super-individuals that have these all.

Let my colleagues in test not learn code in peace. Like James Bach said in twitter: not everyone wants kids. Choices and preferences should ne respected, not continuously feeling attacked. If coding is in demand, who should learn and change: those filling the demand (testers who code) or those (mis)identifying the demand (recruiting managers)?

Surely recruiting managers can go ahead and recruit for skills they need. But it just might be that emphasizing one they lose out on what they really need. But since they don't have it, they might not realize to miss it.

Continuous delivery without test automation, first experiences

It's been a few months since I managed to get my favorite team at work talked away from Scrum and story points into a Kanban-like continuous delivery of an item at a time. There's a long way to go, but first two months are a good point of looking back at some of the things that happened.

Giving up on size estimates

The driver behind the change for us was the frustration with size estimates: story points and hours alike. We observed that the size did not really matter for us, and the ritual of sizing things up was draining our energy. In particular, if there were surprises, things to be learned while doing, we easily ended up with unproductive discussions of how the thing was understood when sized up and how it is understood now as 'requirements changed'. If the team understood the problem, solving it was design. If they did not, solving it was requirements. The externalizing was unhealthy and unproductive.

I kind of like the change in discussions this caused. Instead of sizes we talk of when could I help with testing it and where, and if we can split it into two (or more) deliveries that would already bring value to the end users. Not very good at that yet, but we had not done any of that before the change.

Releasing regularly

In an earlier post, I wrote about the feeling of ease with making releases as they are done continuously. It's a routine, not a hassle. While our continuous delivery does not (yet) rely on test automation, we're not as fast as we could be in making a feature release-ready, but we are capable of analyzing our changes  one by one, thinking of likely side effects and testing manually. And isolating a feature at a time makes it much simpler to understand what caused problems. I really loved last Thursday, when the build completely broke with two lines change that was the only thing in the build we were working on towards the release. We jumped right in to solve the surprises that none of us could foresee.

The two months also taught us about releasing regularly through trial and error. As Git and team talking to each other about what we do was new, we had at one point two significant changes put into our integration branch around the same time and as both had a lot to fix (and test again and again) we managed to block our feature release pipeline for a month, making one "traditional" release, very much like the ones we did before. Single piece in the pipeline bottleneck at a time is great, and it also drives us to think about ways of collaborating to make the bottleneck smaller.

Testing in this all

In testing of this style, there's been ups and downs. When we refactored a major area without automated tests and with time of a developer who had not originally created the feature, testing was somewhat painful as functionalities went missing: the code just had not given out a hint of such an intent being embedded in the old version. I relied a lot on my memory, tested areas I knew like I've never seen them before and digged through a lot of old Jira issues mentioning piece here and there. The specification existed, but was useless on the level of detail that was relevant this time. It was also painful to test the same connected features again and again and again, as a change would easily have impacts elsewhere. It was clear that the model / design of the features wasn't clear, but got clearer.

The good part with this was that some of the lessons learned ended up in automated unit tests. But still not enough. And it drove my focus again towards extending our test automation capabilities together with the team.

While you can do continuous delivery without test automation, you might not enjoy it was a lesson worth experiencing for me.

Back to usual

In the last two weeks, we've been doing releases 2-3 times a week. It's nice and routine again. The developing and testing isn't routine, but making the release is - just as it should be. Releasing more often has also revealed some issues in production that we can honestly say that we would not have thought of to test manually / automate. Fixing them has been quick and routine, and the general build quality in releases has not lead anyone to question the idea of releasing more often. I hope we stay that way.

Single-piece flow will still take us a lot of effort, but some nice agreements on how we organize towards that have already been made. I look forward to starting our pair programming trials in autumn, and working out ways to move from working solo on a task to working as team on a value item. The potential is there, while road will most likely be long and winding. 

A story of a big small bug

This week, after a day at conference and a day home with a sick kid, I got back at the office to test. As I opened Jira and got reminded of recent fixes, I chose an area that I found relevant to start from. The changes were quite extensive as the developer had spent several days puzzled with them. 

I opened the application and clicked though the shortest possible sunny day scenario and the application froze. I could't believe it, so I restarted and it was true. I felt upset. I felt disappointed. I felt that with all the efforts to improve on team responsibility, it just gets worse. I was thinking that perhaps the best way to help my team mates feel responsible would be just to remove me as the safety net - except that did not work either. So I talked with the devs to let them know it doesn't work and blocks me, logged it on Jira and steamed out the worst of frustration in a tweet. 

Then I tested some more, to learn that the first feature I was testing was just a tip of the iceberg. Out of the features I tried, there was one that worked and many that didn't. I realized the problem wasn't with the changes to area I was testing at first, but with common dialog component. As we're a tight team, I realized the issue would belong to another developer, the one with the faulty change. So I reassigned the jira issue. 

At this point, I was even more upset. There was a problem making our application freeze on all actions but the one the change was done for. Not only had the developer making the change skipped testing any other places when changing our dialog component, but he had done the change paired up with another who did the same. And none of the six had used the app in over two days to notice. 

Soon after, there was a quick and dirty fix - by the words of the developer. The final fix would take a little longer. But I was told they're both small fixes, and wouldn't need much testing after. A little later I also learned that a developer had seen the problem, but forgot to mention it to others. At least there was hope, as the whole team wasn't completely hands off the application. Mistakes happen. 

This incident reminded me again about the difference in how I think as a tester and how developers think. When I see a problem, I look into its severity and implications to users. When developers see the  same problem, they look at how interesting or complicated it is to fix. And size of symptoms may be completely unrelated with the size of the fix. 

With the discussions on smallness of the fix, I was left feeling unappreciated. It was a small fix, small effort for the developer. But it wasted a day of my time. How about including my time in sizing up the implications in the team? It would have kept small if there was at least a bit of own testing by the developer before the feature showed up in the common build. Or after. But before it blocked all of my other testing. 

Also, the fix wasn't small to me as I was going through all features in the program for other surprising impacts. While knowing the fix it was unlikely, it was still a possibility. Again some hours of work the developers refuse to take ownership of as it shouldn't have an impact. 

So, negotiating on more test automation ahead. Even if the developers dislike maintaining it. 

Agile Finland in a year - my individual view

Agile Finland non-profit had the annual meeting yesterday. From a personal perspective, I feel there's again an inspiring twist that could not quite be foreseen, just like last year. Last year the twist was that I showed up and volunteered at the meeting, just moments before the executive committee selection. That works great to get a lot of votes. This year I had been driving the formation of the new executive committee, people could have expected I volunteer to be the chairman and that I would at least be available as executive committee member. It turned out I was not. With the active recruiting of new executive committee members being so successful, we had more people than could fit in, and I made room by not making myself available officially. Unofficially, I'm as available as ever and believe that Agile Finland has come to a point in which I or anyone else no longer needs to be "in" to be included actively. So I will be hanging out with  the executive committee without being a member.

In Annual Fannual, Agile Finland did not show a "plan of action" for the upcoming season. Some participants made a comments on this, justifiably. Would be nice to know what will happen next year - still would be. I find personally that it's very hard to make a plan for a group of people that has not yet been selected, but we could have done a little better just making the community members individual commitments visible. Because, that's what we have, a community of volunteers that do things if they feel they want to - we cannot really drive things by deciding something will be done, unless the individuals choose to see those suggested priorities as their priorities. I find it unlikely that we would be "following a backlog", but it's more about seeing where individuals' energies lead us - together.

Now that I'm  not in the board, I'm more free than ever to tell where Agile Finland should be heading. That's what this post is about. And I suggest other individuals will create their own views, publish them and we discuss - perhaps getting a common view that we can then better communicate back to the community.

If things go as I'd like them to go, Agile Finland in a year:

1) Runs three significant conferences: Tampere Goes Agile 2014 in autumn, Scan Agile 2015 in Spring and an unconference-type of a conference with a name not yet known. Since I have a great group around Tampere Goes Agile, Vasco Duarte has his heart set on Scan Agile and Aki Salmi is already actively thinking about an unconference, this is very likely thing to happen.

2) Runs seminar/event -series in major cities: Oulu, Tampere ... perhaps Turku too?
Oulu will see a full-day agile/cloud -seminar as collaboration of Agile Finland and EIT ICT Labs, and Agile Finland is already preparing schedule for an agile sauna late in the year in the Oulu region. Testing cell is also live and kicking in Oulu, there's one session on Security Testing in June (identified as testausOSY event) and a practice oriented session siding the Oulu Agile Seminar. I will also make sure we get one more session for the springtime 2015 in Oulu.

Tampere will have Tampere Goes Agile, but it also has a very lively Coaching circle going on - ask Eveliina Vuolli more on that one. Testing cell is also active in the area, with an event in planning for 4.9 - around a meeting of Tampere Goes Agile organizers. My intention is to get TGA organizing to a level where there would be again local leadership with good support from Agile Finland so that new volunteers for making it happen would have things set up for a good start of TGA 2015.

3) Runs events that are not location-based. Yes, webinars. I want to see us experiment on these and see where the experiment takes us. What drives me to this is that I want to practice delivering webinars, and while doing what I want to do (learn), I'm very happy to help others with that as well. I would want to see a mix of English and Finnish presentations, and perhaps this could also be a way of showing the great stuff we have in Finland outside Finland - when the language is English.

4) Owns a for-profit (company). This may be surprising to some, but very much something I'm driving towards. Agile Finland would want to organize stuff that is real business, not just "non-profit". Real business in the sense that it advances the goals of the non-profit to have absolutely brilliant selection of courses available that are not available in Finland, in all major cities as of now. The for-profit part of non-profits should be set in a company that is fully owned by Agile Finland. The company would pay taxes like all good companies do - non-profits don't exist to go around taxes, but to advance things that companies don't and to create opportunities for us all - individuals and companies in the community.  If my dream world would become real, this would employ someone as a ceo and/or event organizer and pay actual salary. And enable individuals to use the organizing services paid for to make their ideas for the community a reality easier!

5) Has several well-run cells, where some are local and some are built around themes. The context driven non-profit we set up can be seen as a testing cell, since there's so much in common. And we learn better ways to work in these small units of cells, allowing autonomy and support from Agile Finland.

6) Has run a pilot with my local elementary school on a computer club for kids that emphasizes the diverse viewpoints into creating software, not just learning to program. I hope to make people see that making software is fun and really relevant, but that the core of it is in ideas and collaboration. And that there's nothing wrong with girls/boys coding, not coding, whatever but not remaining distant from such an important trend. Create, not just consume. I also hope to deliver a few evening / weekend things within Agile Finland, as I've already talked to many mom's of smart kids who would like to contribute themselves too. There's no official say that Agile Finland will support me on this or identify it as something Agile Finland does, but I will do my pilot with the local school anyway.

7) Has established first connections for professionals to volunteer as speakers on agile / craftmanship themes of various sorts for vocational schools and universities in Finland. We need to make the teachers life in finding great case presenters and inspiring speakers just a little easier. On testing and on other topics. 

8) Collaborates with major student non-profit organizations in IT-area, at least in Helsinki and Tampere. At least the one that I find my non-profit home - Tietokilta, Data Processing Guild. Students bring such energy to organizing our conferences if they are in as full members organizing, I think that is a key to why Turku Agile Day is so great. 

9) Runs a regular coding-oriented cell where we can practice our craft from that angle. Make sure agile does not turn into facilitators and customers silo, but keep the core of development included as well. A friend of mine noted, that Agile used to be the only crowd that encouraged developers to grow in their skills and see the world differently, practice coding. I would hate to see that go away, even if I'd love to see us emphasize the other existing communities in that area. I know there's great activity for security and for devops stuff, and there must be more than I'm aware of.

10) Solves the financial puzzle in such a way that there's enough money to always say yes to events that attract people and bring them together without enforcing "find sponsors" rule. I want to see that we can help with the sponsors so that people could focus on brilliant contents and sharing their lessons learned. There's ways of financing that are tied together with my point number 4. But there's also the idea of corporate membership that I would like to see prepared for action by next Annual Fannual.

11) Runs regular commercial top-notch trainers courses in Finland, on different locations with both international and local teachers. Gets known as a channel to good stuff, and in particular creates good stuff the companies don't yet create. And in particular, on locations other than Helsinki.

Note that my view of Agile Finland does not have the most common aspect of "selling agile to people who don't yet get it". I want to see us focus on being so excellent in every other way that people will get drawn in. Create pull, not push. And I think the stuff Karoliina Luoto and Marika Leeds facilitate on Agile Ownership stream is a great example of that power.

Now that I've shared my ideas, I hope it enables people to talk about where we agree and disagree. And perhaps, help me clarify and change my ideas so that we build an ecosystem of agile, that makes companies extinct that make testing awful by leaving it to the end, under impossible circumstances.  I think Agile ideas are the best thing that ever happened to testing. Agile managed to deliver messages on illusion of speed, fixing loads of bugs creating more that testers have tried to say for ages with less success. And it creates a need for smart and fun exploratory testing, where you are actually required to do more than execute checks - you explore the product in ways where "before implementation" and "after implementation" get mixed up in short cycles. So, there's always a testing idea in there for me.

Agile Finland, it's THAT time of year again

About a year ago, I volunteered to join Agile Finland Executive Committee. It's been an interesting year for me, one in which we've done plenty of things and started more that will continue into the future. A new executive committee will be chosen in Annual Meeting next week (finally), and while the style of opening may give the impression, I'm not going anywhere.

Recently, I've come to know people who volunteer to join the Executive committee for 2014-2015 season in addition to me: Hannu Kokko, Olli Pietikäinen, Jussi Markula, Vasco Duarte and Martin von Weissenberg. This means there's already one more that the executive committee can accommodate according to our rules, and I voluntarily step down to be a spare member - eligible for full membership in meetings when any of the others is away, and always being there. As the meeting has not been held, it is still possible things will turn out to be different, just like last year. I showed up just moments into the voting, volunteered and kicked out someone who had been preplanned into the committee.

The time of year leaves me thinking about what I'd like to see Agile Finland be. The ideas are most certainly influenced by others, but this is not intended as a shared statement from people but a personal view to open discussions.

Agile Finland should be more professional, run 'like a business'

Agile Finland community is about content. To run Agile Finland, there's much more than just content, there's all sorts of administrivia, financial considerations and considerations of what we can do as a non-profit. I'd like to see that more of the stuff that happens in Agile Finland could be considered paid work for someone, starting with the hope of hiring a 'secretary' and continuing with the idea that Agile Finland could actually own a company or collaborate closely with a company. Organizing conferences would be more sustainable if only the content part would be volunteer work. Organizing regular events similarly.

We need to look at models of how non-profits are organized from the bigger non-profits.

This also means, to me, that our events should be profiled to professional, career-advancing stuff. Not something that happens only in evenings and on your own free time. Social aspects are important too. Unconferences, peer conferences and the sorts are social. But they are not freetime activities.

Agile Finland should celebrate and support skills/personalities diversity

I think Agile Development is the way of the future - people emphasis. I joined with a concern that has not been resolved: Agile teams seem to be leaving non-coding testers out. Again and again I hear of some enlightened customers who buy agile development teams from one contractor and add testers from another. But I hear more stories of customers buying just agile development team and not realizing they may be missing something relevant. I love the fact that there's teams doing really great without testers, the fact that developers in agile have learned to test. But I find it sad that there's still a feeling of excludedness for those who identify as 'testers'. Someone I talked with summed it well: testers were struggling with respect 10 years ago and it got better. Agile feels like it's starting all over again.

When I look at Agile Finland events and participants, I get a feeling that something has changed there too. When it all started, a lot of the stuff was about practicing our skills of development (coding dojos in particular). Now we have very little technical content, and very few active developers in the ranks. Most of our contents are about team work, people stuff, methodologies and practices. And coaching, that seems to be the core of it all.

I did a little picture of interest groups I could identify already existing within Agile Finland as I see it. I'd like to find a way to create action for different interest groups without creating walls on which groups you belong to - we're all in it together and just choose to spend time in different way.

I'd like to see more people identify with Agile Finland and agile as the way to do valuable software. While others may find it important to reach out to ones outside development, I'd like to make sure we don't lose out on the ones who are in development. I hope we could have both.

What it comes to testers, I find that many of my colleagues in test won't join as enthusiastically as I did. Also, doing as much on testing as I want to keep the skills growing and new people joining into the great work of testing, Agile Finland alone does not feel sufficient. Thus I've started Ohjelmistotestaus ry - Software Testing Finland -non-profit, that works with skills-oriented testing, a topic that should be close to Agile Finland as well. Knowing testing, growing testing and building bridges to testing is still my calling.

And the others...

On the upcoming season, I want to run a trial on agile development from 'creating together' point of view with 1st graders - small children. I've actually already agreed on piloting this with a local school. The idea emerged from the fact that I feel we lose girls in particular at a very young age from the software professions. To me, it seems some of it is peer pressure and some of it is the idea that "code" is the central element. I'd like to focus on people and I don't mind that we together transfer ideas into code. Ideas are the key. So Agile Finland will have a new audience, the future of the profession in kids.

Similarly, we need to reach out more towards the students. I think Turku Agile Day has been the most energetic of the agile conferences in Finland, and I attribute a lot of that to the collaboration with students. We should have more of them, early on, learning with the more senior ones on creating great contents.

And surely, we should also seek to infiltrate the places that don't yet realize agile has answers to their concerns - the very traditional non-profits. Practical examples, real cases and the discussion about them could perhaps teach us all something. Turning non-agile to agile is just not my thing outside the actual work at companies. Selling Agile is someone else's high priority.

A tester crisis with shift-left work

There's been a long-time discussion about involving testers earlier, but the term "shift-left" is a new concept for me, saying basically the same thing: the need to involve testers early not to find as many problems later in the lifecycle.

I've done a share of shift-left work in the role of a tester, commenting and pointing out flaws. But as I continued working on design stuff, I started noticing that I moved from my tester role ("here's a problem, could you think of a way of fixing it") into a designer role, suggesting solutions. I find the difference essential, as in the tester role I tend to remain somehow disconnected with the eventual solution I did my best for, whereas in the designer role the mistakes we make are mine as well.

Just yesterday the first feature designed by me got into testing - to be done by me. I felt different. I felt quilty for liking the appearance of simplicity of the feature. I felt it must be incorrect. I felt I must have missed something really relevant. I felt insecure.

We did a pair testing effort on the feature, with quite limited time in relation to the complexities related to that. About half-way through our paired session, I felt the urge to mention that the design / fit for use aspects needs to be attacked very critically, as I fear for my bias. I noticed I selected my own test approach for the session based on the concern of bias - comparing with a version of similar feature in a previous version of the product, with different technologies. I paid particular attention to things the old one allows the user to do, and making sure those could be done with the new. And I felt even more strongly that if the previous wizard had 9 steps and the new only 5 steps, there just has to be something wrong. And I kept looking for evidence. I've logged a bunch of bugs (13 from our session yesterday) but none of those bugs yet has what I look for - signs of this design not working for its purpose.

With something I've created, I feel the need of doing my worst to break it is more urgent. I will try. I will invite others to try. And monitor the feedback just as I do with any other features.

I realized I've seen similar shifts of perspectives turn bad earlier on in my career. I've seen decent testers turn into confirmatory mindset by participating in design, missing relevant issues while testing. So I feel that it's my duty to do the extra work needed to try to tackle the concern. If I fail in my attempts to show it does not work, it just might work.

Then again, its no extra duty. It's what I always do testing features. The extra is just the nagging feeling that my bias needs attention. Will see if it did in just few weeks.

 

Developers worth a (better) salary test

Recently, I've spent quite much thinking time with the idea of 'being a professional'. I (re)read Robert C. Martin's book "Clean Coder" to get reminded that as per that book, professional developers estimate and test, and play well with others. The book left me also thinking that professionals are people with stories to share of their learnings, and strive to be on an improvement path towards something better.

I've also been thinking about people who are not as professional as one might like them to be. In particular, a tweet just a few days ago left me wondering:

10% of developers fighting about whether #tddisdead. Other 90% considering whether they should try building before pushing to trunk.
— Jonathan Chambers (@jon_cham) May 13, 2014

It helped me realize that this is very much true in my experience as well. As much as I work with agile-minded organizations and colleagues, I still keep meeting many many developers, who don't do much of automated unit testing. Or if they do, they do it because they have to and just look for opportunities to maintain the unit test base by deleting most of it on a basis of 'architecture change'. there's individual developers that I trust and respect that test - either test first or test soon thereafter continually.  But 90 % of my sample is still people who think testing is trying out something very little if anything, and trusting that it either works or someone else will tell them about it.

There was one developer, who started off telling me that he is too valuable to test. In his perspective, those who can't code are less worthy. The less worthy in this particular case were product management people, same people who should actually spend their time speaking with the customers and making sure there's a steady flow of income to pay for the development. Saying that is less worthy seems off by much, as there's no chance the developer would get a single customer commit to paying anything for the product. Different is not inferior. The attitude was not a very professional one. I would expect just a little more of perspective, seeing things in context.

There was another developer that was (in)famous for his ability to do quick prototyping. The negative side of it was that while he could make the system run once with the happy paths, his code was a maintenance nightmare. There were hacks and little structure. Any way he could make it work before moving elsewhere was the deal. Other developers quietly fixed and compensated after him, complaining in the background. Making things work now without considering maintainability is not very professional either.

And there was yet another developer. His skills were not that toned but he did his best. He just wasn't very enthusiastic about his craft. When sent to a course he requested, he listened a bit but skipped all the exercises. His learning and enthusiasm was quite low, and requiring paired development in the team is his nightmare - he'd rather work solo. Again, not a very professional approach either.

Thinking through all the problems I've had over the years with developers producing more bugs as they attempt to fix something, developers having no clue of what could break with their change and developers creating maintenance nightmares, there seems to be two things in common.

1. None of these developers test and think testing. Rather, they externalize testing as somebody else's responsibility. They also tend to like to externalize requirements and designs as someone else's responsibility.
2. None of these developers practice their craft. They don't talk to others about how to do things better, and submit themselves to feedback and learn actively. They already have "the tool" and that seems to be enough. 

A bad, unprofessional tester wastes his work time into producing very little value. When a tester is bad enough, the rest of the team won't talk to him with various excuses. The bad tester sits in the corner, creates test cases and runs them, creating test cases statuses. A bad tester with a good developer is wasted effort, but not a problem. Bad tester - Bad developer is a pair that seems good enough, as someone needs to do even the most basic checking. But if you've ever seen anything better, you may find it hard to accept. In my experience, in this case the bad developer gets better by removing the tester.

A bad, unprofessional developer causes problems in a much bigger scale. There's no sitting in the corner when your code ends up in the end product and fails. There's the approaches I've seen where you code just a little every week but avoid doing much - to keep the scale in which you fail smaller. 





I'm not looking for the perfect developer. We're all people, with different skills and backgrounds. But if you don't practice, hone your skills and actively get better at what you're doing, could you please consider doing something where you cause less harm to others? Just care a little. 

Testing is learning. It's a thinking tool. Developers who externalize testing delivering just-don't-work-quality systems to testers miss out on being more valuable. And I'd like to believe that we're learning, as industry, to pay better for those who take a bigger chunk of the value chain focusing on throughput instead of sitting quietly in our presumed silos. Be it 'design', 'code' or 'test'. Developers who test should be paid more. Or, developers who don't test should not be paid as much as they are paid now before they learn to be worth as much as their test-able counterparts. Full-stack developer - extending beyond code&test - sounds good, but how come I see so few people like that? It seems developers who consider themselves agile are ones building communities and practicing seriously in dojos and retreats, and unconferences, seeking out mentors they feel they need, in- and outside of their organizations. Or again just my sample?

Within testing specialty, there's a lot of talk about T-shaped testers: doing either business analysis or development as the other thing to testing, extending your skills. That seems relevant as in adding the value you can deliver and thus what you should be worth in salary.  The old-school test case executor testers should be really low pay (or extinct by automation). Active and thinking testers are needed and respected. Professional.