Free Webinar Series by The Test Masters Academy

Test Masters Academy starts free series of webinars and discussions on hottest topics in software testing by renowned speakers and community leaders. All online events will be followed by live chat sessions, where you can ask the speaker questions and discuss the topic among all participants.

SIGN UP FOR FREE EVENTS HERE

DAILY WEBINARS AND ROUNDTABLES

2:00-03:30 PM ET

September 20th, 2:00-03:30 PM ET

Ask the Experts: Whole Team Quality

Panelists: ConTEST NYC Speakers and invited guests

September 25th, 2:00-03:30 PM ET

The Lone Tester in an Agile World

Speaker: Michael Larsen

September 26th, 2:00-03:30 PM ET

Why developers can’t test, and what can you do about it?

Speaker: Joel Montvelisky

September 27th, 2:00-03:30 PM ET

Ask the Experts: Test Automation

Panelists: ConTEST NYC speakers and invited guests

October 2nd, 2:00-03:30 PM ET

Future horizons – mapping out the next decade of testing

Speaker: Christin Wiedemann

October 3rd, 2:00-03:30 PM ET

More Than That

Speaker: Damian Synadinos

October 4th, 2:00-03:30 PM ET

Ask the Experts: Role of the Modern Tester

Panelists: ConTEST NYC speakers and invited guests

October 9th, 2:00-03:30 PM ET

Evaluating Testers in Agile Team

Speaker: Lalitkumar Bhamare

October 10th, 2:00-03:30 PM ET

Presenting with Impact & Influence

Speaker: Todd Cherches

October 11th, 2:00-03:30 PM ET

Ask the Experts: Testing of the Emergent Technologies

Panelists: ConTEST NYC speakers and invited guests

——————————————————————————-

2 DAY ONLINE CONFERENCE _October 16th-17th

10 AM – 3 PM ET

(individual presentations time slots to be announced shortly)

My Problem With the Pyramid: Introducing the Round Earth Test Strategy Heuristic

Speaker: James Bach

Pair Testing Pair Programming

Speaker: Simon Peter Shrijver

Driving Higher Quality with DevOps Initiatives

Speaker: Sigge Birgisson

Evolution—Not Revolution: Transforming Your Testing

Speaker: Julie Gardiner

Communities & Leadership: Our Best Bet to change the State of Testing for better

Speaker: Mahesh Chikane

Senses working overtime: Improving Software Quality Through Accessibility and Inclusive Design

Speaker: Michael Larsen

A Dozen Mistakes of my Software Testing Career

Speaker: Ajay Balamurugadas

The True Untold Story

A True Story

So this is not a true story; that’s what they want me to say. But I will not say it. I will not say it’s not a true story either. What I can say that it could be a futuristic story; it might end up becoming “YOUR STORY” !!!

What happened to me?

I am an engineer; my bosses did not like me. But, I want to be doing hands-on coding for the next 30 years. They don’t let me do that. They want me to learn automation. They want me to learn to code. They want me to learn managerial stuff. They call it growth; I call it a corruption of the mind. I want to stay a tester. They don’t pay me; they don’t give me promotions; they don’t give me newer projects; they say they want me to grow; eventually, I give in. I learn automation; I became a test lead. I did not learn managing people; with time, I was promoted to “manager”.

What did I do as a manager?

I was told to manage resources, but I was given human beings to manage. I was told to manage their time; I wanted to manage their emotions. I was told to show them the carrot and the stick; I never realized that was actually someone showing “me” the carrot. I wanted to care about people; they wanted me to care about their clients. Over time, clients won; people lost. I stopped caring for people and was invested in our business. During hiring events, I was told to hire women; but not the pregnant or married woman. The hiring class that I was a part of trained me how to look at women to see if they are pregnant or married (without seemingly staring at them). I learned how to throw a colleague under the bus; I knew how to stab them in the back and became an expert in back-biting. I became an expert at the blame game. Over time, I became a “senior manager”.

What did I do as a senior manager?

On the 1st day at work as a senior manager, I told myself that I should soon become a director; I had to learn to do office politics to survive; I stole credit from my subordinates. I stole ideas from other people and called them my own. I learned to break up friendships for power; I learned to assert myself by calling back my team members when they were leaving for home and asked them to stay late and attend client calls. I learned to showcase my position by shouting at my subordinates in front of their peers and felt good about it. I created fear in the mind of my team members. I loved it. I wanted more and soon got a promotion to director.

What did I do as a director?

I transformed into someone I hated; I became someone who I did not want to be. I loved the power of this position and wanted more. I loved it when they stayed longer to bill the clients extra money. I strayed away from personal relationships; I realized I preferred to stay out with friends rather than go home to my son. I realized I wanted to visit our foreign headquarters monthly instead of the weekend matinee with my family. I had become someone who I hated; I loved it.

And then…

I was the vice-president of the department; I felt that I was on top of the world. I became a hypocrite. When I found a mistake, I fired an entire department. I loved the power. I wanted more. That’s when karma caught up; I got fired. It was a lay-off. They fired the longest employees. It’s been 6 months. I have not been able to find a job ever since. My son was studying in college; I realized that I barely know him now. My husband had become a globetrotter; he no longer needed me since he found peace traveling the world by himself. I did not know what to do with myself. I was alone. I headed to my room. I took my revolver. I placed the revolver in my temple. My fingers were on the trigger…. And then …..

Like I said at the beginning, this is not a true story; that’s what they wanted me to say. I will not say it. I will not say it’s not a true story either; however, I am still afraid it will be a futuristic story. I am afraid, it just might become Your Story !!!

AUTHOR BIO

What has this author achieved in testing? This author has tested more than a million lines of code and has logged more than a billion defects; He has had a trillion number of arguments with developers on more than a quadrillion bugs; he has been in quintillion triage meetings and has participated in sextillion conferences; every day, he has septillion thoughts and has chosen not to attend Octillion testing conferences. He has selected nonillion candidates from decillion testing interviews. He has Decillion followers on twitter and Undillion followers on testing communities. And by the way, the above contains Duodecillion amounts of exaggeration on what I have done so far.

Systems Design for Mobile Test Development

Are you a “software tester” or a “mobile tester?”  If you identify with the latter and let’s face it, most of the testing nowadays is focused on mobile app development, then you need to stop thinking “I’m only a software tester.”  As software testers we’ve long focused on the software only, meaning the functionality of the software and not really considering a systems perspective.  But with mobile apps, depending on the architecture of said mobile app, a full systems integration approach gives a more complete test coverage approach.

In my career, one hard lesson I have learned is how the inter-dependencies affect software behavior.  Those inter-dependencies include hardware limitations, firmware or operating system functionality or a combination.  The most complex type of testing is the combination of hardware and firmware conditions which directly or indirectly affect the app’s behavior.  A decade ago, I discovered the charging of the battery in various states of charge affects the functionality of a native app, a medical device.  Since then, I’ve seen other, commercial, non-proprietary apps which rely on various states of the hardware or operating system but are not tested as combined states.   

Testing states of the device and app are important but the tester also must understand when the functionality is supposed to behave based on the state.  Adding the sequence of when the functionality is supposed to behave and taking into account the conditions or combination of conditions can be complex and quite overwhelming.  Due to the complexity, a smart, well-planned test strategy is vital to give high test coverage for any mobile app.  And that planned out test strategy needs to incorporate systems thinking. 

Now, what do I mean by systems thinking in mobile test development?  The best way to describe systems thinking for mobile tests is through examples.  But first, the tester and/or test manager should consider these questions:  the who, the how, the where and the when of usage of the mobile app on the mobile device.  Mobile testers need to ask these questions when planning out your regression and new testing.  I’ve often spoken about “testing beyond the GUI” but I have not given any specific examples.  Tests should include system boundary tests based on who will use the app, how the app will be used, where the app is used and especially when at any given point of usage.  The sequence of functionality is not seriously addressed by many testers and often times miss uncomfortable states of the app.  

 One of the most commonly missed or misunderstood tests is when an app receives notifications. The testing of which color LED light to be used for the type of notification is accessing the operating system of the device.  The uniqueness of the device itself may be a factor in which color of the LED light is used to notify the user or there may no outwardly visual notification on the device but it might be audible notification.  Mobile testers need to know what the app uses in its development to let the user know of a notification.  What is also important to consider is when that notification occurs based on whether the app is in use or not.  If not in use, do other apps’ notifications step on your app’s notifications or vice versa?   These might be silly, obvious tests to conduct but yet, I’ve seen and tried to access largely used mobile apps where notifications do not work as I would expect them to work.  Sometimes, they are missing altogether due to an interruption from another app, sometimes, I get no visible notification on the device’s LED light but I see a notification at the top of my screen. 

Another example of a system level test to add to your test strategy is performance.  Now, most testers think of performance as speed or “how fast can I connect.”  That is indeed one test along with how responsive the app is to the commands a user inflicts on the app.  But let’s not forget performance also includes load, stress, and endurance to name a few concepts of tests.  So to illustrate, an example of a use of a mobile app while on an airplane along with many other passengers also trying to access the Internet.  Mobile testers need to not only consider the different functions of the app while accessing the Internet but also more than 100 other passengers trying to access Inflight Internet.  Can the app respond well to the commands based on the load in such a context?    Now, has the development team defined the boundaries or limitations regarding the load on a network and how the app will respond?  What if the app’s limit is degrading to the point of being unusable when 100 other users are trying to access the same network?  Even the use of different routers does not seem to help improve the performance speed.  Knowing how the app will be used, where the app will be used, by whom the app will be used and when can help to formulate your test strategy.   

Let’s further discuss the app on an airplane example. Ask yourself, if you are trying to connect, seeing others connected and streaming content and you try to do the same but the plane hits poor weather, kicking everyone off the network. Then all the passengers are all trying to reconnect to the network at the same time, how does your app handle the load?  How does your app handle the interruption?  Does your app give you a notification to inform you the network is again available?  How responsive is the app once reconnected?  Can you, access the content where you left off before losing connectivity?  Sometimes, an app cannot reconnect because it cannot get a unique MAC address ID which means firmware testing of the router the app is trying to connect.   

Mobile apps which rely on the cache to respond quickly to commands may create problems unforeseen by the testers.  Going back to the example of losing connectivity while on a plane, the app stored the location of where the user was while streaming content.  Once connectivity was reestablished, tests involving the state of the app, the state of the device is maintained without errors, meaning the content continues streaming seamlessly.  But reconnection causes the app to restart.  This may involve loss of battery charge where the user is able to recharge the device and how long of an interruption might affect the app’s behavior.  Tests involve what state can the app be in where the cache is utilized or not.  Testers need to know how important cache retention is to the user at any given point of the app’s usage.  

Mobile tests can be incredibly complex.  Mobile testers need to think “system” and not just focus on software testing.  If the planning is done, automated tests can be created but keep in mind whether your tests are a one-time test or repeatable test.  It’s not cost-effective to create automation tests for one-time tests, and sometimes it’s just faster to perform the test manually.  This is why it’s vital to understand the who, the how, the where and the when of your app’s usage. 

Author Bio


Jean Ann has been in Software Testing and Quality Assurance field for almost 2 decades including 10 years as a mobile software tester. She is a globally recognized a mobile testing software specialist, mentor, trainer, writer, and public speaker.  

Jean Ann’s software testing and quality assurance experience cover various industry domains which include avionics, medical diagnostic tools,  surgical tools, healthcare facilities and insurance, law enforcement, publishing, and the film industry. Testing environments include multi-tiered applications in a strict Waterfall software development life cycle to a medical device regulated the environment in a hybrid of Iterative and Agile software development life cycles.  Testing includes client/server applications, websites, databases, and mainframe records. Mobile apps testing on a proprietary device for police use, medical device diagnostic use, and surgical use. Nonproprietary device apps include financial use, business use, and games. Currently helping to build quality in software development projects for in-flight entertainment.  The development environment is a hybrid of the agile approach to a waterfall environment due to being regulated.

Jean Ann is a consistent speaker at various software testing conferences.  She actively mentors, conducts training and workshop sessions, publishes webinars, participates in podcasts, reviews and contributes to several books. Jean Ann is a graduate of St. Anselm College with a Bachelor of Arts degree in Political Science.

7 Signs That You Should Switch to Contracting

Are you a permanent employee – a “permie” – wondering whether you’d be able to succeed as a contractor? Here are seven signs that you should switch to contracting.

  1. There’s high demand for contractors with your skills

As a start, check your local job websites. They will give an indication of the demand for contractors in your city. Bear in mind that demand can be seasonal – there are less roles advertised during holiday seasons and towards the end of financial accounting periods. Speak with recruiters to gain a better understanding of current market trends. Alternatively, are you willing to move to another city where there is more demand?

When I first started contracting, I realised there are tech companies who only hire permies. Being a contractor excluded me from working at some innovative companies with exciting technologies. If there are specific companies you’d like to work with, find out whether they hire contractors. On rare occasions, those same companies may make an exception.

If there is a downturn in the market for contractors you can always go back to being a permanent employee. After all, being a permie does have benefits… literally.

  1. You’re great at what you do

A lot of us think we’re great testers. What’s more important for contractors though is what other people think about the quality of your work. Are you usually successful at job interviews? Do co-workers seek your advice regularly? Do you keep your skills up to date with new technologies and trends?

When searching for a contract, your skills and reputation will have a large impact on how the process plays out. It’s the difference between receiving calls about upcoming opportunities from recruiters, versus sending out job applications and not receiving any responses.

Seek referrals from former colleagues, and always continue learning either broadly or deeply about testing areas. It’s also important to be a fast learner – contractors are expected to hit the ground running. Taking one month to learn the system under test is not good value for money for your client, especially on a 3-month or 6-month contract. Similarly you should be able to learn a new issue management tool in less than a day (preferably in your own time), and taking a week would be unacceptable.

  1. You have a wide professional network

It’s not only what you know… it’s who you know. Networking – meeting new people and keeping in touch with those you already know – is a useful skill for contractors. Try attending meetups in your area to share knowledge, to learn, and to network with local professionals.

Network internally as well, with colleagues in other teams or departments. To help build professional relationships you should have a strong work ethic, deliver on your promises, and always add value with the work that you do.

You will change jobs more often as a contractor, so it’s important to be able to work effectively with all kinds of people. Don’t burn any bridges when resigning or ending a contract. After all, there’s a fair chance that you’ll work with these people again. It’s funny how often contractors end up working together again at different companies over the years.

  1. You value your time

How does your pay rate compare to market rates? Are you earning what you should be earning? Are you often working 10 hour days as a permanent employee, while being paid for 8 hour days? Imagine getting paid well, for every hour that you work…

For contract work an hourly rate is preferred, particularly for short contracts which may be under pressure to work long hours and meet a tight deadline. Your negotiation skills will be important when deciding on contract terms, after successfully passing the interview process.

For longer contracts of 12 months or more you may compromise and be paid a daily rate. Be wary though… a 12 month contract suggests the comfort of job security, which is an illusion. If there’s a downturn in profits, a change in management or a shift in company priorities then contractors will be the first to go, with only 1 or 2 weeks notice required.

When negotiating rates consider your experience, how unique or relevant your skills are, and the current supply versus demand for candidates. As Gerald (Jerry) Weinberg says in The Secrets of Consulting, “Set the price so you won’t regret it either way”. Will you miss out on an interesting project by asking for too much money? Will you get the contract and then resent not being paid a higher rate?

  1. You understand that job security is a myth

Multiple times in my career as a permanent test manager, I’ve had to make positions on my team redundant. This means that good people have lost their jobs, usually through no fault of their own. As permies, some of these team members had just bought a new car or taken out a mortgage with the expectation of job security allowing them to afford loan repayments.  

Unfortunately I’ve also seen whole departments closed down or relocated to other countries, multiple times. When that happens it no longer matters that you’ve worked long hours, gained domain experience, been a team player or have strong technical knowledge of the company’s systems and products. You will still be looking for a new role alongside your former colleagues.

In reality, job security (or income security) translates to how quickly you can find a new job. This could mean gaining experience with a wide variety of industries, technologies and tools. It could mean specialising in an area which is in demand, such as security penetration testing. It’s important to keep your skills current, and relevant to the local job market.

  1. You’re able to budget for expenses

You will not get paid for sick leave, national holidays, vacations or time in between contracts.

If you have an ongoing credit card debt, or have usually spent your salary by payday, you need to consider how well you’ll be able to save for a rainy day. If you receive a bonus payment, do you usually spend it or save it?

To remain at the top of your field, you will need ongoing education in your own time. All conferences, training courses and education will need to be self-funded. Contractors are not entitled to “free stuff” from their clients. Having said that, local meetup groups usually don’t charge an entry fee; there’s a lot to be learned online for free; and being selected as a conference speaker is one way to attend conferences free of charge.

Contractors can minimise time spent looking for their next role by going through an agency. Naive contractors resent agencies for charging clients a percentage on top of their contract rate. I’ve been on all three sides of this situation at different times – contractor, agency and client. What I’ve noticed is that agencies have stronger negotiating skills and bargaining power – they’re able to charge clients more than you’ll be able to charge on your own, and you’ll have the same rate as you would by contracting directly to the client. You can also find work much faster through an agency because this is what they do, build relationships and contact IT companies regularly about upcoming opportunities. Sometimes they will have exclusive access to fill certain roles, and you would not be able to apply for the role directly. Using an agency will save you thousands of dollars in lost income when searching for a new role, so it’s not worth being bothered by what they charge for their services.

  1. You’re ready to step out of your comfort zone

Companies usually want contractors to start immediately, within 1-2 weeks time at the most. Which makes it difficult to find your first contract if you have a one month notice period as a permie. Resigning without a contract lined up can be daunting. Leaving a permanent job for my first contract position felt like jumping out of an aeroplane, despite the support and encouragement from my mentor at the time. With each new contract though, the process feels more familiar and slightly less nerve-wracking.   

Contracting is not for everyone, you’ll need to be comfortable with feeling uncomfortable. Regularly searching for a new role, joining a new team, learning fast, working hard, and then leaving new friends for your next role… that’s contracting in a nutshell, and many people thrive in this context.  

For more practical tips from Kim Engel and Jody Goodwin on working as a contractor, listen to this podcast:

https://www.supertestingbros.com/podcasts/2017/8/16/episode-7-contracting-for-bugs

There’s more to the story of contract versus permie than just an enticingly high hourly rate. I’m keen to hear from other contractors who started their careers as permanent employees. What convinced you to make the switch?

AUTHOR BIO

Kim Engel has worked in software testing for the past 20 years, with a pragmatic attitude and hands-on approach. She has been instrumental in expanding the awareness and practice of context-driven testing in New Zealand and Australia.

Seeing every teaching experience as a learning opportunity, Kim enjoys sharing her experience with others in articles, presentations, workshops, coaching sessions and via her blog www.isitgoodenoughyet.com 

All roads lead to exploratory testing

At the European Testing Conference(ETC) 2018, I was inspired to jot down a flowchart about my experience and thought processes from working with customers or teams who want to have manual test scripts executed.

It reflects both my experience with how the conversation / project progresses and it also serves me as a guideline for having that conversation with someone who doesn’t know much about software testing. It’s been something in my head for a long time, and ETC encouraged it to come out.

Benefits of exploratory testing

When I’m faced with something to test – be it a feature in a software application or a collection of features in a release, my general preference is weighted strongly towards exploratory testing. When someone who doesn’t know a great deal about testing wants me or my team to do testing for them, I would love to educate them on why exploratory testing could be a strong part of the test strategy. My reasons for the right arrow leading directly to exploratory testing can be summarized as:

  • My experience shows that Exploratory testing is better at finding out relevant quality information more quickly and with less overhead.
  • Exploratory testing lets us identify problems we couldn’t foresee (unknown unknowns). Test cases and test scripts let us ask software, very specific questions – but only questions we know to ask. We can’t write a test for something we don’t know to test for. And it’s usually the risks that we weren’t aware of that end up biting us.
  • If I am writing a test script with high level of detailing (with test data, expected results, individual steps), then I would prefer to write it in a way that a machine can understand it. Basically, I want to automate it and have Jubula or Selenium or <tool of choice> execute it for me.
  • Exploratory testing is infinitely more fun and engaging than following a test script. That makes it less likely that the tester will miss out on important information (either just through boredom and repetition, or through observational blindness, i.e. when we focus on one thing and don’t notice anything else, even if it’s very odd and salient). The customer might not necessarily care how happy and enthusiastic testers are, but I do, because they are my team! Also, I’d like to argue that happier testers will do better testing.
  • Exploratory testing is lightweight. It lets us get to the actual testing in a short amount of time. Long detailed test scripts don’t have to be maintained.
  • Exploratory testing can easily grow and adapt with a team. It can be combined with checklists (for example a list of “familiar problems” that it’s always worth looking into, or, as I like to call it, “’the list of things we usually manage to break even though we’re so sure we haven’t affected them”. New test ideas can quickly be incorporated. Through pair testing and workshops, multiple team members and stakeholders can join in. We do exploratory testing days with customer involvement a lot in Bredex projects, and most of our developers have some understanding and training in it, with some being particularly good and practicing testers.
  • It doesn’t require that I have detailed specifications, documents or expected results. These artefacts can be useful to have for testing, but they are only a part of the potential sources of information. And my experience shows that they are often incomplete or out of date if they have been documented at all.
  • And finally, exploratory testing is where good testers really shine. It is a structured and systematic activity that involves working, thinking and evaluating at multiple levels. It uses all the cool stuff about test design we can use to write test scripts (like equivalence class analysis, boundary testing, …). Models of the software are created in the tester’s mind, and compared and contrasted to knowledge about the product under test, other products, experience, expectations and a host of other know-how gained by the tester thus far. It is simultaneously incredibly natural and a skill that requires explicit practice.

If you’re as excited about testing as I am, then you’re already sold, right? It sounds like a great way of finding out information with the incredibly skilled tester who will be helping the team.

Taking the other route

It turns out that talking about all the reasons why exploratory testing is great doesn’t always help though. As frustrating as that is, I’ve realised that the project always ends up involving some (if not a majority of) exploratory testing anyway, which leads us to the questions on the left-hand side of the flowchart. Ideally, this conversation takes place quickly, but it can be a set of stages where the tester has to find out the information for themselves.

  1. Are there test scripts?

The actual conversation usually goes like this:

Alice: Alright, since I couldn’t convince you how great exploratory testing is, we’ll do it the traditional way and use the test scripts. Where are they saved?

Amanda: …

This conversation can lead to a branch not shown on the flowchart, which is the “then write the test scripts before you execute them” answer. Fortunately (and I’m smiling ironically writing this), most projects that don’t have a continuous embedded tester present have left the testing so late, that it’s plain that writing the test scripts will take more time than we have – and they still haven’t been executed. So not having any test scripts takes us straight to exploratory testing.

  1. Are they up to date?

I’m not usually lucky enough to get out that easily. There often are some test scripts, deep in the intestines of some giant tool, or hidden on a drive in an Excel file. It’s then usually clear from the “last modified” date how much they’ve been adapted and kept up to date with changes in the software. This is actually a big win for my cause of using exploratory testing, for two reasons:

  1. It means they have already seen how unlikely it is that they will actually maintain test scripts once they have been created.
  2. I can use the title or aim of the test cases as a starting point for what might need to be tested, and demonstrate the technique for the team using something that they have already identified needs to be tested.
  1.  Can they all be done in time?

Assuming that they are maintained, up to date test scripts, is it possible to execute them all (or all the relevant ones, assuming we can identify them) in the time we have? Either before a release, or within the context of a short development phase. If not, then we’re better off moving to exploratory testing – that will let us quickly gain an overview of the test object and show us which areas need the limited time we have.

  1.  Are you going to feel confident after executing this identified set of tests?

I’m going to be honest, although the “I have never reached this point” comment comes after this question, I’ve never actually reached this stage either. But I can theorise that this would be the next logical question. If there are indeed maintained test scripts that can be executed in the time frame we have, my suspicion is that they are not covering enough of the risks we want to address with testing. Even if we think that the set of tests is sufficient (again, for me a very theoretical idea), the inherent danger of us missing unknown risks is still there. So even in this case too, I would advocate strongly for some exploratory testing.

Exploratory testing wins

And there we have it. In one or other above explained way, exploratory testing becomes part of the test strategy for a project. That doesn’t necessarily mean that it is the only approach; I have worked on projects that had a mix of exploratory tests, automation, checklists and even small sets of test scripts. What I have never encountered though, is a project where exploratory testing wasn’t useful or helpful or necessary in any way – either because of its intrinsic value or because we’ve gone down the left side of the flowchart. As I showed at European Testing Conference in my demo talk, exploratory testing is a skill that uses a great deal of techniques formed by testers while actually testing. It is worth having people in your team (often in a tester role) that have this added and necessary skill and work on improving it. A good exploratory tester is a fantastic bonus to a team.

Author: Alex Schladebeck

Alex is the head of Software Quality and Test Consulting at BREDEX GmbH. Her passion is communicating with people in IT projects, most specifically about quality. She works with customers, testers, users and developers to help them improve quality in their projects and processes.  Her main areas of interest are quality in agile projects, communication, training testers and test automation.

You’ll usually find Alex talking about quality and how it affects the whole development process. She’s also a frequent speaker at conferences where she likes to share her project experiences and learn from other practitioners.

Web profiles

@alex_schl, www.bredex.de, www.schladebeck.de

Renewal of skill for testers

We’re constantly required to relearn, renew our skills, to keep current in our industry. A question several people have recently asked me is “What direction should I take as a tester; What should I learn next?” This is a hard question to answer; it is one I ask myself regularly. In some respects any learning, any renewal, is worthwhile – life long learning is a habit rather than a periodic effort. It is as important to refresh our mind and body by learning new skills and activities outside testing as it is to keep up to date with our industry.

Here are some suggestions for areas you might like to consider. Don’t try them all at once! Just pick one that appeals.

  1. Learn a new physical skill or activity: this could be a form of exercise, or a craft skill that requires motor skills, or a pastime. Gym exercises, carpentry, sewing, gardening… whatever takes your fancy. By learning a new way to use your body, you’ll also train your mind in new paths. This will help you think about work problems in a different way. You’ll also give the brain a space to NOT think about IT and testing; the break will rest your mind and help you renew. And, you’ll remember the feeling of not be able to … not knowing … that we all encounter before we become skilled. This will help you remember and empathise with what your software users will feel when you deliver that new or changed interface.
  2. Learn a new cognitive skill: this could be a new type of puzzle, learning a new card game or board game, learning a language, joining a debating club and learning to debate. Again, you’ll help your mind to forge new paths, you’ll change your problem solving, you’ll let yourself make mistakes and learn to learn from your errors. Chorus: And, you’ll remember the feeling of not be able to … not knowing … that we all encounter before we become skilled. This will help you remember and empathise with what your software users will feel when you deliver that new or changed interface.
  3. Learn a new management skill: this could be a project management skill you don’t need in your projects and wouldn’t use, but just for fun – can you understand it? Can you see how it works and why it is or was recommended? It could be something used in your projects, but it is not you that does it. This could be PERT charting, or Work breakdown structures, or an estimating method. It could be negotiation skills, financial accounting methods, cost benefit analysis. Any of these skills and techniques could be interesting to look at, even if you then discard them. Remember – we are looking for ways to exercise the mind into new paths. We want to challenge and potentially change our problem-solving methods, make mistakes and learn. Chorus: And, you’ll remember the feeling of not be able to … not knowing … that we all encounter before we become skilled. This will help you remember and empathise with what your software users will feel when you deliver that new or changed interface.
  4. Learn a new teamwork skill: this could be combined with your physical challenge by learning a team game. Or with your cognitive skill challenge by learning a card game where you have to work with a partner, such as Bridge. It could be by pairing to trial a management skill. It could be by learning a specific communication and team work method, such as applying De Bono’s Six Hats for a Meeting. [http://www.debonogroup.com/six_thinking_hats.php]. All the same things will happen: challenges, errors and learning as the brain makes new connections. Chorus: And, you’ll remember the feeling of not be able to … not knowing … that we all encounter before we become skilled. This will help you remember and empathise with what your software users will feel when you deliver that new or changed interface.
  5. Learn a new creative skill: don’t even try being skilled for this one – just do it. Paint – however badly – or draw or doodle.  Use crayons, or pencil, or sew a picture with needle and thread. Write – something, anything, a song, a poem, a haiku, a diary, a stream of consciousness. Sing a song. Dance a dance – I have just started this and I am so bad at it! Yet I enjoy it now I have started. Not in public… yet.  If you already create, try a medium you don’t normally use. Do something you’ll “fail at”, notice how you feel, and then turn that to a feeling of pride that you tried something new. Chorus: And, you’ll remember the feeling of not be able to … not knowing … that we all encounter before we become skilled. This will help you remember and empathise with what your software users will feel when you deliver that new or changed interface.
  6. Learn a new emotional skill: Smile when your heart is breaking, as the old song says. Laugh, smile, be cheerful. Or, if you constantly joke, take a time to be serious instead. I have surprised myself lately by finding a capacity to will myself into a mindset – If I smile, my mind starts to smile, a little more. This can be very hard, so don’t beat yourself up if you cannot manage it.  But it will help you remember, other people are doing the same. Walk thoughtfully, without your phone, without music in your ears and engage with your senses. Experience the world around you fully. Identify the sounds and sights and smells and textures and tastes that you cannot name. Chorus: And, you’ll remember the feeling of not be able to … not knowing … that we all encounter before we become skilled. This will help you remember and empathise with what your software users will feel when you deliver that new or changed interface.

All these ways of trying something different: they free up our mind, they help us feel refreshed and ready to learn, so that we can learn more – about the business domain we serve, about the craft of testing, about the technology we are engaging with. And – all the way through I have emphasised the users’ feelings. For a reason: I think UX is an area that is becoming increasingly important, and holds an opportunity for testers to learn new and valuable skills. So – you could increase your technical skills, or your domain knowledge. But perhaps, your might consider increasing your knowledge and skills in UX.

 

AUTHOR: Isabel Evans

Independent quality and testing consultant Isabel Evans has more than thirty years of IT experience in the financial, communications, and software sectors. Her work focuses on quality management, software testing, and user experience (UX). A published author, popular speaker and storyteller at software conferences worldwide, Isabel is a Chartered IT Professional and Fellow of the British Computer Society, and received the 2017 EuroSTAR Testing Excellence Award. In parallel with her consultancy and teaching in industry, Isabel Evans has recently started as a part-time PhD student at the Department of Computer Information Systems, University of Malta, working with Dr Chris Porter and Dr Mark Micallef on research in human factors for Software Testing. Their current project is logged in ResearchGate as ‘HCITest’. Within that, her current research project is to examine human factors around test tools and the automation of testing, in particular, the UX of test tools for testers.

WOMEN TESTERS JANUARY 2018 EDITION